Collaboration between developers and end-users seems particularly fitting when developing Domain Specific Languages (DSLs) given the fact that DSLs target the experts of a domain. However, current DSL development processes are completely centered on the developers who still lead all phases of the DSL development, while end-users only participate in the very beginning, when the domain is analyzed, and they cannot see how their input was interpreted until the modeling environment for the new language is deployed. The validation is therefore performed at the end, which implies rebuilding the environment (a very costly process, even with current language workbenches) every time the end-user wants to change the language definition (e.g., to add new properties to a metaclass, change their type,…).

To improve this situation, we propose to make the development process for DSLs community-aware, meaning that all stakeholders (i.e., technical and end-users) have the chance to participate, discuss and comment during the DSL definition phase (currently, this process only covers the abstract syntax, i.e., the metamodel, part of the DSL, but it should cover also the collaboration process for the concrete syntax). Moreover, we believe it’s important to track this discussion so that in the future we can justify the rationale behind each language design decision.

Community-driven language development

The following figure summarizes the key differences between a community-driven language development process and a traditional one.

Figure 1. - End-user agreement in (a) a traditional language development process, where a restart may be required due to misunderstandings, and in (b) a community-driven process, where each development phase is agreed by the community, thus involving a possible restart the same phase.

End-user agreement in (a) a traditional language development process, where a restart may be required due to misunderstandings, and in (b) a community-driven process, where each development phase is agreed by the community, thus involving a possible restart the same phase.

This collaborative process is also illustrated in this other figure showing how the key goal is accelerating the feedback and making sure the DSL concepts are agreed upon all the stakeholders from the very beginning instead of waiting until the modeling tool based on such DSL is fully created.

To make this collaborative development process feasible, it is essential to facilitate as much as possible the collaboration between all people involved. Our solution is based on a new DSL, called Collaboro, to represent the collaborations which arise among the members of a language community.

Collaboro: a collaborative (meta)modeling tool

Collaboro enables the involvement of the community (i.e., end-users and developers) in the development of (meta) modeling tasks. It allows modeling the collaborations between community members taking place during the definition of a new DSML.  Collaboro was implemented as an Eclipse-based tool and as a web-based solution that can be used by all kinds of users willing to have an active role in the evolution of their DSL. You can take a look at the project on this webpage or read the paper Enabling the Collaborative Definition of DSMLs. CAiSE 2013: 272-287 or, even better,  the more recent:  Collaboro: a collaborative (meta) modeling tool published in the PeerJ journal. The tool is not maintained anymore (though we plan to reimplement it as part of BESSER in the future).

The core of the abstract syntax of the language is shown in the following picture. As you can see, with Collaboro you can track all the change proposals, solutions (plus the set of changes to apply on the DSL to adopt the solution), comments or votes. The DSL element can represent both abstract (e.g., concepts and attributes) and concrete (e.g., notation symbol or keywords) elements of the DSL under development so that collaboration can arise on any element of the language.

To show how Collaboro works in practice, imagine a Transport DSL used by a transport company to represent its fleet and calculate the most efficient path between several points. The DSL therefore includes concepts such as Truck and Route to model the distribution maps (top part of the next Figure). Thanks to the fact that we are now following a collaborative development process, by looking at this initial version of the Transport metamodel, End-user 1 detects that Transport is missing the possibility of stating the traffic density of each Route concept and claims this is an important concept for the language. Since the rest agree, an initial solution is proposed and improved (after a comment suggesting a slightly different strategy, which is voted and selected by the community).

As can be seen, both the collaboration and the decision processes are modelled. In this case, we have applied a full agreement policy, so the change proposal and the corresponding solution are marked as accepted only if every community member agrees. Other, more complex, governance models are also possible.

While our first versions of Collaboro supported the collaborative development of textual DSMLs in an Eclipse-based environment, the last version offers:

  • Better support for the collaborative development of graphical DSMLs;
  • A new architecture which includes a web-based front-end, thus promoting usability and participation for end-users;
  • A metric-based recommender system, which checks the DSMLs under development to spot possible issues according to quality metrics for both the domain and the notation (relying on Moody’s cognitive framework (Moody, 2009))
  • The development of several cases studies, which have allowed us to improve the general expressiveness and usability of our approach

Crowdsourcing your notation 

As we have said above, the collaborative process should also cover the concrete syntax of your language so that your future users can also participate in the discussion for the best icons, shapes, colors, keywords,… of your graphical (or textual) notation.

You could keep track of the whole process in Collaboro itself, where you can define the notation for each metamodeling element and even show examples of models rendered with that notation as part of the decision-making process.

Full collaborative development process

This subset of the Collaboro metamodel shows the details of the notation metaclasses

Excerpts of the (A) Ecore and (B) notation metamodels used to represent, respectively, the abstract and concrete syntaxes of DSMLs in Collaboro.

But this strong collaboration restricts the number of participants. If you really want to test your possible notation with a large number of users, we propose a two-phased approach where you combine a Collaboro-based approach with a restricted group of users together with a crowdsourced approach to get faster feedback from a larger user base. This could be a great initiative that even major modeling languages (UML, SysML,…) could (and should) take.

As part of this crowdsourcing experiment, you could even run some A/B tests for your notation to choose the alternatives that work best as part of a controlled experiment.

Evolving your language

No matter how good is your initial language design, it will need to evolve overtime as the domain, the users or the usage of your DSL changes. We could trigger revisions of the language from time to time. But you can also run some automatic tests to check how the language is used and detect some issues. Here we would propose the detection of usage patterns to improve language design.

More on language design

This post has been evolving since we started exploring these ideas around ten years ago so in the comments below you’ll also find pointers to other ideas and approaches for language design. Make sure you take a look at them as well!

Want to build better software faster?

Want to build better software faster?

Read about the latest trends on software modeling and low-code development

You have Successfully Subscribed!

Pin It on Pinterest

Share This