(guest post by Benoit Combemale and the rest of the advisory board introducing the GEMOC initiative).
The New Grand Challenge of the Globalization of Modeling Languages
The development of modern complex software-intensive systems often involves the use of multiple DSMLs that capture different system aspects. In addition, models of the system aspects are seldom manipulated independently of each other. System engineers are thus faced with the difficult task of relating information presented in different models. For example, a system engineer may need to analyze a system property that requires information scattered in models expressed in different DSMLs.
In the software and systems modeling community, research on domain-specific modeling languages (DSMLs) is focused on providing technologies for developing languages and tools that allow domain experts to develop system solutions efficiently. Current DSML development workbenches provide good support for developing independent DSMLs, but provide little or no support for integrated use of multiple DSMLs. Unfortunately, the current lack of support for explicitly relating concepts expressed in different DSMLs makes it very difficult for software and system engineers to reason about information spread across models describing different system aspects.
Supporting coordinated use of DSMLs leads to what we call the globalization of modeling languages, that is, the use of multiple modeling languages to support coordinated development of diverse aspects of a system. One can make an analogy with world globalization in which relationships are established between sovereign countries to regulate interactions (e.g., travel and commerce related interactions) while preserving each country’s independent existence. The term “DSML globalization” is used to highlight the desire that DSMLs developed in an independent manner to meet the specific needs of domain experts, should also have an associated framework that regulates interactions needed to support collaboration and work coordination across different system domains.
In the globalized DSML vision, integrated DSMLs support teams working on systems that span many domains and concerns to determine how their work on a particular aspect influences work on other concerns. The objective is to offer support for communicating relevant information, and for coordinating development activities and associated technologies within and across teams, in addition to providing support for imposing control over development artifacts produced by multiple teams.
In this context, DSMLs can be used to support socio-technical coordination by providing the means for stakeholders to bridge the gap between how they perceive a problem and its solution, and the programming technologies used to implement a solution. DSMLs also support coordination of work across multiple teams when they are supported by mechanisms for specifying and managing their interactions. In particular, proper support for coordinated use of DSMLs leads to language-based support for social translucence, where the relationships between DSMLs are used to extract the information needed to make a team working on a system aspect aware of the relevant work performed by teams working on other aspects. Such awareness is needed to minimize the counter-productive form of social isolation that can occur when work is distributed across different teams.
The following article, published in the issue of June, 2014 of IEEE Computer, presents a research initiative, called the GEMOC initiative, that broadens the DSML research focus beyond the development of independent DSMLs to one that supports globalized DSMLs, that is, DSMLs that facilitate coordination of work across different domains of expertise.
 |
