DesignSpace

Abstract

The engineering and maintenance of large (software) systems is an inherently collaborative process that involves diverse engineering teams, heterogeneous development artifacts, and different engineering tools. While teams have to collaborate continuously and their artifacts are often related, the tools they use are nearly always independent, single-user applications. These tools range from programming to modeling tools and cover a wide range of engineering disciplines. However, relations among the artifacts across these tools often remain undocumented and are handled in an adhoc manner. Keeping these artifacts in sync continues to be a key engineering challenge. In this paper, we present our vision of the DesignSpace, a novel engineering infrastructure for integrating diverse development artifacts and their relations. The DesignSpace supports distributed collaboration, a wide range of tools and development, maintenance , and evolution services including incremental consistency checking and transformation.

Multiple model synchronization with multiary delta lenses with amendment andK-Putput

“…The source of confusion is the state-based setting for update propagation, in which a law that looks like demanding strong invertibility is actually a simple Stability law demanding identity preservation. Indeed, in [18, Def.2.1 on p.2], they define a binary symmetric lens over state spaces X and Y with propagation operations (3) ppg XY : X × Corr → Y × Corr and ppg Y X : X × Corr ← Y × Corr (they call elements of set Corr complements rather than corrs, but as it is shown in [11,21], the two notions are equivalent). The law (PutRL) called round-tripping is defined thusly: for any states x and y (in our notation, A 1 and A 2 ) and complements c, c (i.e., our corrs, R, R ), the following condition holds ([18, Def.2.1 on p.2]): The main problem is not in that Stability is called Round-tripping, the problem is that the issue of an actual round-tripping law and its preservation under lens composition is not stated in the state-based lens framework because it is (fallaciously) considered solved!…”

“…A major distinction between the two is that Corr is a general model space category without any further restrictions, everything needed is provided by a family of boundary functors ∂ i : Corr → A i . In contrast, although the class of categories {M(S)| S ∈ S} is broad enough to be practically interesting, it does not include some corr structures appearing in applications, e.g., such as in our Running example, or in paper [9] focused on UML modelling, or in our paper [26], in which a very general pattern for corrs is described as a partial span of graph morphisms, or, finally, in general rule-based synchronization engines as described in [3]. An advantage of the abstract lens framework is that all these constructs are uniformly modelled as category Corr.…”

“…Finally, a major distinction is that in their setting, consistency restoration is non-deterministic while our lenses are deterministic. Overall, lenses appear as an abstract algebraic interface to update propagation that can be implemented by different ways, e.g., with GDG or by repair rules as in [3,30].…”

Collaborative Model-Driven Software Engineering — A systematic survey of practices and needs in industry

“…The framework we set up based on the focus group meetings and used as an input to the questionnaire (Table 2) might result in incorrect categories of concerns. Typically orthogonal concerns might be implicit in our framework, e.g., interoperability of heterogeneous modeling environments as described by Demuth et al (2015) might appear distributed across the concerns of editors supporting multiple types of notations, integration with build and DevOps tools and databases, network architecture, etc. Furthermore, because of the sometimes broad definition of the categories, there is room for interpretation when answering the questionnaire.…”