Requirements require some effort to read and understand. But what if you could bring them to life? This is possible, and you can see this at this year’s ReConf at the science track on Monday, March 16 2015.

Visit our booth us at ReConf 2015.  Please contact us to receive a discount code.

No matter how requirements are captured, there are usually two drawbacks about them: (1) They don’t look like the “real thing”, and (2) they are inanimate.

The first can be corrected to a degree by simply including images into your requirements document.  In fact, sometimes the marketing department will deliver some of the artwork.  The second is what can be fixed as described here, and what we will present at ReConf 2015.

Using BMotion Studio to create interactive specifications

At our talk at ReConf, we will build a simple traffic light system.  We will move from requirements to an interactive visualization in less than an hour.  We use the tool Rodin, enhanced by a few plugins.  Everything you need is freely available.

Let’s start with the requirements.  We won’t describe them here in detail.  The figure to the right tells it all: We have a street with traffic lights that allow pedestrians to cross safely. We assume that the hardware is in place, and that the task is to build the controller to drive the system.

In order to build an interactive visualization, we need a model of the domain (the traffic lights, etc.) and the requirements.  This is the biggest catch in this approach, you need an expert who can model this with an appropriate modeling language.  In the talk, we will use Event-B. How such a model looks in detail is described in the tutorial of the Rodin Handbook.

Building the visualization

Now it gets interesting.  The Plugin BMotion Studio (BMS) has a graphical editor.  The image of the traffic lights can simply be imported, providing the foundation for the visualization.

For the visualization to work, two things need to happen: (1) We need to change the colors of the traffic lights, and (2) we need to make the buttons interactive.  The following picture shows the BMS graphical editor:

You can see a palette on the right side.  One of the available elements is an Ellipse.  To make the colors changeable, we simply draw a circle over each of the “lamps” of the traffic lights.  The figure shows this.  The red light is selected, showing the handles that allow the resizing of the circle, to fit properly over the image.  In the properties view (not shown), the color can be selected.

Next, the newly created elements must be connected to the formal model.  This is done by right-clicking on the circle and adding an observer.  This will open the following dialog, which has already been configured to connect the model (via the Predicate) with the visualization.  If the predicate is true, then the background color is set to the given color value, which represents a light red.

This process has to be repeated for all lights. As the two lights for the cars behave identically, the second light can be created by copy and paste.

The buttons are created in a similar fashion, except that they trigger an event (instead of being an observer, like the lights).

Running the visualization

After the visualization is wired, it can be started.  Users can interact with it by pressing the button and by propagating to the transitions of the traffic light regime. This can also be done in an automated fashion, and the tool can be employed to detect violations of requirements or deadlocks.

Decoupling the visualization from the implementation

What we modeled here was simply the domain, not the functionality.  In other words, nothing we did so far constrained the functionality in any way.  To give an extreme example, we are still free to provide an implementation that switches all lights on at the same time.

To provide the actual traffic light functionality, we’d have to incorporate more requirements into the model. Especially the requirements responsible for the light regime.  But this would not require any changes to the visualization.

In practice, this could also be used for situations where the same hardware is used for different variants (e.g. a standard and a luxury variant).  The same visualization would then be driven by two distinct implementations.

We hope that this little overview made you curious and look forward to seeing you at ReConf 2015.