Constraints

The required functionality of a designed artefact is guaranteed by a set of constraints. The constraints represent relations defined on the values of parameters, expressing dependencies among these parameters. Every constraint is associated with a n-tuple of parameters. Exactly one parameter from these parameters is constrained by this constraint. Its value is dependent on the values of the other parameters from this n-tuple. On the other hand, one constraint can restrict values of more parameters - each of them is limited by one instance of the constraint.

Constraints (similar to parameters) can be both active or inactive. The active constraints define the conditions which should be met in order to ensure the required functionality of the constructed artefact. These conditions represent a set of necessary conditions at the current stage of the design process - if they are not satisfied the artefact is not acceptable. The inactive constraints are not important at the current design stage. Thus there is no need to check them, the functionality of the artefact can be achieved despite their violations.

Only those constraints can be active which are imposed solely on active parameters. If one of these parameters becomes inactive, the constraint is inactivated too. A constraint may be inactivated during the design process (e.g. in order to simplify the solution or as a result of an activation of another constraint etc.). On the other hand, the activation of an inactive parameter can cause the transfer of one or several constraints from the set of passive constraints into the set of active constraints. In this way the number of active constraints depends on the fact which parameters are currently active and on the history of the solution.

In order to achieve an acceptable solution it is necessary to satisfy all active constraints. Only seldom it is done in a random or arbitrary order. A designer usually distinguishes between more and less important constraints. The priority of the constraints can express designer's intention. First a constraint with higher priority is processed and then constraints with lower priority.

If some constraint is violated, the solution must be modified in a proper way in order to remove this violation. A fix is looked for - the correction to a solution capable to reestablish the validity of the constraint. This can change the value of one or more parameters (it can modify not only the constrained parameter but a constraining one too). Some constraints have associated fixes and some have not. If there is no fix available to correct a constraint, in the case of the violations of this constraint the solution cannot be modified in order to remove this violation. On the other hand, some constraints can have more fixes which can differ from each other by its priority. This priority can be dependent on the current stage of the solution.

If a constraint cannot be satisfied using a fix associated with this constraint, then the next step depends on the fact whether this violated constraint stands for a necessary or desirable condition. The solution cannot be constructed and the design process fails if the constraint represents a necessary condition (then the only output is information about the cause of the failure). If the constraint does not represent a necessary condition and the artefact can be designed despite the violation of this constraint (the quality of the solution falls a bit but remains acceptable), then the constraint can be relaxed - it becomes inactive and it is not checked in the next stage of the process.

Constraints can influence each other. The relaxation of one constraint can cause the activation or inactivation of other constraints. Similarly, fixing a constraint can violate other constraints or can require the inactivation of those constraints.