Automated reuse of model transformations through typing requirements models

Model transformations are key elements of model-driven engineering, where they are used to automate the manipulation of models. However, they are typed with respect to concrete source and target meta-models, making their reuse for other (even similar) meta-models challenging. To improve this situation, we propose capturing the typing requirements for reusing a transformation with other meta-models by the notion of a typing requirements model (TRM). A TRM describes the prerequisites that amodel transformation imposes on the source and targetmeta-models to obtain a correct typing. The key observation is that any meta-model pair that satisfies the TRM is a valid reuse context for the transformation at hand. A TRM is made of two domain requirement models (DRMs) describing the requirements for the source and target meta-models, and a compatibility model expressing dependencies between them. We define a notion of refinement between DRMs and see meta-models as a special case of DRM. We provide a catalogue of valid refinements and describe how to automatically extract a TRM from an ATL transformation. The approach is supported by our tool TOTEM. We report on two experiments-based on transformations developed by third parties and meta-model mutation techniques-validating the correctness and completeness of our TRM extraction procedure and confirming the power of TRMs to encode variability and support flexible reuseWork partially funded by the R&D programme of the Madrid Region (project FORTE, S2018/TCS4314), the Spanish Ministry of Science (project MASSIVE, RTI2018-095255-B-I00), the Spanish MINECO(project RECOM, TIN2015-73968-JIN, AEI/FEDER/UE), a Ramón y Cajal 2017 grant, and the European Union Horizon 2020 research and innovation programme through the Polyglot and Hybrid Persistence Architectures for Big Data Analytics (TYPHON) project (#780251

A Case Study for Networks of Bidirectional Transformations

Die Entwicklung moderner Softwaresysteme basiert oft auf mehreren Artefakten. Diese Artefakte teilen sich oft redundante oder abhängige Informationen, welche während der Entwicklung des Softwaresystems konsistent gehalten werden müssen. Die manuelle Durchführung dieses Prozesses ist arbeitsaufwendig und fehleranfällig. Konsistenzerhaltungsmechanismen ermöglichen diese Artefakte automatisch konsistent zu halten. Konsistenzerhaltung basiert oftmals auf bidirektionalen Transformationen, welche ein Zielmodell aktualisieren, wenn ein Quellmodell modifiziert wird. Während das Gebiet der bidirektionale Transformationen stark erforscht ist, hat Konsistenzerhaltung von mehr als zwei Modellen bisher weniger Aufmerksamkeit erhalten. Allerdings umfasst die Entwicklung von Softwaresystemen jedoch oft mehr als zwei Modelle. Folglich benötigt man Konsistenzerhaltung zwischen mehr als zwei Modellen, welche durch Netzwerke bidirektionaler Transformationen erreicht werden kann. Solche Transformationsnetzwerke kombinieren mehrere Transformationen, wobei jede einzelne für die Konsistenzerhaltung zweier Modelle verantwortlich ist. Da die Entwicklung jeder Transformation individuelles Domänenwissen erfordert, werden sie in der Regel von mehreren Domänenexperten unabhängig voneinander entwickelt. Zusätzlich können einzelne Transformationen in anderen Netzwerken wiederverwendet werden. Dies wird jedoch in bisherigen Arbeiten nicht berücksichtigt, macht aber die Konsistenzerhaltung durch Netzwerke bidirektionaler Transformationen anfällig für Probleme. In einem Netzwerk von Transformationen kann es beispielsweise zwei oder mehr Verkettungen von Transformationen geben, die dieselben Metamodelle mit verschiedenen anderen Metamodellen in Beziehung setzen. Jedoch können sie die Elemente unterschiedlich miteinander in Beziehung setzen. Dies kann zum Beispiel zu einer doppelten Erstellung derselben Elemente über die verschiedenen Transformationsketten führen. Es gibt jedoch kein systematisches Wissen über die Problemarten, die in solchen Netzwerken auftreten können oder ob und wie derartige Probleme systematisch verhindert werden können. Diese Thesis führt eine Fallstudie durch, die ermitteln soll, welche Arten von Problemen bei der Konsistenzerhaltung durch Netzwerke bidirektionaler Transformationen auftreten können. Für diese Probleme leiten wir eine Klassifizierung hinsichtlich des erforderlichen Wissens für ihre Vermeidung ab. Für Probleme, die Transformationsentwickler verhindern können, schlagen wir Strategien zur systematischen Vermeidung während ihrer Konstruktion vor. In unserer Fallstudie sind 90\% der gefundenen Probleme verhinderbar. Die übrigen Probleme lassen sich während der Entwicklung einer einzelnen Transformation nicht ohne das Wissen über weitere Transformationen im Netzwerk vermeiden. Folglich hilft diese Thesis Transformationsentwicklern Fehler bei der Erstellung von Transformationen systematisch zu vermeiden und ermöglicht es Netzwerkentwicklern Fehler zu erkennen, die bei der Konstruktion der Transformation nicht verhindert werden können

Model Transformation Languages with Modular Information Hiding

Model transformations, together with models, form the principal artifacts in model-driven software development. Industrial practitioners report that transformations on larger models quickly get sufficiently large and complex themselves. To alleviate entailed maintenance efforts, this thesis presents a modularity concept with explicit interfaces, complemented by software visualization and clustering techniques. All three approaches are tailored to the specific needs of the transformation domain

Environnement d'assistance au développement de transformations de graphes correctes

Les travaux de cette thèse ont pour cadre la vérification formelle, et plus spécifiquement le projet ANR Blanc CLIMT (Categorical and Logical Methods in Model Transformation) dédié aux grammaires de graphes. Ce projet, qui a démarré en février 2012 pour une durée de 48 mois, a donné lieu à la définition du langage Small-tALC, bâti sur la logique de description ALCQI. Ce langage prend la forme d’un DSL (Domain Specific Language) impératif à base de règles, chacune dérivant structurellement un graphe. Le langage s’accompagne d’un composant de preuve basé sur la logique de Hoare chargé d’automatiser le processus de vérification d’une règle. Cependant, force est de constater que tous les praticiens ne sont pas nécessairement familiers avec les méthodes formelles du génie logiciel et que les transformations sont complexes à écrire. En particulier, ne disposant que du seul prouveur, il s’agit pour le développeur Small-tALC d’écrire un triplet de Hoare {P} S {Q} et d’attendre le verdict de sa correction sous la forme d’un graphe contre-exemple en cas d’échec. Ce contre-exemple est parfois difficile à décrypter, et ne permet pas de localiser aisément l’erreur au sein du triplet. De plus, le prouveur ne valide qu’une seule règle à la fois, sans considérer l’ensemble des règles de transformation et leur ordonnancement d’exécution. Ce constat nous a conduits à proposer un environnement d’assistance au développeur Small-tALC. Cette assistance vise à l’aider à rédiger ses triplets et à prouver ses transformations, en lui offrant plus de rétroaction que le prouveur. Pour ce faire, les instructions du langage ont été revisitées selon l’angle ABox et TBox de la logique ALCQI. Ainsi, conformément aux logiques de description, la mise à jour du graphe par la règle s’assimile à la mise à jour ABox des individus (les nœuds) et de leurs relations (les arcs) d’un domaine terminologique TBox (le type des nœuds et les étiquettes des arcs) susceptible d’évoluer. Les contributions de cette thèse concernent : (1) un extracteur de préconditions ABox à partir d’un code de transformation S et de sa postcondition Q pour l’écriture d’une règle {P} S {Q} correcte par construction, (2) un raisonneur TBox capable d’inférer des propriétés sur des ensembles de nœuds transformés par un enchaînement de règles {Pi} Si {Qi}, et (3) d’autres diagnostics ABox et TBox sous la forme de tests afin d’identifier et de localiser des problèmes dans les programmes. L’analyse statique du code de transformation d’une règle, combinée à un calcul d’alias des variables désignant les nœuds du graphe, permet d’extraire un ensemble de préconditions ABox validant la règle. Les inférences TBox pour un enchaînement de règles résultent d’une analyse statique par interprétation abstraite des règles ABox afin de vérifier formellement des états du graphe avant et après les appels des règles. A ces deux outils formels s’ajoutent des analyseurs dynamiques produisant une batterie de tests pour une règle ABox, ou un diagnostic TBox pour une séquence de règle