Sie können Operatoren mit Ihrer Suchanfrage kombinieren, um diese noch präziser einzugrenzen. Klicken Sie auf den Suchoperator, um eine Erklärung seiner Funktionsweise anzuzeigen.
Findet Dokumente, in denen beide Begriffe in beliebiger Reihenfolge innerhalb von maximal n Worten zueinander stehen. Empfehlung: Wählen Sie zwischen 15 und 30 als maximale Wortanzahl (z.B. NEAR(hybrid, antrieb, 20)).
Findet Dokumente, in denen der Begriff in Wortvarianten vorkommt, wobei diese VOR, HINTER oder VOR und HINTER dem Suchbegriff anschließen können (z.B., leichtbau*, *leichtbau, *leichtbau*).
Die technologische Landschaft des kollaborativen modellgetriebenen Software-Engineerings (MDSE) steht im Mittelpunkt dieses Artikels, der sich mit den Werkzeugen und Methoden beschäftigt, die eine effiziente Zusammenarbeit zwischen technischen und nichttechnischen Akteuren bei der Entwicklung von Softwaresystemen ermöglichen. Die Studie identifiziert und klassifiziert bestehende kollaborative MDSE-Technologien und zeigt ihre Fähigkeiten und Grenzen auf. Sie adressiert Herausforderungen wie gleichzeitige Modelländerungen, Konfliktlösung und Integration in bestehende Modellierungsumgebungen. Die Analyse zeigt, dass viele Werkzeuge von bestimmten Modellierungssprachen abhängig sind und keine Funktionen wie Versionierung und Echtzeit-Zusammenarbeit bieten. Der Artikel schließt mit Empfehlungen für zukünftige Forschung und Entwicklung, um die Benutzerfreundlichkeit und Effektivität kollaborativer MDSE-Werkzeuge zu verbessern. Dieser Artikel bietet einen systematischen Überblick und praktische Einsichten und zielt darauf ab, Forschern und Praktikern bei fundierten Entscheidungen über die von ihnen verwendeten Technologien zu helfen.
KI-Generiert
Diese Zusammenfassung des Fachinhalts wurde mit Hilfe von KI generiert.
Abstract
Collaborative technologies are continuously evolving to address existing problems and introduce innovative features for enhancing collaboration in the landscape of model-driven software engineering (MDSE). Different collaborative MDSE technologies (CMTs) provide different solutions to facilitate collaboration, making it hard for practitioners to choose the technology that best suits their needs. This study aims to investigate the landscape of CMTs and to provide a list of recommended technologies tailored to specific use case scenarios in the context of MDSE. We compiled a comprehensive list of CMTs using a systematic search complemented with snowballing, investigating both academic and grey literature. The technologies were selected through a set of inclusion and exclusion criteria and eventually analyzed through an in-depth analysis focusing on model management, collaboration, and communication. The findings of our study reveal that the current landscape of CMTs is characterized by a relatively narrow range of capabilities offered by different technologies. Consequently, practitioners often have to become proficient in combining several different technologies in order to meet their needs. While various CMTs offer distinct collaboration approaches, the current landscape could be richer in terms of capabilities. Our research provides a comprehensive description of recommended CMTs, enabling practitioners to make informed decisions and improve collaboration in their MDSE processes.
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
1 Introduction
In the context of model-driven software engineering (MDSE), collaborative modeling focuses on developing and utilizing methods and tools that can benefit technical and non-technical stakeholders, to collaborate efficiently on large models to build software systems [1]. Collaborative MDSE technologies (CMTs) are designed to enable multiple users to work together on modeling activities. CMTs can be used to support a wide range of modeling languages and technologies [2].
Several challenges are associated with the development of CMTs, including management of concurrent model changes, resolution of conflicts arising during collaboration, and integration of CMTs into existing modeling environments and workflows. [3].
Anzeige
In recent years, the field of collaborative modeling has made significant progress with the introduction of several technologies aimed at addressing related challenges in the context of MDSE. Many of these technologies, including Sirius [4], EMF Compare [5], and WebGME [6], have been available as open-source solutions. While some of these solutions were developed using pre-existing frameworks such as Eclipse EMF1 or MPS,2, others are standalone.
For MDSE practitioners, it can be challenging to navigate this landscape and select a technology that meets their specific needs. Researchers may also find it challenging to identify current trends and gaps in the collaborative MDSE domain. For instance, it can be hard to determine the usability of technologies that offer different notations as a feature or the modes of communication used by the different solutions. This complexity poses a significant challenge for practitioners and researchers in the field, making it difficult to make informed decisions about the technologies they use. To address this challenge, it is essential to conduct in-depth systematic studies that analyze different parameters of CMTs and provide the required information to facilitate informed decision-making (Table 1).
Table 1
Goal of this study
Purpose
Identify, classify, and analyze
Issue
The characteristics of
Object
Existing collaborative MDSE technologies
Context
In relation to their usage or development
Viewpoint
From an MDSE researcher’s and practitioner’s point of view
The aim of this study is to present a comprehensive overview of the CMTs that are prime candidates for supporting collaborative modeling. We investigate related academic and grey literature to identify, classify, and analyze the characteristics of existing CMTs. We compiled a list of CMTs based on their relevance to MDSE. After applying specific inclusion and exclusion criteria, we applied our classification framework to the selected technologies. Eventually, we extracted and analyzed the collected data to provide useful insights about existing CMTs.
The results of our study indicate that CMTs offer a limited number of features for collaboration. For example, Bizagi supports a model repository, a transformation engine, and an editor. Most CMTs in the market favor a centralized network architecture. Additionally, many CMTs lack support for communication, and those that provide a communication medium generally rely on asynchronous communication.
Anzeige
The main contributions of this study are:
A systematic review of up-to-date literature on collaborative MDSE technologies.
A quantitative analysis of collaborative MDSE technologies based on various parameters.
A discussion of current trends in the landscape of collaborative MDSE technologies and their implications for MDSE researchers and practitioners.
The target audience of our study consists of MDSE researchers in the field of collaborative modeling who seek to understand current trends and gaps in existing CMTs, and MDSE practitioners who rely on different CMTs and require guidance for a better understanding of CMTs to make better-informed decisions.
The remainder of the paper is structured as follows: Sect. 2 describes the research design, while Sect. 3 presents the analysis of the technologies using various parameters. In Sect. 4, the findings of the analysis are discussed, along with their implications for the audience. Section 5 addresses the limitations and threats to the study’s validity. Eventually, Sect. 6 concludes the paper.
2 Background
2.1 Model-driven software engineering
Model-driven software engineering (MDSE) describes different aspects of the system being developed through models. With MDSE, stakeholders can focus on domain-specific concepts and assess specific properties of the system early in the development life cycle. Models used in MDSE can be either graphical, tabular, or textual and have unambiguously defined semantics, allowing for precise information exchange and many additional usages [7]. MDSE uses models as first-class entities throughout the system development life cycle, including syntactical validation, model analysis, model simulation, model transformations, model execution, and model debugging, providing suitable engines for defining, analyzing, and manipulating those models [8].
Several examples of MDSE tools include GenMyModel [9], and MDEForge [10]. GenMyModel is designed for real-time design and sharing of design diagrams while ensuring their compliance with the metamodel. It eliminates conflict resolution for end-users and lock-unlock barriers. On the other hand, MDEForge is a web-based modeling platform that facilitates an extensible and community-based repository of modeling artifacts. By adopting a software-as-a-service paradigm, MDEForge enables the development, analysis, and reuse of modeling artifacts.
2.2 Collaborative MDSE
Collaborative modeling is a practice that allows multiple stakeholders to work together on the development of software systems through the use of shared models [7]. These models represent key aspects of the system being developed and are used to guide the design, implementation, and testing of the software [7]. Collaborative modeling enables the management, collaboration, and awareness of each stakeholder’s work on these shared models [11].
Collaborative MDSE is gaining interest in both academic [3] and practical settings [12]. Several research projects are conducted to facilitate large teams of modelers in constructing and refining large models collaboratively [8]. The Dawn Eclipse project3 is currently exploring collaborative user interfaces (UIs) to provide collaborative access for graphical modeling framework (GMF) diagrams. Similarly, EMFCollab4 is a lightweight solution that allows multiple users to edit a single eclipse modeling framework (EMF) model simultaneously.
2.3 Collaborative MDSE technologies
Collaborative MDSE technologies (CMTs) refer to modeling technologies that allow multiple users to create, edit, visualize, and manage models collaboratively [7]. CMTs are designed to improve team collaboration by enabling a diverse group of stakeholders to work together seamlessly. CMTs can be classified into several categories, such as model repository, language workbench, and transformation engine, which cater to different modeling use cases [13]. In today’s landscape, CMTs facilitate collaboration in real-time, offline, or in hybrid mode, depending on organizational constraints or project requirements [12]. CMTs come equipped with features like version control and built-in communication to aid in the collaborative process [12]. They also support various types of editors, such as graphical, textual, and tabular, to accommodate different user preferences [3]. Popular CMTs, including Sirius, are an open-source tool that enables the creation of graphical modeling environments for various domains. Along with typical graphical modeling features, Sirius provides extended mechanisms for each domain.5 IBM Rhapsody offers a solution for modeling and systems design activities that reduce the complexity many organizations face with product and systems development. Rhapsody provides a collaborative design development and test environment for systems engineers that supports UML, SysML, UAF as well as AUTOSAR import and export capabilities.6
3 Identification of collaborative MDSE technologies
The search and selection phase of our study aimed to identify a diverse set of CMTs. To accomplish this, we conducted a comprehensive review of academic sources such as peer-reviewed papers, as well as grey literature such as websites, online blogs, and other online resources. The information gathered from these sources was analyzed to identify specific modeling technologies. The purpose was to provide a thorough understanding of the technologies that are available in the market for collaborative modeling.
3.1 Search: collecting initial sources
The process of gathering literature for our study involved searching for both academic and grey literature. By utilizing search engines such as Google Scholar for academic studies and a general Google search for grey literature, we were able to identify a diverse set of modeling technologies that support collaborative MDSE. Our primary source for information retrieval from existing literature was Google Scholar since empirical evidence shows that Google Scholar has proved to be a sound choice to identify the initial set of literature studies for the snowballing process [14], while at the same time (i) providing a high number of potentially relevant studies compared to other four relevant libraries (Scopus, ACM Digital Library, IEEE Explore, and Web of Science) and (ii) facilitating the exporting and the (programmatic) management of the produced search results. The search process focused on utilizing specific keywords related to collaborative MDSE and relevant modeling categories. This helped in narrowing down the search results to only include relevant studies. This step resulted in an initial set of literature studies to be used as input for our snowballing process, by which we gathered a comprehensive overview of the technologies available in the market to support collaborative MDSE.
(collaborat*ORcoordinat*ORcooperat*ORconcur*ORglobal) AND (MDEORMDDORMDAORMDS*ORDSLORDSML OR "model driven"OR "model based"ORMB*OR"domain specific language"OR"domain specific modeling language" )
Query: Search string used for grey literature
The initial search for academic literature on collaborative MDSE was conducted using Google Scholar. As shown in Fig. 1, a total of 77 relevant papers were identified through this search. For the grey literature, we used the above-mentioned query string on the Google search engine to collect results from the first 10 pages. This generated a total of 100 web pages, which included various forms of documentation on CMTs, such as blogs, GitHub pages, and more.
3.2 Identification and validation
We extracted potential MDSE technologies by applying snowballing, including those not specifically designed for collaborative use. Snowballing is often used to identify relevant literature for qualitative studies, systematic reviews, and meta-analyses, where a comprehensive set of literature is needed [14].
Fig. 1
Overview of identification, selection, and validation of CMTs
We then applied three rounds of search regression to identify the potential target CMTs. The entries were thoroughly examined using multiple rounds of selection via an adaptive reading depth approach [15].
✋ Round-1:
In the initial round, we evaluated the resource title to eliminate sources that did not meet the criteria.
✋ Round-2:
In this round, we assessed the resource’s conclusion and results.
✋ Round-3:
Finally, we thoroughly reviewed the content, and if the proposed technology passed the general criteria, it was considered as a potential target for further examination.
Validation:It is vital to validate the CMTs identified during the selection phase to ensure the accuracy of the results and minimize potential validity threats. The validation process serves to eliminate any false positives (CMTs that are mistakenly included) and prevent false negatives (CMTs that are overlooked). While a false positive may not have a noteworthy impact on the overall outcome of the study, a false negative could significantly skew the results. Thus, the validation process was an essential step to ensure the integrity and credibility of the study.
To validate the collected data, we employed a technique known as double data entry [16]. This involved collecting information from ten sources, comprising academic researchers and practitioners in CMTs, with each dataset being collected by two different researchers following the same protocols. We then used the Cohen-Kappa coefficient [17] to compare the results and determine if the level of agreement met our desired threshold. In the first round, we achieved a threshold of 0.82, which allowed us to proceed with the data collection process for the entire set of sources to gather as many potential targets as possible.
3.3 Selection
3.3.1 Technologies selection
In this step, we carefully filtered out the potentially relevant technologies that were identified in the previous phase. To minimize bias, we defined a set of inclusion and exclusion criteria beforehand. Table 2 illustrates the list of inclusion criteria; for a technology to be included, it must meet all the inclusion criteria. In contrast, if a technology satisfied any of the exclusion criteria (see Table 3), it was excluded.
Table 2
List of inclusion criteria
Inclusion criteria
I1
The modeling technology supports collaborative modeling, i.e., it allows multiple stakeholders to manage, collaborate, and be aware of each others’ work on a set of shared models representing key aspects of the same system
I2
The modeling technology is publicly available (either as an open-source or commercial product)
I3
The documentation of the modeling technology is publicly available
Table 3
List of exclusion criteria
Exclusion criteria
E1
The modeling technology does not explicitly address/support collaborative modeling, e.g., Eclipse EMF, MPS, ATL, Epsilon, etc
E2
The modeling technology is not available for download as a binary that can be run on current operating systems from an official website or an affiliated platform supporting it (e.g., a GitHub repository)
E3
The documentation of the modeling technology is not available in English
3.3.2 Validation and enrichment
In order to strengthen the correctness and completeness of the CMTs selected via our selection steps, we contacted 11 experts on collaborative MDSE and asked them to (i) validate the current list of CMTs and (ii) propose missing CMTs. Such 11 experts were identified via convenience sampling [18] among our collaboration network and within the consortium of the BUMBLE (Blended Modeling for Enhanced Software and Systems Engineering) ITEA3 European project, which has a dedicated work package on Collaborative Modeling. Specifically, 7 of the 11 experts are industrial practitioners employed by the following organizations: Canon Printing Technologies (The Netherlands), Strumenta (Italy), Eclipse Source (Germany), Modeling Value Group (The Netherlands), HCL (Sweden), Xitaso (Germany), Malina Software (Canada); the other 4 experts are academic researchers active in the MDSE scientific community and affiliated in 4 different universities across Germany, Austria, Italy, and Canada. In all cases, the contacted expert has multiple years of experience in MDSE (Table 4).
We provided to each selected expert the full list of the currently selected CMTs, and we asked them to (i) revise the list and (ii) add potentially missing CMTs. When needed, we asked them for additional details about the main reasons for their provided feedback. The inputs and feedback lead to the inclusion of the following seven CMTs (refer to Table 5 for the details): T23, T24, T25, T26, T27, T28, T29. Finally, during the revision and improvements phase of this manuscript, we received further suggestions from three more academic experts which resulted in the inclusion of T30, T31 and T32.
3.4 Data extraction
In this phase, we analyzed the 32 CMTs that were identified during the selection process. The input for this task consists of the documentation and information available on the official website of each CMT. In those cases where the required information could not be retrieved from the official website or documentation, additional research was conducted on the web to gather the needed information.
In Table 5, we present the CMTs that we identified, selected, and analyzed. It is worth noting that while we made efforts to gather all necessary information, we could not obtain some release-related information for a few CMTs. This is due to the fact that GitHub repositories for those technologies were no longer maintained or the information was not publicly available on official websites.
Table 4
List of parameters and its definition
Parameters
Definition
Options
Model management
Supported languages
The name of the language, in case, if it is independent of the modeling language, we put INDEPENDENT
UML, BPMN,SysML, etc./Independent
Technical space
Identify if the technology uses Eclipse, Jetbrains MPS, or any other framework as its inherited framework. In case it doesn’t have any dependency, then we use Standalone
Eclipse, MPS, Atom, Standalone
Supported editor
Notations used in the technology
Graphical, Textual, Tabular, Sketch, or Independent
Extensible
Whether the technology can be extended with plugins or similar
Yes/No
Collaboration
Collaboration type
Determine if the technology employs real-time or offline collaboration type in its approach
Real-time,Offline or Both
Versioning
Technologies that have versioning support enable users to keep track of changes made over time and easily revert to previous versions if necessary
Yes/No
Network architecture
Does the technology utilize a distributed, centralized, or peer-to-peer architecture? This information can indicate how the tool handles data and communication within the system
Distributed, Centralized, P2P, or Hybrid
Communication
Communication type
The technology supports a specific type of communication, either synchronous or asynchronous, which determines the flow of information and actions between users in real time or with a delay
Asynchronous or Synchronous
Workspace awareness
Workspace awareness refers to the ability of technology to allow users to see what other collaborators are doing in real-time, such as the cursor location of others in a document
Yes or No
In this phase, we used both qualitative and quantitative techniques to extract the data, depending on the type of characteristic being extracted (see Table 4). In both cases, to minimize bias, two researchers have been involved and have carried out their tasks iteratively. For the purely quantitative characteristics (e.g., year of latest release), the first author of this study performed the initial data collection; then, one of the other authors reviewed the collected data, and in case of ambiguities or missing data, the disagreements were solved with a dedicated discussion. If the agreement could not be achieved, a third author stepped in and made the final decision. For the characteristics that have a qualitative nature, i.e., those requiring the analysis of open/unstructured text (e.g., the types of supported editors), two authors analyzed each CMT individually by applying a process inspired by the open card sorting technique [19]. For each technical characteristic, the card sorting was performed in two phases: (i) we coded each CMT with its representative information about the used techniques, or collaborative characteristic, and then, (ii) we grouped the extracted codes into meaningful groups with a descriptive title (e.g., support for versioning, extensibility, type of communication among users, etc.).
3.5 Data analysis
In this phase, we performed a combination of content analysis and narrative synthesis [20].
The content analysis consists in a quantitative assessment of the extracted data (e.g., the frequency of CMTs using graphical editors with respect to those using textual editors). In this context, we used descriptive statistics to quantitatively analyze the extracted data about each technical characteristics of the CMTs.
Then, we used narrative synthesis on the results of the content analysis. Narrative synthesis refers to the systematic method where a textual narrative summary is adopted to (1) explain the quantitative information emerging from the content analysis and (2) identifying emerging patterns and trends [20]. We grouped the results of our data analysis phase according to the research questions of the study. This mixed-method procedure enabled us to understand the data and draw meaningful conclusions.
3.6 Data availability
The complete replication package is available online [21] to allow independent researchers to replicate and verify the results of our study, and to reuse the collected and extracted data for other purposes.
A modeling environment based on UML, is a visual development environment for systems engineers and software developers creating real-time or embedded systems and software
Web-based tool for creating and editing graphical modeling workbenches collaboratively
4 Results
We classified each CMT according to four main dimensions. The first dimension is about the main capabilities provided by the CMT (i.e., its main reasons of existence) and their longevity (see Sect. 4.1). The other three dimensions are based on the level of assistance the CMT provides within the three dimensions of collaborative MDSE introduced by Franzago et al. [2, 7]—model management, communication, and collaboration, as shown in Table 4 (see Sects. 4.2, 4.3, and 4.4).
4.1 Capabilities and longevity
Results
In this dimension, we focus on the main capabilities provided by each CMT. Some CMTs offer solutions for several features, placing them in multiple categories. For example, GenMyModel provides a model repository, an editor, and a version control system. This underscores the importance of considering the various capabilities of a CMT when classifying it, ensuring an accurate representation of its features and applications. This classification process revealed the unique features of CMT and their potential uses in different contexts. According to our analysis, the main capabilities provided by the analyzed CMTs are as follows:
➊ Model repository: is a central location for storing, managing, and sharing models. It enables multiple stakeholders to access, edit, and track changes to models in a controlled manner [49].
➋ Transformation engine: transforms models from one representation or format to another [2] [50].
➌ Diff/Merge engine: compares and merges differences between different versions of a model [51].
➍ Version Control System: enables multiple users to collaborate and manage changes made to a set of files over time [52].
➎ Editor: allows users to create, edit, and visualize models using a specific modeling language or notation.
➏ Language workbench: allows the definition and design of (domain-specific) languages and their development environments [53].
➐ Real-time collaboration engine: ] allows collaborative editing of data by multiple modelers over a network, in real-time [54].
Table 6 illustrates the list of CMTs and their support of the identified capabilities. For instance, Bizagi (T2) provides a model repository, a transformation engine, and an editor. Our analysis shows that sixteen CMTs provide support for Model repository. The next most supported features are Editor, Transformation engine, and Version control System (VCS). Furthermore, it should be noted that only ten CMTs offer support for multiple (>1) features. This highlights the importance of considering the range of capabilities offered by different technologies when choosing a CMT to support collaborative modeling. It also indicates that many of the CMTs focus primarily on specific aspects of collaborative modeling, rather than offering a broad range of capabilities.
Table 6
Collaborative MDSE technologies classification
Technologies
Model repository
Transformation engine
Diff/Merge
Version control system
Editor
Language workbench
Modeling workbench
Facilitator
Real-time collaboration engine
Modeling framework
Support capability
T1
✓
✓
2
T2
✓
✓
✓
3
T3
✓
✓
2
T4
✓
1
T5
✓
1
T6
✓
✓
✓
3
T7
✓
1
T8
✓
1
T9
✓
1
T10
✓
✓
2
T11
✓
✓
2
T12
✓
✓
✓
3
T13
✓
1
T14
✓
1
T15
✓
1
T16
✓
1
T17
✓
✓
2
T18
✓
1
T19
✓
1
T20
✓
1
T21
✓
1
T22
✓
✓
✓
3
T23
✓
✓
2
T24
✓
1
T25
✓
1
T26
✓
1
T27
✓
1
T28
✓
1
T29
✓
1
T30
✓
1
T31
✓
✓
2
T32
✓
✓
2
Total
16
6
3
5
9
2
1
1
1
4
Figure 2 shows the longevity of the analyzed CMTs. The longevity of a CMT consists in the difference in years between the year of the first release and the year of the last release of the CMT. Intuitively, it gives an indication about the lifespan of a CMT in the market/community, independently of its user base, application domain, technological hypes, etc. In Fig. 2 we observe that a significant number of CMTs have an age higher than 10 years and that six CMTs have been in existence for over two decades. Sirius Web [48], Eclipse CDO [45], LowKey [40], Modelix [34] and EMF Cloud [33] are the latest additions to the set of CMTs under analysis in this study, and indeed, their longevity is relatively shorter than the others.
Half of CMTs provide a dedicated model repository component. This result is not surprising per se since we can expect that collaborating on a shared set of models also means that those models have to be stored (and in the case of 5 CMTs also versioned). However, this might be an indication of a potential risk of tool lock-in in terms of the formats in which the models are stored. Specifically, if we consider Modelix (T17) as a representative example, its documentation explicitly mentions that all models are stored in a dedicated model server,7 which exposes an ad hoc Rest API and internally runs a PostgreSQL database, with on top an Apache Ignite caching layer. This means that Modelix users must adopt the full “Modelix stack” in order to benefit from the collaboration features provided by this CMT. Also, in this case, models are stored in one or more PostgreSQL tables, making it relatively difficult to import/export them from other technical spaces in case a migration to/from Modelix is needed. A similar risk is present also for CMTs providing their own modeling framework (4 occurrences in our dataset), modeling framework, and language workbench.
Our analysis of the longevity of the selected CMTs provides an indication of the relatively high longevity of various CMTs in the collaborative MDSE landscape and how new technologies are continuously emerging and evolving in the model-driven technological landscape.
4.2 Model management
The model management dimension deals with managing the life cycle of models, including their creation, manipulation, and storage [12]. Several tools are available to handle specific challenges related to model management [55]. In the following, we outline the characteristics of CMTs in relation to the model management capabilities that they offer.
4.2.1 Supported language
Results
Figure 3 shows that about 52% of the CMTs support specific sets of languages, while about 48% of the CMTs are independent of any particular modeling language, indicating that they are capable of supporting a wide range of languages. Most CMTs use popular languages such as UML, BPMN, SysML, XML, and XBRL. The most widely used languages are UML and BPMN, which are present in 10 of the 13 CMTs that depend on a specific language.
Our results also indicate that CMTs supporting UML also exhibit support for BPMN. Table 7 shows that only one CMT uses UML only, and two CMTs use BPMN only. However, eight CMTs provide support for both languages.
Observations
We observe that more than half CMTs are specifically designed to support particular modeling languages, with a predominance of the Unified Modeling Language (UML)8 and the Business Process Model and Notation (BPMN).9. UML and BPMN are widely used in software development and business process management. These modeling languages provide a familiar and standardized way of representing and communicating system and business process designs among stakeholders. This improves the collaboration and communication between stakeholders, which in turn leads to quality designs and more efficient development and implementation of systems and business processes [56]. This result is expected since UML and BPMN are historically among the most used languages in the software industry, specially for architecture description [57], justifying technology builders to prioritize those languages over others.
4.2.2 Technical space
Results
As shown in Fig. 4, CMTs primarily rely on existing technical spaces—such as Eclipse EMF or Jetbrains MPS—to create, manage, and manipulate models. These technologies provide the infrastructure necessary for defining, storing and processing models, as well as generating code and other artifacts from models [58]. Our analysis reveals that the majority of CMTs rely on Eclipse (48.4%) and the remaining utilize either MPS (6.5%) or Atom (3.2%). Eclipse has robust capabilities for supporting text-based notation, and it was observed that the CMTs using Eclipse as a technical space also support textual notation [59]. The only technologies in this study that use MPS as their technical space are Modelix (T17) and Parsafix (T18). Interestingly, 41.9% of the CMTs are standalone, indicating that a non-negligible number of CMTs are developed from scratch (Table 8).
Classification of technologies per technical space
Language
Technologies
Standalone
T23,T25,T26,T27,T24,T1,T10, T9,T6,T5,T2,T12
T15,T30
EMF
T3,T4,T7,T8,T11,T13,T14,T16, T19,T20,T21,T31,T32
T22,T29
MPS
T17,T18
Atom
T28
Observations
The fact that Eclipse EMF is the most adopted technical space is not surprising. EMF has been one of the first modeling frameworks developed specifically in the context of MDSE projects and it comes with plugins and APIs that facilitate modelers and developers in accessing, manipulating, and interacting with models, including also support for command-based editing, undo/redo functionality, etc.10 Another used technical space is Jetbrains MPS,11 a software development environment that enables users to create their own domain-specific languages (DSLs) and associated editors in the Jetbrains ecosystem. MPS offers a variety of useful features in software development, including code generation, refactoring, and debugging tools, in addition to its DSL development capabilities.
The fact that EMF is much more adopted for realizing CMTs than MPS may be due to many factors, including non-technical ones like support from a dedicated foundation, different dissemination strategies, etc. It is also important to note that EMF has a temporal advantage over MPS; the first release of EMF dates back to 200312. Finding the main reasons behind the wider adoption of EMF over MPS is beyond the scope of this study, but it would be interesting and useful to investigate them in future research (e.g., via a questionnaire-based survey or focus groups), since the MDSE community might learn useful lessons about the development and distribution of future modeling languages in the coming years.
4.2.3 Supported editor
Results
Notations, or concrete syntaxes, convey complex information in a clear and concise way, improving collaboration and communication among stakeholders. In any CMT, the capabilities offered by the supporting editor in terms of notation can be crucial. Different types of notation are used in CMTs, such as textual, tabular, graphical, or tree based. Textual notation is a way to represent models using text-based languages, such as programming or markup languages [60]. Textual notations are often used for the implementation of models and the generation of code. Graphical notations represent models using diagrams or visual representations. These notations are commonly used to represent business processes and workflows. Tree-based notations represent models as hierarchies. Sketch notations are informal types of notation, often used in the brainstorming and conceptualization phases of modeling. These notations are valuable elements for stakeholders to effectively communicate and collaborate throughout the modeling process [61].
Different CMTs offer different levels of editing notation in their technology. Table 9 classifies the CMTs by the number of notations they support. Among the CMTs studied, 8 CMTs support a single notation, 5 CMTs support two notations, 2 CMTs support three notations, and 3 CMTs support four different notations (Fig. 5 and Table 9).
Table 10 summarizes the notations offered by CMTs, including Graphical, Textual, and Tabular. Among these, Graphical notation is the most widely supported (13 out of 18 CMTs), while Sketch is the least popular, supported by only three CMTs but Sketch-based editors are anyways way less demanded by practitioners [12].
Table ?? shows that graphical, textual, and tabular are the most popular notations supported by CMTs. They are also utilized in a hybrid/blended manner, i.e., in combination. UML and BPMN commonly use graphical and textual notations to design diagrams such as class diagrams, sequence diagrams, etc. One of the popular CMTs, WebGME, integrates graphical, textual, and tabular notations to provide various features, such as UML diagram creation, textual analysis, spreadsheets, and more.
Observations
The majority of analyzed CMTs rely heavily on graphical notation as a primary means of representation, with a few also incorporating additional notations for editing purposes. This is in line with previous research on industrial needs concerning collaborative MDSE, which showed that practitioners tend to demand more graphical editors [12]. Additionally, we observed that a few CMTs also support multiple notations, known as blended modeling [62], which allows them to support a broader range of users with different preferences and requirements.
4.2.4 Extensibility
Results
Extensibility entails the possibility of adding new functionalities and capabilities to the CMT at hand through the use of plugins or add-ons. Extensibility is a vital characteristic of CMTs since it allows users to tailor them to their specific needs [63].
Table 11 classifies the set of CMTs based on their support for extensibility. Figure 6 shows that half of the CMTs, 50.0%, can be extended through the use of plugins or add-ons, while the rest (50.0%) lacks this capability.
Observations
Half of the surveyed CMTs support extensibility, highlighting its significance as a competitive advantage, specially for CMTs designed for domain-specific modeling, such as MetaEdit+ and DeltaEcore, which frequently incorporate extensibility features to allow users to tailor the CMT to their specific domain needs.
We also note that 11 out of 16 open-source CMTs, like Modelio and Sirius Web, provide extensibility mechanisms. This phenomenon can be traced back to the fact that open-source CMTs use open-source modeling frameworks like Eclipse EMF, which provide off-the-shelf plugin architectures or API-based customization. This is in line with the open-closed principle [64] of object-oriented software design, which roughly states that a software module should be closed to modification, but nonetheless open to extensions, e.g., via custom components/plugins.
Finally, while extensibility is crucial for individual customizations, it also comes with risks potentially impacting collaborative modeling. CMTs with strong extensibility mechanisms may (i) require careful management to ensure compatibility and interoperability among users, (ii) raise the level of complexity of the CMT, negatively impacting their maintainability and understandability, or even (iii) create additional overhead at runtime, potentially lowering the workspace awareness dimension (see Sect. 4.4).
4.3 Collaboration
Collaboration features are responsible for enabling efficient groupwork across the involved stakeholders. Typical means of collaboration in MDSE include versioning systems with merging and branching support, consistency management mechanisms, and conflict resolution algorithms [12]. In this section, we discuss the characteristics of CMTs with respect to the collaboration aspect among the users of CMTs.
Table 11
Classification of technologies with respect to extensibility support
Extensibility
Technologies
Yes
T5,T7,T8,T9,T11,T12,T13,T15, T16,T19
T20,T21,T24,T29,T31,T32
No
T1,T2,T3,T4,T6,T10,T14,T17, T18,T22
T23,T25,T26,T27,T28,T30
4.3.1 Collaboration type
Results
In collaborative modeling, collaboration can take place in two ways: either in real-time or offline [2, 3]. On the one hand, real-time collaboration refers to the ability for multiple users to work on a shared document or project simultaneously, with changes made by one user immediately visible to the other users [54]. This type of collaboration typically requires a continuous connection to the Internet and resembles face-to-face interactions. Real-time collaboration is effective and efficient as it allows to solve issues instantly without incurring any delays. On the other hand, offline collaboration refers to the ability of multiple users to work on a shared document or project without seeing each other’s changes in real-time, even when not connected to the Internet. Users still can work on same modeling artifacts but not at the same time. The changes made by each user are stored locally and synced once a connection is re-established. CMTs providing offline collaboration need to ensure an infrastructure, which facilitates resolving conflicting changes that might occur. According to the analyzed data, half of the CMTs (see Fig. 7 and Table 12) facilitate offline collaboration (50%), followed by real-time collaboration (43.33%). The remaining CMTs (6.66%) offer both types of collaboration, depending on the scenario at hand.
Classification of technologies by collaboration type
Collaboration type
Technologies
Offline
T1,T3,T4,T5,T8,T12,T13,T15,T16
T19,T20,T21,T29,T30,T31,T32
Real-time
T2,T6,T7,T9,T10,T11,T14,T18,T23
T24,T25,T26,T27,T28
Hybrid
T17,T22
Observations
The choice between real-time and offline collaboration type depends on the specific requirements and goals of the current project. Overall, this result is in line with those of our previous industrial survey on collaborative MDSE practices and needs [12], where both collaboration types were as highly needed by software practitioners, even though currently offline participation is adopted more often than real-time collaboration. This means that current CMTs are mainly aligned with the needs of practitioners.
If we look at recent academic research on collaborative MDSE [3], we observe a different phenomenon; researchers tend to investigate more aspects related to real-time collaboration as compared to offline collaboration. We do not have an objective explanation for this phenomenon, but we speculate that it might be due to the fact that offline collaboration has been extensively studied in the last decades (e.g., think about all studies about versioning [65], models evolution [66], change propagation [67]).
Interestingly, Modelix (T17) and the MONDO Collaboration Framework (T22) support a combination of both real-time and offline collaboration. As an example, in the following we describe how the two collaboration types are combined in the MONDO Collaboration Framework. In both offline and real-time collaboration scenarios, the MONDO Collaboration Framework leverages a backend based on off-the-shelf version control systems (e.g., Subversion or Git) for model storage and version control. In offline mode, a federation of so-called front repositories provides access to a subset of modeling elements in the central repository, based on their access and authorization rights; users interact with front repositories via standard versioning protocols and client software. In real-time mode, users collaborate on models directly within a web-based editor (implemented as an Eclipse RAP application), bypassing the need for local client installations. Both collaboration types utilize a fine-grained access control mechanism to manage user permissions.
4.3.2 Network architecture
Results
A network architecture in a collaborative MDSE framework indicates whether the system is organized as a distributed or centralized system.
A distributed network architecture for collaborative MDSE refers to a system in which different components, such as clients, servers, and data storage, are located in different locations and connected through a network. It allows multiple users to access and work on the same model from different locations and provides better scalability as well as fault tolerance [68].
In contrast, a centralized network architecture for collaborative MDSE refers to a system where all components, such as clients, servers, and data storage, are located in a central location and connected through a network. It allows for better control and management of the system but also makes it more vulnerable to single points of failure. The choice of network architecture depends on the specific requirements and goals of the project. Distributed architecture is suitable for projects that require high scalability and fault tolerance, while centralized architecture is suitable for projects that require more control and better management.
Besides those two, other architectures such as peer-to-peer (P2P) and hybrid are also used in CMTs. P2P computing refers to a network of equals that allows two or more individuals to collaborate spontaneously without necessarily needing any centralized coordination [69]. Hybrid is a mix of distributed and centralized architectures.
Fig. 8
Classification of technologies by network architecture
Figure 8 displays the network architectures adopted by different CMTs. The centralized architecture is the most prevalent, utilized by 41.37% of the technologies. Hybrid and distributed architectures are leveraged by 27.58% and 24.13% of the technologies, respectively, while the remaining 6.8% of the technologies rely on P2P architecture. This finding suggests that although the centralized architecture is currently the most popular option among CMTs, hybrid and distributed architectures are gaining momentum.
Table 13
Breakdown of technologies by architecture
Architecture
Technologies
Distributed
T1,T5,T8,T12,T13,T15,T19,T20
Centralized
T2,T4,T6,T16,T17,T21,T22,T23, T24,T25,T26,T29,T32
P2P
T14,T28
Hybrid
T3,T7,T9,T10,T11,T18,T27, T30,T31
Table 13 presents a breakdown of the network architectures utilized by different CMTs. Of the 32 technologies analyzed, six were found to use a hybrid network architecture, which is a combination of centralized and distributed network structures, but not with P2P.
Observations
The observed trends can be attributed to several factors. Centralized architectures remain popular due to their ease of management, control, and lower complexity, making them ideal for many projects, especially where legacy systems and resource constraints, like in Sirius Web (T32) play a central role [70]. Hybrid solutions, like MetaEdit+ (T10), offer a balance between control and scalability, while distributed architectures provide scalability and fault tolerance, driven by advancements in technology and global collaboration needs [71, 72]. The choice of architecture depends on the scale of collaboration, the distribution of the team, and the available resources, with centralized models more suitable for smaller projects while hybrid and distributed options are better for larger global teams [73]. These factors explain why centralized systems are still dominant, but hybrid and distributed architectures are gaining traction. P2P architectures face challenges with coordination, consistency, and security, limiting their use to specific, decentralized applications [74].
4.3.3 Versioning
Results
Since the modeling artifacts also evolve in their life cycle, for instance modifications made due to changed requirements. In these scenarios, the availability of a versioning mechanism becomes quite important. Versioning refers to the process of tracking and managing changes that a model has undergone over time. It allows multiple users to edit the same model simultaneously without interfering with each other’s work [75]. Versioning typically involves creating snapshots of the model at different points in time, allowing users to roll back to previous versions if needed [76]. When a user edits a model, a new version is created and the old version is stored as a historical version [77] (Table 14).
Table 14
Breakdown of technologies by versioning percentage
Despite the fact that the need for model versioning is mainly recognized by practitioners [12], our analysis shows that more than half of the CMTs (53.12%) do not provide versioning capabilities, as illustrated in Fig. 9.
Observations
The lack of versioning capabilities in 53.12% of tools can be attributed to multiple factors. Implementing and maintaining versioning are technically challenging and resource-intensive [75], often deprioritized in resource-constrained projects, as in the case of academic tools like DeltaEcore (T4). Additionally, end-users often rely on external version control systems [78], reducing the urgency for built-in features, for instance EMF.Cloud (T16) exploits Git. Those CMTs that are aimed at simpler use cases, such as Parsafix (T18), or less dynamic scenarios, may not prioritize versioning either [76], and older CMT platforms may lack versioning due to design limitations, making retrofitting overcomplex [78].
4.4 Communication
Communication features play an important role in enabling a meaningful exchange of information and models among stakeholders involved in collaborative modeling. These features supplement the information conveyed by the models used in the collaboration. Examples of commonly used communication channels include chats, wikis, model annotations, comments, change proposals, and forums [12].
4.4.1 Communication type
Results
In collaborative modeling, communication type refers to how users interact and exchange information while working on a shared model. Communication can be done in two ways, that is, synchronous or asynchronous [79]. Synchronous communication refers to real-time communication in which all users are participating and working on the same model at the same time. This type of communication allows for immediate feedback and enables users to see the changes made by other users in real time. Examples of synchronous communication include instant messaging, video conferencing, and audio calls. Asynchronous communication refers to communication that occurs at different times, where users can work on the model independently and at their own pace. Examples of asynchronous communication include email, annotations, comments, and commit messages. The choice of communication type depends on the specific requirements and goals of the project. Synchronous communication is suitable for projects that require real-time interaction and immediate feedback, while asynchronous communication is suitable for projects that require flexibility and independence (Tables 15, 16 and 17).
Table 15
Breakdown of technologies by comm. support
Comm. support
Technologies
Yes
T1,T2,T3,T4,T5,T6,T9,T10
T12,T15,T23,T26
T30,T31,T32
No
T8,T11,T13,T14,T16,T17,T18
T19,T20,T21,T22,T24,T25,T27
T28,T29
The data depicted in Fig. 10a suggest that half of CMTs, 16 out of 32, do not support communication. It is unfortunate to observe that the industry’s needs in the communication dimension starkly contrast with those of academic research [3]. The remaining technologies, however, provide communication support, which can be further classified as either asynchronous or synchronous, depending on the problem or use case addressed by the technology. Figure 10b illustrates that the majority of the CMTs support asynchronous communication.
The lack of communication support in many CMTs and the dominance of asynchronous communication can be attributed to several factors. Several CMTs prioritize core modeling functionalities over integrated communication due to legacy designs, reliance on external tools, and resource constraints [3, 79]. Asynchronous tools provide flexibility for distributed teams, lower implementation costs, and better support for documentation and long-term projects, making them more common than synchronous options [79]. This is also shown in our analysis, since the combination of distributed collaboration and asynchronous communication is the most common of all. Real-time communication requires significant infrastructure and coordination, which can deter implementation and adoption [3]. Nevertheless, this kind of collaboration is successfully provided both in the EMF ecosystem by Sirius (T13) and in MPS by Modelix (T17). Academic research emphasizes comprehensive systems with communication features, while industry often prioritizes practical tools with external integrations, which may lead to a gap between research insights and real-world adoption [3].
4.4.2 Workspace awareness
Results
Workspace awareness refers to the ability of a CMT to allow users to see what other collaborators are doing. It facilitates users to have an understanding of the operations performed by other users on the modeling artifacts in real time. It can include features such as the ability to see the cursor of other users and view changes, comments, and annotations made by other users [80]. Workspace awareness is an important aspect of collaborative MDSE because it allows users to work together more effectively by providing transparency and visibility into the actions and contributions of other users [81] as well as improving communication among team members. Workspace awareness scopes only the events happening in the workspace, it should not be mixed up with synchronous (audio or video) or asynchronous (chats, emails etc) communication.
The data presented in Fig. 11 suggest that a large majority of CMTs, 87.1% does not facilitate workspace awareness. The CMTs T10 and T14 did not provide workspace awareness initially but have added supporting features in their recent releases.
Observations
The limited adoption of workspace awareness in CMTs (87% lacking this feature) can be attributed to several factors. Implementing real-time workspace awareness, such as live updates and cursor tracking, is complex and resource-intensive [80]. Older tools often focused on core functionalities, as workspace awareness was not a primary user requirement [81]. The inclusion of these features in newer versions of some tools, such as MetaEdit+ (T10) and SyncMeta (T14), reflects evolving user demands and competitive pressures. In large teams, real-time awareness features can lead to clutter and overwhelm users [80]. Adding workspace awareness to legacy systems is resource-intensive, slowing widespread adoption. Overall, while historically not prioritized, workspace awareness is gaining attention as user needs and competitive landscapes evolve.
5 Discussion
In this section, we discuss the insights obtained from our analysis of CMTs and highlight their implications for researchers and practitioners. Our results for Model management dimension show that many CMTs are tied to specific modeling languages like UML and BPMN. The dominance of Eclipse and JetBrains MPS frameworks presents both opportunities and challenges. Graphical notations are the most widely supported, followed by textual and tabular notations. For Collaboration dimension, we found that there exists a lack of tools that support both offline and real-time collaboration to meet varying users needs. More than half of the CMTs do not provide versioning capabilities, highlighting a significant gap. While centralized architectures are common, there is a growing interest in distributed and hybrid architectures to improve scalability and fault tolerance. When it comes to Communication dimension, many CMTs lack built-in communication features, necessitating the integration of chat or video features to facilitate collaboration. Workspace awareness is a critical yet an underrepresented feature in existing tools. Tools like the Language Server Protocol (LSP) and Eclipse GLSP offer better integration and scalability, addressing some limitations of traditional CMTs. The results of our research can assist practitioners in selecting the technology that suits best their requirements and help researchers to identify areas for further investigation and innovation. Table 18 summarizes the main implications for each parameter of our data extraction form.
Table 18
Overview of the main implications of this study for both researchers and practitioners
Parameters
Implications
Researcher
Language support
We recommend researchers to work on language-independent technologies for collaborative modeling
Technical space
We recommend researchers to address existing challenges in both the Eclipse and MPS ecosystems and to provide better means for customization (in the case of stand-alone technical spaces).
Supported editor
There is no pressing need to address the existing technological landscape in the context of additional types of editors
Collaboration types
We recommend researchers (and developers) to address the lack of hybrid technologies to meet the growing demand of users for CMTs that provide both offline and real-time collaboration capabilities
Versioning
We recommend researchers to focus on developing technologies that incorporate versioning
Communication types
We suggest researchers to focus on identifying ways to incorporate a built-in communication mechanism in their CMT to provide a more comprehensive and integrated collaborative experience for the modelers
Workspace awareness
We recommend researchers to work on incorporating features for workspace awareness into their future solutions
Practitioners
Language support
We advise practitioners to invest in acquiring proficiency in diverse modeling languages, since various technologies in the collaborative MDSE landscape have varying advantages and varying levels of language support
Technical space
Practitioners should invest in improving their skills and knowledge, independently of specific technical spaces since several CMTs are employing their own, ad hoc technical space
Supported editor
Practitioners can focus their efforts primarily on graphical, textual, and tabular editors since they are the most used/supported ones in todays CMTs
Collaboration types
In the current landscape of CMTs, there exists a balance between offline and real-time collaboration. There is no pressing need for the practitioners to find alternatives
Communication types
At present, many CMTs do not provide communication support. We recommend practitioners seek an alternative to fulfill their communication needs while working with the CMTs
Workspace awareness
Currently, a large number of CMTs provide low support in terms of workspace awareness. It is suggested to invest effort on this aspect of collaborative MDSE in future tools.
5.1 Implications for researchers
5.1.1 Language independence
Our analysis indicates that many CMTs are dependent on specific modeling languages such as UML or BPMN. Though these languages have relatively larger userbase, language dependent CMTs limit flexibility and usability for users unfamiliar with these languages. Developing language-independent tools can cater to a diverse set of users by eliminating the need to learn new terminologies and syntaxes, thus fostering wider adoption and usability of CMTs, since learning new terminologies and syntaxes is challenging [82, 83].
5.1.2 Enhancing ecosystem customization
In our study, it emerged that CMTs are mostly based on Eclipse EMF or are standalone, with a relatively smaller percentage which is MPS based. This trend presents both challenges and opportunities. Eclipse has been in existence since 2002 and has a more established user base and community, resulting in higher adoption rates and support. However, there are still issues associated with EMF-based technologies presenting additional complexities, such as Eclipse’s plugin architecture, documentation quality, initial technology setup, and interoperability [84]. While Eclipse offers more general-purpose features, MPS has a more specialized focus on language workbench and model engineering. Users of JetBrains MPS face challenges related to language modularity and complexity when implementing DSLs [85].
Standalone technologies allow to overcome these issues since developers can implement their own features. These added benefits definitely come at the cost of potentially higher development time. However, we suggest researchers in Eclipse and MPS to provide more options for customization, enabling technologies to inherit existing technological spaces.
Our study suggests that CMTs primarily offer two notations in their modeling editors: textual and tabular. There are only a limited number of CMTs that provide support for more than two variants in the editor, and there is relatively less support for interactive notations, such as sketching. However, our recent study targeting industry experts using collaborative MDSE technologies indicates that the need for sketch-based notations in collaborative MDSE is neither significant nor expected to gain popularity in the near future [12]. There is no pressing need to address the existing technological landscape in the context of additional types of editors. However, it is important to continue monitoring changes and advancements in the field to ensure that the notations remain relevant and effective for collaborative modeling.
5.1.3 Support for hybrid collaboration
Previous research indicates that there is significant demand for both offline and real-time collaboration in the field of collaborative MDSE [12]. Our results depicted a slightly higher percentage of CMTs providing offline collaboration. There is currently a significant gap in CMTs that support both offline and real-time collaboration. Hybrid collaboration tools are increasingly in demand as they offer flexibility for various working conditions and preferences. Future research needs to prioritize the development of CMTs that integrate both collaboration modes, thus enabling seamless teamwork regardless of geographical location or connectivity constraints.
5.1.4 Version control integration
The current landscape of CMTs is heavily dependent on robust version control mechanisms. These mechanisms are crucial due to a high demand for versioning capabilities in today’s collaboration technologies [12]. However, a significant number of technologies still lack adequate support for version control which can limit their usability and flexibility. Given this deficiency, it is important that research and development efforts concentrate on integrating version control features into new and existing technologies. By doing so, developers can better meet user needs, providing enhanced flexibility and functionality in CMT applications.
5.1.5 Integrated communication mechanisms
Effective communication is critical for successful collaboration, yet many existing technologies lack built-in communication features. Practitioners often rely on external technologies such as email, messaging apps, or chat platforms to overcome this gap. The existing technologies primarily support asynchronous communication, however, the need for both asynchronous and synchronous communication is equally prevalent. Future research should focus on integrating communication mechanisms such as chat or video conferencing within CMTs. This integration will streamline the collaborative process and enhance the overall user experience by reducing the need to switch between different applications.
5.1.6 Boosting teamwork with workspace awareness
Workspace awareness is an emerging feature which enables users to view their collaborators’ activities in the real time and is essential for effective collaboration. Our research findings indicate that many CMTs lack this feature. A significant obstacle in implementing this feature lies in guaranteeing that all collaborators are utilizing the identical model version, ensuring that modifications and that any changes made by one participant are immediately visible to others. This requires a substantial degree of synchronization and coordination across various users, which is challenging to achieve [86]. While there may not be an urgent need for this feature at present, future researchers can work on overcoming these hurdles to incorporate this functionality into the technologies for future aspirations.
Our analysis shows that although few characteristics of CMTs can align, there are trade-offs between the three dimensions of collaborative MDSE. For example, while real-time collaboration enhances immediate feedback, it may also introduce (different) complexities in conflict resolution compared to offline collaboration. Similarly, integrating comprehensive communication mechanisms might improve user experience, but could also lead to performance overhead. Understanding these trade-offs can help to design more balanced and effective CMTs.
Suggested research questions for future studies on, and for, CMTs
By building on our analysis of the current landscape of collaborative MDSE tools and our experience in various industrial and academic research projects, we propose the following research questions that can help guide future investigation and innovation in this domain:
How can CMTs incorporate translation layers or adaptors to bridge language-specific features while maintaining interoperability?
How can CMTs offer greater customization options while maintaining ease of setup for users with varying levels of technical expertise?
What innovations can CMTs implement to enable real-time updates in offline environments once connectivity is restored?
How can CMTs ensure a consistent user experience across hybrid collaboration modes?
How can CMTs ensure secure and context-aware communication within the tool environment?
What version control features should be integrated into CMTs to support real-time conflict detection and resolution in collaborative environments?
What benchmarks or testing frameworks can be developed to evaluate the scalability of collaborative MDSE tools?
5.2 Implications for practitioners (developers and tool vendors)
5.2.1 Proficiency in multiple modeling languages
The findings of this study indicate that a relatively larger number of CMTs are dependent on specific languages for their functionality. Specifically, UML and BPMN are most commonly supported by the technologies in this space. Consequently, tool users should invest in learning these languages as this proficiency will enable them to leverage full potential of the tools. However, it is worth noting that in recent years, new technologies have emerged that are independent of languages, such as the Language Server Protocol (LSP)14., allowing users to maintain continuity and build expertise with a single technology. This shift toward language independence has the potential to provide greater flexibility and ease of use for practitioners in the field of collaborative modeling.
5.2.2 Staying updated with technological advancements
In the context of technical space, standalone technologies are widespread in the modeling landscape. In this context, EMF-based technologies are widespread in our dataset, with only a few using other technologies, like the use MMPS or Atom. Staying updated with advancements and improvements in EMF and other standalone technologies will ensure effective utilization of most recent and advanced tools available. This may pose a challenge for some developers and may require a significant investment in terms of time and resources to learn new technologies and concepts. Participation in training programs, workshops, hackathons, and communities of practice can facilitate this continuous learning process.
5.2.3 Modeling notations
In the landscape of CMTs, graphical, textual, and tabular variants are the preferred choices for editors. These notations have become the de facto standard in the technological landscape [12], allowing practitioners to use a single technology to fulfill their needs. However, for other interactive editors such as tree and sketch, there are fewer options available as the demand for these editors is not as significant [12].
5.2.4 Investing further in in-built communication features
Our study reveals that in the collaborative MDSE domain, there is a significant absence of in-built communication features. This is aligned with the previous findings where communication is found to be the most neglected dimension in collaborative MDSE research spectrum [3], yet demanded and desired by practitioners [12]. A few technologies including ADOxx, Bizagi, Bonita Studio, etc. provide asynchronous communication via email, messages, and forums; however, we cannot dismiss the importance and efficiency of synchronous communication in collaboration sessions. We expect that tool developers will take into consideration the growing demand for in-built communication features. In the meantime, tool users can resort to external means to fulfill their communication requirements while collaborating.
5.2.5 Investing further in features for worskapce awareness
Prioritizing CMTs that offer built-in workspace awareness features can significantly enhance productivity. These functionalities provide real-time insights into team activities. For now, the support for the workspace awareness is limited in CMTs. As a result, practitioners may need to find alternative methods for sharing updates about their modeling activities, which might increase the risk of adding overhead to the collaboration.
5.2.6 Adapting to hybrid collaboration models
Previous research showed that practitioners tend to need both real-time and offline collaboration [12]. It might be interesting to work on CMTs that support a hybrid collaboration model that combines offline and real-time collaboration. This flexibility will allow teams to collaborate effectively in today’s work environment, where synchronous and asynchronous work models coexist. Technologies that offer robust support for hybrid collaboration will be essential for maintaining productivity and cohesion among distributed teams.
Relevance of Modern Solutions: Modern options such as the Language Server Protocol (LSP) and web-based solutions like Eclipse GLSP play a crucial role in addressing some of the limitations of traditional CMTs. These solutions offer better integration, flexibility, and scalability, which are essential for contemporary modeling practices. Practitioners should evaluate and adopt these modern tools to stay updated with industry trends and enhance their collaborative MDSE efforts.
Implementation choices matter: It is important to note that in a few cases, implementation choices can play a vital role in the functionality and usability of CMTs. For instance, while the choice regarding the network architecture (such as centralized, distributed, peer to peer) is primarily an implementation aspect, but it can still have a strongly visible effect on the functional aspects of the CMT as well. For example, a centralized architecture can lead the CMT having a single point of failure, preventing all users from collaborating in case of severe failure, whereas in principle a peer-to-peer network or simply a distributed one with horizontal scaling might mitigate the risk of completely disrupting the collaboration capabilities of the CMT [2]. Moreover, a distributed architecture where, for example, the models repository and the component for managing collaboration sessions run on separate nodes within the network has some inherent (and user noticeable) latency due to the communication overhead between those nodes. This shows that by carefully considering the implementation choices, developers of CMTs can create more effective, efficient, and user-friendly tools that enhance the overall collaboration experience.
In essence, our observation is that the landscape of collaborative MDSE technologies is continuously evolving, with new tools and features emerging to meet diverse user needs. We highlighted several areas where current CMTs can be improved and provides recommendations for researchers and practitioners to address these gaps. By focusing on language independence, hybrid collaboration support, integrated communication mechanisms, and workspace awareness, future CMTs can offer more comprehensive and user-friendly solutions. Practitioners, in turn, should prioritize continuous learning and the adoption of tools that best meet their collaborative needs. Through these efforts, the field of collaborative MDSE can achieve greater efficiency, flexibility, and inclusivity. Understanding the trade-offs and aligning dimensions within CMTs will further enhance their effectiveness and adoption in both academic and industrial settings.
Based on the obtained results and their implications for practitioners, we propose the following set of development lines to guide developers toward innovating their future CMTs:
What features are essential for reducing the learning curve associated with transitioning from language-specific to language-independent modeling environments?
How can standalone CMTs be designed to balance the trade-offs between development effort, language independence, and feature flexibility?
What tools can be designed to enhance real-time workspace awareness, while ensuring accurate synchronization among collaborators?
How can CMTs dynamically adapt their resource usage based on the complexity of the model and the number of collaborators?
How can CMTs leverage cloud-based technologies to offer scalable, platform-agnostic collaboration features, possibly with recent technologies like LSP (language server protocol) and web-based solutions?
5.3 Threats to validity
5.3.1 Internal validity
This study’s main internal threat to validity is the identification of CMTs obtained from academic papers and grey literature, as this could result in missing potential targets or including those outside the scope of the study. To mitigate the threat, we carefully designed the study and discussed it in detail in Sect. 3.2. It ensures that the technologies chosen for analysis are relevant. This helped us minimize the selection bias, which could have affected the accuracy and reliability of the study results.
5.3.2 External validity
The primary concern for external validity in our study may arise from the potential need for more representation of the broader research on CMTs due to our reliance on selected primary studies. To address this concern, we employed a search strategy that combined both automatic search and forward snowballing of the primary studies identified through the automatic search. We sought to minimize selection bias also by having the dataset reviewed by a panel of experts in the field of CMTs. To further mitigate the risk, we applied explicit and well-defined inclusion and exclusion criteria, which were strictly followed during the selection phase. By adopting these measures, we aimed to enhance the representativeness of our study and thereby minimize the potential for external threats to validity.
5.3.3 Construct validity
We recognize that the selection of parameters used to analyze the technologies can pose a threat to construct validity. Therefore, it is critical to carefully choose the parameters that can broadly represent different categories of modeling technologies. In order to mitigate this threat, we analyzed existing studies and research that specifies the recommended parameters used in CMTs from the viewpoint of researchers and practitioners. We have classified these parameters into three categories: model management, communication, and collaboration [12]. Additionally, we have performed a quantitative analysis of the results obtained from our studies. By doing so, we aim to ensure that the parameters we have selected are appropriate and representative of different categories of CMTs, thus enhancing the construct validity of our study.
5.3.4 Conclusion validity
In our study, the primary threat to conclusion validity is the possibility of measurement bias. To mitigate it, we have established a robust framework that is applied consistently across all technologies (see Sect. 3.5).
6 Conclusions and future work
In this paper, we presented an in-depth analysis of collaborative MDSE technologies from both researcher’s and practitioner’s perspectives. To conduct this study, we reviewed a total of 77 academic literature and 100 grey literature sources. Through a thorough selection process, we were able to identify 814 technologies and further narrowed down our selection to 32 technologies by applying three inclusion, and three exclusion criteria, and through expert recommendations. These technologies were then evaluated by a group of experts in the field of collaborative modeling, who provided valuable feedback and suggestions for additional technologies to include in our study.
Upon analyzing the results, we observed that many of the technologies currently available in the market mainly offer a single capability in terms of collaborative modeling. For example, DeltaEcore is only a language workbench and does not offer other capabilities. Additionally, we noticed that the majority of the technologies only support one or two notations, with only a few offering interactive notations such as Sketching and Tree. Furthermore, the balance between real-time and offline collaboration is an important factor in collaborative modeling, yet we found that only two technologies, Modelix and MONDO collaborator, offered both. Additionally, we identified a significant gap in the number of technologies that provide workspace awareness.
Our study highlights certain gaps in the current landscape of collaborative modeling, which suggests a need for further research in this field. To address these gaps, we recommend researchers develop new CMTs that provide more comprehensive capabilities and overcome the limitations of current CMTs. For instance, our study reveals that most CMTs are language dependent, and it would be beneficial to introduce workspace awareness in new or existing CMTs. Similarly, practitioners could benefit from having access to a wider range of technologies that meet their needs for collaborative modelings, such as those that support features like Tree and Sketch in editors. We recommend that practitioners become proficient in different CMTs to better meet their expectations and needs.
To leverage existing specialized collaborative MDSE tools in developing a comprehensive collaborative MDSE environment, the learning curve can be quite steep. Additional mechanisms, particularly on the HMI side, are needed to simplify the seamless use of multiple collaborative MDSE tools. Furthermore, there are significant research challenges related to interoperability, cyber-security, distributability, as well as predictability, and timeliness, where more research, both theoretical and technical, is needed.
In terms of future work, expanding the scope of the study to include a broader range of types of collaborative MDSE technologies that were not included in the current study is important. Additionally, performing a more in-depth analysis of newer parameters, such as user interface, usability, and scalability of the reviewed technologies, would provide more detailed and valuable information for both researchers and practitioners. Additionally, it would be interesting to compare the performance of the reviewed technologies when used in different domains and projects, and this would give a better understanding of the technology’s capabilities and limitations. A user study can be conducted to understand how practitioners use the technology and what are their expectations and needs. This would help researchers to understand how to improve the technologies to better meet the needs of practitioners.
Acknowledgements
The authors would like to express their gratitude to the external reviewers of this study: Eugen Schindler, Maximilian Koegel, Federico Tomassetti, Wim Bast, Mattias Mohlin, Jan-Philipp Steghöfer, Bran Selic, Istvan David, Ludovico Iovino, Luca Berardinelli, and Alexander Raschke. Their insightful comments and constructive feedback greatly enhanced the quality of this research paper. The authors are also thankful for the valuable suggestions and technologies proposed by the reviewers during the selection process, which have contributed significantly to the richness and diversity of the presented research.
This research was partially funded by the Rijksdienst voor Ondernemend Nederland (RVO) through the ITEA3 BUMBLE project (18006).
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.
Publisher's Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
Abhishek Choudhury
Abhishek works as an AI Engineer specializing in AI-driven query optimization for relational databases. He holds a Computer Science BSc degree from Staffordshire University, UK, and a Computer Science MSc degree from Vrije Universiteit Amsterdam, specializing in Big Data. His MSc thesis focused on developing an AI model to classify different sitting postures while working in front of a computer.
Ivano Malavolta
Associate professor and Director of the Network Institute at the Vrije Universiteit Amsterdam (The Netherlands). His research focuses on software engineering, with a special emphasis on green software and software architecture. He applies empirical methods to assess practices and trends in the field of software engineering. He authored more than 150 scientific articles in international journals and peer-reviewed international conference proceedings. He is a program committee member and reviewer of international conferences and journals in the software engineering field. He received a PhD in computer science from the University of L’Aquila in 2012. He is a member of ACM, IEEE, VERSEN, and Amsterdam Data Science. More info at: www.ivanomalavolta.com
Federico Ciccozzi
Federico Ciccozzi is a Professor in Computer Science at Mälardalen University (Sweden), head of research education in computer science and electronics, and leader of the automated software language and software engineering research group. His research focuses on several aspects of model-driven engineering and automated software engineering for the development of complex embedded safety-critical cyber-physical systems based on domain-specific modeling languages (DSMLs). More info at: www.es.mdh.se/staff/266-FedericoCiccozzi
Kousar Aslam
Assistant Professor at Vrije Universiteit Amsterdam, The Netherlands. Her research focuses on collaborative modeling, ethical issues in the software industry, and development of inclusive iCT applications. She is a reviewer of international conferences and journals in the software engineering field. She received the Ph.D. degree in computer science from the Eindhoven University of Technology. She is a member of VERSEN, EUGAIN, and Amsterdam Data Science.
Patricia Lago
Full professor and Director of the Digital Sustainability Center at Vrije Universiteit Amsterdam, The Netherlands, where she founded the Software and Sustainability research group in the Computer Science Department. Her passion in research is to create software engineering knowledge that makes software better, smarter, and more sustainable. Her research focuses primarily on software architecture design and decision making, software quality assessment, and software sustainability. She is the recipient of an Honorary Doctorate at NTNU, Norway, for her contribution to the field of software sustainability, and of the 2023 IEEE CS TCSE New Directions Award. She has a PhD in Control and Computer Engineering from Politecnico di Torino and a Master in Computer Science from the University of Pisa, both in Italy. She has published over 250 articles in all major scientific conferences and journals of her field. She is a member of ACM and VERSEN, and a senior member of IEEE. More info at: www.patricialago.nl
Di Ruscio, D., Franzago, M., Malavolta, I., Muccini, H.: “Envisioning the future of collaborative model-driven software engineering,” in 2017 IEEE/ACM 39th International Conference on Software Engineering Companion (ICSE-C), (2017), pp. 219–221
2.
Franzago, M., Di Ruscio, D., Malavolta, I., Muccini, H.: Collaborative model-driven software engineering: a classification framework and a research map. IEEE Trans. Software Eng. 44(12), 1146–1175 (2017)CrossRef
3.
David, I., Aslam, K., Faridmoayer, S., Malavolta, I., Syriani, E., Lago, P.: “Collaborative model-driven software engineering: a systematic update,” in 2021 ACM/IEEE 24th International Conference on Model Driven Engineering Languages and Systems (MODELS). IEEE, (2021), pp. 273–284
Franzago, M., Di Ruscio, D., Malavolta, I., Muccini, H.: “Collaborative model-driven software engineering: a classification framework and a research map,” IEEE Trans. Softw. Eng. PP, 1–1, (2017)
8.
Marco Brambilla, M. W.: Jordi Cabot, Model-Driven Software Engineering in Practice, Second Edition. Springer Cham, (2022), pp. 7–24
Muccini, H., Bosch, J., van der Hoek, A.: Collaborative modeling in software engineering. IEEE Softw. 35(06), 20–24 (2018)CrossRef
12.
David, I., Aslam, K., Malavolta, I., Lago, P.: Collaborative model-driven software engineering—a systematic survey of practices and needs in industry. J. Syst. Softw. 199, 111626 (2023). https://doi.org/10.1016/j.jss.2023.111626CrossRef
13.
Bagheri, E., Ghorbani, A.: An exploratory classification of applications in the realm of collaborative modeling and design. Inf. Syst. E-Bus. Manag. 8, 257–286 (2010)CrossRef
14.
Wohlin, C.: “Guidelines for snowballing in systematic literature studies and a replication in software engineering,” in Proceedings of the 18th International Conference on Evaluation and Assessment in Software Engineering, ser. EASE ’14. New York, NY, USA: Association for Computing Machinery, (2014). [Online]. Available: https://doi.org/10.1145/2601248.2601268
15.
Ali, N.: “Towards Guidelines for Conducting Software Process Simulation in Industry,” Ph.D. dissertation, (01 2013)
16.
King, D.W., Lashley, R.: A quantifiable alternative to double data entry. Controlled Clin. Trials 21(2), 94–102 (2000)CrossRef
17.
Vieira, S. M., Kaymak, U., Sousa, J. M. C.: “Cohen’s kappa coefficient as a performance measure for feature selection,” in International Conference on Fuzzy Systems, (2010), pp. 1–8
18.
Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., Wesslén A., et al., Experimentation in Software Engineering. Springer, (2012), vol. 236
19.
Spencer, D.: Card Sorting: Designing Usable Categories. Rosenfeld Media (2009)
20.
Keele, Staffs, “Guidelines for performing systematic literature reviews in software engineering,” Technical report, ver. 2.3 ebse technical report. ebse, Tech. Rep., (2007)
Christian Bartelt, T. S., Molter, Georg: “A model repository for collaborative modeling with the jazz development platform,” Hawaii International Conference on System Sciences, vol. 8, (2009)
50.
Calegari, D., Szasz, N.: Verification of model transformations: a survey of the state-of-the-art. Electron. Notes Theor. Comput. Sci. 292, 5–25 (2013)CrossRef
51.
Lars Bendix, P. E., Molter, Georg: “Diff and merge support for model based development,” NA, NA
52.
Kelly, S.: Collaborative Modelling with Version Control. In: Seidl, M., Zschaler, S. (eds.) Software Technologies: Applications and Foundations, pp. 20–29. Springer International Publishing, Cham (2018)CrossRef
Riemer, K., Frößler, F.: Introducing real-time collaboration systems: development of a conceptual scheme and research directions. Commun. Assoc. Inf. Syst. 20, 204–25 (2007)
55.
Torres, W., Van den Brand, M.G., Serebrenik, A.: A systematic literature review of cross-domain model consistency checking by model management tools. Softw. Syst. Model. 20, 897–916 (2021)CrossRef
56.
Geambaşu, C. V.: “BPMN vs. UML activity diagram for business process modeling,” in Proceedings of the 7th International Conference Accounting and Management Information Systems AMIS, (2012), pp. 934–945
57.
Malavolta, I., Lago, P., Muccini, H., Pelliccione, P., Tang, A.: What industry needs from architectural languages: a survey. IEEE Trans. Software Eng. 39(6), 869–891 (2013)CrossRef
Gerhart, M., Boger, P. D. M.: “Modigen: model-driven generation of graphical editors in eclipse,” Int. J. Comput. Sci. Inform. Technol., vol. 8, (2016)
60.
Addazi, L., Ciccozzi, F.: Blended graphical and textual modelling for uml profiles: a proof-of-concept implementation and experiment. J. Syst. Softw. 175, 110912 (2021)CrossRef
61.
Ignat, C.-L., Norrie, M.: “Draw-together: graphical editor for collaborative drawing,” ACM, pp. 269–278, (11 2006)
62.
Ciccozzi, F., Tichy, M. ,Vangheluwe, H., Weyns, D.: “Blended modelling—what, why and how,” in 2019 ACM/IEEE 22nd International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C), (2019), pp. 425–430
Altmanninger, K., Seidl, M., Wimmer, M.: A survey on model versioning approaches. Int. J. Web Inform. Syst. 5(3), 271–304 (2009)
66.
Paige, R.F., Matragkas, N., Rose, L.M.: Evolving models in model-driven engineering: state-of-the-art and future challenges. J. Syst. Softw. 111, 272–280 (2016)CrossRef
67.
Hinkel, G., Burger, E.: Change propagation and bidirectionality in internal transformation DSLs. Softw. Syst. Model. 18, 249–278 (2019)CrossRef
68.
Piyadasa, Tharinda Dilshan: “Centralized vs Distributed Systems in a Nutshell,” 2020, accessed on Feb 20 (2023). [Online]. Available: https://x.gd/hAowF
69.
Cabani, A., Ramaswamy, S., Itmi, M., Shukri, S., Pécuchet, J.-P.: Distributed Computing Systems: P2P versus Grid Computing Alternatives, (2007), pp. 47–52
70.
Jiang, Y., et al.: Centralized architectures in collaborative modeling: challenges and opportunities. J. Collab. Technol. 10(3), 123–135 (2022)
71.
Smith, A., Patel, R.: Scalability and flexibility: the case for distributed and hybrid architectures. Int. J. Netw. Syst. 8(4), 567–580 (2021)
72.
Team, T. T.: “White paper: Emerging technologies in collaborative systems,” (2023), available online: https://www.techtrends2023.com
Doe, J., Clark, T.: The role of peer-to-peer architectures in modern collaboration. J. Decentralized Syst. 15(2), 200–215 (2020)
75.
Brosch, P., Seidl, M., Wieland, K., Wimmer, M., Langer, P.: “We can work it out: collaborative conflict resolution in model versioning,” in ECSCW 2009. Springer, (2009), pp. 207–214
76.
Kelly, S., Tolvanen, J.-P.:“Collaborative creation and versioning of modeling languages with metaedit+,” in Proceedings of the 21st ACM/IEEE International Conference on Model Driven Engineering Languages and Systems: Companion Proceedings, (2018), pp. 37–41
David, J.: Collaborative modeling technologies in industry: a survey. Softw. Syst. Model. 19(3), 501–518 (2020)
79.
Gaudou, B., Marilleau, N., Ho, T. V.: “Toward a methodology of collaborative modeling and simulation of complex systems,” Intell. Netw. Collab. Syst. Appl., pp. 27–53, (2011)
80.
Torres, M. J. R., Barwaldt, R., Pinho, P. C. R., de Topin, L. O. H., Otero, T. F.: “An auditory interface to workspace awareness elements accessible for the blind in diagrams’ collaborative modeling,” in Frontiers in Education Conference (FIE). IEEE, (2020), pp. 1–7
81.
Bang, J. young, Popescu, D., Medvidovic, N.: “Enabling workspace awareness for collaborative software modeling,” in The Future of Collaborative Software Development at the ACM Conference on Computer Supported Cooperative Work (FutureCSD), (2012)
82.
Rodrigues da Silva, A.: “Model-driven engineering: A survey supported by the unified conceptual model”. Comput. Languages Syst. Struct. 43, 139–155, (2015)
83.
Bucchiarone, A., Cabot, J., Paige, R., Pierantonio, A.: Grand challenges in model-driven engineering: an analysis of the state of the research. Softw. Syst. Model. 19, 1–9 (2020)CrossRef
Voelter, M., Kolb, B., Szabó, T., Ratiu, D., van Deursen, A.: Lessons learned from developing mbeddr: a case study in language engineering with MPS. Softw. Syst. Model. 18(1), 585–630 (2019)CrossRef
86.
Jae young Bang, N. M., Popescu, Daniel: “Enabling workspace awareness for collaborative software modeling,” ACM, (11 2012)
