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 / FreeDigitalPhotos.net