SCXML/State machines visualization library

3,007 views
Skip to first unread message

Jacob Beard

unread,
Oct 8, 2012, 7:37:49 PM10/8/12
to d3...@googlegroups.com
Hi,

tl;dr, check out this cool thing I built with d3: http://goo.gl/wG5cq

I've released a JavaScript library for state machine visualization based on d3: https://github.com/jbeard4/scxml-viz

It accepts SCXML documents as input, and produces SVG output using d3's Treemap layout.

Visualized models can be animated in response to state changes using the SCION SCXML interpreter: https://github.com/jbeard4/SCION

You can play with these libraries together using this simple web simulation environment: http://live.echo-flow.com/scion-web-simulation-environment/

Here's a demo of this environment in action: http://goo.gl/wG5cq

Alternatively, you can use SCION and scxml-viz in a live user interface. Here, the state machine specifies drag-and-drop behaviour on the div, and is graphically animated in response to DOM user interface events: http://jsfiddle.net/jbeard4/mjm72/

This was my first time using d3, and overall I'm really pleased with the project.

If you have any questions, please don't hesitate to ask. Thanks,

Jake

nick

unread,
Oct 9, 2012, 10:46:34 AM10/9/12
to d3...@googlegroups.com
looks great! love the simulation part.

I'd love the option for a state trace while watching what happens.

scxml is a really good looking technology... haven't found the right reason to use it yet, though!

i have been working on a d3 integration with Blockly... I don't have the demo up and running: the one up there is a few months old, and hardlinked to blockly, which changed its API since i posted it. perhaps there is an opportunity for collaboration, i.e. building up SCXML with Blockly blocks, then using your visualization for simulation. The dependencies are mostly the same: i'm already using jqurey, codemirror, and, obviously, d3.

Jacob Beard

unread,
Oct 9, 2012, 3:43:16 PM10/9/12
to d3...@googlegroups.com
On Tue, Oct 9, 2012 at 10:46 AM, nick <nick.b...@gmail.com> wrote:
looks great! love the simulation part.

Cool, thanks for the feedback :)
 

I'd love the option for a state trace while watching what happens.

I had that feature before I created the visualization part of it. Should be easy to add back in.
 

scxml is a really good looking technology... haven't found the right reason to use it yet, though!

Feel free to email me directly if you want to rap about ideas.
 

i have been working on a d3 integration with Blockly... I don't have the demo up and running: the one up there is a few months old, and hardlinked to blockly, which changed its API since i posted it.

I tried out the demo here, and clicking on "d3" under the "Blocks" tab didn't appear to do anything.
 
perhaps there is an opportunity for collaboration, i.e. building up SCXML with Blockly blocks, then using your visualization for simulation. The dependencies are mostly the same: i'm already using jqurey, codemirror, and, obviously, d3.

 
I'm not sure if blockly could be used for developing SCXML. SCXML is based on Statecharts, which is a visual language based on hierarchical graphs, or "higraph", which is basically a graph where every node in the graph can itself contain a nested subgraph. I'm not sure if blockly is suitable for graph-based visual languages at all. For example, does blockly allow you to draw a graph edge between two blocks?

Best,

Jake

nick

unread,
Oct 10, 2012, 7:16:37 PM10/10/12
to d3...@googlegroups.com, jbe...@cs.mcgill.ca

I'd love the option for a state trace while watching what happens.
I had that feature before I created the visualization part of it. Should be easy to add back in.
I think it would be an "as needed" feature. the visualization is the big feature. i have used lots of programs that were great drawing state machines that couldn't meaningfully execute them.

scxml is a really good looking technology... haven't found the right reason to use it yet, though!

Feel free to email me directly if you want to rap about ideas.

I guess what I meant was, "I haven't found the right way to use it for work!" here's the spiel directly:

http://sourceforge.net/p/allura/discussion/general/thread/9fb735e2/#5fd2

tldr; use D3 to build SysML/UML diagrams of state machines which you could use to control project workflows in Apache Incubatee Allura. Didn't work out, yet!
 
i have been working on a d3 integration with Blockly... I don't have the demo up and running: the one up there is a few months old, and hardlinked to blockly, which changed its API since i posted it.
I tried out the demo here, and clicking on "d3" under the "Blocks" tab didn't appear to do anything.
Gah, that's the problem with my inexperience with git submodules: I haven't put together a build system, as my recent default, "push to gh-pages" isn't working currently.  Priority one is "make build system":

https://github.com/bollwyvl/blockd3/issues/3
 
perhaps there is an opportunity for collaboration, i.e. building up SCXML with Blockly blocks, then using your visualization for simulation. The dependencies are mostly the same: i'm already using jqurey, codemirror, and, obviously, d3.
 
