design patterns - Best practices in block based or flow based system programming -

I am trying to implement a LabW-similar system (in Java) where some blocks are enabled - sourcing
- sinking -
data through passing.

There are many inputs (> = 0) in each block and many outputs (> = 0) and it is dedicated to a function to convert inputting, output, and data. Data flow is presented as a sample, taken from the field measures coming from different devices (thermometer, wind-speed meter, radiation sensor, power-meter and other).

Each sample is related to "era." It is an instant where all values ​​are captured, a trigger starts with a trigger (should be a special trigger input in the source block), so from an era A sample group should be processed with the same samples along with the other samples.

The problem is that I am unable to find and apply a pattern that summarizes this problem. Maybe it's just like how LabWe or simulal blocks are working internally, but I still have not had any success in finding "best practice". The big problem with my "push-policy" is that, on the basis of chain size and depth, blocks with multiple inputs work on different era specimens (two coming from two separate measurements artifacts Imagine a comparison block while comparing samples).

Thanks in advance for all the advice, tips, best practices and everything that can be able to solve my over-the-phyllosophical-programming problem.

Fun questions!

I suggest separating the ideas of "block" (the unit of functionality of a representation in a box), the definition of how topology blocks are connected), and controls (instant messaging) Passes and flow controls due to the blocks executed at the right time.). The goal is to eliminate the coupling between the blocks (blocks should not have the full knowledge of each other) and create an arbitrarily configurable system.

Here's my idea on three main components:

Topology Definition : The definition of topology is usually in a resource file that is not a code file (the user is configurable Should be correct). The resource file should contain information about the information about how to block, their input (output can usually be obtained from knowledge of input) and blocks of any property. For example, a resource JSON file might look like the following: [/ unique] " Input: ["1", "2"], initial output = 0}, {uniqueId: "4", "sign", step size: 0.1: "simple", "3", type: "multiplier" , Initial output = 0}, {uniqueId: "3" type: "plotters", input: ["3"],}]

control

The control mechanism starts by reading the topology definition (do not forget the verification) and then instantiate the block components. Use this information to the host and using input knowledge of each block is the block components are added to build the messaging infrastructure (each input to be treated as a separate message queue). Specifically, the controller needs to determine the execution order of blocks in each stage. There are several steps in control every time, which starts with the beginning of your block series, which outputs the "listening" input queue. Perform the next layer of blocks. Push the next layer of blocks, etc. (Or some other such strategy.)

Block

The blocks are basically only aware of how the input should be given and a suitable output Returns.

---

As another system, you can use circuit simulation programs (like Spice) to be used by electrical engineers. These generally have circuit components (your block), a node list file (topology definition), and some simulations runtime of some type.

---

Anyway what I think is ..