The growing complexity of everyday life systems (and devices) over the last decades has forced the industry to use and investigate diferent development techniques to manage the many diferent aspects of the systems. In this context, the use of model driven engineering (MDE) has emerged and is now common practice for many engineering disciplines. However, this comes with important challenges. As set of main challenges relates to the fact that diferent modeling techniques, languages, and tools are required to deal with the diferent system aspects, and that support is required to ensure consistence and coherence between the diferent models. This paper identifies a number of the challenges and paints a roadmap on how tooling can support a multi-model integrated way of working.
• Software and its engineering → Software notations and tools; Heterogenous modeling, model consistency, domain specific languages
The fast growing, ever increasing, complexity of everyday life
systems (and devices) over the last decades has forced the industry to
use and investigate diferent development techniques to manage the
many diferent aspects of the systems. In this context, model driven
engineering (MDE) has emerged as an efective solution [
However, this comes with important challenges. A set of
important challenges are related to the fact the development of the
diferent aspects of a system require engineers from diferent
disciplines, with diferent skills and expertise, and that these aspects are
typically developed using diferent modeling techniques, languages,
and tools. Using the automotive industry as an example, the
development of cars has evolved in the last decades from pure mechanical
engineering to multidisciplinary engineering where engineers from
diferent domains (including software engineering, electrical
engineering, safety engineering, and mechanical engineering) are
involved. From an MDE perspective, tools like Matlab/Simulink are
used to describe continuous behavior of a component or system,
while modeling languages like UML or SysML are used to describe
system architecture and discrete behavior (using state machines or
activity diagrams), and other modeling techniques, languages and
tools are used for other aspects. Over the years, the MDE
community has placed the main focus on the development of techniques,
languages and tools to support specific modelling context and
domains, but little focus has been placed on the development of proper
methodologies and tooling to support the development,
maintenance, and evolution of a set of related models in the context of
cross- or multi-disciplinary modeling [
To complement previous general discussions about the
globalization of modeling languages1 [
In the following section, we motivate the language-support of both stakeholders and technical artefacts built during the development process of complex systems. Then, in Section 3, we look ahead and provide a research and technology roadmap to meet the requirements. 2
The excavation of domain concepts depends on the engineers working in diferent technological spaces when developing (complex) systems. The dependencies and relations between the models used by these engineers are defined by the relations between the domain concepts at the domain (i.e., metamodel) level. The model driven technology space is defined by the architectural layering of M0 through M3. We will take a slightly diferent viewpoint. We are not interested in the level M3 (meta-metamodel) level, but are interested in the organisational relations or the relations created via workflow dependencies in product development.
To answer the questions mentioned in Section 1, we propose to focus in this paper about the language and the tooling issues. As a ifrst step, we need to focus on the definition of the overall domain model that defines the top level system concepts independently of the specific modeling techniques, languages and tools that will be used in the development process. At this stage the goal is to define the overarching conceptual framework that will govern the development of the system. As Melvin Conway 2 had observed, how organizations were structured would have a strong impact on any systems they created. In this task the (system) architect plays an important role, the architect has the overall view on the project and the technical and non-technical dependencies between the domain engineering disciplines. The excavation of domain concepts needs to be done with care and involves a close investigation whether the definition of domain concepts used in diferent disciplines can be mapped onto each other. The identification of common domain concepts is necessary in order to establish relations and dependencies on the model level and to be administrated and maintained via tooling. Adapting existing domain specific tooling is costly; an alternative is to develop generic tooling that communicates with existing tools, via APIs, repositories, etc., to administrate and maintain the relations and dependencies. We envision that the relations and dependencies on the model level represent the organisation structure and/or the workflow of product development.
As a second step, we can proceed with the definition of the role of the diferent modeling techniques, languages and tools that will be used to model the diferent aspects of the systems and the definition of the semantic relationships between the diferent models and model elements. The identification of relations can be done in two directions (see Fig. 1), from models upwards and from people downwards. The optimal results is obtained when both directions are taken into consideration. 2.1
We restrict ourselves to the relationships between models across disciplines. The relationships within models and across models within a specific discipline are often maintained via the current tooling used by the domain engineers.
The construction of inter-relations among models from diferent disciplines can only be done if the models use clearly related domain concepts. If both domains use the same name for a concept then this can be a strong indication that the objects adhering to this concept are related. Of course, a sanity check on the semantic level is still required. The corresponding metamodels should use the same name as well. These common concepts have to be acknowledged by the domain engineers or the (system) architect. 2.2
Objects that adhere to domain concepts with implicit relationships are much harder to establish. There could be a temporal dependency based on the fact that objects are created, updated or deleted more or less in sync, but advanced repository mining techniques are needed for this. These implicit relationships have to be made explicit on the level of the domain engineers and (system) architects. Engineers and architects have to map the domain concepts and have to administer the relationships explicitly. These relationships have to be established in the supporting tooling and maintained during the development, maintenance and destruction of the models.
This type of functionality is typically tool agnostic. We can not expect that existing modeling environments ofer this type of functionality out-of-the-box. Overarching tooling is needed to deal with multidisciplinary models and their relationships. 3
For realizing overarching tooling for multidisciplinary modeling projects, several challenges have to be tackled. First, more explicit connection points are needed for models which in turn allow for a more systematic interlinking and integration of models. Second, rich linking support is needed which is capable to work across discipline boundaries. Third, governance for evolving linked models is required to ensure efective and eficient engineering processes. 3.1
Current approaches to connect models assume to define links
potentially between every model element available in the models. While
this allows for general solutions to connect models, more pragmatic
solutions are needed for large-scale projects. The interface(s) of a
model to other discipline(s) have to be explicitly defined in order
to coordinate work without having to explore and interpret full
models. First work going in this direction is emerging [
Traceability relationships may help stakeholders to understand the
associations and dependencies that exist among heterogeneous
models and their correspondences [
The framework we are outlining aims at supporting
stakeholders that need to coordinate their activities without impacting their
own current way to work. Typically, when designers work with
heterogeneous models, they considered employing diferent
modeling languages that are tailored to specific system aspects or a
specific application area, i.e., domain specific languages (DSLs) [
Besides the technical aspects discussed in the previous sections, the
development and evolution of a set of related models also require
the establishment of a clear governance that defines who is
responsible for updating the diferent models and how model changes
must be managed to ensure coherence and consistency between
the models. This requires a tooling infrastructure that provides a
cross-model change impact capability that accounts for the
maintenance and evolution of the trace links. This means, that trace links
have to be versioned and that they may need meta-information on
current validity (invalid trace links may point out inconsistencies
between the models) and who is maintaining the links [
In this paper, we elaborated on our vision about the languagesupport of the socio-technical coordination required in the development of modern complex software-intensive systems. More specifically, we first discuss the need for explicit relationships between the domain models of the various languages involved. Then, we argue for more focus in the community on tool-support for the coordination at the levels of language users and the actual heterogeneous models. For such a purpose, we derive a roadmap of concrete and actionable challenges to be further addressed by the community.
We hope this paper raises interesting discussions, and initiates and federates various related research activities. Collections of benchmarks and case studies are also required for further evaluating and positioning the diferent approaches and intents.