Merge Nodes and Finalized Runs

Merges can be used to combine control flows within activity diagrams at given points of the specification of functionality to be tested. Merges can be explicit, i.e., merge nodes, or implicit, i.e., activity nodes with multiple incoming control flows.

Control flows are often merged with the good intention to reuse common steps or actions in different flow variants. If they overused, however, they can however lead to unnecessary model complexity. When tests are generated using the advanced “Enable Only Finalized Runs” option each merge node encountered in a path leading to a test increases the test generation complexity  and time required to complete test generation.

If the intent is that all flows passing through the merge should take the following action then a common technique to avoid merge nodes is to isolate the path after the merge node into a sub diagram, and then - instead of merging or connecting <n> control flows to one activity calling that subdiagram – create and connect the <n> control flows to <n> activities calling that same activity diagram. Note that remodeling also multiplies the number of generated test targets by <n>, i.e. there will be separate targets for each action, data etc in the subdiagram for each control flow branch – even though the model browser always shows the same diagram underlying all <n> activities.

Often a high number of merges is an indicator of trying to model “too much functionality” with a single model. In these cases, other symptoms commonly include a high model complexity (see section Model Complexity) as well as use of state variables (see section Avoid Overuse of State Variables).  Here, the good intentions of reuse backfire into unnecessary model complexity: (multiple) state variables are deployed to “remember” which (combination) control flow branches have “taken” prior to the merge(s) which quickly increases risk for modeling error as well as diagram complexity, and reduces understandability. In these cases generally the best option is to split the model into multiple models and reduce this way the merges required.