I'm not sure if blockly could be used for developing SCXML. SCXML is based on Statecharts, which is a visual language based on hierarchical graphs, or "higraph", which is basically a graph where every node in the graph can itself contain a nested subgraph. I'm not sure if blockly is suitable for graph-based visual languages at all. For example, does blockly allow you to draw a graph edge between two blocks?

I think they might be a great way to get used to them for the first time. Think of blockly as being a visually controlled vocabulary for building any kind of text (usually code). The initial rough go at building scxml blocks, which i have sketched but not digitized, would basically look just like the XML (1 block per element, attributes as input slots) and would run in your environment, if they were valid... guaranteed to be well-formed (I think)!

next, one could make it hard to make a "broken" one, which is sometimes tough with raw XML without a good validating editor, by adding type definitions and callbacks so that the user could only set the "To State" dropdown input field of an "Add Transition" block/child block. A lot of work to get to parity with a validating editor, but probably worth it!

Regards,
nick

Jacob Beard

unread,
Oct 10, 2012, 10:51:43 PM10/10/12
to d3...@googlegroups.com
On Wed, Oct 10, 2012 at 7:16 PM, nick <nick.b...@gmail.com> wrote:

 i have used lots of programs that were great drawing state machines that couldn't meaningfully execute them.

Any good free ones? I've found it's usually not too difficult to hook SCION into most graphical environments, and I certainly do see the value in having a tool that can be used for both diagramming and graphical simulation.


tldr; use D3 to build SysML/UML diagrams of state machines which you could use to control project workflows in Apache Incubatee Allura. Didn't work out, yet!

What was the blocker?


I think they might be a great way to get used to them for the first time. Think of blockly as being a visually controlled vocabulary for building any kind of text (usually code). The initial rough go at building scxml blocks, which i have sketched but not digitized, would basically look just like the XML (1 block per element, attributes as input slots) and would run in your environment, if they were valid... guaranteed to be well-formed (I think)!

next, one could make it hard to make a "broken" one, which is sometimes tough with raw XML without a good validating editor, by adding type definitions and callbacks so that the user could only set the "To State" dropdown input field of an "Add Transition" block/child block. A lot of work to get to parity with a validating editor, but probably worth it!

OK, I see what you had in mind. However, my feeling about this is that as the Statecharts language already has a visual syntax, described in the original 1987 paper, I would be disinclined to introduce a different visual syntax, particularly when that new syntax is no longer graph-based. 

Best,

Jake

nick

unread,
Oct 11, 2012, 3:11:40 PM10/11/12
to d3...@googlegroups.com, jbe...@cs.mcgill.ca


On Wednesday, October 10, 2012 10:52:07 PM UTC-4, Jacob Beard wrote:


On Wed, Oct 10, 2012 at 7:16 PM, nick <nick.b...@gmail.com> wrote:

 i have used lots of programs that were great drawing state machines that couldn't meaningfully execute them.

Any good free ones? I've found it's usually not too difficult to hook SCION into most graphical environments, and I certainly do see the value in having a tool that can be used for both diagramming and graphical simulation.
I've mostly done UML/SysML-based state machines with MagicDraw and Enterprise Architect which are not free. The open source TOPCASED, which can execute machines fairly well, though you have to dig through 5 layers of eclipse UI to get to some parts of it.
 
tldr; use D3 to build SysML/UML diagrams of state machines which you could use to control project workflows in Apache Incubatee Allura. Didn't work out, yet!

What was the blocker?
Basically money/availability. Had to move on to other projects. Haven't been hacking too much Allura in my spare time, though that community is heating up, some, with some new contributors adding good stuff.

OK, I see what you had in mind. However, my feeling about this is that as the Statecharts language already has a visual syntax, described in the original 1987 paper, I would be disinclined to introduce a different visual syntax, particularly when that new syntax is no longer graph-based. 
If the editing was done in d3 as well, I couldn't agree more, but is XML really an appropriate input format for all users?

Also, I like the natural-language part of blockly: the blocks are readable aloud, a nice property of a visualization. This way, I user can learn the terminology of state machines, while building, visualizing, and executing them.

What about when you get to datamodel embedded logic, etc? Even in the best authoring environments above, they were pretty crappy IDEs: I always hate that with, say, Eclipse, where I am expected to write code in a modal with a textbox when I've got a full-featured editor open a few layers behind it. Here, blockly has a leg up, as it's likely one could enable the javascript and python implementations directly off the end of the appropriate expression attrs.

Meanwhile, still puttering along: I did get my gh-pages build sorted last night, so blockd3 is up and running. The d3 actually is hooked up to the "run" button, but I need some better examples... and need to unbreak some of the datatyping stuff, which appears to be mostly turned off now.
Reply all
Reply to author
Forward
0 new messages