Using RMF to integrate your models

We’ve all seen it: You need to write a spec, so you open Word, write some text, you copy a state diagram from Enterprise Architect, and eventually send it off as a PDF.

Okay, things are slightly better now. In the Eclipse ecosystem, maybe you are using Papyrus for modeling with UML or SysML. You may even use a real requirements tool, like Eclipse ProR. But again, you need to get that diagram into the model, so you will still perform the dreaded copy & paste operation, which will inevitably convert your beautiful model into a lifeless bitmap.

There have been attempts to correct this, for instance by connecting the models with a traceability framework. This is a step forward and allows you to create and analyze your traceability, but it ignores the issue of presentation.

An RMF-based Canvas

What we’ve been experimenting with, and where we see a lot of potential is RMF-based model integration and traceability. The Requirements Modeling Framework is an established project for working with textual requirements, which uses ReqIF, an OMG standard, as the underlying data model. We noticed that ReqIF already contains everything you need for traceability: atomic requirements (“SpecObjects”) that can by customized with an arbitrary number of typed attributes, and traces (“SpecRelations”), that likewise can hold any number of attributes. But on the downside, you are confined to the ReqIF universe: You can only create traces between SpecObjects.

But here is the idea: Introduce SpecObjects that act as proxies. These contain references, which are resolved upon rendering. ProR renders information in a grid structure, not unlike Excel (but with a hierarchy). Every box represents the value of a SpecObject, so it is contained in an atomic fashion, with a neat rectangular border around it.  We’ve already implemented this for traceability to Event-B (formal) models, but we are currently working on a generic solution for EMF-based models.

So this is the vision: You work within Eclipse, e.g. you create a UML state diagram in Papyrus. You then drag it into ProR (the RMF user interface), where a proxy element is constructed that renders the diagram seamlessly in your specification (in a box with a border around it). Suddenly, what used to be a requirements tool, becomes a drawing board with boxes that can be filled with content from anywhere – content that is referenced, and rendered on demand. The user does not care whether the content is retrieved from another model that is active within Eclipse, or via a web service, or OLSC, from half across the world.

We broadly identified three integration models, that we would like to present here:

Proxy element in text flow

A proxy element can be inserted simply into the flow of SpecObjects, as shown above.  This is the equivalent of “copy and paste” (no traceability), but at least the content is always up to date.  In the above figure, the proxy element is a child (as seen from the indentation), to indicate the parent-child relationship.

Proxy element with additional attributes

A proxy element can be enriched with “normal” attributes, which tightly connects all values – they represent one unit.  This is shown in the above figure, that shows a ReqIF-value and proxy-value next to each other.

Proxy element via SpecRelation

Last, a “classical” traceability can also be realized.  But in contrast to external solutions, we use (ReqIF) SpecRelations for the traceability.  As a result, the link target’s name that is shown in the main view is provided by the model (in this example “safety_property (mac)”.  The actual value can be inspected in the Properties View, by simply selecting the link target.

Put it to work

Of course, these three approaches can be mixed and matched, to maximize value.  For instance, it makes a lot of sense to establish a linked-based traceability, for instance to check the modeling coverage or to analyze the impact of changes.

There are a number of advantages to this approach: The user can find the most convenient presentation, referencing other content in-line (in a box) or via a link; to analyze the traceability, only the ReqIF data structures have to be known, the analyzer can be oblivious to where the content is pulled from; And last, is is possible to store a cashed version of the content, in addition to the ID. This means that by sharing the ReqIF model, the traceability is shared as well. You could open the exported .reqifz file in Rational DOORS, and you would see all the referenced content (which of course may be stale and cannot be edited here, but hey, it’s in DOORS). Even better, you could use DOORS’ powerful traceability analysis tools.

Next in line: Papyrus (UML and SysML)

What we just described has been realized and is available for the (Eclipse-based) Rodin platform, which supports the Event-B modeling language. But Event-B is rather exotic.  Therefore, we are working on a Papyurs-integration right now.

Image courtesy of digitalart /

One Pingback/Trackback

  • Pingback: Is Eclipse Papyrus Ready for Industry? - Formal Mind GmbH()

  • Jan Klostermann

    What do you think about joining forces and setting up a full-blown open source systems engineering toolchain from the existing stuff, that is easy to install for evaluation purposes, supports the best engineering practices and is suitable to start serious work with it: ReqIF Studio, Papyrus, … (maybe even allowing install choices like Rodin)
    Potential users could be academia and students (always short on money), small teams and startups, OpenSource projects, freelancer and systems engineers at home, Open Source Evangelists, and in the long run companies and even the big corporates…
    And it should be accompaigned by a discussion and knowledge sharing around the stuff:
    * How to build and customize such a toolchain
    * How to use it
    * How to collaborate with it
    * How to integrate it with other tools to collaborate with other people’s toolchains
    … showing what already works, workarounds, and what still needs to be done.
    And create well discussed, high quality models to show-off the features and good systems engineering methodology.

    Maybe this can grow a community around it and help spreading deep modelling knowlegde that is so much needed (and too often lacking)…

    • Hello Jan,

      Thank you for your feedback and your suggestion. Actually, we even tested the water for something similar, which you can find at .

      However, here comes the big “but”: We also used the above initiative to see the market response to this idea. And the response suggested that the business case for this was not strong enough. After all, the whole thing needs to be financed somehow.

      The bottom line is: The target group that you mention (academia and students) cannot support this, if realized by a small company like Formal Mind. It makes more sense to see whether this could be funded as a research project (in fact, this is what got Rodin where it is today).

      If you are a student or researcher, you may want to talk to the teaching staff regarding this idea. If you find a department that is willing to apply for a research grant to implement this, then we’d consider joining it.

      Again, thank you for your suggestion.


      – Michael

      • Jan Klostermann

        Hi Michael,

        Cool idea, what you set up there. But I would focus more on the professionals already working as systems engineers, as a ‘community of practice’ somehow. Maybe the order in the list was suggesting something different 😉
        And I understand the business case issue! It would be helpful to find some companies that would like to invest the money they spent into the proprietary vendors to invest in the getting up and running of the open source tool chain ecosystem, bringing them together with the service providers and coders…

        • Hello Jan,

          > It would be helpful to find some companies that would like to invest (…)

          This is what the Eclipse Working Groups do, and for what you’re mentioning, you may want to look particularly at PolarSys and the Papyrus Industrial Consortium. We are following those activities, but so far did not find the business case to actively participate.


          – Michael