In the previous sections, we have already mentioned the notion of nesting:

Definition: A nested Configuration Process contains nodes (Configuration Processes or forms) which are either reused multiple times inside the nested Configuration Process, or which are reused in other external Configuration Processes.

We have already explained what was previously called pure nesting, meaning that Configuration Processes or forms can be reused in multiple parent objects.

However a second type of nesting is important, and is called looping. Looping happens whenever a subset of the configuration has to be repeated multiple times.

Definition: A looped Configuration Process or form is an object that can be cloned several times. Each clone is said to be an instance of the generic parent looped object.

Looping objects really becomes clear when looking at the difference between the model in the Designer repository and the instance that has been created for a particular user session.

The generic model can be represented as follows:

In the user session however, the looped Configuration Process will be instantiated multiple times,

meaning that the generic object will issue clones of itself, allowing the user to answer the same questions multiple times:

Looping object can be practical, but has to be used carefully. Indeed, there are a number of modeling restrictions that only apply on looped objects.

Looped objects have a number of modeling restrictions that have to be taken into account. In contrast to these restrictions they also have a certain number of advantages.

Suppose that in the example shown above that a certain number of BRC are added to the problem:

The figure shown above shows the modeling restrictions that currently apply to looped objects.

Indeed, when using these kinds of inter-loop constraints, you must ensure that BRC address objects necessarily belonging to existing instances (i.e. to the interval defined by the minimum number of instances and the maximum number of instances defined on the “nested” properties).

Furthermore, BRC are statically attached to their instance number. They are then independent of the content of their instance: a BRC based on the instance 2 stays on the instance 2 even when instances 2 and 3 are switched.

Therefore, if you use BRC on specific instances, make sure that these instances are static: they should always exist and the order should remain the same.

However, there are clearly a certain number of advantages when using looped objects: looped objects allow you to model only once a business need (a part of a product or a service) and call it multiple times without changing the business logic.

There are 2 alternatives for looping. The first alternative concerns copying and pasting. Indeed, when few instances are needed (typically only 2 or 3), it could be much more flexible to model the first Configuration Process and the underlying forms and to copy and paste the whole structure (or to just model the Configuration Process twice or three times). The advantages are clear: as there are no loops, the above-mentioned constraints do not apply. In the following example, we have copied cp_1a, form_2a and form_3a to cp_1b, form2b and form_3b respectively.

The second alterative concerns the duplication of the Configuration Process (that would have been looped originally) with reuse of the original form. The resulting model will then look as follows: