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)
Automating system rearchitecture? Based on a real industrial example, we try to automate some parts of a system rearchitecture. Thalès is currently changing one of its system architecture to a component based one and projects to modify the architecture of other systems. Currently, the work is manually performed by engineers that have a deep knowledge of the system. The target is to provide tool support to reduce the dependence to such engineers and accelerate the process. We observe on the fied that such automation or at least tool support are really not trivial. (work done in the context of Gustavo Santos' PhD))