UML tools such as Enterprise Architect or Rhapsody (and others) are well established in the software development process. Sometimes the modeling guidelines are following a custom modelling, e.g. with specific profiles. So when you are modelling for AUTOSAR systems, at sometimes you are faced with the problem of transforming your model to AUTOSAR. For customer projects, we have analyzed/implemented different stratgies.
Artop as a integration tool
First of all, if you are transforming to AUTOSAR, the recommendation is to transform to an Artop model and let Artop do all the serialization. Directly creating the AUTOSAR-XML (.arxml) is cumbersome, error-prone and generally "not-fun".
Getting data out: Files or API
To access the data in Rhapsody, you could either read the stored files or access the data through the API of Rhapsody. This post describes aspects of the second approach.
Scenario 1: Accessing directly without intermediate storage
In this scenario, the transformation uses the "live" data from a running Rhapsody as data source. Rhapsody provides a Java based API (basically a wrapper to Windows COM-API). So it is very easy to write a transformation from "Rhapsody-Java" to "Artop-Java". A recommended technology would be the open source Xtend language, since it provides a lot of useful features for that use case.
Scenario 2: Storing the data from Rhapsody locally, transforming from that local representation
In this scenario, the data from Rhapsody is being extracted via the Java-API and stored locally. Further transformation steps can work on that stored copy. A feasible approach is to store the copied data in EMF. With reflection and other approaches, you can create the required .ecore-definitions from the Rhapsody provided Java classes. After that, you can also use transformation technologies that require an .ecore-definition as a basis for the transformation (but you can still use Xtend). The stored data will be very close to the Rhapsody representation of UML.
Scenario 3: Storing the data in "Eclipse UML" ecore, transforming from that local representation
In this scenario, the data is stored in the format of the Eclipse provided UML .ecore files, which represent a UML meta-model that is true to the standard. That means that your outgoing transformation would be more conforming to the standard UML meta-model and you could use other integrations that use that meta-model. However, you would have to map to that UML meta-model first. There are several technical approaches to that. You can even to the conversion "on-the-fly", implementing a variant of Scenario 1 with on-the-fly conversion.
Technology as Open Source
The base technologies for the scenarios are available as open source / community source:
- Eclipse EMF
- Eclipse Xtend, Qvto (or other transformation languages)
- Artop (available to AUTOSAR members)
Comments