=Paper=
{{Paper
|id=Vol-2019/flexmde_4
|storemode=property
|title=Process-Aware Model-driven Development Environments
|pdfUrl=https://ceur-ws.org/Vol-2019/flexmde_4.pdf
|volume=Vol-2019
|authors=Levi Lúcio,Saad Bin Abid,Salman Rahman,Vincent Aravantinos,Ralf Kuestner,Eduard Harwardt
|dblpUrl=https://dblp.org/rec/conf/models/LucioARAKH17
}}
==Process-Aware Model-driven Development Environments==
https://ceur-ws.org/Vol-2019/flexmde_4.pdf
Process-Aware Model-Driven Development
Environments
Levi Lúcio Saad Bin Abid Salman Rahman
Model-Based Software Engineering Model-Based Software Engineering Technische Universität München
fortiss GmbH fortiss GmbH Munich, Germany
Munich, Germany Munich, Germany salman.rahman@tum.de
lucio@fortiss.org abid@fortiss.org
Vincent Aravantinos Ralf Kuestner Eduard Harwardt
Model-Based Software Engineering Diehl Aerospace Diehl Aerospace
fortiss GmbH Munich, Germany Munich, Germany
Munich, Germany ralf.kuestner@diehl.com eduard.harwardt@diehl.com
aravantinos@fortiss.org
Abstract—Due to recent advances in Domain Specific Language classic MetaEdit+ [18]. With the maturity of these technolo-
(DSL) workbenches, it has become possible to build model-driven gies, one can safely say that building your own MDE tool
development environments as sets of individual DSLs that get has never been so easy – technology enthusiasts in various
composed for a specific purpose. In this paper we explore how
model-driven development environments can become process- industries now develop their own domain- or even company-
aware, to assist the user when building a model. We offer an specific tools.
explanation to our ideas at three levels of abstraction: 1) the meta- On the other hand, as [20] also mentions, tools are an
meta level, the Meta-Programming System (MPS) workbench enabler, but they are not everything: “More focus on processes,
with its language definition capabilities; 2) the meta level, where less on tools”. Even when a tailored tool is available, allowing
brick DSLs are defined and assembled into frameworks that are
further tailored for particular modelling scenarios through the the modelling of one’s domain through many sub-DSLs makes
introduction of an explicit process for model construction; and 3) it such that new users often become overwhelmed by the
the model level, where models are built through progressive tool- amount of modelling techniques at their disposal. This is in
guided refinements and automated steps based on the process fact the case for even very specialized tools like Sfit [9] for
introduced at the meta level. We exemplify our approach by the modelling of industrial manufacturing – while modelling a
providing the main highlights of the ongoing development of
a model-driven requirements gathering environment for our restricted domain, the tool contains a large number of different
industrial partners. models, mostly rendered as diagrams. The question of method-
Index Terms—Process-awareness, Domain-Specific Languages ology or process then naturally follows: in which order should
(DSLs), Model Construction, generic requirement gathering one build the diagrams? More generally, which information
framework, process language, requirement refinement process, should one model at a given point in time? The funding
requirement engineer, model driven development environment
of research projects focusing on this question demonstrates
the relevance of this question: for example SPES-XT [16],
I. I NTRODUCTION
targets the development of methodologies for the domain of
The current trends in domain specific software engineer- embedded systems. Similarly, Arcadia [10] emphasizes the
ing, domain specific languages (DSL) and domain specific importance of the methodology in connection with MDE.
modelling languages (DSML) demonstrate the interest for Just like for tools however, methodologies and processes can
tailored software solutions. When it comes to model-driven seldom be general enough to match all use cases and answer
engineering (MDE) tools, studies like [20] show that this all needs. There is thus also a need for tailoring at that level.
trend is justified: among the MDE tools considered in the To facilitate the acceptance of the methodology, it is essential
reported study, the ones which were successful in penetrating that the tool supports the methodology: this is for instance
industry were precisely those which were developed in a the case with Capella and Arcadia. Capella however, supports
tailored manner for a given audience, the recommendation only the Arcadia methodology which is specific to avionic
being: “Match tools to people, not the other way around”. systems engineering and to the processes of Thales. All the
Many technologies now precisely enable this sort of tailor- above points to the fact that, if the tools can be tailored, the
ing, among which JetBrains’ MPS [15], Sirius [11], or the process itself should be tailorable.
In this paper, we propose an approach to develop DS(M)Ls
This work was developed in the context of the “IETS3” research project,
funded by the German Federal Ministry of Education and Research under in JetBrains’ MPS [15], equipped with a means to customize
code 01IS15037A/B. the tool in order to support a given process: using our
approach, in addition to the usual MPS mechanisms to develop Then, in section IV, we exemplify the construction of the
their DSLs, developers can also explicitly express their own requirements using the environment described in the previous
process. Such a process of model construction is declared as a section. Section V provides pointers to work in the literature
statechart-like diagram, being that the current state is defined that closely relates to the results we present here. Finally,
by the satisfaction of some properties of the model as well as section VI presents a discussion of our research and potential
by its previous states. For each state, the tool developer can future work.
define hints to be displayed as well as quickfixes in the form
of creation of new artifacts. II. T HE metameta L EVEL : MPS: A L ANGUAGE
In order to clarify our work we draw an analogy with the M ETA -E DITOR
M-levels defined by the Object Management Group: The metameta level (M3, in MOF terms) is where the bricks
• M3: the MPS tool with its language definition capabili- for our approach are built. These bricks consist of DSLs,
ties. defined in the MPS (Meta Programming System) [3] frame-
• M2: development and composition of “brick DSLs” in a work. MPS is a stable and industrially-proven projectional
domain-specific model-driven development environment, meta-editor which provides editing capabilities at the meta-
together with a model construction process. levels needed for our approach: M2 and M1. It uniformly
• M1: usage of the developed domain-specific tool. integrates language and editor design capabilities, together
We also identify four different roles in the development and with code generation tools and in-built correct-by-construction
usage of the framework: techniques such as meta-model conformance, syntax highlight-
ing, auto-completion or type checking. MPS is developed by
• the framework developer (in our case JetBrains), who
JetBrains, which assumes the role of framework developer.
develops MPS (level M3),
Throughout this paper we will often use vocabulary that is
• the framework customizer (the authors of this paper), who
close to that used in the MPS world in order to remain
develops a library for process-customizable DSLs (level
aligned with the technical aspects of our work. In particular,
M2),
the following terms are recurrently used in what follows:
• the (domain-specific) tool developer (typically a consul-
• Language: an MPS language includes a metamodel, in
tant or the in-house technology department of a company)
who actually develops the domain-specific tool, making the classical EMF sense. It additionally includes one or
use of our libraries (level M2), more editors for its metamodel, which provide concrete
• and the user (level M1).
syntax.
• Concept: the MPS equivalent of metamodel class.
In this work, we contribute a framework at level M2 to support • Concept / language instance: concepts can be instanti-
the tool developer in developing a process-aware domain- ated, in the same way metamodel classes can. We will
specific tool. At the M1 level, a “dashboard” allows the user also sometimes write language instance to refer to an
to know permanently what is the next step to achieve. instance of the root concept of an MPS language.
As a case study, we demonstrate how to use this framework • Intentions: actions attached to concepts of a language,
for the specific domain of requirements engineering: the step- available to the user.
by-step formalization of requirements is a common approach, • Language composition: Reference or containment rela-
making it, therefore, an ideal candidate for the development of tions can exist between instances of concepts of different
a process-aware tool. For this purpose, we have implemented languages, which is the primary language composition
a set of DSLs supporting the MIRA [17] framework, a gen- mechanism in MPS. Another composition mechanism is
eral approach for the stepwise formalization of requirements the MPS model, which can contain instances of concepts
focusing on quality assurance for requirements. belonging to many languages.
A tool developer can use this set of DSLs as a basis for
their model-based development environment, by composing III. T HE meta L EVEL : D EFINING A R EQUIREMENTS
them with more specific DSLs of their own design. This can G ATHERING F RAMEWORK IN MPS
also “drive” the user in her requirements formalization process
A. A Generic Requirements Gathering Framework
by implementing a process using our Process language.
We illustrate this approach by developing a requirements- The requirements gathering framework we introduce here
engineering tool specialized in the development of hardware borrows its structure from the Model-based Integrated Re-
cooling systems, inspired from a case study from our industrial quirement Specification and Analysis (MIRA) Framework [8],
partners at Diehl Aerospace. [17]. The main parts of the MIRA framework are as follows:
The remainder of this paper is structured as follows. In • The system context describes the relevant elements that
section II we describe the MPS framework, which we use belong to the context of the system being developed.
as the technological basis for all the results presented in • The requirement list documents the capabilities and lim-
this paper. Section III then describes our case study – the itations of the system under development.
construction of a model-driven development environment for • The trace link list keeps the relations between the arte-
the incremental gathering and refinement of requirements. facts being defined.
• The QA collection describes quality assurance activities generic requirements gathering framework that has been in-
and results. troduced in section III-A in order to specialize it for gathering
This broad classification of the concepts necessary to build requirements for software controllers for hardware cooling
a requirements gathering framework is helpful to us in an systems. In particular, we will add a process for specifying
operational manner. We wish to build our framework as a set of this type of requirements. The case study we present here is
composed domain specific languages in the MPS environment. inspired by a requirements document (that for non-disclosure
For that we need an architecture around which we can organize reasons we cannot cite here) which was made available to
such languages. The MIRA architecture thus helps us in us by Diehl aerospace, one of our industrial partners. Diehl
understanding how to group and compose those languages. builds hardware for airplanes and, as such, cooling systems
A particularity of MIRA is that quality assurance is natively for that hardware also need to be produced. The process
integrated in the framework. MIRA’s quality assurance has an of gathering requirements of the software that controls such
operational counterpart in the MPS environment – in terms of cooling systems is currently almost completely manually done.
language checks that come with the DSLs defined in MPS This poses a problem to Diehl, as the current requirements
as well as other (formal) analyses that can be defined by gathering process imposes a large amount of effort to ensure
the domain-specific tool developer building the framework. that those requirements are documented in a fashion that is
These analyses are orchestrated during the definition of the complete, correct, and traceable. Additionally, the aerospace
process when building a tailored model-driven development industry has to adhere to strict regulations such that their
environment and correspond to MIRA’s verification activities. systems can be certified to be used in production. In order to
In figure 1 we present the first two meta-levels of our frame- specialize the two lower layers of the language stack presented
work in the form of a stack of languages: at the bottom of the in figure 1 we have added the following languages: the Table
stack we have MPS itself, with its meta-editing capabilities; language, for defining the behavior of the controller for the
in the lower half of the layer immediately above we define the cooling system; the ModelProperty Language, which contains
four aspects of the MIRA framework. Each one of the four algorithms for checking properties that are specific to the
aspects includes groups of DSLs that allow the requirements cooling system requirements gathering system. Additionally,
engineer to express parts of the complete requirements model. the domain specific tool developer also builds a process
The framework customizer, in this case our group at fortiss, is that will configure the dashboard’s behavior. The dashboard
responsible for building this part of the stack. The subset of assists the requirements engineer during the construction of
MIRA we use for the work we present here is composed of the requirements by displaying hints and press-button actions
the following languages: that guide the refinement of the requirements model. The dash-
• System Context: this aspect of the framework contains a board is configured by a description of which hints should be
Glossary language to allow defining the domain specific provided to the requirements engineer under which conditions.
glossary terms that are used across a requirements project, This information is provided as an instance of the Process
together with values associated to those terms. language. In figure 2 we provide an example of such a process,
• Requirements List: this aspect of the framework contains depicted directly in our tool’s concrete statechart-like syntax,
a Requirements language for expressing textual require- for the cooling controller requirements. The top part of each
ments, together with meta-information such as the author state in the figure includes the description of the conditions
of the requirement or the requirement’s current state. that need to be satisfied such that the hint associated to that
• Trace Links: this group contains a generic trace language state is displayed on the dashboard. The conditions described
that can be extended to build trace links from any to any on the states of figure 2 are boolean properties that are checked
model element in MPS. on the current state of a requirements project. An example of
• QA collection: the QA collection group includes the the boolean properties is GlossaryTermDefinedProperty. The
Process and the Dashboard languages. The Process boolean property GlossaryTermDefinedProperty returns true if
language allows defining refinement tasks for the re- a glossary term is defined and false elsewise. The boolean
quirements engineer. The Process language is used in properties are implemented in the ModelProperty Language
conjunction with the Dashboard language in order to in figure 1. This language holds the algorithms that implements
define at which moments a specialized requirements the analyses required for our specific requirements gathering
gathering framework will provide visual hints and press- system. Note that, although this customization work has been
button actions that guide the requirements engineer in the done at fortiss, the idea is that in the future this work would
direction of achieving her task in a correct manner. be performed by a domain specific tool developer at Diehl.
In a similar fashion, frameworks for gathering requirements
B. Customising the Framework: An Industrial Case Study for purposes other than for cooling systems could also be
Nowadays, many embedded hardware systems (e.g. in lap- customized using as basis the same original set of languages
tops, cars or planes) are assembled together with cooling as the one described in section III-A.
systems. The main purpose of those cooling systems is to
maintain an appropriate temperature during the operation of
the hardware being used. In this section we will extend the
Fig. 1: A language stack for gathering software requirements
IV. T HE Model L EVEL : A D OMAIN -S PECIFIC fan requirements project is depicted in figure 2. The dash-
R EQUIREMENTS G ATHERING F RAMEWORK IN ACTION board is the central artefact the requirements engineer refers
We will now exemplify how a user, in this case a require- to during requirements construction. It displays the current
ments engineer, can make use of the specialized requirements hint given to the user, as well as the current state of the
framework we have defined in section III-B. In particular, requirements refinement process as a graph or a table. The
based on an existing requirements document provided by hint displayed by the dashboard at the beginning of the project
Diehl Aerospace and following the directions made available is “Create Project Structure”. This hint is creational, which
to us from engineers at Diehl, we will incrementally build means the user can mouse-click on the hint to produce the
the requirements for the software that controls a fan-based instances of concepts that constitute the initial structure of
cooling system to cool down hardware boards embedded in the project in the same model where the dashboard instance
the doors of passenger airplanes. Because of the fact that has been created. Following this action a new hint, as shown
airplane doors include slides that should only be deployed in figure 3, proposes to the requirements engineer defining a
when a plane lands under specific conditions, the logic running new requirement for the system that includes the temperature
in those boards is non-trivial. The goal of the controller is thresholds for the functioning of the cooling system. Note that
to make sure the cooling fan runs at the correct duty cycle at this point the current state of the requirements model has
(fan speed) such that the hardware board works under ideal now changed to “Empty requirements model and no glossary
temperature conditions. The calculation of the duty cycle for terms defined”, as highlighted in orange in figure 3 – which
the fan at a given time depends on two inputs: 1) the current now presents a tabular view of the refinement process. The
temperature of the hardware board that needs cooling; and overall desired behavior of the cooling controller is stated as is
2) whether the hardware board’s temperature is increasing an instance of the Requirements language in figure 4. From
or decreasing. Note that in the example that follows we this requirement the requirements engineer can then extract
do not pretend to be exhaustive in the construction of the minimum (e.g., “Minimum increase value’) and maximum
requirements for the fan’s controller. This section reflects (e.g., “maximum increase value’) threshold values using the
part of our partners’ requirements refinements process and MPS intention “Extract Into Glossary”. When used, this MPS
demonstrates our framework’s abilities in terms of providing intention generates in the project’s glossary an entry with the
automated assistance to the requirements engineer. same names as words or sets of words selected from the text.
This constitutes the first refinement of the original abstract
Tool Supported Requirements Definition and Refinement requirement. The next step is to define the duty cycle of the
The first thing to do in a requirements project for a cooling fan as a function of the current temperature of the controller
controller is to create a new dashboard by instantiating the board and whether the temperature is going up or down.
Dashboard language that implements the cooling controller The dashboard assists the requirements engineer in this task
requirements process. A newly generated dashboard for our by providing a hint that, when mouse-clicked, automatically
Fig. 2: A newly created dashboard for the requirements framework
Fig. 3: The Dashboard provides a hint for adding a new requirement
generates a table to define such behavior. An example of such manually insert rows in the table that define the duty cycle for
a table is depicted in figure 5. Note that the minimum and given intervals of temperature, when the temperature is going
maximum threshold values in the table are preset in advance, up or down. The Table language itself implements checks for
as the process itself defines they should copied from the values completeness (all the temperatures between the thresholds are
previously stored in the glossary. We now come to the last mapped onto duty cycles) and functionality (only one duty
refinement, which is to precisely define the behavior of the cycle value is given per temperature). Violations of these
cooling fan’s controller. In order to do this it is necessary to properties are pointed out in the editor as red markers. Figure 5
Fig. 4: The requirements engineer adds a new requirement
Fig. 5: A filled in table and associated 2D visualization of the defined function
represents a filled in table holding, for non-disclosure reasons, construction (e.g. only correct models that conform to a meta-
a fictitious behavior of the fan’s controller. In the figure a model can be built), or a-posteriori checks for conformance
2D-graph representation of the table is also visible and it to certain well-formedness rules. This is the case for example
is produced by applying the Visualize Graph MPS intention for DSL workbenches such as Sirius [11], AutoFocus3 [8],
to the table. The running example we have described in this MetaEdit+ [18] or MPS [15] itself. However, none of those
paper can be downloaded at [1] as an MPS project. Another tools is capable of natively providing the means to explicitely
case study of using our framework is available at [2], where define a model construction process or methodology that can
we have designed a process to assist the user in building assist users when building instances of DSLs specified in those
natural langage-like requirements for embedded controllers. environments.
Two videos demonstrating our tool and portraying these two Model construction processes naturally depend on the do-
case studies can be found at [5], [6]. main the DSLs are aimed at. It is thus not surprising that
the explicit notion of process is more present in modelling
V. R ELATED W ORK environments that are specifically aimed at certain domains –
Mechanisms for providing some kind of guidance to the as previously mentioned, the Capella tool is a model-driven
domain-specific language user are present, to a smaller or engineering solution for systems and software architecture
larger extent, in all DSL definition workbenches. In most engineering which enforces the Arcadia [10] methodology,
cases, that guidance is provided in the form of correctness-by- aimed at specific domains such as transportation, avionics,
space or radar; the Soley tool suite [4], dedicated to model- performance degradation in larger systems. Potential solutions
based data extraction, processing and visualization, includes to this problem are currently being investigated by colleagues
workflows as first-class citizens. Coming back to generic of our at fortiss [7]. As future work, beyond mitigating the
workbenches for language constructions, there exists a large shortcomings above, we will continue working with Diehl
body of work in the area of model transformation chaining to Aerospace to develop the case study we present in this paper
orchestrate the flow of models to achieve a modelling goal. into a usable requirements gathering system. Other partner
For example, authors such as Wagelaar [19] or Kolovos [12] companies have shown interest in applying our work domains
propose mechanisms for automatically orchestrating model other than requirements engineering, which points to building
transformations such that certain modelling goals are achieved. or assembling different language stacks as well as different
In this area, the study which is the closest to the proposal in processes.
this paper is the FTG+PM framework [13], [14]. The FTG+PM
R EFERENCES
defines an explicit process for the execution of model trans-
formations. Enacting that process means that certain model [1] Cooling Controller Model Development Environment. https://github.
com/levilucio/CoolingControllerReqsDash.git.
transformations are performed automatically, while for others [2] EARS-CTRL Model Development Environment. https://github.com/
the user will have to input data at given points. The differences levilucio/EARS-CTRLDash.git.
with the work we present in this paper have to do with the [3] Meta Programming System. https://www.jetbrains.com/mps/.
[4] Soley Tool Suite. https://www.soley.io/.
fact that our process is non-invasive, and is aimed at advising [5] Video for the Cooling Controller IDE. https://youtu.be/HcYH6AV1UEU.
the user rather than executing a pre-defined work flow. With [6] Video for the EARS-CTRL IDE. https://youtu.be/vzhUwjH8eLE.
our approach automated actions are proposed to the user, who [7] V. Aravantinos and S. Kanav. Tool support for live formal verification.
Submitted to the Practice and Innovation Track at MoDELS 2017.
remains in complete control of the model edition process at [8] V. Aravantinos, S. Voss, S. Teufl, F. Hölzl, and B. Schätz. AutoFOCUS
all times. 3: Tooling Concepts for Seamless, Model-based Development of Embed-
ded Systems. In Proceedings of ACES-MB (co-located with MoDELS),
VI. C ONCLUSIONS AND F UTURE W ORK pages 19–26, 2015.
[9] A. Bayha, L. Lúcio, V. Aravantinos, K. Miyamoto, and G. Igna. Factory
We have presented a technique for the construction of product lines: Tackling the compatibility problem. In Proc. of VaMoS
domain-specific model editors in MPS, where these editors 2016.
[10] S. Bonnet, J. Voirin, D. Exertier, and V. Normand. Not (strictly) relying
are based on a set of composed DSLs and on a description on sysml for MBSE: language, tooling and development perspectives:
of the process that should be followed when building the The arcadia/capella rationale. In Proceedings of SysCon 2016, pages
models for that domain. We have applied our approach to the 18–21. IEEE, 2016.
[11] J. Hauswald, M. A. Laurenzano, Y. Zhang, C. Li, A. Rovinski, A. Khu-
construction of an editor for gathering software requirements rana, R. G. Dreslinski, T. N. Mudge, V. Petrucci, L. Tang, and J. Mars.
at two meta-levels: firstly, we build an abstract requirements Sirius: An open end-to-end voice and vision personal assistant and its
gathering framework, following the guidelines in the MIRA implications for future warehouse scale computers. In Proceedings of
ASPLOS’15, pages 223–238, 2015.
framework [17]; secondly, we specialize that framework for [12] D. S. Kolovos, R. F. Paige, and F. A. Polack. A framework for
our industrial partners at Diehl, by introducing a specific composing modular and interoperable model management tasks. In
requirements refinement process for controllers for cooling MDTPI Workshop, EC-MDA, 2008.
[13] L. Lúcio, S. Mustafiz, J. Denil, H. Vangheluwe, and M. Jukss. FTG+PM:
systems. The main technical contribution of this paper are an integrated framework for investigating model transformation chains.
the means to define a process to assist in building a model In Proceedings of SDL 2013, pages 182–202, 2013.
in a domain-specific model-driven development environment. [14] S. Mustafiz, J. Denil, L. Lúcio, and H. Vangheluwe. The FTG+PM
framework for multi-paradigm modelling: an automotive case study. In
This process is based on a set of automated model analyses Proceedings of MPM@MoDELS 2012, pages 13–18, 2012.
and can guide the user until the model is complete. At a [15] V. Pech, A. Shatalin, and M. Voelter. Jetbrains MPS as a tool for
methodological level, our contribution regards our ideas on extending java. In M. Plümicke and W. Binder, editors, Proceedings
of PPPJ ’13, pages 165–168. ACM, 2013.
the separation of the framework customizer and the domain [16] K. Pohl, M. Broy, H. Daembkes, and H. Hönninger, editors. Advanced
specific tool developer roles. While the former is responsible Model-Based Engineering of Embedded Systems, Extensions of the SPES
for defining a number of fundamental “brick” DSLs, the latter 2020 Methodology. Springer, 2016.
[17] S. Teufl, D. Mou, and D. Ratiu. Mira: A tooling-framework to
further specializes them for a particular application by adding experiment with model-based requirements engineering. In Proceedings
more languages and organizing the whole according to a of RE’13, pages 330–331, July 2013.
process. In its current state, the main shortcoming of the [18] J. Tolvanen. MetaEdit+ for collaborative language engineering and
language use (tool demo). In Proceedings of SLE 2016, pages 41–45,
technique we propose in this paper is the fact that it is the 2016.
complete responsibility of the domain-specific tool developer [19] D. Wagelaar. Blackbox composition of model transformations using
to check the consistency of the properties being checked domain-specific modelling languages. In Proceedings of CMT 2006,
2006.
during the unfolding of the process, as well as their logical [20] J. Whittle, J. E. Hutchinson, M. Rouncefield, H. Burden, and R. Heldal.
sequence in the process. Although we have gathered some Industrial adoption of model-driven engineering: Are the tools really the
information about process construction through the two case- problem? In Proceedings of MODELS 2013, pages 1–17, 2013.
studies at [5], [6], it is necessary to model larger processes
to better understand the advantages and disadvantages of our
proposal. Scalability is also an issue as analyses currently
run very often in the background, which will rapidly lead to