Collaboro: a collaborative (meta) modeling tool

Software development is becoming more and more collaborative, emphasizing the role of end-users in the development process to make sure the ﬁnal product will satisfy customer needs. This is especially relevant when developing Domain-Speciﬁc Modeling Languages (DSMLs), which are modeling languages speciﬁcally designed to carry out the tasks of a particular domain. While end-users are actually the experts of the domain for which a DSML is developed, their participation in the DSML speciﬁcation process is still rather limited nowadays. In this paper, we propose a more community-aware language development process by enabling the active participation of all community members (both developers and end-users) from the very beginning. Our proposal, called Collaboro, is based on a DSML itself enabling the representation of change proposals during the language design and the discussion (and trace back) of possible solutions, comments and decisions arisen during the collaboration. Collaboro also incorporates a metric-based recommender system to help community members to deﬁne high-quality notations for the DSMLs. We also show how Collaboro can be used at the model-level to facilitate the collaborative speciﬁcation of software models. Tool support is available both as an Eclipse plug-in a web-based solution.


22
Collaboration is key in software development, it promotes a continual validation of the software to be 23 build (Hildenbrand et al., 2008), thus guaranteeing that the final software will satisfy the users' needs.   get the requirements from the end-users to create a preliminary version of the language to kickstart the 148 actual collaboration process (step 1). This first version should include at least a partial abstract syntax but 149 could also include a first concrete syntax draft (see DSML Definition). An initial set of sample models are 150 also defined by the developers to facilitate an example-based discussion, usually easier for non-technical 151 users. Sample models are rendered according to the current concrete syntax definition (see Rendered   152 Examples). It is worth noting that the rendering is done on-the-fly without the burden of generating the 153 DSML tooling since we are just showing the snapshots of the models to discuss the notation, not actually 154 providing at this point a full modeling environment. 155 Now the community starts working together in order to shape the language (step 2). Community 156 members can propose ideas or changes to the DSML, e.g., they can ask for modifications on how some There is no need to represent complex routes for assigned trolley. It is enough to specify the name of the taxiway of the airport.  Management Group (OMG), 2015a) expressions) to discover the rationale behind the elements of the 184 language (e.g., the argumentation provided for its acceptance).

185
To illustrate our approach, the development of the Baggage Claim DSML mentioned above could have 186 been the result of the imaginary collaboration scenario depicted in Figure 3. After developers completed a 187 first version of the language, the collaboration begins with a community member detecting the need of 188 expressing the capacity of the conveyors. Since now we are still in the definition phase, the community 189 has the chance to discuss the best way to adapt the language to support this new information. The member 190 that identified the problem would create a change proposal with that aim, and if the change is deemed 191 as important by the community, other members could propose a solution/s to adapt the language. As an 192 example, Figure 3 graphically depicts a possible collaboration scenario assuming a small community 193 Flight concept (as we will explain later, this is the result of applying the metric called Symbol Deficit). To be able to discuss about changes on the DSML to-be, we must be able to represent both its abstract 219 syntax (i.e., the concepts of the DSML) and its concrete syntax (the notation to represent those concepts) 220 elements. Additionally, to improve the understanding of how changes in its definition affect the DSML, 221 we provide a mechanism to automatically render DSML examples using the concrete syntax notation 222 under development.

224
The abstract syntax of a DSML is commonly defined by means of a metamodel written using a meta- of this metamodeling concepts. Figure 4a shows an excerpt of the well-known Ecore metamodeling 229 language, on which we rely to represent the abstract syntax of DSMLs.

231
Regarding the concrete syntax, since the notation of a DSML is also domain-specific, to promote the 232 discussion, we need to be able to explicitly represent the notational elements proposed for the language.

233
Thanks to this, community members will have the freedom to create a notation specially adapted to typically available in other tools. Therefore, we contribute in this paper our own metamodel for concrete 241 syntaxes. Figure 4b shows an excerpt of the core elements of this notation metamodel. As can be seen, 242 the metamodel is not exhaustive, but it is a lightweight solution that suffices to discuss about the concrete 243 syntax elements most commonly used in the definition of graphical, textual or hybrid concrete syntaxes 244 (offering a good trade-off between expressiveness and manageability of the description in order to render 245 and analyze/recommend changes). Note that with this metamodel, it is possible to describe how to 246 represent each language concept, thus facilitating keeping track of language notation changes.

