Requirements and Eclipse: RIF/ReqIF as Ecore (and with Xtext)

Within the VERDE project, itemis is working on the traceability of requirements based on the Eclipse platform. To be able to work with requirements, we have implemented an Ecore representation of the RIF/ReqIF requirements exchange format. RIF was developed by the German HIS Automotive and is now being standardized by the OMG under the new name “ReqIF“.

Nirmal has derived the Ecore format from the specification that is provided as an Enterprise Architect model. And of course we have combined this with textual DSLs. RIF allows you to model your own requirements structure (i.e. define requirement types, attributes and links). This can be done through the ecore editor and the GUI for the requirements is automatically generated during runtime. A possible structure could look like this:

The definition of this requirement structure is like this:

In our solution, you cannot only define natural language requirements, but through the integration of Xtext you can bring in more formal notations – be they standard or project specific. Of course, you get all the benefits of Xtext, like content assist, syntax highlighting etc. Here is a screenshot of the content assist in our small formal language.

Android, AUTOSAR and Xpand

Xtext 1.0.0 is scheduled for the Helios release and while I think that it is a great tool we shouldn’t miss the other apects of a toolchain that are crucial for MDSD: M2T, especially code generation. It is only with M2M and M2T that models show their full potential, since we can use automation. The front end does not necessarily have to be Xtext – In this example we are generating code for several platforms from Artop, the community source tool platform of AUTOSAR. Artop provides an EMF based implementation of the AUTOSAR metamodel (and much more) and is a perfect source for code generation.

In the AUTOSAR methodology, as described by the standard, a Run Time Environment (RTE) is generated from the model. The specification defines a C API that represents the RTE and all commercially availalbe tools implement this C specification. However, we use the AUTOSAR models to generate Java code for Android and specifications for business applications, too!

This is our showcase, that we present on fairs etc: A RC car chassis contains several ECUs. A sensor transmits data to a Gateway ECU. This ECU forwards the data both to a display (like your infotainment), but it also forwards this data to a server running a webserver from which it is transferred to mobile devices, like android phones. This is typical for the future challenges in automotive systems: The convergence of technologies from different domains.

Showcase - ECUs communicating with Web Services and Android

With manual coding, the code for accessing and transmitting the data would have been written several times independently, and changes would have been integrated the same way too. However, we have written Xpand templates for code generation, that not only generate to different RTEs for the in-car ECUs, but also generate code fragment for the Web-Service and the Android application. Adding new data (like rpm) to the transmitted information is supported by code generation, resulting in less manual changes and in higher quality at shorter development cycles.

Using Xpand to generate more than C from Artop

Eclipse technologies provide a great set of tools for leaving the trodden path of monolithic tools and implement efficient solutions for customer requirements.

Android application - basic data API is generate from AUTOSAR model

Xtext and Papyrus / UML

The Papyrus team are doing a great job integrating Textual DSLs with graphical modelings. I am happy that we could help them a bit in integrating Xtext with their modeling tool. The combination solves several usability glitches that I hated in all modeling tools: Adding attributes through a property sheet is cumbersome.

I have created a short video to demo how the current nightly build of Papyrus supports the editing of ports nicely (Update: by the use of ANTLR, next versions will use Xtext, which is also based on ANTLE). If you choose to edit a port, you get a textual editor with syntax highlighting and content assist (and content assist knows about your UML model!)
Great job, Papyrus team!

Grab your nightly build at: https://build.eclipse.org/hudson/job/cbi-papyrus-0.7-nightly/

Soon coming: A blog entry about how we integrate Xtext to bring more formal notations into requirements engineering.