Graphical dataflow composition framework [closed]

Question

I am interested to embed a MathWorks Simulink like type tool into my application. In this embedded tool units are expressed as blocks with their input and output ports and parameters for each block using my block definition files written in any way that the tool wants. I want the framework to be generic and read the block definitions from somewhere and then allow the user to compose a dataflow of the given blocks based on their definition (preferably comes with graphical editor to do so). I then want the tool to export the user composed dataflow of blocks where I could pragmatically read it in Java (or other languages) and do whatever I need to with it like building an executable version of the given dataflow.

I know at advance level, the exported block compositions can be smart enough to be executable but I am ok with exporting the block composition/topology and the input and outputs connected to each other . In other words, I am NOT looking for a dataflow programming language. I am looking for the just the tool-set that allows graphical composition of dataflows and then export the composition as say a json or something that I could load in a programming languages and do whatever with it.

The above framework/tool is what Simulink does for blocks coming from its different libraries but I need to embedded such thing in my own tool and was wondering what open source project is close to what I want to do. I guess what I want is a dataflow composition framework. Please correct my view of looking at this.

Answer 1

Data flow languages are special case of (colored) Petri nets. A colored Petri net consists of a graph of places, each holding colored tokens carrying values (colors is a funny name for "data type", a value is just a color/datatype instance). Tokens from multiple places combine via transitions to produce tokens in following places; the "transition" can combine the "colors" (e.g, compute values). So, one might have a token "color" for floating point values, and transitions consisting of add, subtract, multiply, divide; and you can pretty easily model arithmetic data flow (e.g., Simulink) with this.

More importantly, CPNs are amazingly general. They are filled out with hierarchical CPNs, which give the effect of data-flow subroutines, and allow all kinds of extensions (such as timed-constraints, etc.).

The Colored Petri Net Tools site offers a complete suite of tools for building/editing/displaying and even evaluating arbitrary Colored Petri Nets. (You might not even need to write your Java program to evaluate them!). It even offers static analysis of such graphs, such as "terminates", etc, which you usually don't get with Matlab or National Instruments style data flow language.

It wouldn't surprise me if there were a Java-based version of the CPN tools; that group has been building such tools for over a decade. It also wouldn't suprise me if there was a way to constrain the colors and transitions to a specific set, e.g., to the "dataflow" langauge you define, relatively easily.

Answer 2

My proposal would be Yakindu Statecharts Tool. I'm not sure though if that would be too complex. But I think it should be mentioned around here. You can define rules and errors are shown, when things are connected that shouldn't be. I think it also looks a bit like what Simulink does, doesn't it?

Answer 3

You should take a sneak peak on J. Paul Morrison's DrawFBP. I was unable to draw an edge with it, but it must be my fault.

Also, the best UI I've seen is moonbase.com, if I ever write one (I will), it will be similar. Nice preview area, tutorial mode, it's beautiful. I haven't figured out, wheter the editor is available or what's the aim of this project.

---

Last, our DF script language (just to see, what should we hide with a graph editor):

redbutton: Button  // we have a button
redbutton.press >> redlamp.on   // it turns the red lamp on
redbutton.press >> greenlamp.off  // and the green off
redbutton.presst >> redmsg.in  // also reports the action

greenbutton: Button  // opposite
greenbutton.press >> greenlamp.on
greenbutton.press >> redlamp.off
greenbutton.press >> greenmsg.in

redlamp: Lamp
greenlamp: Lamp

redmsg: Text
redmsg.value = "red"
redmsg.out >> console.in

greenmsg: Text
greenmsg.value = "green"
greenmsg.out >> console.in

console: Stdout

As you can see, there are only 3 elements of the language:

• place a component (name: Type)
• set value of a property (compname.propname = value)
• define a message (srccomp.srcport >> dest.destport)

Of course, a graphics editor should be better. We have only visualizer now.

Answer 4

I am also looking for a tool like this and stumbled upon JGraph, a developer library which can be used to build an interactive graph/diagram drawing tool on your own. This does not mean that you have to do all the hard work on your own, since a good starting point is already provided by com.mxgraph.examples.swing.GraphEditor in the folder examples.

A screenshot of that demo editor

When exported to the so called mx Graph Editor File (*.xme) one actually gets xml. For the example above:

<mxGraphModel>
    <root>
        <mxCell id="0" />
        <mxCell id="1" parent="0" />
        <mxCell id="4" parent="1" style="fontSize=24" value="Start"
            vertex="1">
            <mxGeometry as="geometry" height="120.0" width="160.0" x="80.0"
                y="250.0" />
        </mxCell>
        <mxCell id="5" parent="1" style="fontSize=24" value="???"
            vertex="1">
            <mxGeometry as="geometry" height="120.0" width="160.0" x="310.0"
                y="480.0" />
        </mxCell>
        <mxCell edge="1" id="6" parent="1" source="4" style="" target="5"
            value="">
            <mxGeometry as="geometry" relative="1">
                <mxPoint as="sourcePoint" x="290.0" y="310.0" />
                <mxPoint as="targetPoint" x="220.0" y="330.0" />
            </mxGeometry>
        </mxCell>
        <mxCell id="9" parent="1" style="fontSize=24" value="Profit"
            vertex="1">
            <mxGeometry as="geometry" height="120.0" width="160.0" x="570.0"
                y="710.0" />
        </mxCell>
        <mxCell edge="1" id="10" parent="1" source="5" style="" target="9"
            value="">
            <mxGeometry as="geometry" relative="1">
                <mxPoint as="sourcePoint" x="520.0" y="670.0" />
                <mxPoint as="targetPoint" x="490.0" y="840.0" />
            </mxGeometry>
        </mxCell>
    </root>
</mxGraphModel>

The parsing of the file using standard XML libraries should not be a problem, so in summary, when all the position information is ignored, one gets a simple dataflow description.

However, please take my suggestion with a grain of salt, since I am also looking for the right way to go.