From Builders to Editors: Bidirectional Transformations of Low-code Models

OutSystems provides a model-driven low-code development environment and delivery platform that allows developers to create enterprise-grade web and mobile applications. OutSystems developers interact with Service Studio, the platform's IDE, using domain-specific visual languages to shape the fine-grained application model.In recent years, OutSystems introduced the 'Application Builders', a set of tools that lower the learning curve even more and provide an inclusive entrance to non-IT developers. The builders focus on specific application development scopes such as User Experience or the definition of Business Processes. Each application domain requires a specific and appropriate meta-model abstracting selected parts of the underlying OutSystems model. Ultimately, they represent OutSystems concepts in a higher degree of abstraction, just like views of the base model.OutSystems builders define a unidirectional model transformation strategy. This limitation hinders the interoperability between the different development tools in the OutSystems ecosystem. An application developed with one particular builder is unreadable in other builders and can only be further customized in Service Studio. However, changes made in the IDE are irreversible and unreadable by the original builder. This comes off as a direct consequence of the current problem of OutSystems builders defining unidirectional model transformations.In this paper, we explicitly address this limitation by defining fully bidirectional builder model transformations in OutSystems: builder to IDE and IDE to builder. The implemented strategy consists of a synchronization algorithm that maintains consistency between models on all allowed evolutions, thus leading to the point where builders become model editors.The instantiated and evaluated implementation focuses on one particular builder of OutSystems, the 'Experience Builder'. We successfully represented all Service Studio operations that become either invisible or correctly mapped onto the builder's model. In addition, it was possible to portray evolution steps taken in the builder tool without reverting the customization made in Service Studio.