I don’t get the example given here that shows three steps joined by arrows and claims that the diagram is ambiguous about the order of execution of the steps.
The steps are called step 1, step 2 and step 3. The arrows between them must imply some. Kind of sequencing or dependency. If the person who drew the diagram didn’t mean to communicate that the execution sequence was step 1, then 2, then 3, they should have given the steps different names.
Simple dependency or data flow graphs like that are great for recognizing redundant dependencies, for example - like noticing ‘step 3 uses the results of step 1 and step 2, but step 2 depends on step 1 so we can just simplify this down to a sequential process - or we need to break the dependency of step 2 on step 1 so we can parallelize them’
This is notation to help you use pattern recognition and visualize structure to make better decisions, not to capture the final design. Diagrams are for helping with the ‘working out’ phase, not expressing the solution.
The steps are called step 1, step 2 and step 3. The arrows between them must imply some. Kind of sequencing or dependency. If the person who drew the diagram didn’t mean to communicate that the execution sequence was step 1, then 2, then 3, they should have given the steps different names.
Simple dependency or data flow graphs like that are great for recognizing redundant dependencies, for example - like noticing ‘step 3 uses the results of step 1 and step 2, but step 2 depends on step 1 so we can just simplify this down to a sequential process - or we need to break the dependency of step 2 on step 1 so we can parallelize them’
This is notation to help you use pattern recognition and visualize structure to make better decisions, not to capture the final design. Diagrams are for helping with the ‘working out’ phase, not expressing the solution.