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