Origin of ProcessFlow

[joerg_vogel_HsH]

I'd like to know on which language, program or concept the graphical data flow programing language ProcessFlow is based on. I'd like to learn this kind of programming, because it seems it is the future of building models and I can't get a grip on this method so far. I need more background on it like the structure, syntax, keywords,.. - not in Flexsim specifically, more the general approach.

[Ben_WilsonADSK]

There are many different platforms that take advantage of a "flowchart-style" take on logic building, also called visual scripting or visual programming.

UML and xUML/xtUML have been evolving for decades.

There are a number of educational products that take a graphical approach to coding as a starting point for children and computer science students. While these are not all "flowchart-style", they are nonetheless platforms on which coding is more tactile than is generally regarded in traditional text-based programming.

We know of several commercial products that use visual scripting to define behavior in game design, 3D modeling, and other uses.

@Brandon Peterson could add some history of how he started using process-style logic in his own model building. Brandon's work was the direct precursor to FlexSim's built-in Process Flow capabilities. @Matt Long can share details on his own inspirations for FlexSim's built-in Process Flow tools, how he decided on user-interface design, and other considerations.

[matt_long · Accepted solution]

Process Flow was designed as a way to graphically define logic in your model. Rather than hiding logic in triggers on objects through messages and entry/exit triggers, we wanted to expose all of that in something that was easy to read and follow. Process Flow is self documenting as you build your process and apply names to each of your activities. It becomes very easy to walk non-engineers and non-programmers through a process when it's graphically laid out.

In addition to exposing logic, Process Flow also reduces the need for writing code. Each of the activities is designed to a very limited amount of logic. This allows you to break everything up into very small steps and keep away any of the 'hidden' logic that is found in all of the standard FlexSim 3D objects. Process Flow can help make very complex problems much simpler and easier to handle. Things that would otherwise require a lot of custom coding to accomplish in standard FlexSim can now be done with just a few activities and little to no code.

Tokens are really the heart of making Process Flow work. They store all of the data on them that the activities use. As a token moves through the model, it collects data that can be accessed and manipulated. We designed the tokens to be as small and memory friendly as possible. You'll notice when you drag an activity out that many of the property fields have a Label: labelName in them. This syntax (which is equivalent to saying getlabel(token, "labelName")) was added for two reasons:

1. For a new user who isn't comfortable with coding, it provides a more concise label access on the tokens that is easier to read less 'scary'.
2. It's faster execution that executing code, and as this label access happens all over the place, it made for some decent speed improvements.