Introduction

Modeling requirements is an important activity during the requirements engineering process, as it supports elicitation by facilitating communication between stakeholders and engineers and documentation of requirements [Po12]. There are different possibilities to create diagrams, e.g., with computer-aided tools or by hand. Hand-drawn models (including those created with drawing tools like PowerPoint, Visio, etc.) are fairly easy to create and offer a lot of freedom to express the desired concepts [Sh05] while dedicated modeling tools (e.g., Enterprise Architect) allow for automated verification and code generation and thus support further development activities [Sp16].

Consequently, both ways have their advantages but also disadvantages. Drawing tools allow for customizing figures and creating domain specific modeling languages easily, but offer no code generation and verification of the created diagrams. In addition, often only a few basic shapes, such as rectangles and ellipses are available out of the box. Dedicated model editors exist for a large number of standardized modeling languages and often offer the possibilities to verify diagrams and generate code artifacts from the created diagrams (e.g., [Be12]). However, apart from often being expensive (at least for small and medium sized companies), these kinds of tools usually require intensive training due to their large set of features and often unintuitive use [Am06]. Another disadvantage of model editors is their limitation to pre-defined modeling languages. While some allow the definition of other modeling languages, this usually requires the manual creation of profiles and extensions, which can be quite laborious (e.g., [Sp16]).

In this paper, we propose to bridge the gap between both approaches by customizing common off the shelf software. Namely, we propose to create a customized model editor with integrated formal methods using Microsoft Visio. This allows not only to tailor tool support for requirements elicitation but to integrate model-based requirements engineering seamlessly into a continuous model-based engineering framework. Specifically, we show how to use extension, stencils and hyperlinked shapes to adapt Microsoft Visio in such a way that it can serve as model editor for requirements engineering models which are in accordance with the SPES XT modeling framework [Bö16]. Furthermore, we show that automated methods such as model verification techniques, which were defined to ensure consistency among the different models of the SPES XT modeling framework can be implemented and applied using the approach. Hence, the resulting tool support cannot only serve as model editor that allows documenting requirements in model-based fashion as foreseen by the SPES XT modeling framework, but to also allow implementation of advanced automated techniques, which have been defined for diagrams and models of the SPES XT modeling framework (cf. [Po16]). Thereby, we show that this approach combines the easy-to-use nature of diagramming tools and the powerful capabilities of dedicated model editors.

The paper is structured as follows: Section 2 introduces the SPES XT modeling framework for which we developed a Visio-extension. In Section 3, the shapes and the functions of the extension are presented. Subsequently, a brief overview of related approaches for customizing model editors for specific model generations and model verifications is given in Section 4. Finally, Section 5 concludes the paper and discusses future work.

The SPES XT Modeling Framework

The SPES XT modeling framework [Bö16] is an artifact-centric approach to continuous model-based engineering of embedded systems. The SPES XT modeling framework defines four viewpoints and several granularity levels as can be seen from Fig. 1. The Tool-Support to Foster Model-based Requirements Engineering for Cyber-Physical Systems 3 granularity levels allow reducing complexity by supporting the decomposition of the system into subsystems, while the viewpoints allow reducing complexity by allowing for separation of concerns. The four viewpoints are:

• The requirements viewpoint addresses the model-based documentation of requirements and the separation of the system from system context. To this end the requirements viewpoint supports the creation of context, goal, scenario, and requirements models.

• The functional viewpoint addresses the functional system specifications (derived from the requirements viewpoint) and modeling of system functions.

• The logical viewpoint addresses the decomposition of the functional building blocks into logical sub-systems with the main goal of delivering a logical architecture i.e. functions are clustered into logical components and

• The technical viewpoint addresses the mapping of logical components to the technical realization and their hardware and software components. Tool-Support to Foster Model-based Requirements Engineering for CPS 49

The SPES Visio Extension

Microsoft Visio offers a model editor for standardized modeling languages. In addition, by using stencils and associated shapes, new modeling languages can be created. Furthermore, Visio provides an API to write specific functions for model generation, verification, and import and export. In this section, we will show how to make use of these functionalities to create a Visio extension which provides support for the SPES XT modeling framework by ensuring conformance to the defined modeling languages and which implements defined methodological building blocks of the SPES XT modeling framework.

Visio provides a selection of pre-installed stencils for various modeling languages such as UML or BPMN and layout functions for creating diagrams. The Visio model editor consists (as shown in Fig. 2) of the shape view, the opened drawing sheet, the toolbar and existent drawing sheets for the document. In the shape view (left side), the installed stencils can be viewed and selected to be used in the drawing sheet. It is also possible to model on different sheets, which are located at the bottom of the editor window. The toolbar (top) provides various functionalities such as changing color, size, or alignment of model elements. To provide support for modeling languages not included in Visio, new stencils can be defined. Beyond the definition of stencils, Visio extensions can add new functionalities to the application and provide them to the user via the toolbar. For model generation and formalization, the necessary functionality has been added via the Visio API and SDK. It offers the possibility to control the Visio application in a programmatic way and all interaction possibilities that are available to the user as well.

Model Generation

The SPES Visio extension5 enables users to create diagrams according to the SPES XT modeling framework and helps them navigate between the various viewpoints and granularity layers. As the system or a subsystem is further decomposed, a tree hierarchy of the system is automatically defined and each element in the tree is linked to the sheet of the related viewpoints. An example of an automatically generated decomposition hierarchy is shown in Fig. 3. In a first step, the user specifies the name Adaptive Cruise Control as the system under development. Next, the user can navigate to the logical viewpoint and select specific model elements to decompose the system into sub systems.

