I hope so much there is someone who can help me.
First a brief preamble. It seemed to me that the path generation algorithm is made up of different phases; one properly called generation phase and some others including a cycle integration phase and a condensing path phase. If I understood, existing constraints are applied after paths set construction discarding those that do not respect the constraints.
And now here it is the need.
I want to condition the paths produced during the generation phase and not discard them at the end of the generation using constraints. More clearly, I need to force a generating path to route through a specific edge of a decision block based on the route built up by the algorithm until that point.
I will try to explain better with an example. Consider the following simple flow.
Without having to modify the flow design, during the path construction when the path enters into "b" from "a" it must route through the True edge of "b" while when it enters into "b" from "e" it must route through the False edge of "b". In other words during the path generation progress, the algorithm must keep track of the routes followed up to that point. It is as if the diagram was like a Moore automata where a state transition is not only dependent on the current state and on an event occurring in it, but also on an input.
The need could be satisfied if the choice of a specific decision branch was depending on the value of a variable set with different values in blocks "a" and "e".
If so, is there anybody so kind to let me see how it is possible to do it, for example using the flow that I brought the picture back to?
If there is more than one solution to the problem I would prefer not to use the CA-ARD automator (ex Javelin)
Thank you to everyone in advance.
I have been working with development and it looks like ARD does not fully support this. We do have a kind of a workaround (see below), but it is not exactly intuitive and may not make sense to do based on your situation. It is also somewhat hard to explain over the communities. We really recommend reaching out to your CA Account Manager to find a resource help you with this one on one.
There is a feature called #reset rules which lets us create constraints that rewrite the “history” in a path.
Before we describe how to achieve this, please note the following:
1. Constraints do not quite work with loops. In ARD they may appear to work in most cases, but the implementation is unreliable, so e.g. in the new optimizer we have not tried to port the corresponding code.
2. #reset rules are tricky and you can easily crash ARD if you do not use them in a proper way. There are many limitations. For example, they are only supposed to work with arrows, not nodes.
ConstraintBooleanExpression::getVarsFromItems(NULL, &if_1_arrowVarIDs, NULL, if_1_Items);
int resetPos = arrows->indexOf(if_1_arrowVarIDs.first()); // modifiedArrows, not arrows
if (resetPos >= 0)
QList< QList<int> > then_1_arrowVarIDs;
ConstraintBooleanExpression::getVarsFromItems(NULL, &then_1_arrowVarIDs, NULL, then_1_Items);
3. You can only “rewrite” the history in one direction: if true then false (not vice versa):
if (ifBoolValue && (ifBoolValue->GetValue() == ConstraintBooleanValue::TrueValue)
&& thenBoolValue && (thenBoolValue->GetValue() == ConstraintBooleanValue::FalseValue))
4. In the “if” part of a reset rule, we typically reference back edges of loops. As for the “then” part, here is the thing: Although technically you can refer to edges outside loops, it only makes sense to reference edges from inside loops, simply because the edge through which a path enters the loop always comes before the loop edge, so if you “reset” an outer edge, you will always make it “false” (for a path that goes through the loop), which is not useful at all. In other words, it only makes sense to reset edges that may come both before and after the loop edge (because that will only affect the ones before, not the ones after).
So instead of referencing nodes “a” and “e” in your reset rule, you need to create the following constraints:
Constraint #1 – note that the unconditional “true” in its “if” part
Now you need to create another copy of constraint #2 and put it under the reset rule (as an embedded constraint), so the constraints highlighted below are identical:
I apologize for the long names of arrows here, but that is what ARD creates if you save & re-open flows with some debugging turned on.
With the above constraints and the loop enabled, you will only get 2 paths (instead of 6) using All Possible Path – please use the old optimizer, as the new one does not attempt to adjust constraints for loops in loop expansion (unlike in flattening, where we have a dedicated algorithm in place).
If you still need help with this or if this did not answer your question, please reach out to your CA Account Manager and we will be able to go over this more on a WebEx.
really a very very great thank you for the time you spent to try a solution to my need. In any case better a partial workaround, also if it is not simple to use, than no solution.
But more strategically I observe that in real world requirements which involve loops to be verified are very frequent especially when a whole process has to be modeled and the test perspective to use is a behavioral one, meaning that the designed test cases will be, in reality, end-to-end scenarios obtained visiting graphs modeled by a requirement engineer using, for example, UML (Unified Modeling Language) statechart.
In general, a loop exists or not, often the real world requires that, during path construction, adding a decision branch depends on verifying one or more conditions applied to an input.
Now the problem is that in CA-ARD decision blocks you can set output variables but you are not able to receive input variables on which to define the conditions to be verified to determine the choice of a decision branch during the path construction.
According to my opinion once a path is generated it is difficult to reconstruct it by working on its history; it is easier during path generation to condition the transition from one block to another (from one state to another in the case of graphs modeled by statechart)
Let me suggest to the Product Owner the opportunity to improve CA-ARD path exploring with the described product enhancement. So CA-ARD would become a more complete product that first can model also non-trivial process requirements and then generate, using path explorer, end-to-end scenarios verifiable with a UAT test level.
That is what very often happens and is needed in real word!