Benoit Combemale, Julien DeAntoni, Benoit Baudry, Robert B. France, Jean-Marc Jezequel, Jeff Gray, “Globalizing Modeling Languages,” Computer, vol. 47, no. 6, pp. 68-71, June 2014, doi:10.1109/MC.2014.147 (the preprint is freely available here) |
The GEMOC Initiative
GEMOC is an open and international initiative that aims to develop breakthrough software language engineering (SLE) approaches that support global software engineering through the use of multiple domain-specific languages. GEMOC researchers aim to provide effective SLE solutions to problems associated with the design and implementation of collaborative, interoperable and composable modeling languages.
The GEMOC initiative aims to provide a framework that facilitates collaborative work on the challenges of using of multiple domain-specific languages in software development projects. The framework consists of mechanisms for coordinating the work of members, and for disseminating research results and other related information on GEMOC activities. The framework also provides the required infrastructure for sharing artifacts produced by members, including publications, case studies, and tools.
The members involving in the GEMOC initiative gather complementary expertise from software language (programming and modeling), models of computation (including time and communication issues), model driven engineering (MDE), and software validation & verification (V&V) and Testing.
The governance of the GEMOC initiative is ensured by the Advisory Board. The role of the Advisory Board is to coordinate the GEMOC work and to ensure proper dissemination of work products and information about GEMOC events (e.g., meetings, workshops). The advisory board is also in charge of organizing an annual workshop on the topics of the initiative, in conjunction with the international MODELS conference. Each open workshop will be followed by an annual meeting of the advisory board, and then by a dinner with all the members of the initiative in which all the coordination and dissemination issues are reported. Other opportunistic meetings would also be organized over the year (e.g., co-located with ICSE).
The GEMOC initiative is supported by different projects that explore several dimensions of tools and methods in software language engineering (SLE) to support the globalization of modeling languages. In particular, the ANR INS Project GEMOC (2012-2016) aims to provide a language workbench for heterogeneous modeling and simulation of complex software-intensive systems. For this purpose, the partners of the ANR INS project GEMOC (INRIA, IRIT, I3S, ENSTA Bretagne, Obeo and Thales Research & Technology) explore the coordination of multiple executable modeling languages to support the coordinated execution of heterogeneous behavioral. The project aims to provide scientific and technological foundations on modeling language design, implementation and coordination, integrated into the GEMOC studio.
The GEMOC Studio
The GEMOC Studio is an Eclipse Modeling package that contains all the components coming from the GEMOC community, especially for building and composing DSMLs. It includes two main workbenches:
- The GEMOC Language Workbench: intended to be used by language designers, it allows to build and compose, possibly executable, DSMLs.
- The GEMOC Modeling Workbench: intended to be used by systems and software designers, it allows to create and execute models in a coordinated way.
Benoit, Jean-Marc, Jeff and Robert
The Advisory Board of the GEMOC initiative
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
I believe that the enabling feature for globalization for DSLs was UML infra and super-structure, along with multiple packages and conformance levels.
Sadly enough, all that was dropped in favor of an eclipse-friendly flat monolythic construct of UML.
There’s no way to base DSLs in common UML infra/supra packages.
So, there’s all that new work to be done by GEMOC – more effort.
Dear Antonio,
Thank you for your feedback.
UML addressed the various DSLs to be used in software design by providing a single **Unified** Modeling Language that includes a fixed set of, (more or less) related, DSLs.
In contrast to the “unification” approach (i.e. a kind of top-down approach where, by definition, the DSLs are fixed and their relationships between them are predefined), we claim in the GEMOC initiative for a “globalization” approach, i.e., a bottom-up approach where DSLs are developed from the ground (i.e., from the expertise of the various domains) and then connected together according to the expected connections between the different domains. This difference between “unification” and “globalization” is essential, even if this difference can only be in the point of view that we have on the DSLs we are using. This is where the metaphor with the world globalization come from: “relationships are established between sovereign countries to regulate interactions”
The term “DSML globalization” is used to highlight the desire that DSMLs developed in an independent manner to meet the specific needs of domain experts, should also have an associated framework that regulates interactions needed to support collaboration and work coordination across different system domains.
All the best,
Benoit
Thanks Benoit for your kind comments,
One of the agreed-upon goals of UML2 was to resolve the often competing forces of software modeling in general, and common foundation abstractions to be reused in DSLs.
In other words: UML2 was pursued, among other things, to settle the fight between the MOF and UML “camps”.
One of the approaches was to render a number of core abstractions that many of us kept reusing in DSLs and also in many other software engineering metamodels, as reusable (meta)modeling packages, that could be included and adopted without taking the whole UML.
While it was thought packages in “infrastructure” would be more atomically reusable, constructs in “superstructure” were also available for reuse.
There was at the time an ever more powerful proposal by Desmond D’Souza, supplying a mechanism to map semantics and syntax for composable (meta)model fragments.
UML 2.5, now back a monolythic monster, has destroyed all that composability, so, yes indeed GEMOC may claim there is very important work to be done.
May be GEMOC approach is oriented in a totally different direction, not seeking any commonality of abstractions or model reuse, but rather with emphasys in interaction-supporting frameworks.
I wonder where all the DSL talent was, when the proponents of monolythic UML were having their way in the OMG (’til they got it down its knees with 2.5).
¡ah! I remember: distracted by IBM’s gorgeus maneouvers with the Eclipse ecosystem DSLs (EMF, GMF, M2T, M2M, …).
I wonder why the authors state that “Current DSML development workbenches provide little or no support for integrated use of multiple DSMLs”. Unfortunately the article does not describe further support for that claim.
Nevertheless, I can share that view e.g. in MOF based approaches (and tools build on that like Eclipse GMF) as if there is not even a concept of “language” identified in the metamodel then integrating something that can’t be described is obviously challenging…
For me the challenge related to language coordination as described in the article looks a bit related to tooling in a particular technology stack. Interestingly, many of the tools called nowadays Language Workbenches (see http://www.languageworkbenches.net/past-editions/) have moved to different ways to define languages and their coordinated use.
Hi Juha-Pekka,
Thanks for your feedback.
The support for an integrated use of multiple DSMLs that we are talking about is both at the language and tooling levels.
In particular, we are looking at (meta)languages for expressing domain-specific relationships (aka composition, coordination, synchronization… operators) between initially independent DSLs. This also include behavioral relationships (not co-simulation, but relationships between the behavioral semantics of, possibly heterogeneous, DSLs) to support, among others, a coordinated execution of heterogeneous models.
Cheers,
Benoit
Hi Benoit,
The most covering review of different metamodeling languages that I’m aware of is http://www.dsmforum.org/events/DSM11/Papers/kern.pdf. It would be good if similar studies would be also on tools and how various language workbenches/modeling tools enable integration using different technologies – which is particularly relevant when the languages are already used and apply different technologies.
Yours,
Juha-Pekka