Camilo Correa

Jacques Robin
email: jacques.robin@esiea.fr

Raùl Mazo

Raul Mazo
email: raul.mazo@ensta-bretagne.fr

Camilo Correa Restrepo
email: camilo.correa-restrepo@univ-paris1.fr

Raul Mazo

Raul Mazo

Raul Mazo

Raul Mazo

Generating Constraint Programs for Variability Model Reasoning: A DSL and Solver Agnostic Approach

Keywords: CCS Concepts:, Software and its engineering → Software product lines, Software architectures, • Computing methodologies → Model verification and validation Software Product Lines, Automated Reasoning, Generic Architecture, Configuration Automation

Verifying and configuring large Software Product Lines (SPL) requires automation tools. Current state-of-the-art approaches involve translating Variability Models (VM) into a formalism accepted as input by a constraint solver. There are currently no standards for the Variability Modeling Languages (VML). There is also a variety of constraint solver input languages. This has resulted in a multiplication of ad-hoc architectures and tools specialized for a single pair of VML and solver, fragmenting the SPL community. To overcome this limitation, we propose a novel architecture based on model-driven code generation, where the syntax and semantics of VMLs can be declaratively specified as data, and a standard, humanreadable, formal pivot language is used between the VML and the solver input language. This architecture is the first to be fully generic by being agnostic to both VML and the solver paradigm. To validate the genericity of the approach, we have implemented a prototype tool together with declarative specifications for the syntax and semantics of two different VMLs and two different solver Families. One VML is for classic, static SPL (Feature Model) and the other is for run-time reconfigurable dynamic SPL with soft constraints to be optimized during configuration. The two solver families are Constraint Satisfaction Program (CSP) and Constraint Logic Programming (CLP).

Introduction

