Wednesday, July 05, 2017

Tool supported Papyrus customization

by Draskovits Stefan and Heinzl Michael

Introduction

Papyrus is a model based open source engineering tool. The core feature of Papyrus is to create domain specific applications. Therefore, you can customize every important aspect like: UML profile, model explorer, diagram notation and style, properties views, palette and creation menus and much more.
This customization has a high impact on the usability in real productive environments. Furthermore, this customization mechanism of Papyrus positively influences the pace of work, because only relevant elements are displayed to the user.


Example of a Papyrus instance

Thus the Papyrus environment provides a huge set of customization possibilities. Papyrus has many configuration files, where you can specify exactly the look and feel of the environment. This results in a huge set of files with configuration properties and references, which makes the customization of Papyrus surprisingly complex. The target audience has not the required knowledge and insight in this configuration system. As model based engineering is a rather new field, it is developing constantly.

The approach of Papyrus is a very ambitious one, but too complex for their target audience. This results in a huge overhead to set up a new Papyrus projects. For that reason it is very time costly and more likely to put people off, as there are many possibilities and ways to customize a Papyrus instance. Besides that it requires a lot of time to set up a project, it is also necessary to maintain and update the project. If you want to use a certain feature you have to configure multiple files to achieve the desired result.
Additionally you have to have a certain base knowledge about programming and model driven engineering. As there are so many properties and references in these configuration files it is a lot to process at a time if you are not familiar with the system. In summary the whole process of setting up and maintaining a project is cumbersome and tedious.

This paper deals with exactly with those described problems. Our goal is to develop a meta model with a textual representation to describe a specific set of the customization possibilities and gather them in one place. Furthermore, we develop an automatic tool which can process our meta model and generate all relevant configuration files to build a customized Papyrus instance. Many of those configuration files are an instances of a corresponding meta model. The meta models of the configuration files are used to generate and adapt the files without interfering directly with the textual representation. By using the meta models of the configuration files following advantages emerge:

  • Concise and precise definition of the language concepts Standardized exchange format
  • Checking correctness of models
  • Simple maintenance
  • Extensibility of modelling languages
By using this model oriented approach one can setup a customized Papyrus instance in a few simple steps. Therefore, the setup time decreases significantly. As our textual representation of our meta model is designed for easy use, it is not necessary to read the whole complex Papyrus customization documentation. Furthermore, you only have to specify a certain feature once and it will be added to multiple configuration files. Overall the tool provides a simple but powerful language to describe and generate a Papyrus configuration. 


Meta Model

The meta model which is used as a an input is kept simple on purpose. Users should be able to simply create a model for their needs. The meta model contains the root element CustomPapyrusModel which contains multiple ItemsThe element Item contains one property of type EString which is name. It is used to generate pallet rules, assistant rules and element creation menus, which represents the configuration files for a papyrus instance.

Meta Model


Future work

There are still menus, where it would be nice if they are configured automatically, which is not handle by this project at the moment. Therefore, for future work the tool could be extended with a generator for other features.
  • Properties view
  • Multiple viewpoints Styling (CSS)
  • Extended branding Welcome page
  • UML Profiles 

Tuesday, July 04, 2017

Model Profiling

by Serap Kadam, Andrey Maltsev, Polina Patsuk-Bösch

Introduction

In this work we describe an execution-based model profiling approach by modeling an autonomous-driving vehicle control system in UML, where the main behavior is modeled with statecharts. Code generated from this model provides activity logging information at runtime, which is used to represent the interaction between the components of the system and their behavior. From the outputted logs a sequence diagram (SD) is generated by using a tool called UML Miner. These sequence diagram is then analysed and transformed back to statecharts (SC) by means of metamodeling and model transformation.

Approach

Our approach is based on the unifying conceptual framework for execution-based model profiling. An adapted version of this framework is presented in the figure below.


The framework has two perspectives: the prescriptive perspective on the left-hand side, where design models are used to create a system, and the descriptive perspective on the right-hand side, where observation models are used to describe the actual system behavior at runtime.
In the prescriptive perspective a design model is used to prescribe how a certain system should be built on the modeling level. This design model is created in design language, which resides on the metamodeling level above the design model.
In the descriptive perspective there is an observation language on the metamodeling level. This language refers to the design language in the prescriptive perspective. The observation language captures the operational semantics of the design language, i.e. everything that can change in a running system modeled in this design language.
The observation models conform to the observation language and can be transformed into model profiles for further analysis in diverse tools such as process mining tools, runtime verification tools, monitoring tools.
In our extension of this approach we take sequence diagrams and statecharts as model profiles. We suggest to transform the observation model into a sequence diagram to observe actual interaction of the system components at runtime. The next step is to transform the sequence diagram into one or several statecharts. New statecharts give a different overview of the system and the objects in the system.