In this example, the system Adaptive Cruise Control is divided into the sub-systems System Management, Speed Adjustment and Data Processing. Each node is linked to a corresponding template (shown in Fig. 4 for the adaptive cruise control node). The template contains links to models from the various viewpoints (however, tracing for inter-model changes is not yet supported). The root node and the corresponding template is defined initially for each SPES modeling project. Subsystems and their corresponding templates are automatically added when the user designates a certain model element as a subsystem.

Upon opening an empty file for a certain kind of model (e.g., a scenario model) the corresponding stencils are displayed automatically.

Additionally, several functions that automatically generate skeletons from information already modelled are implemented. For example, for each MSC reference in the modelled high-level Message Sequence Chart an empty sheet with the name of the referenced object will be generated and the shapes of the basic Message Sequence Chart will be displayed.

Custom-Made SPES Stencils

For the SPES XT modeling framework several modeling languages are required to define specific requirements models of the system under development (cf. [Da12]). For the artifacts of the different viewpoints standardized model languages such as UML class diagrams [OM15] or the ITU User Requirements Notation (including Goal-oriented Requirements Language and Use-Case Maps) [IT12] are used. Most of the modeling languages exist as stencils for Visio. For the modeling languages that do not exist as stencils, Visio offers the possibility to create customized shapes and bundle them in a stencil. This feature is required for several in the projects SPES2020 and SPES XT defined modeling languages. For example, for creating context of knowledge models [Da14] a customized notation must be created in form of a template (called stencil). The stencil for the context of knowledge and an exemplary context of knowledge model for an adaptive cruise control system is shown in Fig. 5. On the left side, the application offers the elements for modeling the context of knowledge. On the right side of the window, it shows the model and its elements, which describe which knowledge sources provide information for or constrain the development of the adaptive cruise control system. For instance, the document Regional Traffic Codes constrains the possible behavior of the adaptive cruise control to be developed.

Model Verification

The extension also offers support for model verification. In particular, it implements a variety of model verification algorithms to check the models for syntactic correctness.

The checks are realized with validation rules similar to UML constraints. For example, in the functional viewpoint a function network [Al16] can be checked for syntactic correctness, and the associated interface automata [AH01] can be checked with regard to completeness. Therefore, the incoming and outgoing messages are compared. Missed model elements can be detected and automatically added to the model. Fig. 6 illustrates an algorithm using path checking to ensure all elements are reachable in directional models.

INSTANCE1 INSTANCE2 INSTANCE3 Message1 Message2 Message3 ACTION Message4 INSTAN CE1 Message1 Message3 Message2 INSTAN CE2 ACTION INSTAN CE1 INSTAN CE3 Message4 INSTAN CE1

MscReference Fig. 6: Example BMSC and associated path-tree

The example in Fig. 6 displays a Basic Message Sequence Chart (left) and the tree the extension creates by traversing the model from element to element. The extension checks reachability by traversing the tree and identifying the elements not contained in it. In this example, the model on the left contains an unreachable element ("MscReference", bottom left) and therefore it does not exist in the traversing tree (right). This missing element then notifies a verification violation.

Related Work

There are several model editors for formalizations and model generation of models and textual descriptions. For instance, FormulaBuilder [Jö06] is a tool for graph-based modeling and generation of formulae. Therefore, the formal specification of properties describes the requirements of a system. This is different to the SPES Visio extension, because of the focus. FormulaBuilder deals with formalization of models, in contrast to the Visio extension focusses on the generation of models for requirements engineering. A similar approach is followed by the tool from [EW02]. This tool supports UML activity diagrams as workflow models and exports the model into a format that a model checker can verify against requirements. Here, the focus is more on model verification than on model generation. [KK15] developed DOREF an approach for the generation of models and to check them against requirements in real-time. The focus here, is to generate models from formal text and to perform verification. [Fo15] presented an approach for the Papyrus UML editor. Therefore, a systematic generation of a diagram definition is used to generate a modeling language tool that guarantees compliance to standard notation. [Ca11]

Conclusion and Future Work

It is hard to provide appropriate tool-support for model-based requirements engineering, which seamlessly integrates into further model-based development activities. As requirements engineering is a conceptual activity employing creativity and lots of stakeholder communication, a modeling tool needs to be lightweight to adequately support the requirements engineers in their day to day work. This contradicts the approach of most professional tool-suites for model-based engineering, which in part rely on a formal specification of requirements and models, which the requirements engineer typically is not able to provide at early stages. In contrast, easy to use standard modeling editors commonly lack the potential for formalization and application of automated methods needed in the engineering of complex cyber-physical systems. In this paper, we proposed an approach making use of both concepts leading to a lightweight model editor, which can easily be tailored to fit for automated approaches as well. We presented an MS Visio extension for the modeling of cyber-physical system using the SPES XT modeling framework. The extension shows, that Visio, in combination with its API, can be used for modeling requirements through several viewpoints. Additionally, the extension for Visio allows formal checks of the created models, such as function networks or Message Sequence Charts. Furthermore, Visio offers the possibility to create drawing elements for domain specific modeling languages. The defined shapes can be used for drawing conceptual models and check them. Hence, models can be generated on the needed level of formalization and automated techniques can be applied accordingly. Future work will have to deal with a thorough evaluation, particularly, the approach shall be evaluated with respect to other modeling applications and needs to consider further extensions for verifications of other modeling languages.