247
Concrete syntax elements are classified following the NotationElement hierarchy, which in-   details about the render process will be given in the Section describing the developed tooling). 274 We believe the advantages of this approach is twofold. On the one hand, it is a lightweight mechanism    and RefValue metaclass instances are referring to elements from the abstract syntax metamodel. Figure   283 1b shows a possible renderization of a model for such language.

284
Representing the Collaborations 285 The third metamodel required in our process focuses on representing the collaborations that anno-286 tate/modify the DSML elements described before. This collaboration metamodel, which is shown in 287 Figure 6, allows representing both static (e.g., change proposals) and dynamic (e.g., voting) aspects of the 288 collaboration. Being the core of our collaborative approach, we refer to this metamodel as the Collaboro are expressed in terms of elements conforming to the notation metamodel presented before.

318
The Change metaclass has a reference to the container element affected by the change (referredElement apply) the collaborations accepted by the community. As commented before, most times it is necessary to 344 have the role of the community manager to trigger the decision process and solve possible decision locks. The recommender applies a set of metrics on the DSML to check its quality, in particular, to ensure 378 that the resulting language is expressive, effective and accurate enough to be well-understood by the we consider that such structures are invalid whether either there is only one derived class or whether an 398 inheritage is redundant (i.e., already covered by a chain of inheritage). As our approach relies on Ecore, 399 other metrics defined for this metamodeling language could be easily plugged in by using the extension 400 mechanism provided, as we will show afterwards.

402
The concrete syntax of a DSML can be textual or graphical (or hybrid). As textual DSMLs are usually 403 defined by means of a grammar-based approach, which is also the case for GPLs, existing support for 404 evaluating the quality of GPLs could be applied (e.g., Power and Malloy (2004) and Crepinšek et al.

405
(2010)). Apart from this GPL-related support, the current support to assess the quality of the concrete 406 syntaxes in the DSML field is pretty limited. Thus, in this paper, we apply a unifying approach to check a kind of flattening process where all the concepts are enriched to include the attributes and references 430 inherited from their ancestors. The aim is to identify the DSMLs elements (i.e., concept, attribute or 431 reference) for which a concrete syntax element has to be defined. On the other hand, the analysis of 432 the concrete syntax focuses on the discovery of symbols. When a symbol uses multiples graphical 433 elements to be represented (e.g., using nested Composite elements or SyntaxOf elements), they are 434 aggregated. The result of this analysis is stored in a map that links every abstract syntax element with the 435 corresponding concrete syntax element, thus facilitating the calculation of the previous metrics. This map 436 will be also used in the computation of the remainder metrics.

437
Visual Expressiveness. This principle refers to the number of visual variables used in the notation of a 438 DSML. Visual variables define the dimensions that can be used to create notation symbols (e.g., shape, 439 size, color, etc.). Thus, to promote its visual expressivenes, a language should use the full range and 440 capacities of visual variables.

441
To assess this principle, we define a metric which analyzes how visual variables are used in a DSML.

442
The metric leverages on the previous map data structure and enriches it to include the main visual variables 443 used in each symbol. According to the current support for visual variables of the notation metamodel  Graphic Economy. This principle states that the number of notation symbols should be cognitively 450 manageable. Note that there is not an objective rule to measure the complexity of notation elements (e.g., 451 expert users may cognitively manage more symbols than a novice). There is the six symbol rule (Miller, 452 1956) which states that there should be no more than six notation symbols if only a single visual variable 453 is used. We therefore devised a metric based on this rule to assess the level of graphic economy in a 454 DSML.