Case Study

The main goal of case study is to evaluate to what extent descriptive models such as sequence diagrams and statecharts can be applied to analyze and improve a model-driven engineered system. In particular, we analyze a Raspberry Pi-based car, which software is a fully model-driven engineered system. We enhanced this system with execution-based model profiling capabilities, performed live experiments, collected the runtime information in form of observation models and transformed them into SD and SC.
The example has been modeled using a small subset of UML, which has been named Class/Statecharts (CSC). The modeled state chart of PiCar is shown below.


Technical Realization

The technical realization of the case study has six major steps:
  1. Logging instrumentation of the system under study (SUS) - we implemented a logging component named csvWriter in Python that is used by the SUS at runtime. This component creates a CSV file and adds rows to this file every time the component is called from an operation.
  2. Extension of the code generator - we extended the code generator in such a way, that the name of the required log call can be modeled as tagged values of the package on which the code generation is called. Additionally some mapping or specification for the parameters of the log call has to be introduced.
  3. Transformation of logs into a sequence diagram - we used UML Miner to transform CSV logs into a sequence diagram in XMI format. This XMI file can be imported into Enterprise Architect (http://www.sparxsystems.com/products/ea/), where it is visualized as a sequence diagram. Further we transformed this XMI file into statecharts.
  4. Metamodel extraction from the generated sequence diagrams -  we created a  metamodel for files generated by UML Miner. We decided to construct a XML-schema (XSD) of generated files. To generate XSD we used a tool inst2xsd (Instance to Schema Tool) from XMLBeans Tools library. Then we took the created XSD-files as source for the generation of an Ecore model, that we used for further research.
  5. Transformation of the sequence diagram into a statecharts - we decided to take an approach proposed by Tewfic Ziadi, Loic Helouet and Jean-Marc Jezequel. To realize a sequence diagram into statecharts transformation, we created a target metamodel for state machines in EMF. We used a simplified metamodel of the UML statechart. At this point, generated XMI files from this case study did not contain any additional combined fragments, which are responsible for the composition operators. So the only possible way, we could get basic flat statecharts, was to transform lifelines without any additional conditions, into flat statecharts.
  6. Visualization of the statecharts - we developed a graphical concrete syntax for statecharts with Sirius that allows to display statecharts and results of our research in visual and more human form. We used the graphical concrete syntax to test data and to make high-level analyses of the observation model.
The overview of the technical realization is given below:

 

Observation language

The metamodel of the observation language is derived from the operational semantics of the design language CSC used in the context of this study. Both observation language and design language CSC as well as their relation is depicted in the Figure below. The changes at runtime included updates of the attribute values in the static aspect of the system, i.e. class diagram, and changes of the current state and the current fired transition in the dynamic aspect of the system, i.e. statechart. These elements are tagged with the <<observe>> stereotype.

 

Generated Model Profiles

We derived two types of model profiles from the logs in form of observation models: sequence diagrams and statecharts. We used UML Miner to generate a sequence diagram and the approach described in above to realize the model transformation from sequence diagrams to statecharts.


Conclusion and Future Work

In this work, we transformed an observation model into a sequence diagram and further into statecharts to observe the actual interaction of the system components at runtime and gained new information about the system.
We extended the unifying framework for execution-based model profiling with operation calls. We took a Raspberry Pi-car as a basis for our case study and fulfilled all the requirements for the system under study. We enhanced this system with execution-based model profiling capabilities and realized the prescriptive perspective of the unifying conceptual framework. During the implementation of this case study we extended the used code generator with the possibility of generating log calls in the code. This logging code reflects the operational semantics of the design language. We performed live experiments and collected runtime information in form of observation models. The descriptive perspective was realized by the implementation of transformation of logs into a sequence diagram and transformation of this sequence diagram into statecharts. After the transformation of logs into the sequence diagram we could observe the internal behavior and communication between the systems objects. These results could be used for the high-level analysis, conformance checking and pattern identification.
While the first results seem promising, there are still several open challenges, which were covered in this work. The quality of the information in the generated sequence diagram could be improved with design pattern recognition. After this improvement we hope to fully realize the chosen algorithm for transforming sequence diagrams into statecharts and to get more information for the high-level analysis of the system behavior.