Challenges for reuse in collaborative modeling environments Omar Alam Jonathan Corley Constantin Masson and Trent University University of West Georgia Eugene Syriani Peterborough, ON, Canada Carrollton, GA, USA University of Montreal omaralam@trentu.ca jcorley@westga.edu Montreal, QC, Canada constantin.masson,syriani@iro. umontreal.ca ABSTRACT effort among themselves, keep track of issues and bugs, and sched- Software systems are not developed by individuals, and have be- ule the delivery of releases. Together with VCS and repositories, come increasingly collaborative endeavors between stakeholders advances in reuse allowed software development activities to be with complimentary expertise. Model-driven engineering (MDE) more organized and collaborative. For example, a group of develop- facilitates such collaboration by enabling developers to work on ers can use a Git repository to collaborate in coding the classes of models (often domain-specific) rather than application code directly. a software program and another developer can reuse these coded Collaborative modeling environments help promote the integration classes. However, the concern of reuse in collaborative modeling of models. The issue of model reuse is crucial in a collaborative has not been a focus of study yet. environment to foster the practice of modeling. Relying on a ver- In this paper, we present a set of challenges that needs be ad- sion control system as the sole means of reuse limits the usefulness dressed in a framework that enables reuse in collaborative modeling. of collaborative environments. This article discusses a set of chal- Though there are emerging collaborative modeling tools, support lenges that must be addressed in a collaborative environment to for reuse in these tools is limited [19]. Commercial tools such as support model reuse. Our investigation of the state of practice in Rational Rhapsody [11], Visual Paradigm [13], MagicDraw [8], and existing environments shows that they do not provide sufficient Enterprise Architect [6] are modeling tools that are used in industry support for reuse yet. and offer collaborative support. Some MDE technologies, such as Eclipse CDO [2] and EMFStore [5], provide some support for VCS. KEYWORDS Rocco et al. [19] and Franzago et. al. [22] provide an overview of these tools and discuss their potentials and shortcomings. They ac- Model-driven engineering, Collaborative computing, Reusable Soft- knowledge that support for reuse and discovering reusable artifacts ware, Reuse models. is limited, increasing the upfront development cost for many model- based projects. Therefore, the potential benefits of collaborative 1 INTRODUCTION modeling in these approaches is limited. Existing collaborative envi- The development of complex software-intensive systems requires ronments do not provide sufficient support for reuse, and we outline stakeholders from diverse domains to work in a coordinated manner the challenges that we have identified as significant to addressing on different aspects of the system. Often times, developers do not this concern. The paper lists some well-known collaborative envi- just communicate and exchange information among themselves, ronments and tools and investigates how they address the identified but also reuse each other’s work. Various tools have emerged that challenges. serve different kinds of collaboration. For example, a version control In the remainder of this paper, we first discuss the potential system (VCS) is an offline collaboration tool that allows developers for reuse in collaborative modeling environments along with an to reuse each other’s code. A collaborator who uses a VCS does not example scenario exploring cases of reuse in Section 2. In Section 3, have real-time updates on other collaborators’ work. Other tools we discuss challenges for reuse in these environments. In Sec- offer real-time collaboration, by making each collaborator aware tion 4, we examine the support for reuse in some popular modeling of other’s activity through different mediums of communication. environments. Finally, we conclude in Section 5. Online editing tools (e.g., Google Docs and Microsoft Online Office) allow a collaborator to visualize the changes by others in real-time. 2 POTENTIAL FOR REUSE IN Regardless of the specific collaboration tool, reuse of each other’s COLLABORATIVE ENVIRONMENTS work is a major outcome of collaboration. The success of reuse in software development facilitates collabo- 2.1 Model-driven engineering for collaboration ration and coordination during software development activities, as Model-driven engineering (MDE) [21] helps in reducing the gap exemplified by class libraries, services, and components. A devel- between heterogeneous domains using principles of separation of oper can reuse the artifacts developed by other developers through concerns, automatic generation, and domain-specific languages the reuse interfaces of these artifacts. Modern software developers (DSL). In MDE, stakeholders work on models in order to design, typically use VCS, such as Git repositories [1], to collaborate and transform, simulate, and analyze systems. MDE advocates using track development activities throughout their projects. These sys- the most appropriate modeling formalism that expresses the rele- tems allow developers to organize and distribute the development vant properties of the system under development at each level of abstraction, for a given stakeholder group. A formalism used at the environments. Supporting reuse in modeling languages is critical requirement level for scientists is different from the formalism used to supporting reuse of models but is not the within the scope of at the design level for developers. Through model transformations, this paper. models of higher abstraction levels are integrated with lower-level models that are closer to the solution space, such as algorithms, 2.3 Modeling Reusable Components of a data structures, networking, etc. This process continues until an Modern Vehicle executable model (which can be code) is generated [24]. To better understand how modelers collaborate to reuse each other’s MDE is a potential solution to help develop systems collabo- model, we provide an example of reusing components of a modern ratively [31]. Stakeholders from diverse backgrounds who work vehicle. We refer to this example to explain the challenges for on the system under development using different notations can supporting reuse in Section 3. Fig. 1 illustrates an example of collaborate and reuse each other’s work. Furthermore, in a complex collaboration in a vehicle manufacturing project. Initially, two system, models can quickly grow in size, deeming the efforts of a modelers (Modeler 1 and 2) were working on the project. Modeler single modeler insufficient to maintain and evolve the system. In 1 developed the self-parking feature (version 1) to support parallel such projects, collaboration is a necessity to cope with the growing parking, while Modeler2 worked on a model of the car that uses that size of models. Therefore, there is a need for collaborative platforms feature. At some later time, Modelers 1 and 3 collaborated directly that allow teams of stakeholders with varying expertise to work on extending the self-parking feature to support perpendicular together to produce a coherent and complete system [17]. In par- parking as well. Modeler 2 used version 2 of self-parking in Car 2, ticular, there is a need for collaborative environments that support but only for parallel parking support. Eventually, Modeler 4 wanted different modeling formalisms and allow stakeholders to reuse each to reuse all of the self-parking feature version 2 in Car 3. All models other’s models. (components and cars) are assumed to be stored in some available repository. 2.2 Reuse in Collaborative Environments As stated in Section 2.2, we focus on environmental support for reuse in collaborative MDE, e.g., through storage or search In general programming language (GPL) environments, reuse of mechanisms. It is certainly possible that the modeling language libraries and components is common practice. Most programs are used when developing the self-parking component has support for created by mixing several existing libraries ranging from standard reuse, e.g., through reuse interfaces [25, 30]. However, such reuse libraries to custom modules created in-house. Powerful collabo- mechanisms are outside the scope of this paper. rative platforms, such as Github, and specific language features, such as polymorphism, facilitate code reuse in those environments. Most software developers rely on VCS, libraries, or repositories for 3 CHALLENGES AND SUPPORT FOR REUSE collaboration. Unfortunately, this is not the norm in MDE projects. As we consider the potential of collaborative environments, we first Though some new environments are supporting more complex explore the various challenges to reuse and examine how collab- sharing systems (e.g., GenMyModel [7]), ease and efficiency of orative environments might be able to address or mitigate these reuse is still far from the programming equivalent. For example, challenges. We identified these challenges based on our experi- VCS is mostly used to track and collaborate in the development of ences in building and using collaborative modeling environments non-reusable models [19]. Unlike VCS repositories for GPL environ- [14, 32]. This list also builds on the requirements for collaborative ments, model reuse in repositories through VCS is still a challenge environments presented in [28]. in MDE [26]. Enforcing consistent reuse is necessary to cope with the growing complexity of software systems. In MDE, modelers 3.1 Supporting Communication typically create models from scratch because modeling languages As we seek to support collaborative development environments, offer limited support to reuse existing models and modeling envi- a primary consideration is communication between developers. ronments tend not to ship with any reusable models. For example, We consider here two types of communication, direct and indirect when a modeler wants to implement a new DSL, it is common to communication between developers who reuse the same models. build it from scratch instead of reusing existing language artifacts [22]. Lack of support for reuse limits the potential of modeling 3.1.1 Direct Communication. The modeling environment can environments in MDE, as checking out, committing, and updating support direct communication from one developer to another in two models that cannot be reused will not be very useful for collabora- ways. First, the environment can provide synchronous (e.g., text, tive environments. voice, or video chat options) or asynchronous (e.g., messaging sys- When collaborating, modelers may work on the same artifact, tems) communication facilities. These tools have obvious benefits, different parts of the same artifact or distinct artifacts that are part but are not essential to be provided within the environment, as of the whole system [18]. Modelers may need to reuse each other’s external solutions are plentiful (e.g., Slack [12]). However, a more models, or reuse models that are external to the project, i.e., im- essential concern within the environment is the concept of au- ported from a different project. Support for reuse in collaborative thorship. Environments, such as VCS provide facilities to track MDE can be facilitated with reuse mechanisms in modeling lan- the contributors to a project. This enables other developers to guages and their environments. In this paper, we focus only on identify those who are actively working on a system or who have environmental concerns and support, describing challenges and contributed in the past. In other words, the subject of discussion summarizing the current state of practice of collaborative MDE (i.e., the artifact) is defined and traceable in discussion threads. If 2 Model er1 Model er3 Self Self Par kingV1 Par kingV2 Car1 Car2 Car3 Model er2 Model er4 Figure 1: Example for Collaboration in a Vehicle Manufacturing Project modelers use an external communication solution such as Slack, system designed in Java would not be considered complete without it will be difficult to point out which artifact is being discussed, javadocs describing the various interfaces. Yet, a model might be generating confusion among collaborating modelers. Collaborative offered without any concern for describing the use and purposes environments could capture similar authorship information provid- of that model. Thus, the design decisions made when constructing ing the facility to identify the contributions of other collaborators; the models is completely lost, and new collaborators may violate i.e., track the authors of a given model as well as there contributions these decisions when seeking to extend and reuse existing models. over time. Thereby, authorship knowledge within the system can Consider the example scenario detailed in Section 2.3. As Modelers be used to guide collaborators direct communication. Considering 2 and 4 are working on the car, they must understand the usage the example from Section 2.3, Modeler 3 might identify the existing and limitations of the self-parking model being reused. In the fu- Self Parking model, but require adding the additional parking fea- ture, Modeler2 might even work on evolving the Car1 model to ture for their own use cases. If the environment supports tracking an updated version of that vehicle. Having the documentation of authorship, Modeler 3 could then identify Modeler 1 as the most the two versions will help support the decision to either use V2 of appropriate individual to contact, and request a direct collaboration self-parking or stay with V1. If the V2 of the self-parking model as- to update the Self Parking model with the new features. sumes more accurate control of the braking system than V1, it may not be an option for some vehicles. However, this information could be very difficult to identify without some sort of documentation 3.1.2 Indirect Communication. Indirect communication encom- declaring it. passes the practices of documentation including the use of com- The use of comments in general-purpose languages such as Java ments and external sources, such as wikis. This communication has proved to be a great benefit. This practice could easily be sup- informs future modelers of basic concerns, such as structure and ported within collaborative modeling environments. Although com- use of the software artifacts. It can also convey less direct details, ments are important components of a specific modeling language, such as intent and rationale for implementation decisions. This we think they should be supported generically at the environment information is essential to guide new collaborators through the level. Much like a view can be maintained separate from the un- more mundane details of how the system is used. Although it may derlying modeled elements, a comment could be linked to those not be essential for modelers experienced with the systems, the elements without needing to disrupt the focus and intent of the documentation of these basic concerns facilitates new collabora- modeling formalism. The value of the environment providing this tors, and eliminates often non-trivial barriers to reuse. A software 3 generic concern is particularly noteworthy when considering the them. The collaboration scenario in Fig. 1 would be possible when prevalence of domain-specific languages (DSLs). Support at the Modeler1 can store the self-parking component in a repository that environment level, would de-facto offer support to all DSLs within has VCS facilities, to allow Modeler 3 to collaborate and introduce the environment. the second version for that component after making her updates. 3.2 Versioning of Models 3.4 Searching for Models VCS are tools that trace all changes for a system and have facili- One of the powerful features of VCS is the ability to search artifacts ties for managing the history of these changes. Ideally, all basic in the repository. The search activity identifies relevant models VCS features available in a GPL environment may be present in based on their metadata: VCS allows searching elements based on collaborative MDE environments. their change metadata. The search feature is important for collab- Branching is widely used in VCS and requires support for branch oration and reuse of model elements. In Fig. 1, Modelers 2 and merging. The strong semantics of models add a layer of complexity: 4 would be able to search and find the component based on its a simple textual comparison of their serialized format (in XMI) may meta-information and reuse it. In addition to VCS, Integrated De- be insufficient in order to detect all conflicts. Instead, syntactic and velopment Environments (IDEs) allow programmers to search for semantic similarity tests would require a more complex process to code snippets in large code bases or libraries. Collaborative mod- detect conflicts. In GPL environments, projects often reuse a specific eling environments will benefit from advanced search capabilities version of an external dependency. Since dependencies themselves of programming IDEs to reuse from potentially large number of make use of version control, we may have a direct link to the specific projects. Searching can be performed at different levels of gran- version of the dependency. For instance, a CMake build system can ularity: searching for whole models, parts of the model, actions download and compile a specific tag from a branch of the required performed on models, authors of model manipulations. Searching dependency. Though tools like GenMyModel or WebGME [27] can be performed by browsing through a dynamic list of artifacts introduce model repositories with VCS support, linking to specific or by querying the repository. It is important that the result of the versions is not currently possible. Linking to an external model is search is provided quickly for effective collaboration. not enough. A system to select specific version, tag, and branch is required. Consider Fig. 1: Car 1 uses self-parking version 1, which has now evolved to version 2. Without a proper tag system and 3.5 Granularity of Model Reuse support for versioning, Car 1 would be automatically updated to use There are different scenarios that motivate the reuse of a model the self-parking version 2 feature with unforeseen consequences [18]. The most trivial reuse mechanism is copying a model from from the forced shift. In this way, indirect collaborators reusing one project to another. In this case, the copied model and the components from an ongoing project can manage the migration to original evolve separately which may lead to inconsistency. A newer versions of their dependencies on their own timetable. model can be imported to a local project as a reference. In this GPL developers find the ability to reuse the same language el- case, the imported model is a proxy of the original and changes ements across a wide variety of development environments, but in the latter are transposed to the former. When reusing a model, similar interoperability has long been a source of frustration for it is possible to reuse the whole model, as a black box, in which modelers. Modern support for XMI formats presents a step in case the reusing entity communicates with a dedicated interface of the right direction. However, when considering the prominence the reused model. For example, in Fig. 1, Car 1 reuses self-parking of domain-specific models, complete support for tool interoper- version 1 as a whole. ability is a daunting challenge at best. However, modern trends in Alternatively, in a white box approach, one model may reuse developing new languages that compile to a common base (e.g., Cof- specific content from another model, as it is the case with Car 2 feeScript [3]) could present a way forward. and Car 3. The model can expose all elements, the data they en- capsulate, or the relationships between them. Further information may be hidden with the use of views encapsulating parts of a model 3.3 Model Repositories (sub-model or aggregation) [18]. Like when reusing a library, the Nowadays, software developers extensively use repositories, such dependency of a reused model must be meticulously analyzed. as Github, to collaborate and track development activities through- out their projects. Coupled with version control facilities, these systems allow developers to organize and distribute the develop- 3.6 Relationships between Models ment effort among themselves, keep track of issues and bugs, and To fully reap the benefits of repositories, the stored models should schedule the delivery of releases, as well as reuse each other’s define relationships among them. At the modeling language level, code. To facilitate collaboration between modelers, a repository models should define interfaces that facilitate reuse. Reuse in soft- should provide a storage facility that is equipped with VCS features ware engineering is enabled by modular interfaces between arti- (e.g., commit - update versioned history, browse - manually explore facts [25]. Having an explicit model interface makes it possible models). Modelers can use these features to reuse each other’s to apply proper information hiding principles [29] by concealing models, document the changes made to the models, and schedule internal design details of the model from the rest of the application. their activities. When working with models in a project, the storage Unlike programmers, modelers often create models from scratch facility should use the meta-information about the models to orga- due to lack of model interfaces that facilitate reuse. Popular reuse nize them and to record the relationships that may exist between units (e.g., code, components, and services) provide interfaces that 4 Tool Comm. Versioning Repository Search Reuse granularity Relationships WebGME [27] None History, Branch Storage, Tracking Browse elements None None MDEForge [9] Indirect History Storage Browse models None Yes MetaEdit+ [23] None History, Branch Storage Query elements None None OBEO [10] None History Storage, Tracking None View None AToMPM [32] Direct None Storage Browse models Model, View, Element None GenMyModel [7] Indirect History, Tags Storage, Tracking Query elements Model, Element None CDO [2] None History, Branch Storage, Tracking None None None Visual Paradigm [13] Indirect History Storage, Tracking Browse elements Model, Element None EMFStore [5] None History, Branch Storage, Tracking None None None EMFCollab [4] None History,Branch Storage, Tracking None None None Table 1: Support for reuse in popular collaborative modeling environments enable selecting/choosing the reused unit, coordinated customiza- 4 SUPPORT FOR REUSE IN POPULAR tion of the unit and using the customized unit in the context of MODELING ENVIRONMENTS it reusing artifact. These interfaces are important to specify what Table 1 overviews the support for reuse in 10 existing popular structures and behavior the reused model provides to the reusing collaborative modeling environments. We selected the tools based model, and how to adapt reused model to the specific needs of the on the set compared in [28] and surveyed in [19]. We summarize reusing model [15]. how each of these ten tools addresses the challenges described Furthermore, the modeling environment should use the relation- previously. As mentioned earlier, we only investigate whether the ships between models to support traceability. Modelers should be modeling environment address the challenges. It is possible that able to trace models that are involved in their project to understand some of the challenges are addressed at the modeling language their functionality, read their documentation, and access their de- level, which is not the focus of this paper. velopment history. Models can be traced based on the relationships defined by the modeling language as discussed above, as well as relationships that are defined by the environment. If there is a 4.1 Reuse dimensions modeling environment that supports multiple modeling languages, We explain the categories and tags used in Table 1. it can define relationships between related models that serve the Communication category describes support for communica- same purpose as in the case of megamodels that define relation- tion within the environment. ships between different kinds of models [20]. Relationships in a • Direct - environment supports direct communication (e.g., mes- megamodel can range from input/output of model transformations, saging) global constraints across models, to conformance between a model • Indirect - environment supports documenting the models and a type model. at some level, including documenting use, intention, and/or For example, if a modeling environment allows modeling require- authorship ments and design models, and the modelers want to create models • None - environment provides no clear support for commu- for security, they can define traceability links between security nication requirement and design models. Versioning category describes support for managing versions Finally, modelers may visualize the traces and relationships, of models. whether they are defined by the language or by the environment. This enables them to get the big picture of the project, visualize • History - environment provides support for maintaining a changes made to related models, as well as plan and coordinate history of changes made to a model future developments based on those changes. • Branch - environment provides support for managing/merging In Fig. 1, Modeler 3 would need traceability support to update distinct branches of a model the self-parking component. She would need to trace back and • Tags - environment provides support for identifying sig- visualize her changes to version 1 of the component, and this trace nificant versions of a model for reuse between the versions would be useful to Modeler 2 when moving • None - environment provides no clear support for manag- from one version to the next. In addition, model interfaces of the ing versions of models car models are necessary to allow Modelers 2 and 4 to reuse the Repository category describes support for storage, retrieval, or self-parking component and map its elements to elements in the tracking of models. car models. • Storage - environment provides support for storing models • Tracking - environment provides support for tracking fea- tures/bugs for models • None - environment provides no clear support for storage, retrieval, or tracking of models 5 Search category describes support for searching models. The MDEForge and AToMPM only allow the user to browse through tags can be any combination of the following. model file names. OBEO, CDO, EMFStore and EMFCollab do not • Browse - environment provides support to browse artifacts directly support searching, however they rely on the Eclipse IDE • Query - environment provides support to query artifacts for that functionality. • Models - Search is performed on whole models Granularity of Reuse: AToMPM, Visual Paradigm, GenMy- • Elements - Search is performed on parts of models or their Model, and OBEO provide explicit environmental support for reuse. elements Visual Paradigm and GenMyModel enables linking between UML • None - environment does not provide support for searching formalisms, e.g., linking objects in sequence diagrams to classes Granularity category describes the granularity of model that defined in a class diagram. may be reused in the environment (this category considers only AToMPM and OBEO are the only tools where specific views of a environment support and not language level support). large model can be created and reused. Relationships: Most environments could support some forms • Model - environment provides support for reusing models of traceability (especially those with versioning support), but higher as an atomic unit level analysis (e.g., tracing dependencies to understand the impact • View - environment provides support for reusing views of of proposed changes) is not clearly defined by the environments. a model(s) as an atomic unit Furthermore, while most environments could support either hetero- • Element - environment provides support for reusing an geneous models (e.g., via megamodeling) or linking through genera- element of a model as an atomic unit tive transformations (e.g., converting platform-independent models • None - environment provides no clear support for reusing to platform specific models), most environments provide little or existing models, views, or elements in new models no support to analyze and manage these relationships. MDEForge Relationships - category describes support for analyzing re- is the only exception as it provides support for megamodel-based lationships of models to support, for example, understanding of relationships between artifacts and allows modelers to track those existing systems or impact of proposed changes. relationships. • None - there are no such relationships • Yes - there is support for such relationships 5 CONCLUSION 4.2 Discussion Building a software system is typically a collaborative endeavour. Different stakeholders, from potentially diverse domains, coordi- Communication: AToMPM supports direct communication via a nate with each other to fulfill the goals of the software project. chat system. MDEForge and GenMyModel support indirect commu- Reuse is a key facet of software system development that increases nication through documentation (though not comments). Addition- both productivity and maintainability, as well as reducing both ally, some modeling languages support the concept of comments production cost and time-to-market. Increasingly, software practi- within the language, but we feel this should be an environment tioners rely on collaboration tools, such as Github, that allow them concern and not contained within the language. to both document and manage their own work as well as finding Versioning: History is usually an ordered list of changes. Tools and reusing each other’s work. like WebGME, EMFStore and EMFCollab add a Git-like feature, like In MDE, developers collaborate to create, update, and analyze commit hash for each change and a branching system with merging. models of a system under development. However, despite the suc- Tools, such as MetaEdit+, rely on an external VCS in the backend to cess stories in GPLs as exemplified by the proliferation of reuse implement these features. However, history is generally used only through libraries, services, and components; model reuse is a chal- for error recovery inside the project (i.e., revert back to a working lenge in MDE. Over a decade ago, Bran Selic stated clearly that version). We have not identified a tool that supports linking to an mature tool support is necessary to support adoption and growth older version of a model for reuse. GenMyModel does have a tag of MDE [16]. In this paper, we identified challenges facing reuse in system to identify a specific version, but this feature seems to be collaborative MDE environments and investigated the support pro- intended only for internal use. vided by existing environments. Our study of the state of practice Repository: All tools we reviewed have some form of stor- in existing environments shows that their support for reuse is not age system, but some method of discovering new models (Search sufficient. We believe that the identified challenges in this paper in Table 1) is not always present. Tools like WebGME, EMFStore, will help guide the development and improvement of modeling EMFCollab and GenMyModel offer a Github-like repository that tools to provide better support for reuse. In particular, we hope the allows users, among others, to browse models and see other users. categorization demonstrated on the 10 identified environments in Other tools, such as, OBEO and AToMPM use folder path structure. Section 4 will prove useful in analyzing MDE tools for support of Several environments support tracking features and bugs in models these challenges. As we look forward to the future of MDE, we see developed within the environment. a clear place for collaborative modeling environments as well as a Search: MetaEdit+ and GenMyModel provide the most advanced great need to support reuse in those environments. searching mechanism as they allow to query the repository to find model elements that match the query expression. The query is based on the information provided by the metamodel (e.g., type REFERENCES [1] Last accessed: 2017. Git. (Last accessed: 2017). https://git-scm.com/ names or meta-language name). WebGME and Visual Paradigm [2] Last accessed: 2018. CDO Model Repository. (Last accessed: 2018). allow to browse for models, but also model elements, whereas http://www.eclipse.org/cdo/. 6 [3] Last accessed 2018. CoffeeScript. (Last accessed 2018). https://coffeescript.org/. Environment. In MODELS 2013 Demonstration. 21–25. [4] Last accessed: 2018. EMFCollab. (Last accessed: 2018). http://qgears.com/products/emfcollab/. [5] Last accessed: 2018. EMFStore. (Last accessed: 2018). http://www.eclipse.org/emfstore/. [6] Last accessed: 2018. Enterprise Architect. (Last accessed: 2018). http://www.sparxsystems.com/products/ea/. [7] Last accessed 2018. GenMyModel. (Last accessed 2018). https://www.genmymodel.com/. [8] Last accessed: 2018. MagicDraw. (Last accessed: 2018). https://www.nomagic.com/. [9] Last accessed 2018. MDEForge. (Last accessed 2018). http://www.mdeforge.org/. [10] Last accessed: 2018. OBEO Designer. (Last accessed: 2018). https://www.obeodesigner.com/. [11] Last accessed: 2018. Rational Rhapsody Designer Manager. (Last accessed: 2018). www-03.ibm.com/software/products/en/ibmratirhapdesimana. [12] Last accessed: 2018. Slack. (Last accessed: 2018). https://slack.com/ [13] Last accessed: 2018. Visual Paradigm. (Last accessed: 2018). https://www.visual- paradigm.com/. [14] Omar Alam. 2016. Concern-Oriented Reuse: A Software Reuse Paradigm. Ph.D. Dissertation. McGill University. [15] Omar Alam, Jörg Kienzle, and Gunter Mussbacher. 2013. Concern-Oriented Software Design. In Model-Driven Engineering Languages and Systems - 16th International Conference, MODELS 2013, Miami, FL, USA, September 29 - October 4, 2013. Proceedings. 604–621. [16] Bran Selic. 2003. The Pragmatics of Model-Driven Development. IEEE Software 20, 5 (2003), 19–25. [17] Benoit Combemale, Julien DeAntoni, Benoit Baudry, Robert B. France, Jean-Marc Jézéquel, and Jeff Gray. 2014. Globalizing Modeling Languages. Computer 47, 6 (2014), 68–71. [18] Jonathan Corley, Eugene Syriani, Huseyin Ergin, and Simon Van Mierlo. 2016. Modern Software Engineering Methodologies for Mobile and Cloud Environments. Number 7. IGI Global, Book section Cloud-based Multi-View Modeling Environ- ments, 120–139. [19] Juri di Rocco, Davide di Ruscio, Ludovico Iovino, and Alfonso Pierantonio. 2015. Collaborative Repositories in Model-Driven Engineering. IEEE Software 32, 3 (2015), 28–34. [20] Jean-Marie Favre. 2006. Megamodelling and Etymology. In Transformation Techniques in Software Engineering (Dagstuhl Seminar Proceedings), Vol. 05161. [21] Robert France and Bernhard Rumpe. 2007. Model-driven Development of Com- plex Software: A Research Roadmap. In Future of Software Engineering (FOSE ’07). IEEE, 37–54. [22] M. Franzago, D. D. Ruscio, I. Malavolta, and H. Muccini. 2018. Collaborative Model-Driven Software Engineering: a Classification Framework and a Research Map. IEEE Transactions on Software Engineering (2018). DOI:http://dx.doi.org/10. 1109/TSE.2017.2755039 [23] Steven Kelly, Kalle Lyytinen, and Matti Rossi. 1996. MetaEdit+: A Fully Con- figurable Multi-User and Multi-Tool CASE and CAME Environment. In CAiSE. Springer-Verlag, London, UK, UK, 1–21. [24] Steven Kelly and Juha-Pekka Tolvanen. 2008. Domain-Specific Modeling: Enabling Full Code Generation. John Wiley & Sons. [25] Jörg Kienzle, Gunter Mussbacher, Omar Alam, Matthias Schöttle, Nicolas Belloir, Philippe Collet, Benoı̂t Combemale, Julien DeAntoni, Jacques Klein, and Bern- hard Rumpe. 2016. VCU: The Three Dimensions of Reuse. In Software Reuse: Bridging with Social-Awareness (ICSR). 122–137. [26] Dimitrios S. Kolovos, Louis M. Rose, Nicholas Matragkas, Richard F. Paige, Esther Guerra, Jesús Sánchez Cuadrado, Juan De Lara, István Ráth, Dániel Varró, Massimo Tisi, and Jordi Cabot. 2013. A Research Roadmap Towards Achieving Scalability in Model Driven Engineering. In BigMDE Workshop. ACM, 2:1–2:10. [27] Miklós Maróti, Tamás Kecskés, Róbert Kereskényi, Brian Broll, Péter Völgyesi, László Jurácz, Tihamer Levendovszky, and Ákos Lédeczi. 2014. Next Generation (Meta)Modeling: Web- and Cloud-based Collaborative Tool Infrastructure. In Proceedings of the 8th Workshop on Multi-Paradigm Modeling. 41–60. [28] Constantin Masson, Jonathan Corley, and Eugene Syriani. 2017. Feature Model for Collaborative Modeling Environments. In International Workshop on Collabo- rative Modelling in MDE, Vol. 2019. CEUR-WS.org, 164–173. [29] David Lorge Parnas. 1972. On the Criteria to Be Used in Decomposing Systems into Modules. Commun. ACM 15, 12 (1972), 1053–1058. [30] Daniel Strüber, Stefan Jurack, Tim Schäfer, Stefan Schulz, and Gabriele Taentzer. 2016. Managing Model and Meta-Model Components with Export and Import Interfaces. In Proceedings of the 4rd Workshop on Scalable Model Driven Engineer- ing part of the Software Technologies: Applications and Foundations (STAF 2016) federation of conferences, Vienna, Austria, July 8, 2016. 31–36. [31] Eugene Syriani. 2016. Framework to Model Collaboratively. In International Workshop on Collaborative Modelling in MDE, Vol. 1717. CEUR-WS.org, 4. [32] Eugene Syriani, Hans Vangheluwe, Raphael Mannadiar, Conner Hansen, Si- mon Van Mierlo, and Hüseyin Ergin. 2013. AToMPM: A Web-based Modeling 7