Maintainably converting flowchart ideas to an architecture

Question

My team is communicating proposals for the interaction of several processes as a flowchart. I've been drafting a codebase architecture we can use as a starting point. There are two ways intended behaviour can change, each of which poses maintainability issues:

• What each edge does. Edges are in general bidirectional, allowing one node to query another for information. Multiple copies of a given flowchart may be executed, with different behaviours of the node objects.
• How the flowchart looks, due to adding/removing nodes/edges.

My current approach, which addresses the first issue, is to make each node an instance of a daughter of a parent class on which edges execute with a method. So no matter how varied instances of a specific flowchart become, we just need to use instances of suitable daughters.

But the second issue is poorly addressed. When the flowchart changes, I need to reconsider what classes are needed, what methods they need to handle their interactions, what fields/properties are needed and when they're set or modified, and how to prevent cyclic dependencies between classes. (I'm working in Java, which has to mention the types of any arguments passed to constructors, plus we'll likely split across multiple files.)

What's a more maintainable approach? I don't want decisions made now to trip us up when we start filling in the methods of mostly empty classes in the current draft. This is especially likely to happen if it's realized only once such filling in begins that the flowchart needs to change again.

Answer 1

Your question is ambiguous, as it may address two different topics

Modeling flows

Whether you use old-style control flows models (flowcharts, swimlane charts), or data flow models, or whether you use more modern flow diagrams such as UML activity diagrams, UML sequence diagrams or BPMN for more complex workflows and process orchestration, the recommendation is simple:

• Use the diagrams for sketching the big picture, i.e. highlighting things that cannot easily be read in the code.
• Do not try to use models for visual programming not too detailed models: it leads to double work and in the end unmaintainable models. Even the UML founders have expressed their position against this practice.

The arrow representing method calls (this is typical for sequence diagrams) work very well. In practice, it's good to illustrate some scenarios and discuss in a team how very complex interactions shall work. But this is not the way to go to show all the possible flows with all their details.

(Note that this advice is for the general case. In some high security domains such as aerospace and defense or life critical systems such as medical devices, it could be required to deliver detailed and accurate models, and there's nothing to argue about).

Or implementing flows?

If you need to design a flexible workflow oriented system, where a flow model is the run-time input to coordinate dynamically a set of sub-systems/functions, then it's a different story:

• First, it's not only about knowing the arrows, but it's also about finding dynamically the corresponding nodes.
• For the input it may be interesting to consider BPMN, since there is a standard XML conversion and you would not have to reinvent the wheel for a new input format.
• For the execution, you may consider an event-based architecture (the arrow represents an event, that can be generated by one node and dynamically dispatched to/subscribed by other nodes).

But you could as well think about some existing business process management tools/frameworks on the market. Because dynamic process orchestration is a hard nut to crack.

Answer 2

If you have a flowchart, you probably want something like BPMN which exists to help turn flowcharts into executable code. It sounds like you aren't doing a flowchart though if you have bidirectional flow. The key you should probably focus on is define the process first. There shouldn't be nodes doing different things based on variations of a flowchart, there should be different nodes that are chosen based on inputs/derived values. If two things can each talk to each other that should probably be modeled as two separate processes as there is probably different reasons for thing 1 or thing 2 to initiate that process.