Software Product Lines Engineering (SPLE) [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles, and Techniques[END_REF] is a collection of engineering techniques for managing the design, development, and subsequent evolution of large sets of software products that share partially overlapping sets of requirements and reusable software assets implementing them. Considered as one whole, these products form the eponymous Software Product Line (SPL). Crucially, each product in a SPL is a variant that includes a specific subset of the requirements and reusable assets. This variability makes SPLE unique: it needs to be managed across the entire product line to control the quality and consistency of the products. To carry this out, SPLE prescribes the construction, verification and maintenance of an additional software artifact called a Variability Model, that represents the relationships holding among the SPL's variable requirements and the reusable assets implementing them. These models have been used for three main distinct purposes:

• Software Mass Customization [START_REF] Krueger | Easing the transition to software mass customization[END_REF] from a baseline software version with automated variant code generation from reusable artifacts. • Design Space Exploration [START_REF] Liu | Design Space Exploration for Distributed Real-Time[END_REF], i.e., determining which set of design choices best satisfices1 a set of hard (i.e., must have) and soft (i.e., nice to have) requirements. • Context-aware Autonomic Adaptation [START_REF] Lalanda | Autonomic computing: principles, design and implementation[END_REF][START_REF] Weyns | An introduction to self-adaptive systems: A contemporary software engineering perspective[END_REF] through runtime self-reconfiguration. The third purpose involves embarking the VM as a runtime artifact to support re-exploring the design space during operations to find an alternative configuration that restores requirement satisficing following an operational context change that rendered the current configuration inadequate. SPLs for such self-adaptive systems are called Dynamic SPLs (DSPL) [START_REF] Hallsteinsen | Dynamic Software Product Lines[END_REF].

In all three cases, the models support the semi-automatic derivation of correct configurations, i.e., choices of cohesive and consistent requirements that satisfy the business, technical and regulatory constraints captured by the Variability Model. Real-life, industrial SPLs are too large and complex to be manually verified, troubleshooted and correctly configured [START_REF] Mannion | Using First-Order Logic for Product Line Model Validation[END_REF]. To make things worse, these tasks need to be repeated after each evolution of the SPL during its life-cycle that routinely spans over multiple decades [START_REF] Botterweck | Evolution of Software Product Lines[END_REF]. Automated reasoning must thus be used to repeatedly verify, troubleshoot and (re)configure an SPL at initial design-time, evolution-time and even runtime throughout its life-cycle. In most cases, the augmented intelligence [START_REF] Douglas | Augmenting Human Intellect: A Conceptual Framework[END_REF] flavor of automated reasoning is required, in which the reasoning must be explainable to the team of human engineers and operators managing the SPL and that have the final say concerning each configuration or defect correction choice.

Today, there is no accepted standard for SPL Variability Models, so every SPLE automation tool uses its own Domain-Specific Variability Modeling Language (DSVML). However, despite superficial syntactic differences, at the semantic level, most DSVMLs used for Software Mass Customization define cohesive requirement sets, generally called features, and share four key expressive capabilities: SFM1 Organize these features into abstraction and composition hierarchies and associate the lowest level ones with reusable and composable concrete software assets implementing them. SFM2 Distinguish between mandatory features shared by all configurations from optional elements specific to strict configuration space subsets. SFM3 Specify ranges of alternative possibilities for the refinement of a higher-level feature into a set of lowerlevel features. SFM4 Specify simple required co-occurence or exclusion constraints between two features across the abstraction hierarchy.

DSVML providing such expressive capabilities are generally referred to as Simple Feature Models (SFM). Four additional expressive capabilities are provided by DSVML which are often called Extended Feature Models (EFM):

EFM1 Structure features into sets of attributes of various types rather than limiting them to Boolean variables. EFM2 Specify ranges of alternative possible values for those attributes. EFM3 Specify multiplicity constraints on those attributes and on relationships among features. EFM4 Specify complex constraints on the values of attributes of features located anywhere in the abstraction hierarchy.

Whether SFM or EFM, all models used for Software Mass Customization only contain hard constraints that must be collectively consistent and fully satisfied by all valid configurations. In contrast, models used for Design Space Exploration and Autonomic Adaptation also contain soft constraints to satisfice as much as possible rather than necessarily fully; thus their modeling languages need to be semantically more expressive.

A wide variety of approaches have been proposed to implement SPL model verification and model-guided SPL configuration in SPLE automation tools. Just like for Variability Modeling Languages, there is also currently no accepted standard API for such tools. Nevertheless, the overwhelming majority of them include a translator of the DSVML to some logical Knowledge Representation Language (KRL). This allows them to reuse practically scalable Inference Engines (IE) developed over the last 50 years for formal software engineering and artificial intelligence. Four main paradigms of such IEs have been used to automate SPL model verification and model-guided configurations:

• SATisfiability (SAT) solvers [START_REF] Gomes | Satisfiability Solvers[END_REF] and their extensions with Satisfiability Modulo Theories (SMT) [START_REF] De | Satisfiability modulo theories: introduction and applications[END_REF]. • Constraint Satisfaction Problem (CSP) solvers and their extensions for Constraint Optimization Problems (COP) [START_REF] Dechter | Constraint Processing[END_REF]. • Logic Programming (LP) engines and their Constraint LP (CLP) extensions [START_REF] Frühwirth | Essentials of constraint programming[END_REF]. • Description Logic (DL) engines and their semantic web ontology reasoning extensions [START_REF] Baader | Introduction to description logic[END_REF].

Notably, the foundational feature-based SPLE tool FODA used an LP engine [START_REF] Kyo | Feature-Oriented Domain Analysis (FODA) Feasibility Study[END_REF], the original version of VariaMos [START_REF] Team | VariaMos Framework[END_REF] used a CLP engine, FeatureIDE [START_REF] Thüm | FeatureIDE: An Extensible Framework for Feature-Oriented Software Development[END_REF], FlamaPy [START_REF] José | A Python Framework for the Automated Analysis of Feature Models: A First Step to Integrate Community Efforts[END_REF], Splot [START_REF] Mendonca | Software Product Lines Online Tools[END_REF], Glencoe [START_REF] Schmitt | Glencoe-a Tool for Specification, Visualization and Formal Analysis of Product Lines[END_REF], Kernel Haven [START_REF] Kröher | Ker-nelHaven -An Experimentation Workbench for Analyzing Software Product Lines[END_REF] and pure::variants [START_REF] Beuche | Modeling and Building Software Product Lines with Pure::Variants[END_REF], all use a SAT solver, Familiar can use either an SMT or a CSP solver [START_REF] Mathieu Acher | FAMILIAR: A Domain-Specific Language for Large Scale Management of Feature Models[END_REF], COFFEE used a CSP solver [START_REF] Villota | Coffee : A Framework Supporting Expressive Variability Modeling and Flexible Automated Analysis[END_REF] and AUFM used a DL engine [START_REF] Mahdi Noorian | Feature Model Debugging Based on Description Logic Reasoning[END_REF].

Each pair of KRL and IE from these paradigms corresponds to a different trade-off in terms of semantic expressiveness, inference scalability and reasoning explainability. The best KRL for a given SPL reasoning task is thus very much dependent on both the nature of the task and the semantic expressiveness of the DSVML used to model variability [START_REF] Benavides | Automated Analysis of Feature Models 20 Years Later: A Literature Review[END_REF]. Since SPLE is a heavy upfront investment method whose "Return on Investment" takes a fairly long time before becoming tangible [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles, and Techniques[END_REF], SPLE projects have long life cycles. Therefore, both the expressiveness requirements of a DSVML and the automated reasoning tasks to analyze the VM and correctly (re)configure the SPL can evolve significantly during its life cycle.

The main common limitation of the state-of-the-art SPLE automation tools listed above is their ad-hoc architectures that tightly couples a single DSVML with an IE from a given automated reasoning paradigm. This impedes one from making the choice of IE follow in lockstep the evolution of the DSVML and reasoning task requirements at a cost that is low 2 enough to avoid denting the long-term benefits of adopting SPLE.

In an attempt to overcome this severe limitation of current state-of-the-art SPLE tools, we try, in this paper, to answer the following open research question:

How to architect an SPLE automation tool so that IEs from various paradigms can be seamlessly plugged in and out of it at minimal development cost to adapt the tool's reasoning capabilities to the evolution, throughout the SPL's life cycle, of both the semantic expessiveness of the DSVMLs that it supports for variability modeling and the analysis and configuration automation tasks to run on the Variability Model?

Our first research hypothesis to answer this question is that such an architecture must satisfy the following requirements:

REQ1 Support low-cost extension of existing DSVMLs and addition of new DSVMLs. REQ2 Support low-cost addition of new automated reasoning tasks to run on the VM. REQ3 The architecture must be agnostic w.r.t. the logical KRL and IE paradigm used for automated reasoning on the VM, supporting low-cost addition of interoperability with solvers from different paradigms. REQ4 The architecture must be agnostic w.r.t. the DSVML editor tool, accepting the VM as input data exportable from multiple popular editors.

To satisfy these requirements, we propose the following design principles, inspired from Model-Driven Engineering [START_REF] Schmidt | Model-Driven Engineering[END_REF]:

DP1 The concrete and abstract syntaxes of the DSVML should be decoupled from one another. DP2 They both should be declaratively specified as data in a widely used exchange format, rather than hard-coded in the SPLE tool. DP3 The semantics of the DSVML should also be declaratively specified as data in a widely used exchange format encoding a mapping from the abstract syntax elements to expressions in a formal KRL. DP4 The set of reasoning automation tasks to be run on the VM should also be declaratively specified as data in a widely used exchange format, which must furthermore be decoupled from any specific IE KRL. DP5 The many-to-many translation from the multiple DSVMLs to the multiple IE KRLs should be decoupled into a pipeline of N many-to-one transformations to a standard pivot intermediate language followed by M one-to-many transformations from this pivot, to avoid the combinatorially explosive cost of developing and evolving NxM direct DSVML to IE KRL transformations. DP6 This standard pivot language must be easily interpretable by a wide range of stakeholders.

Our second research hypothesis is that REQ1 and REQ4 can be satisfied by the combination of DP1 to DP3, REQ2 can be satisfied by DP4 and REQ3 by that of DP5. In the rest of the paper, we attempt to verify our two hypotheses.

To do so we proceed as follows. In section 2, we start by presenting two SPLE reasoning task examples that we have used as a first step toward validating these hypotheses. While they are small enough to fit in this article, they are purposely representative of very different VM language families used for very different VM purposes. In that section, we also explain how these tasks can be carried out by leveraging, as intermediate pivot language between the two different input DSVML and any logical IE input KRL, the ISO standard for logical IE interoperability CLIF (Common Logic Interchange Format) [START_REF]Information Technology -Common Logic (CL) -A Framework for a Family of Logic-Based Languages[END_REF] following the original proposal of [START_REF] Correa | A Lightweight Method to Define Solver-Agnostic Semantics of Domain Specific Languages for Software Product Line Variability Models[END_REF]. Next, in section 3, we propose a detailed SPLE tool architecture following the design principles DP1 to DP5 listed above. We then discuss the prototype SPLE tool PLEIADES (Product Line Engineering Intelligent Assistant for Defect detection Explanation and Solving) that we (a) implemented to show the practical feasibility of this architecture and (b) tested on the two example tasks presented in section 2. In section 5, we then compare PLEIADES with state-of-the-art SPLE tools. Since none of them aimed to satisfy requirements REQ1 through REQ4, nor explicitly followed design principles DP1 to DP5, this comparison is grounded on various tool versatility criteria which are met by following these principles. In section 6 we discuss the limitations of both the presented architecture and its current implementation in terms of satisfaction of requirements REQ1 to REQ4 and the future work that we intend to carry out to overcome them. Finally in section 7, we conclude by recapitulating the original contributions of the presented research.

Background and Running Examples

To illustrate our approach on concrete examples, we now present two of them. The first concerns a defect detection verification task on an SFM. The second concerns an optimal reconfiguration search for a DSPL that leverages a DSVML specifically designed for that purpose and presented in [START_REF] Sawyer | Using Constraint Programming to Manage Configurations in Self-Adaptive Systems[END_REF]. They thus represent two intentionally distant points in the space of the VM diversity encountered in the literature.

Variability Modeling Languages

2.1.1 Simple Feature Models. In Fig. 1, we present a minimalist SFM example. Its graphical concrete syntax shows features as rectangular vertices in a directed graph and the hierarchical decomposition of features in mandatory and optional sub-features as edges ending with a filled or empty circle (respectively). This decomposition forms a tree. Edges ending with an arrow represent exclusion or co-occurence Verification reasoning tasks on such VMs generally search for defects, which were comprehensively categorized in [START_REF] Benavides | Automated Analysis of Feature Models 20 Years Later: A Literature Review[END_REF].

In figure 1 we show a SFM which contains two dead feature defects. A feature is said to be "dead" if, although it is present in the VM, it can never be selected in any valid configuration due to contextual constraints relating to other features. Following principle DP4, the text beside the SFM diagram is the declarative specification in JSON [START_REF] Crockford | The Application/Json Media Type for JavaScript Object Notation (JSON)[END_REF] of the search for dead feature defects reasoning task. The one-way widgets on the top-left features F4 and F5 visualize the result of this task. It detects that F4 and F5 are dead. F4 is dead as excluded by the selection of F3, which must be selected in all configurations as a mandatory descendant of the top-level feature F1. F5 is also dead as a child of F4, a dead feature.

Sawyer et al.'s DSPL VML.

In Fig. 2, we present a second example of reasoning task. This time it is a search for an optimal reconfiguration leveraging the context-aware DPSL VM of a flood early-warning system. The vocabulary of concepts and relations of this DSPL DSVML [START_REF] Sawyer | Using Constraint Programming to Manage Configurations in Self-Adaptive Systems[END_REF] is much more extensive than that of SFMs used in the first example. They are the following:

• Hard goals, shown as green parallelograms, determine the functional requirements of the system and are analogous to features in feature models. Hard goals are structured in a decomposition hierarchy where higher level ones can be achieved by achieving all their lower level components. • Soft Goals, shown as blue clouds, encode the nonfunctional requirements of the system and can be satisficed on a 0 to 4 scale, which is encoded as "--", "-", "=", "+", "++" in the model. They are themselves structured into a decomposition hierarchy. The level of satisficing of a higher level soft goal in this hierarchy is the average of the satisficing level of its lower level components.

• Context Variables, shown in blue rectangles on the right, encode the state of the system's context among symbolic value enumerations. • Operationalizations, shown as gray hexagons, are concrete software assets that can implement the hard goals. • Bundles, shown as white circles, contain integer range expressions for the multiplicity of the operationalizations that can implement a hard goal. • Claims, shown as white trapezoids, express the level to which operationalizations satisfy soft Goals as a function of which has been selected. • Soft Influences, shown as grey ellipses, relate the context variables to the soft goals, and determine the required level of satisfaction when the given state is determined by the context, e.g., if CV1 is "Low", the required level of satisfaction of SG5 is "++".

The VM in Fig. 2 models the various redundant means of communications available to transfer sensor data in a distributed autonomic flood early-warning system. It also supports determining which set of means represent the best trade-off between energy consumption, fault tolerance and prediction accuracy in various flood risk contexts.

The contrast between the VM of figures 1 and 2 highlights the great diversity of DSVMLs and the reasoning tasks to carry out on them.

CLIF and Model Transformation

The language used to encode the semantics of the different variability modeling languages, CLIF, is part of a larger family of (logic) languages "designed for use in the representation and interchange of information and data among [...] computer systems" [START_REF]Information Technology -Common Logic (CL) -A Framework for a Family of Logic-Based Languages[END_REF] named Common Logic. CLIF has not been created ex nihilo, but rather, is a simplified descendant of the Knowledge Interchange Format Version 3 [START_REF] Michael | Knowledge Interchange Format-Version 3[END_REF] KRL. It uses a LISP [START_REF] Mccarthy | Recursive functions of symbolic expressions and their computation by machine, part I[END_REF] derived syntax to represent logical expressions. For example (𝑎 ∧ 𝑏) would be rendered as (and a b) where 𝑎 and 𝑏 can also be nested subexpressions. Figure 3 exemplifies the overall mechanism underlying the architecture. Given a fragment of a diagram and the corresponding semantics specification given as a JSON [START_REF] Crockford | The Application/Json Media Type for JavaScript Object Notation (JSON)[END_REF] object, our architecture would allow then for the construction of the human-and machine-readable semantics in CLIF. It would then allow one to target different solvers based purely on the CLIF semantics. The object, then, of this article, is to provide a detailed account of how this is achieved and how this architecture overcomes the key limitation of ad-hoc architectures and tools specialized for a single pair of variability modeling language and solver.

Reasoning Tasks

One of the primary goals of our approach is to allow practitioners to perform reasoning tasks on their models through a simple specification mechanism to avoid the need to understand the particular details of the underlying implementation or how to perform meta-programming, for example. Both of our running examples (Figs. 1 and2) include a JSON object that encodes the reasoning request that is to be made about the model. For the Feature Model, we perform an iterative reasoning task that corresponds to searching for dead features [START_REF] Benavides | Automated Analysis of Feature Models 20 Years Later: A Literature Review[END_REF]. This object informs the backend of the operations required for the reasoning task. The first attribute "operation" determines what type of problem will be solved( e.g. a satisfiability check, finding a concrete solution, or solving an optimization problem). The second, "solver", tells the system which runtime to utilize for the query.

The two attributes above are always required and set the main parameters of the system. The (optional) attribute "iter-ate_over" allows the user to perform a succession of queries on the model. Its value is a list of objects that determine how the elements will be modified in each run of the iteration. In the concrete case of Fig. 1, it will iterate over all "Features", setting their associated variable to 1, i.e., selected. The result of the reasoning task is then overlayed on the model as a red prohibition/one way sign showing that those two features are not selectable in any valid configuration.

The other attributes depicted in Fig. 2, "optimization_target" and "optimization_direction" serve a different purpose. They parametrize the search for optimal solutions where the optimization expression is a variable in the desired direction, e.g. maximizing it. At the very bottom of Fig. 2 are the textual constraints that complement the graphical model and permit the construction of the optimization problem. They are written in CLIF right alongside the Graphical models and are part of them, exhibiting our support for hybrid textual/graphical models. The key takeaway of these constraints is that they define a set of equations related to the model elements and ultimately allow one to equate the optimization variable to a complex expression. In this case, our objective variable is ObjValue which is defined as a weighted (shown below) sum over the satisfaction level of claims, soft influences and soft goals as defined above. Since we seek to simulate the behaviour of a context-aware Dynamic SPL, we also provide It is the fact that the reasoning request comes with declarative specifications of the abstract syntax and formal semantics of the VML in which the VM is modeled that allows VM reasoning services following this PLEIADES architecture to be VML agnostic. And it is also the fact that the VML's formal semantics are expressed in CLIF, a standard for logical inference engine interoperability, whose expressiveness subsumes that of all constraint solvers widely used for SPLE automated reasoning, that allows VM reasoning services following the PLEIADES architecture to be solver agnostic.

In addition to its public answer operation endpoint, the SPLE Reasoning Web Service also encapsulates three pri- The third is the Generic2SpecificCSP Translator which translates this solver-agnostic representation of a CSP into one accepted as input by the solver chosen in the Reasoning Task Specification. This component is also used to translate the solver output back in the other direction into a Solver Agnostic CSP Solution. Note that due to its purely declarative, relational and intentional nature, a CSP and its solution can be uniformly represented by the same three data types: Constraint, Variable and Domain. A CSP solution is merely a CSP with less constraints and more variables with domains reduced to a singleton [START_REF] Dechter | Constraint Processing[END_REF]. As shown at the bottom-left of 4, the Reasoning Response data type associates the value of those singleton domains with the VM element represented by the CSP variable whose domain has been reduced to a single value. That value is injected in the Reasoning Response that is then serialized and sent back to the client VM editor.

The fourth is the Solver Controller, the most complex component of the architecture. Understanding its role requires realizing that many VM verification tasks cannot be directly executed through a single call to a constraint solver. They rather require meta-programming an iteration over the VM elements in which, at each step, the initial CSP representation of the VM is modified by adding or removing some constraints and the solver is called on this modified CSP [START_REF] Salinesi | Defects in Product Line Models and How to Identify Them[END_REF].

Depending on the result returned by the solver at each step, the iteration proceeds to the next step or stops. During the iteration, the results of each solver call are accumulated in a set. The IterativeBridgeCall operation of the Solver Controller implements this iteration. It returns a set of Solver Output data type instances.

As an example of this need for iteration, let us consider the search for so-called dead features in a feature model: i.e., those that cannot be selected in any valid configuration. The declarative specification of this task as a JSON object is shown beside the model of Fig. 3. It defines a strategy for the Solver Controller to find dead features in the VM [START_REF] Benavides | Automated Analysis of Feature Models 20 Years Later: A Literature Review[END_REF]. It consists of iterating over the VM features, and, for each of them, adding to the CSP, representing the VM, the new constraint that this feature is selected ("with_value": 1) and checking whether this makes the CSP unsatisfiable. To be able to repeatedly call the requested solver, the Solver Controller encapsulates a set of bridges, one for each solver to be integrated in the SPLE Reasoning Web Service. The role of each bridge is to start a new instance of the solver, call its API to pass the CSP to solve at each iteration of the IterativeBridgeCall operation and pass the result of each such call back to the Solver Controller.

The control flow of the top-level answer operation of the root SPLE Reasoning Web Service component is modeled by the UML activity diagram of Fig. 5. It shows the input and output parameter of the answer and in what order this operation internally calls the other operations of the architecture. It also shows the data structures that these calls exchange as arguments. At a high-level, this activity is divided in three main phases. The first is the pipeline on the left side of Fig. 5 that progressively transform the Serialized Reasoning Request received from the VM web client editor into an input for the solver (Solver Input) chosen as a property of the Serialized Reasoning Request. The second is the loop of calls to the solver made by the Solver Controller shown in the top right quadrant of Fig. 5. The third and last phase is another pipeline, shown in the bottom right quadrant of Fig. 5, that translates the solver outputs accumulated during the iteration into a Serialized Reasoning Response to send back to the web client editor.

Revisiting Requirements and Design Principles

In light of the requirements and design principles we've outlined in the Introduction, it is important to highlight how our architecture reflects these principles and above all meets the requirements. Design principles DP1 and DP2 are reflected first in the clear separation of the data types shown in Fig. 4, where every concern has its own dedicated data structure (and hence treatment in the function signatures in the components). They are also reflected in the envisioned operation of the architecture shown in Fig. 5, where they are taken as user-specified specifications (as part of the Reasoning Request) instead of being hard-coded into the architecture. The same is also true for Principle DP3 when it comes to the specification of the semantics. As for the widely used exchange format, JSON [START_REF] Crockford | The Application/Json Media Type for JavaScript Object Notation (JSON)[END_REF] is well supported and certainly widely used. In addition, concerning the enconding into a formal KRL, this is covered by the translation into CLIF based on the semantics specification, allowing virtually any DSVML with first order semantics to be translated into it. Considering that we have met these principles with our architecture, this would cover requirements REQ1 and REQ3. Design Principle DP4 is handled in much the same way as DP2, wherein JSON is again used to allow the user to tailor his specification for his reasoning task with no need to manually hard-code it in the system, as described in Section 2.3. This would then cover requirement REQ2. Principle DP5 is, firstly, contingent on the earlier principles being met, and, second, is covered by the VM transformation outlined in Fig. 5. Indeed, a significant portion of the architecture is dedicated to enabling this translation, as evidenced by both the component solely dedicated to it (VM2CLIF Translator shown in Fig. 4) and the subsequent components that are dedicated to the treatment of the generated CLIF to arrive at the solvers' input. To be clear, what this achieves is to completely decouple integrating DSVMLs and IEs into the architecture by linking both through CLIF and meeting requirement REQ3.

Design principle DP6 stands alone as it is tied to a consideration that is not purely functional, as are the requirements, but rather, it is tied to the very nature of the architecture, that is, easing the use and analysis of VMs by different stakeholders without needing to dive into the details of the specific underlying solvers. This also aids users to construct (and debug) new DSVMLs as they can examine the semantics in CLIF of their models independent of any particular solving technology.

Prototype

To validate our architecture and its feasibility for constructing a reasoning platform that covers all of the requirements outlined above, we have implemented a prototype in Python based on this architecture. Fig. 6 shows how the prototype specializes the components outlined in the architecture. This prototype's internal component structure closely reflects the architecture. A key element of our prototype is the integration of multiple solvers from different solver families: SWI Prolog [START_REF] Wielemaker | SWI-Prolog[END_REF] and MiniZinc [START_REF] Nethercote | MiniZinc: Towards a Standard CP Modelling Language[END_REF] (which allows us to target multiple Constraint and Integer Programming Solver libraries). To implement the pivot language, we wrote our own "CLIF Parser" with the TextX library [START_REF] Dejanović | TextX: A Python tool for Domain-Specific Languages implementation[END_REF] based on the grammar described in the latest version of the ISO standard [START_REF]Information Technology -Common Logic (CL) -A Framework for a Family of Logic-Based Languages[END_REF].

We demonstrate our approach within an open-source tool called VariaMos [START_REF] Team | VariaMos Framework[END_REF] for all visualization concerns, and for the specification of the concrete visual syntax, the abstract syntax and the formal semantics in JSON format. The examples shown in Figs. 1 and2, and the results shown, were all done within this tool. We have modified the tool so that the reasoning requests can be made directly from it by specifying the address of the reasoning web service. We have made the prototype available on GitHub as an open source tool2 .

5 Related Work

State of the art VM tools

In this section, we examine state-of-the-art tools with aims similar to ours that are currently available, mature and well documented as reported by a recent survey [START_REF] José | Empirical Analysis of the Tool Support for Software Product Lines[END_REF], with the addition of some others that we consider particularly relevant. The tools we've identified are: Feature IDE [START_REF] Thüm | FeatureIDE: An Extensible Framework for Feature-Oriented Software Development[END_REF], its related project FAMILIAR [START_REF] Mathieu Acher | FAMILIAR: A Domain-Specific Language for Large Scale Management of Feature Models[END_REF], FlamaPy [START_REF] José | A Python Framework for the Automated Analysis of Feature Models: A First Step to Integrate Community Efforts[END_REF], the COFFEE Framework [START_REF] Villota | Coffee : A Framework Supporting Expressive Variability Modeling and Flexible Automated Analysis[END_REF], SPLOT [START_REF] Mendonca | Software Product Lines Online Tools[END_REF], Glencoe [START_REF] Schmitt | Glencoe-a Tool for Specification, Visualization and Formal Analysis of Product Lines[END_REF], ClaferTools [START_REF] Antkiewicz | Clafer Tools for Product Line Engineering[END_REF], Kernel Haven [START_REF] Kröher | Ker-nelHaven -An Experimentation Workbench for Analyzing Software Product Lines[END_REF], pure::variants [START_REF] Beuche | Modeling and Building Software Product Lines with Pure::Variants[END_REF], and Gears [START_REF] Krueger | Feature-Based Systems and Software Product Line Engineering with Gears from BigLever[END_REF]. Though most of these tools also cover other use-cases such as modeling, visualization or code generation, we focus on the verification pipelines.

In Table 1 we present an analysis of the characteristics of these tools. We divide our analysis into five main dimensions:

• First, we examine the different approaches from a purely architectural perspective. Of interest are the following characteristics: whether the approaches are well documented with standard modeling languages like the UML; the detail and granularity of the models as a function of the quantity of elements they contain; whether the models are structural, behavioral, or both; and, finally, what general architectural pattern is applied for their tool. We also analyze the interaction with model editors as part of their architectural patterns related to requirement REQ4. • Next, we analyze the support their respective approaches have for the diversity of variability modeling languages. This includes the treatment of integers, and first-order constraints among the elements of a variability model. Two other key factors are whether the languages support concepts of context-aware dynamic SPLs and whether the semantics of the variability models are expressed in a human-interpretable language, or whether they are implicit as part of the tools' internal pipelines. This is related to requirement REQ1 and the types of languages supported by competing tools.

• We analyze in a similar way the support for different solver features among the tools. We must, nevertheless, highlight the fact that our analysis of these features relates to the capabilities of the solvers themselves and not necessarily as they are used within the tool. For instance, though Fea-tureIDE has a mechanism to handle numeric attributes in their models, and their solving backend, a modified SAT4J [START_REF] Le | The Sat4j Library[END_REF], it cannot run automated verification or configuration tasks on these aspects of the models. Among the characteristics we examine we find the treatment of integer domains; whether there are first order constraints; whether optimization can be run in addition to pure solving; whether there are meta-programming mechanisms to control the behavior of the solvers; and whether the solvers can present series of solutions without restarting the search space exploration from scratch. This is tied to our requirement REQ3 and the backend support offered by the different tools. • We also analyze the support for declarative specifications of the reasoning tasks to be performed and whether this is declarative and user-specifiable. This is related to requirement REQ2. • Finally, we analyze the use of internationally recognized standards as part of the proposals as part of our analysis tied to our design principle DP6.

From this one can conclude that all of the approaches cited follow an approach of transforming the variability model into an input for a constraint solver. (It is worth repeating that here the term "constraint" is to be understood in its general sense, thus including other families such as SAT solvers, SMT solvers, etc.) We, therefore, have integrated these ideas and seek to generalize them to provide a truly generic architecture to perform these tasks and, moreover, lift the veil on the details of how these transformations are performed. Notably, the characteristics of the competing approaches tied in directly to our formulation of the requirements for the architecture.

Domain Specific Languages in SPL

A key feature of our architecture is its agnosticity w.r.t. DSVMLs; while one can make use of Feature Models and all its derivatives, the use of DSLs as alternative VMLs has been well attested in the literature, whose fit as alternatives to feature models is highlighted in [START_REF] Bryant | Domain-Specific Software Engineering[END_REF], with some of the first proposals aiming to integrate textual DSVMLs directly into artefacts [START_REF] Batory | Achieving Extensibility through Product-Lines and Domain-Specific Languages: A Case Study[END_REF]. This was further explored in a survey article [START_REF] Voelter | Product Line Engineering Using Domain-Specific Languages[END_REF] where all the possible combinations of DSLs and Feature Models (and variations thereof) were explored, concluding that they may coexist to different degrees in a project, or that one may outright replace the VM with a DSVML model. Though their focus was primarily on textual-based DSLs, other authors have found it important to construct Graphical DSL based proposals. In this vein, the work of Demuth et al. [START_REF] Demuth | Cross-Layer Modeler: A Tool for Flexible Multilevel Modeling with Consistency Checking[END_REF] is particularily important. They proposed a tool that would allow one to construct DSLs and their meta-models all as part of a single graphical tool. This allows the generation of artefacts from the models since all of their elements are ultimately mapped to a restricted subset of UML, though the analysis capabilities were quite limited.

There have been other approaches to use and integrate Graphical DSLs for Variability Modeling, such as [START_REF] Tokumoto | Product Line Development Using Multiple Domain Specific Languages in Embedded Systems[END_REF], presenting a case study of a DSL for creating variants of robot software. Several approaches hinged on creating custom UML profiles [START_REF] José | A Domain Specific Language to Generate Web Applications[END_REF][START_REF] Ziadi | Towards a UML Profile for Software Product Lines[END_REF] to aid in the automated generation of websites. A large set of industrial case studies where Graphical DSLs for managing variability were employed has also been presented [START_REF] Tolvanen | How Domain-Specific Modeling Languages Address Variability in Product Line Development: Investigation of 23 Cases[END_REF], highlighting the use of a commercial DSL development tool [START_REF] Tolvanen | Describing Variability with Domain-Specific Languages and Models[END_REF]. This tool has also been used for creating a graphical DSL for an automatic performance test generation approach based on a product line approach [START_REF] Bernardino | Canopus: A Domain-Specific Language for Modeling Performance Testing[END_REF].

These approaches, however, are all held back by one fundamental limitation which is the need for an ad-hoc implementation to construct a formal representation (if they do so at all), which does not allow one to tailor the underlying reasoning to the particular characteristics of the DSL, as we have done with Sawyer et al.'s language [START_REF] Sawyer | Using Constraint Programming to Manage Configurations in Self-Adaptive Systems[END_REF], which, though originally a graphical DSL for DPSL without any code generation capabilities, we have brought directly into our approach as a key demonstrator of its capabilities.

Evaluation and Discussion

Requirements coverage

Given the novelty of our approach, and the mechanism employed, we begin first with an analysis of the coverage of our requirements by our approach. This analysis is informed both by our analysis of the architecture in Section 3 and the lessons learned from the prototype implementation.

REQ1 Support low-cost extension of existing DSVMLs and addition of new DSVMLs: Our approach is specifically designed to use a declarative specification of the modeling languages, and, within reason, any VML could be handled by our approach. We illustrate this variety by implementing and testing our implementation with two languages that differ greatly syntactically and semantically. REQ2 Support low-cost addition of new automated reasoning tasks to run on the VM: Our architecture is designed to handle precisely this, with a view on exposing a large variety of operations to the user so that as new DSVMLs are created, it is simple to create the corresponding reasoning tasks. As a consequence, the prototype reflects this and has been demonstrated to be robust enough to support very different reasoning tasks through the same mechanism. REQ3 The architecture must be agnostic w.r.t. the logical KRL and IE paradigm used for automated reasoning on the VM, supporting low-cost addition of interoperability with solvers from different paradigms: Given that multi-solver support has been a key design goal for the architecture, this is covered by the Nto-one-to-M translation approach through CLIF, so that there is no hard-coded bias towards any IE and allowing easy integration of new IEs. REQ4 The architecture must be agnostic w.r.t. the DSVML editor tool, accepting the VM as input data exportable from multiple popular editors: Our architecture seeks to be as independent as possible from any particular modeling tool by relying on the declarative specifications of the languages to perform all processing instead of relying on a particular set of technologies.

Our prototype implementation has been developed and tested initially on the VariaMos [START_REF] Team | VariaMos Framework[END_REF] modeling framework which has been modified to allow for the declarative specifications needed for the prototype. Further integration with other tools will require determining how to add this functionality to them.

Limitations of the architecture and prototype

The architecture has one important omission that is worth discussing. The architecture has an underlying assumption that the models are graphical models with possibly a portion of the model being text (constraints in CLIF). This has an important effect on the abstract syntax and therefore interpretation of the models: it is not yet clear how to deal with purely textual VMLs that don't use a well-known data interchange format like JSON. The reason for this is simple. Textual VMLs with their own grammar and structure would need their parser to be integrated into the architecture. In addition to this, a more abstract, common representation of both the hybrid and textual models would need to be constructed such that it would serve the base for constructing the semantics. Nevertheless, this seems possible with some modifications to the architecture, with, in particular, a more capable input management system. The prototype we present is limited in some key ways. We have developed the prototype utilizing the VariaMos modeling environment, which has the underlying assumption that all the graphical models are directed graphs where the nodes can be typed and have attributes. This is sufficiently general for the DSLs we've observed in the literature, though one could imagine DSLs that use a more complex underlying structure. We seek nevertheless to combat this limitation through the abstract syntax specification mechanism which has only been partially implemented in the current prototype, given the limitation outlined in the previous paragraph.

Threats to validity

In addition to the limitations above, our work is subject to internal and external threats to validity. In terms of Internal Validity our primary concern is how feasible our architecture is. To counter this threat, we have created a prototype that covers as closely as possible the proposed architecture. The converse of this is the correctness of the prototype, that we've endeavored to test extensively. We have sought, therefore, to demonstrate its capacity to provide the functionality envisioned in the architecture. Another further threat is tied to the correctness of our architectural design. We have utilized a standard and well-understood modeling language (UML) for its definition and have sought to collect feedback from colleagues and users of the tool, both from a developer's perspective and from an end-user perspective. Now, in terms of external validity, we recognize that we can't provide guarantees on the exhaustiveness of the tools surveyed, more recent efforts that the authors are unaware of might have been proposed in the meantime. Nevertheless, we have sought to base our overview on a recent and well sourced survey of these very tools. An additional threat concerns our ability to manage purely textual languages within the architecture, as mentioned in the previous section.

To combat this we have designed a flexible and modular architecture capable of being modified in this direction.

Future Work

To overcome our limitations, work continues in several directions: first, textual languages, beginning with UVL, are being integrated; second, work continues on enlarging the set of reasoning requests possible, including having a more fine grained control over the variables used for iteration; third, more output languages, beginning with the Z3 SMT solver, are being integrated and tested, to further guarantee the robustness of CLIF as pivot representation; and, finally, work is being done on adding an incremental solving component (as opposed to iterative) in order to make interactions far more efficient. This will all imply minor refinements of the architecture, though we believe the core will remain unchanged.

Another future work we envision is to treat the architecture itself as an SPL, such that we could create fully configurable distributions for particular needs, i.e. include commercial solvers if the licenses are present, and, more importantly, give a larger freedom on the query formulation. We see value in this direction because the decision system for DSPLs can be modeled and then exported for whatever solver is supported, or even combinations of solvers, which could enable portfolio [START_REF] Amadini | SUNNY-CP: a sequential CP portfolio solver[END_REF] constraint solving using multiple engines.

Conclusion

In this paper, we have presented an innovative software architecture to provide automated reasoning for SPLE. As we have seen in section 5, its main contribution is to be the first proposal focused on being agnostic with respect to both the VML used to model variability, and the constraint solving paradigm used to implement the reasoning. Such agnosticism allows fully decoupling the VM and SPL asset editing tools from the automated reasoning tools. We have put forward four requirements for an architecture to achieve such agnosticism. We then have presented fairly detailed structural and behavioral models for the architecture and discussed why it satisfies those requirements. Its key ideas are (a) to avoid combinatorial explosion of components by using a pivot standard semantic language and (b) pass as parameters declarative specifications of (i) the abstract syntax and semantics of the VML used by the VM to analyze and (ii) the analysis task itself.

We have validated this architecture by quickly refining and instantiating these models allowing for four distinct SPLE reasoning pipelines already available in our PLEIADES framework prototype. Each one combines any of two VML languages, respectively feature models and a context-aware dynamic SPL VML, with solvers from two logical reasoning paradigms, respectively CLP, through libraries of SWI-Prolog, and CSP, through the CSP solver integration layer MiniZinc. We hope that our demonstration of the feasibility of VML and solver agnostic SPLE reasoning services together with the simplicity of instantiating the PLEIADES architecture we propose into a working implementation, reusing various VML and solvers, will foster more reuse of third party SPL model editors and third party solvers in the SPLE community.

Figure 1 .

 1 Figure 1. First part of our running example with a synthetic Feature Model. The query specifying the iterative search for dead features in the model is beside the model.

Figure 2 .

 2 Figure 2. Second part of our running example with a model using Sawyer et al.'s DSPL VML. This model reproduces the original example from the paper[START_REF] Sawyer | Using Constraint Programming to Manage Configurations in Self-Adaptive Systems[END_REF] for a flood early-warning system. As with our other example, in addition to a reasoning query to solve (on the bottom right), this time, an optimization problem to find an optimal configuration whose additional constraints are shown below the model (bottom left).

Figure 3 .

 3 Figure 3. Concrete examples of translation using the translation rules specification for Feature Models (top) and Sawyer et al. 's DSPL Variability Modeling Language (bottom).

Figure 4 .

 4 Figure 4. High-level components and data types of the PLEIADES architecture

  vate operations: one to deserialize the reasoning request JSON string into an instance of the Reasoning Request data type, one to generate the instance of the Reasoning Response data type from the result returned by the solver called to answer the Reasoning Request in a solver agnostic format and one to serialize this Reasoning Response data type instance into a JSON string. This top-level component also has access to the operations of its nested components. Let us now review them in top-tobottom order as depicted in Fig. 4. The first is the VM2CLIF Translator which translates the VM data structure contained in the Reasoning Request data structure into a CLIF text by simultaneously leveraging the VM syntax and semantic specifications that accompany the VM in the Reasoning Request. The second is the CLIF2GenericCSP Translator which translates the CLIF text representing the semantics of the VM into a semantically equivalent solver-agnostic CSP representation of the VM. As shown at the top right of Fig.4, this representation is simply a set of constraints relating variables, each one associated with its domain of possible values. This translation occurs in two steps. The first is to parse the CLIF text into an Abstract Syntactic Tree (AST) and the second is to generate, from this AST, the constraints, variables and domain data types of the solver-agnostic CSP.

Figure 5 .

 5 Figure 5. Activity diagram detailing the operation of our achitecture.

Figure 6 .

 6 Figure 6. Current PLEIADES prototype instantiating the generic architecture

1 )

 1 FeatureIDE; (2) FlamaPy; (3) FAMILIAR; (4) COFFEE; (5) Kernel Haven; (6) SPLOT; (7) Glencoe; (8) ClaferTools; (9) Pure::Variants; (10) Gears; (11) Our Approach Architecural Patterns: A Java API + Eclipse Plugin; B CLI + Python API (Plugin-Based); C CLI + Java API + Eclipse Plugin; D 3-Layered Web Service; E 3 Layered Monolith with Plugin System; F Client/Server (With no further details); G Haskell API/Web Server + Web Client; H IDE Plugins (With no further details); I Multi Layer Python API/Web Server + Pivot Language Legend: Y -Yes; N -No; P -Partial Fulfillment; ? -Unknown/Unclear;

Table 1 .

 1 GPCE, October 22-27, 2023, Cascais, Portugal Camilo Correa Restrepo, Jacques Robin, and Raul Mazo Characteristics of State of the Art Tools

	Tools

Satisfice is a portmanteau word derived from satisf ying and suffice, conveying satisfaction to a sufficent extent rather than necessarily completely. 1

https://github.com/ccr185/semantic_translator. The use manual is in the repository's wiki page: https://github.com/ccr185/semantic_translator/wiki


Maud Fagny

Véronique Jamilloux

Johann Joets

Clémentine Vitte

The role of transposable elements on gene expression regulation in maize and its response to drought

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Material & Methods

Genetic material F331

(2.2 Gb)

F4

(2.1 Gb)

F2

(2.1 Gb)

Gaspe

(2.1 Gb)

EA1197

(2.3 Gb)

Background

Transposable elements (TEs) are major constituents of plant genomes and contribute to their dynamics and evolution. Existing softwares packaging tools using TE structural features detection and repetitiveness approaches have proven useful for TE annotation of small genomes. Attempts have been made to adapt them for large genomes analysis (Jamilloux et al., 2016 -Proceedings of the IEEE). However, this remains challenging, mainly due to the amount of genomic data to analyze and to the structural complexity of these genomes. In particular, tools based on repetitiveness can be run only on a subset of the genome because of the required amount of memory and computation times. Tools based on structural features have been successfully applied on wheat (Wicker et al., 2018 -Genome Biology) and maize (Anderson et al., 2019 -bioRχiv). However, these studies were based on a succession of in-house scripts, and no pipeline has emerged so far to annotate all TE classes in large genomes. Consequently, while half of angiosperm species have a genome size above 1.6 Gb (Pellicer et al., 2018 -Genes), only a handful of large plant genomes have been annotated so far. To better characterize the potential role of TEs in maize local adaptation, we aim at characterizing TE polymorphisms in seven maize inbred lines of contrasted origins. With its 2.1 Gb genome, we use maize as a model for TE annotation of an average angiosperm genome.

Table 1: Comparison of different de novo TE annotation approaches

• Structural-based tools are relatively fast to run on large genomes, but have high false-positive rates and necessitate additional filtering steps.

• Repeats-based tools have a lower false-positive rate, but are slow and must be run on a subset of the genome (<300Mb), hampering the detection of low copy-number TEs, which may play an important role in adaptation.

Test of de novo TE annotation tools on the B73 genome

Conclusions

New pipeline based on structural features

Modified integrated pipelines

• Modify data storage structures

• Improve memory usage for repetitiveness-based tools

  De novo TE annotation** Structural features + TE-specific genes (TIRs, LTRs, gag, pol, Tase, RPA, …) + TE Clustering and redundancy removal (by sequence similarity 80-80-80) Repetitiveness (all-against-all alignment of the genome) + TE Classification (by annotation of TE-specific features) approaches shown here are built to de novo annotate TEs on assembled genome sequences. Other approaches exist to detect TEs from unmapped reads.

Finding

  the right accuracy/computing time balance to de novo annotate TEs in large plant genomes is challenging. A few softwares exist that integrate both structure-based and repetitiveness-based tools, such as REPET-Tedenovo (Quesneville et al., 2015 -PLoS Comp Bio) or PiRATE (Berthelier et al., 2018 -BMC Genomics). But their application to large genomes is hampered by the long computation time (up to months), the high amount of memory necessary to run the repetitiveness-based tools on the whole genome, and the absence of filtering steps to filter out the false positives generated by structural features-based tools.

Northern Flint Gaspesian Flint Corn Belt Dents Tropical European Flint *Maize reference genome -not sequenced by us Optimizing the de novo annotation of transposable elements in large, TE-rich genomes Maud Fagny

  1 , Véronique Jamilloux 2 , Johann Joets 1 , Clémentine Vitte 1 1 Génomique Quantitative et Evolution -Le Moulon, INRA, Université Paris-Saclay, CNRS, AgroParisTech, Université Paris-Sud, Gif-sur-Yvette, France. 2 Unité de recherche Génomique Info, INRA, Versailles, France

B73* (2.1 Gb) F252 (2.1 Gb) MBS847 (2.2 Gb)

All genomes Independency from TE database

		Structural features	Repetitiveness	Similarity
		LTRharvest, TEA,
	Examples	detectMITE, SINE-finder,	REPET-TEdenovo	RepeatMasker,
	tested	HelitronScanner	(RepeatScout,	REPET-TEannot
	(not tested)	(SINE_scan, MGEScan,	RepeatModeler)	(TE-HMMER)
		LTR_retriever, …)
				Future directions

• Add tunable filters to clean up structure-based results


Factors influencing adherence to secondary prevention medication after ischemic stroke: a prospective population-based cohort study in Rhône area of France

Factors influencing adherence to secondary prevention medication after ischemic stroke: a prospective population-based cohort study in Rhône area of France

Results

 Among the 752 patients with acute IS, 254 patients participated to the phone survey (98 died before 3 months, 115 took medication with help and 285 where lost of follow-up).  Characteristics of patients and IS management were compared between adherence group (table 1).

Background and aims

Adherence to secondary prevention medication is important among ischemic stroke (IS) patients to reduce the risk of recurrence. We aimed to identify factors associated with medication adherence among IS patients taking their medication alone.

Methods

Conclusion

Aging and calling EMS tended to be associated with a higher adherence. Surprisingly, having a history of stroke/TIA and being professionally active tended to be associated with a decreased adherence. These results will be further investigated in a larger cohort with multivariate analyses.

  M. Viprey 1,2 , C. Fokoun-Matchikou 1 , A. Termoz 1,2 , J. Haesebaert 1,2 , M. Chakir 1 , C. Della Vecchia 2 , O. Tassa 1 , K. Tazarourte 2,3 , N. Nighoghossian 4 , S. Cakmak 5 , S. Meyran 6 , B. Ducreux 7 , C. Pidoux 7 , T. Bony 8 , M. Douplat 8 , V. Potinet 8 , A. Sigal 9 , L. Derex 2,4 , A.M. Schott 1,2 1 Hospices Civils of Lyon, Public Health Department, Lyon, France; 2 University of Lyon, University Claude Bernard Lyon 1 -HESPER EA 7425, Lyon, France; 3 Hospices Civils of Lyon, Emergency Department -Hôpital Edouard Herriot, Lyon, France; 4 Hospices Civils of Lyon, Department of Stroke Medicine, Bron, France; 5 Hôpital Nord Ouest, Department of Stroke Medicine, Villefranche-sur-Saône, France; 6 Hôpital St Joseph St Luc, Emergency Department, Lyon, France; 7 Hôpital Nord Ouest, Emergency Department, Villefranche-sur-Saône, France; 8 Hospices Civils of Lyon, Emergency Department -Centre Hospitalier Lyon Sud, Pierre Bénite, France; 9 Hospices Civils of Lyon, Emergency Department -Hôpital Croix Rousse, Lyon, France

Table 1 :

 1 Characteristics of patients and Ischemic Stroke management according to adherence group

	Morisky < 6 (N = 21)	6 ≤ Morisky < 8 (N = 88)	Morisky = 8 (N = 145)	p

4th European Stroke Organisation Conference -16-18 May, 2018 -Gothenburg, Sweden