The communication of web services is typically organized through APIs, which rely on a common data model shared among system components. Over time, this data model must be changed in order to accommodate new or changing requirements, and the components including the data they are operating on must be migrated. In practice however, not all affected components can be migrated instantly and at the same time. A common approach is to plan data model changes in a backward compatible fashion, which causes serious maintenance problems and is a common cause of technical debt. We propose an alternative solution, using a translation layer serving as a round-trip migration service, responsible for the lossless translation of object-oriented data model instances of different versions. We present a framework which offers a version-aware interface definition language (IDL) for APIs, a typed JavaScript-based language using the IDL definition, and a run-time environment. From a methodological point of view, development is supported by a catalog which comprises a set of typical evolution scenarios along with corresponding round-trip migration strategies. We showcase the applicability of our approach via a case study of a real-world e-commerce web application, and evaluate correctness through automated testing.

Model-driven engineering suggests that models are the primary artefacts of software development. This means that models may be refactored even after code has been generated from them, in which case the code must be changed to reflect the refactoring. However, as we show neither re-generating the code from the refactored model nor applying an equivalent refactoring to the generated code is sufficient to keep model and code in sync - rather, model and code need to be refactored jointly. To enable this, we investigate the technical requirements of model/code co-refactoring, and implement a model-driven solution that we evaluate using a set of open-source programs and their structural models. Results suggest that our approach is feasible.

As with design patterns before, the naming and cataloguing of refactorings has contributed significantly to the recognition of the discipline. However, in practice concrete refactoring needs may deviate from what has been distilled as a named refactoring, and mapping these needs to a series of such refactorings — if at all possible — can be difficult. To address this, we propose a framework of specifying refactorings in an ad hoc fashion, and demonstrate its feasibility by presenting an implementation. Evaluation is done by simulating application through a user on a set of given sample programs. Results suggest that our proposal of ad hoc refactoring is, for the investigated scenarios at least, viable.