BLANC Xavier

Model Driven Software Engineering Environment

Since more than forty years, Software Engineering keeps producing new technologies to solve the intrinsic complexity of large software production. This constant provision of new technologies is obviously the source of an integration difficulty. Indeed, all these technologies target only some of the Software Engineering activities and hence have to be integrated to cover the whole Software process. This paradox is probably one of the main motivations of the genesis of Software Engineering Environments (SEEs) that aim at offering an integrated support to the developers while they collaboratively develop software. SEEs provide many useful facilities to developers such as version control, collaborative edition, inter-tools coordination (for instance, when the program code is updated, the compiler is automatically called) and support to process enactment. In the context of Model Driven Engineering (MDE), SEEs need to support new software artifacts, new tools and new processes. They have to handle models that are complex software artifacts composed of millions of distributed yet related model elements. They have to handle new operations on models, such as model collaborative edition, model transformations and model verifications, which are all currently used by developers in a disconnected mode. They have to assist developers who follow a software process that can evolve dynamically and that is itself specified as a model. As a consequence, this raises the need for Model Driven Software Engineering Environments (MDSEEs). Since 2004, our research contributions mainly address the MDSEEs field and target the three aspects of MDSEEs, which are the data integration, the control integration and the process integration. In particular, we present ModelBus, Praxis and UML4SPM. ModelBus addresses the data integration and the control integration. Regarding the data integration, ModelBus is based on the copy-modify-merge paradigm. Models are split into several XML files that are stored in a central repository, called the model base. The model base supports persistency and version control. Regarding the control integration, ModelBus proposes a communication layer, called tool adapter, whose architecture is a classical broker architecture. Praxis addresses the data integration but is more related to the detection of inconsistencies. To detect model inconsistencies, Praxis represents models by sequences of construction operations. Praxis then uses logical constraints on top of those sequences to define inconsistency rules. UML4SPM addresses the process integration. Regarding processes modeling, UML4SPM comes in form of a meta-model that extends the UML2.0 Superstructure one. Thanks to UML4SPM, software process can then be represented by graphical models that look like UML diagrams. Regarding the execution of software processes, UML4SPM provides two execution approaches. The first one consists in translating a UML4SPM process model into an executable language (such as BPEL) whereas the second one consists in providing an interpreter of UML4SPM process models.

Defence : 11/18/2009 - 14h30 - Site Passy-Kennedy - salle 847

Jury members :

Colin Atkinson, University of Mannheim, rapporteur
Franck Barbier, Université de Pau et des Pays de l'Adour, rapporteur
Laurence Duchien, Université de Lille 1
Jacky Estublier, Laboratoire Informatique de Grenoble, rapporteur
Marie-Pierre Gervais, Université de Nanterre
Jean-Marc Jézéquel, Université de Rennes 1
Fabrice Kordon, Université Pierre et Marie Curie

7 PhD graduated 2006 - 2012