I currently perform my research in the CRIStAL lab of the University Lille 1. I am also member of INRIA Lille Nord Europe. I joined the RMoD team in 2012 (after 6 years in the Dart team). My current research interests concern analysis and reengineering of complex legacy systems. I defended my HDR: "Metamodelisation to support Test and Evolution" in June 2016.

Co-Evolution of Database and Program Databases (DB) are used by programs that can be internal or external to the DBMS. DB schema can be very complex, more over when they integrate views, triggers and stored procedures. Thus, when one element of the schema (table, column, view, procedures,...) evolves it may have an impact on lot other ones. Existing tools do not provide any help to study this impact and suggest other evolutions to maintain the DB in a consistent state. We adapt the existing methods of software maintenance to databases. First results are pretty promising.

Refactoring from examples Software continously evolve. However, most of these evolutions are manually performed even if they are repetitive. Based on a first evolution, we define like a macro that is automatically generalised to be applied in lot of other places getting the same properties. We also help the programmer to determine, in a context of restructuration, what is the next refactoring to apply. Indeed, when a class is moved to another package, whatever the reason, it can be relevant to also move other classes. (work done in the context of Gustavo Santos' PhD))

Test selection Running tests can be very long. In the context of Worldline, we observed until five hours to run all the tests of a system. In that conditions, we can easily understand that all the tests are rarely all performed. However, programmers that do not know which test run after a change can be easily tempted not to run any test. First, we are observing the test habits in Worldline company. Second, we provide a tool based on static analysis approach to select the right tests to run after a change. Only tests impacted by the change are relevant to run. Finally, we will analyse if the introduction of such a tool changes the programmers habits in the domain of tests.(work done in the context of Vincent Blondeau's PhD)

Towards transformation libraries: The DaRT team has developped an MDE-based co-design framework to generate SystemC, VHDL, OpenMP... Several MDE transformations chains have thus been defined. These chains are no more metamodel but transformation focused. They rely on a new approach that applies the separation of concerns to the transformations. Thus each transformation has a unique precise intention. Only few concepts are transformed at each step of the chain. The other concepts remain unchanged. From this way, transformations are smaller, and so more readable, easily tested, maintained and reused. It becomes possible to define transformation libraries. Such a mechanism is very useful when several chains are defined in the same framework from almost the same metamodel (in our case UML profiled with MARTE) and to target different languages (as in Gaspard) or to design product lines.

Chaining transformations: The transformations available on the shelves have to be composed, chained in order to generate the specified system. The new transformation type introduces new chaining constraints relating to metamodel typing. However, checking typing constraints is not enough. Stakeholder's requirements have also to be satisfied. We are currently working on the definition of intentional constraints that must be fulfilled by the generated system and thus checked by the chain.

Genericity: The transformations available on the shelves focusing on a specific intention, are small and can be easily reused. Their reusability can be further increased thanks to genericity. The idea is to specify the transformation with generic concepts and to establish bindings with concepts of the involved metamodels in order to specialize the transformation.

Evolution: As any other artefact, metamodels evolve. The transformations whose definition relies on these metamodel must consequently also evolve. We are currently working on the co-evolution of metamodel and transformation.

Test and verification: Some intentional constraints are verified when the chain is built. But it is not enough. We have developed approaches based on traceability mechanism to locate errors in a single transformation or in a chain. We have also automate the test set enhancement step of the mutation process. Mutation process enables the qualification of test sets.

Optimization of models: Once the chain has been enoughly tested and is trustworthy, if errors or wrong behaviours remain in the generated system, they come from errors or wrong specifications in the input models. We have developed a traceability based mechanism establishing a feedback of the execution of the generated system to the input model. This mechanism also enables to check that performance constraints are satisfied.

I have done my PhD thesis under the supervision of Professors Colette Rolland and Camille Salinesi on the alignment between business processes and information system in a context of evolution. I had proposed a solution based on Requirement Engineering. More details can be found in French on this page. Since I left the Centre de Recherche en Informatique, I stopped research in this domain. However, Requirements Engineering remains for me a frame of mind and is never very far in my research propositions. Indeed, taking into account stakeholder's requirements is a leitmotive in my research and requirements engineering notion such as intentionality are the basement of it.