455
Perceptual Discriminality. This principle states that different symbols should be clearly distinguishable 456 from each other. Discriminality is primarily determined by the visual distance between symbols, that is, 457 the number of visual variables on which they differ and the size of these differences. This principle also 458 states that every symbol should have at least one unique value for each visual variable used (e.g., unique we believe that assessing this principle strongly depends on the profile and background of the DSML 480 end-users and it is therefore hard to measure.

514
In this section we will show how our approach could be easily adapted to support collaborative modeling.   To support this development process, the modifications to perform in the original Collaboro metamodel 523 are very small. Figure 9 shows the new metamodel to track the collaboration. As can be seen, the only 524 changed element is the SyntaxElement, which now has to refer to the main (i.e. root) metaclass of the   Collaboro model that, once accepted, will update the abstract and concrete syntax models and link them 592 together according to the selected solution. Figure 12a includes a snapshot of the environment showing 593 the last step of the collaboration described in previous sections. In particular, the Version view lists the 594 tasks to extract the model/s of a running system. At the moment, the only way to define a MDRE workflow 636 is by using an interactive wizard. MoDisco users have been asking for a specific language to do the same 637 in a more direct way, i.e., without having to go through the wizard.

638
Some years ago an initial attempt to create such language was finally abandoned but, to simplify 639 the case study, we reused the metamodel that was proposed at the time to kickstart the process. Five 640 researchers of the team followed our collaborative process to complete/improve the abstract syntax of the 641 DSML and create from scratch a concrete syntax for it. Two of the members were part of the MoDisco 642 development team so they took the role of developers in the process while the other three were only users 643 of MoDisco so they adopted the role of end-users in the process. One of the members was in a different 644 country during the collaboration so only asynchronous communication was possible.

645
The collaboration took two weeks and resulted in two new versions of the MDRE workflow language 646 released. The first version was mainly focused on the polishment of the abstract syntax whereas the second 647 one paid more attention to the concrete syntax (this was not enforced by us but it came out naturally).

648
The collaboration regarding the abstract syntax involved changes in concepts and reference cardinalities, 649 while regarding the concrete syntax, the community chose to go for a textual-based notation and mainly 650 discussed around the best keywords or style to be used for that.

651
Defining metamodels 652 We have also applied Collaboro for defining a set of metamodels used in a model-driven re-engineering 653 process (i.e., only the abstract syntax of the DSML was part of the experiment since the models were to 654 be automatically created during the reverse engineering process). In particular, the process was intented 655 to provide support for migrating Google Code to GitHub projects, thus requiring the corresponding 656 PSM metamodels for both platforms, plus a PIM metamodel to represent such projects at high level of 657 abstraction (following the typical terminology defined by the Model-Driven Architecture (MDA) approach 658 from the OMG Object Management Group (OMG) (2014a)). As the developers were distributed across 659 different geographical locations, we decided to use Collaboro to create the PSM and PIM metamodels 660 required.

661
Six researchers geographically dispersed (i.e., the participants were part of three research groups, 662 making three groups composed of 3, 2 and 1 researchers) collaborated in the definition of the metamodels.

663
To kickstart the collaboration, one of the teams created a first version of each metamodel. As the 664 collaboration was focused on defining only the abstract syntax of the language, there was no need 665 for creating a notation model, and therefore the set of examples were rendered following a class-like 666 diagram style. The collaboration took three weeks and resulted in two versions for each one of the PSM 667 metamodels and only one version for the PIM metamodel since there the agreement was faster.
far. In particular, to be able to use Collaboro for managing the ADDL-BA language definition process we 687 needed to import: (1) previous discussions stored in the wiki-based platform and (2) the current concrete 688 syntaxes of the AADL and AADL-BA language defined in Xtext and ANTLR respectively (the abstract 689 syntax was already defined as an EMF model so it could be directly imported into Collaboro). It was 690 also clear that to simplify the use of the tool, we had to provide a web interface since it would be too 691 complex for the members of the AADL community to install an Eclipse environment just for the purpose 692 of discussing around language issues.

693
In the end, time constraints prevented us to test the tool with AADL community at large (the AADL-694 BA committee meets at fixed dates and we did create a web-based interface but could not get a new version 695 of the tool with all the scripts required to import the legacy data on time), but the private iterations with 696 the AADL-BA developer and his validation and positive feedback helped us a lot to improve Collaboro 697 and learn more about the challenges of using Collaboro as a part of an ongoing language development 698 effort. We are still in contact with this community and we will see if we can complete the test in the future 699 or reach out other similar standardization committees.  In all the case studies the notation view allowed the participants to quickly validate the concrete syntax.

718
This is specially important since for non-technical users it is easier to discuss at the concrete syntax level 719 than at the abstract level.