The first task is the test for solution existence which tests the possibility of finding a solution. It is not a detailed test taking into account all constraints. It is usually a rough heuristic which can detect the impossibility of finding a solution under particular circumstances. The test represents the necessary condition of finding a solution. If the test does not reject the possibility of finding a solution, this solution may or may not be found. The aim of the task is to filter out those cases when it is obvious that the solution does not exist. The task is not mandatory - it can be skipped.
The task initialize is the first phase of the design process. It is a compulsory task which assigns a value to each active parameter from the given set of parameters. The initialization can be done in two ways - one approach is based on the domain design knowledge and the other one uses an implicit domain independent strategy. It is an advantage if designer is able to provide special knowledge how to initialize particular parameters in order not to violate some of the constraints related to these parameters. Such an initialization can decrease the number of fixes used in the second stage of the design. An implicit initialization can be performed for instance by random choice of a value from the set of possible values for the given parameter. Of course, the combination of both approaches can be used - first some parameters are initialized using domain knowledge and the others are initialized in an implicit way. It is beneficial if the task contains domain knowledge (the explicit initialization can be performed), but it is not necessary (all parameters can be initialized by implicit initialization).
The second phase consists of the net of three tasks (evaluate, change, and relax) and typically consists of several cycles of these three tasks. In each loop the system tries to remove only one constraint violation (but it may happen that the correction simultaneously corrects other violations too). The number of loops depends on the violated constraints.
The task evaluate detects changes of constraint violations (which constraint is marked to be violated but currently it is satisfied or on the contrary which constraint is currently violated despite the fact that it is marked as valid) and in accordance with the result of this detection it updates the trajectory in the design state space. The outcome of the task is the list of all violated constraints together with all parameters which violate these constraints. The task is based exclusively on domain knowledge.
If at least one parameter is violated, the activity is passed to the task change. The task change then selects one constraint from the set of violated constraints to be corrected. The choice can be done either in a dynamic way according to the current stage of the solution (the combination of violated constraints) or in predefined order (e.g. given by the priority of particular constraints). The dynamic choice enables minimization of the number of used corrections (one fix can correct more constraints at the same time), but it requires additional domain knowledge.
When a constraint to be corrected is selected, a fix to perform the correction is looked for. The fixes are represented by domain design knowledge. An appropriate fix is executed and the activity is transferred back to the task evaluate. If more different fixes are applicable, only one can be used (the problem of selection this fix is similar to the selection of one violated constraint which should be corrected).
If for the selected constraint violation no fix is available, the solution cannot be modified in order to remove this processed violation. In this case the task relax becomes active. This task investigates whether this violated constraint has an influence on the basic functionality of the artefact or only on some desired feature of the artefact. If the constraint does not represent a necessary feature, it can be relaxed. The task relax is based on two types of domain knowledge - knowledge about the importance of particular constraints and consequences of their violations, and knowledge how to relax those constraints which can be relaxed.
If the task evaluate does not detect the violation of any active constraint, the second phase of the design (the creation of an acceptable solution) ends. The current form of the solution can be used as the final solution or it can be further optimized in the third phase of the design process. The optimization can be performed only using of domain knowledge.
In the case of the impossibility of creating a final solution (detected by the task test for solution existence before the design starts or as the consequence of the impossibility of correcting a constraint which cannot be relaxed) the system is able to provide the reason for this failure.