=Paper=
{{Paper
|id=Vol-2245/gemoc_paper_3
|storemode=property
|title=Tool-Support of Socio-Technical Coordination in the Context of Heterogeneous Modeling
|pdfUrl=https://ceur-ws.org/Vol-2245/gemoc_paper_3.pdf
|volume=Vol-2245
|authors=Francis Bordeleau,Benoit Combemale,Romina Eramo,Mark van den Brand,Manuel Wimmer
|dblpUrl=https://dblp.org/rec/conf/models/BordeleauCEBW18
}}
==Tool-Support of Socio-Technical Coordination in the Context of Heterogeneous Modeling==
https://ceur-ws.org/Vol-2245/gemoc_paper_3.pdf
Tool-Support of Socio-Technical Coordination
in the Context of Heterogeneous Modeling
A Research Statement and Associated Roadmap
Francis Bordeleau Benoit Combemale Romina Eramo
Ecole de Technologie Superieur, University of Toulouse, CNRS IRIT University of L’Aquila
Universite du Quebec Toulouse, France L’Aquila, Italy
Montreal, Canada benoit.combemale@irit.fr romina.eramo@univaq.it
francis.bordeleau@etsmtl.ca
Mark van den Brand Manuel Wimmer
Eindhoven University of Technology TU Wien
Eindhoven, The Netherlands Vienna, Austria
m.g.j.v.d.brand@tue.nl wimmer@big.tuwien.ac.at
ABSTRACT typically developed using different modeling techniques, languages,
The growing complexity of everyday life systems (and devices) and tools. Using the automotive industry as an example, the devel-
over the last decades has forced the industry to use and investigate opment of cars has evolved in the last decades from pure mechanical
different development techniques to manage the many different engineering to multidisciplinary engineering where engineers from
aspects of the systems. In this context, the use of model driven different domains (including software engineering, electrical en-
engineering (MDE) has emerged and is now common practice for gineering, safety engineering, and mechanical engineering) are
many engineering disciplines. However, this comes with important involved. From an MDE perspective, tools like Matlab/Simulink are
challenges. As set of main challenges relates to the fact that different used to describe continuous behavior of a component or system,
modeling techniques, languages, and tools are required to deal with while modeling languages like UML or SysML are used to describe
the different system aspects, and that support is required to ensure system architecture and discrete behavior (using state machines or
consistence and coherence between the different models. This paper activity diagrams), and other modeling techniques, languages and
identifies a number of the challenges and paints a roadmap on how tools are used for other aspects. Over the years, the MDE commu-
tooling can support a multi-model integrated way of working. nity has placed the main focus on the development of techniques,
languages and tools to support specific modelling context and do-
CCS CONCEPTS mains, but little focus has been placed on the development of proper
methodologies and tooling to support the development, mainte-
• Software and its engineering → Software notations and
nance, and evolution of a set of related models in the context of
tools;
cross- or multi-disciplinary modeling [4]. Important issues include:
KEYWORDS - How can we ensure coherence and consistency between models
defined using different modeling languages (that are based on
Heterogenous modeling, model consistency, domain specific lan-
different metamodels)?
guages
- How can we maintain coherence and consistency between mod-
els that are independently defined and evolved throughout the
1 INTRODUCTION development process by different engineers and teams?
The fast growing, ever increasing, complexity of everyday life sys- - How can we govern the evolution of the system and associated
tems (and devices) over the last decades has forced the industry to models?
use and investigate different development techniques to manage the To complement previous general discussions about the global-
many different aspects of the systems. In this context, model driven ization of modeling languages1 [3] or multilingual programming
engineering (MDE) has emerged as an effective solution [10] as it al- environments [12], we focus in this discussion paper on the im-
lows leveraging abstraction and automation. Among other things, it portance of the tool-support for the socio-technical coordination
provides automated transformation/generation techniques, which within the development of complex software-intensive systems.
allow increasing productivity and reduce time to market, and anal- Indeed, since languages are pivot in between the various engineers
ysis/validation/simulation techniques, which allow increasing sys- and the technical artefacts they have to build with, we envision
tem quality. The use of MDE has been steadily increasing and is that the tool-support of the relationships between those languages
now common practice for many engineering disciplines [13]. helps both to support the seamless coordination of the stakeholders,
However, this comes with important challenges. A set of im- and to automate the coordination of the technical artefacts.
portant challenges are related to the fact the development of the
different aspects of a system require engineers from different disci- 1 See [3] for a comprehensive description of the related Grand Challenge of the Global-
plines, with different skills and expertise, and that these aspects are ization of Modeling Languages.
In the following section, we motivate the language-support of existing tools, via APIs, repositories, etc., to administrate and main-
both stakeholders and technical artefacts built during the devel- tain the relations and dependencies. We envision that the relations
opment process of complex systems. Then, in Section 3, we look and dependencies on the model level represent the organisation
ahead and provide a research and technology roadmap to meet the structure and/or the workflow of product development.
requirements. As a second step, we can proceed with the definition of the
role of the different modeling techniques, languages and tools that
2 LAYERING IN HETEROGENEOUS will be used to model the different aspects of the systems and
MODELING the definition of the semantic relationships between the different
The excavation of domain concepts depends on the engineers work- models and model elements. The identification of relations can
ing in different technological spaces when developing (complex) be done in two directions (see Fig. 1), from models upwards and
systems. The dependencies and relations between the models used from people downwards. The optimal results is obtained when both
by these engineers are defined by the relations between the domain directions are taken into consideration.
concepts at the domain (i.e., metamodel) level. The model driven 2.1 From Models to People
technology space is defined by the architectural layering of M0 We restrict ourselves to the relationships between models across
through M3. We will take a slightly different viewpoint. We are disciplines. The relationships within models and across models
not interested in the level M3 (meta-metamodel) level, but are in- within a specific discipline are often maintained via the current
terested in the organisational relations or the relations created via tooling used by the domain engineers.
workflow dependencies in product development. The construction of inter-relations among models from different
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 From People to Models
Objects that adhere to domain concepts with implicit relationships
are much harder to establish. There could be a temporal depen-
dency 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.
Figure 1: Language-Oriented Socio-Technical Coordination Engineers and architects have to map the domain concepts and have
to administer the relationships explicitly. These relationships have
To answer the questions mentioned in Section 1, we propose to to be established in the supporting tooling and maintained during
focus in this paper about the language and the tooling issues. As a the development, maintenance and destruction of the models.
first step, we need to focus on the definition of the overall domain This type of functionality is typically tool agnostic. We can not
model that defines the top level system concepts independently expect that existing modeling environments offer this type of func-
of the specific modeling techniques, languages and tools that will tionality out-of-the-box. Overarching tooling is needed to deal with
be used in the development process. At this stage the goal is to multidisciplinary models and their relationships.
define the overarching conceptual framework that will govern the
development of the system. As Melvin Conway 2 had observed, how 3 ROADMAP
organizations were structured would have a strong impact on any For realizing overarching tooling for multidisciplinary modeling
systems they created. In this task the (system) architect plays an projects, several challenges have to be tackled. First, more explicit
important role, the architect has the overall view on the project and connection points are needed for models which in turn allow for
the technical and non-technical dependencies between the domain a more systematic interlinking and integration of models. Second,
engineering disciplines. The excavation of domain concepts needs rich linking support is needed which is capable to work across
to be done with care and involves a close investigation whether discipline boundaries. Third, governance for evolving linked models
the definition of domain concepts used in different disciplines can is required to ensure effective and efficient engineering processes.
be mapped onto each other. The identification of common domain
concepts is necessary in order to establish relations and dependen- 3.1 Model Interfaces
cies on the model level and to be administrated and maintained Current approaches to connect models assume to define links poten-
via tooling. Adapting existing domain specific tooling is costly; an tially between every model element available in the models. While
alternative is to develop generic tooling that communicates with this allows for general solutions to connect models, more pragmatic
2 Conway’s law: https://en.wikipedia.org/wiki/Conway%27s_law solutions are needed for large-scale projects. The interface(s) of a
2
model to other discipline(s) have to be explicitly defined in order must be managed to ensure coherence and consistency between
to coordinate work without having to explore and interpret full the models. This requires a tooling infrastructure that provides a
models. First work going in this direction is emerging [11] where cross-model change impact capability that accounts for the mainte-
the interaction points between metamodels and models are expli- nance and evolution of the trace links. This means, that trace links
cated. However, a strong requirement to be further explored in have to be versioned and that they may need meta-information on
the future is how much control can be enforced on the existing current validity (invalid trace links may point out inconsistencies
tools to manage such interfaces on both, the provider and customer between the models) and who is maintaining the links [6]. Based
side. Finally, model interfaces must support IP management, and on this meta-information, a life-cycle model for inconsistencies
correspond to the integration concerns for supporting functional may be established. One may tolerate, ignore, or resolve them, but
chains. awareness is needed all the time as inconsistencies have to live
with the evolving models and co-evolve.
3.2 Model Linking
Traceability relationships may help stakeholders to understand the 4 CONCLUSION
associations and dependencies that exist among heterogeneous
In this paper, we elaborated on our vision about the language-
models and their correspondences [8, 14]. In MDE, the definition of
support of the socio-technical coordination required in the develop-
traceability focuses on models as the primary artifacts and refers
ment of modern complex software-intensive systems. More specifi-
to traceability (or trace) links: in particular, a trace link is a rela-
cally, we first discuss the need for explicit relationships between the
tionship between one or more source model elements and one or
domain models of the various languages involved. Then, we argue
more target model elements, whereas a trace model is a structured
for more focus in the community on tool-support for the coordina-
set of trace links, e.g., between source and target models. Trace
tion at the levels of language users and the actual heterogeneous
links may be defined between entire artefacts (e.g., a requirements
models. For such a purpose, we derive a roadmap of concrete and
document and a design model) or between parts of artefacts. We
actionable challenges to be further addressed by the community.
propose the use of trace links as the basis for defining and inform-
We hope this paper raises interesting discussions, and initiates
ing related stakeholders about correspondences between models.
and federates various related research activities. Collections of
Furthermore, trace links incorporate consistency relations between
benchmarks and case studies are also required for further evaluating
the connected models. As it is difficult to keep a software system
and positioning the different approaches and intents.
consistent at all times, tools need to have different policies for
consistency enforcement. Thus, traceability may support consis- REFERENCES
tency restoration policies. In MDE, this can be implemented by [1] M. Barbero, F. Jouault, and J. Bézivin. 2008. Model Driven Management of
updating unidirectional transformations and synchronizing bidi- Complex Systems: Implementing the Macroscope’s Vision. In IEEE Int. Conference
rectional transformations, and it can be also supported by means of and Workshop on Engineering of Computer Based Systems (ECBS 2008). 277–286.
[2] A. Cicchetti, D. Di Ruscio, R. Eramo, and A. Pierantonio. [n. d.]. JTL: A Bidi-
constraints [2, 7]. Among the existing approaches that work with rectional and Change Propagating Transformation Language. In International
correspondences, it is worth mentioning multi-view modeling [9], Conference on Software Language Engineering (SLE).
that supports distinct views on a shared model, and megamodeling [3] B. Combemale, B.H.C. Cheng, R.B. France, J.M. Jézéquel, and year=2015 B. Rumpe,
series=Lecture Notes in Computer Science. [n. d.]. Globalizing Domain-Specific
[1], that proposes a technique for managing dependencies among Languages: International Dagstuhl Seminar.
models in a heterogeneous system. [4] B. Combemale, J. Deantoni, B. Baudry, R.B. France, J.M. Jézéquel, and J. Gray.
2014. Globalizing Modeling Languages. Computer (2014), 10–13.
The framework we are outlining aims at supporting stakehold- [5] A. Van Deursen, P. Klint, and J. Visser. 2000. Domain-specific languages: An
ers that need to coordinate their activities without impacting their annotated bibliography. 35, 6 (2000), 26–36.
own current way to work. Typically, when designers work with [6] S. Feldmann, M. Wimmer, K. Kernschmidt, and B. Vogel-Heuser. 2016. A com-
prehensive approach for managing inter-model inconsistencies in automated
heterogeneous models, they considered employing different mod- production systems engineering. In IEEE International Conference on Automation
eling languages that are tailored to specific system aspects or a Science and Engineering (CASE). 1120–1127.
specific application area, i.e., domain specific languages (DSLs) [5]. [7] S. Hidaka, M. Tisi, J. Cabot, and Z. Hu. 2016. Feature-based classification of
bidirectional transformation approaches. Software & Systems Modeling 15, 3
Stakeholders coordination does not require to know any languages (2016), 907–928.
that are used, but rather the concepts that are involved in their [8] R.F. Paige, N. Drivalos, D.S. Kolovos, K.J. Fernandes, C. Power, G.K. Olsen, and
S. Zschaler. 2011. Rigorous identification and encoding of trace-links in model-
activities. To this end, we need to create an external infrastructure driven engineering. Software and System Modeling 10, 4 (2011), 469–487.
to relate heterogeneous models in different tools. If heterogeneous [9] J.E. Rivera, J.R. Romero, and A. Vallecillo. 2008. Behavior, Time and Viewpoint
software artifacts, tools, stakeholders are to interoperate effectively, Consistency: Three Challenges for MDE. In Models in Software Engineering,
Workshops and Symposia at MODELS 2008. Reports and Revised Selected Papers.
they must have a common understanding of each other’s informa- 60–65.
tion structures, which requires a common language (i.e., a common [10] D.C. Schmidt. 2006. Guest Editor’s Introduction: Model-Driven Engineering.
metamodel for traceability) describing how common concepts are Computer 39, 2 (2006), 25–31.
[11] D. Strüber, S. Jurack, T. Schäfer, S. Schulz, and G. Taentzer. 2016. Managing Model
related one with the other. and Meta-Model Components with Export and Import Interfaces. In Workshop
on Scalable Model Driven Engineering at STAF 2016. 31–36.
[12] T. van der Storm and J.J. Vinju. 2013. Towards Multilingual Programming Envi-
3.3 Model Governance ronments. Science of Computer Programming (2013).
Besides the technical aspects discussed in the previous sections, the [13] J. Whittle, J. Hutchinson, and M. Rouncefield. 2014. The State of Practice in
Model-Driven Engineering. Software, IEEE 31, 3 (2014), 79–85.
development and evolution of a set of related models also require [14] S. Winkler and J. Pilgrim. [n. d.]. A Survey of Traceability in Requirements
the establishment of a clear governance that defines who is respon- Engineering and Model-driven Development. 9, 4 ([n. d.]), 529–565.
sible for updating the different models and how model changes
3