Task change
The aim of the task is to chose one constraint violation and to
correct it. In such a way the cycle consisting of the two tasks
evaluate and change tries to eliminate violations
of all active
constraints. In every step the most important constraint
violation
is corrected. This order is based on the priority of constraints.
The priority can be defined as a value of the slot
priority in
the
constraint definition. Another way (and a simpler one from the
point
of view of implementation) is to express the priority as the
priority of rules related to this task.
If it is not possible to correct a constraint violation with the
highest priority (there is no rule applicable in the given
situation),
the task does not try to correct another constraint violation but
ends without success and asserts the name of this non-correctable
constraint into the database. Thus the task relax can pick up the
name of the constraint to be relaxed.
The task consists only of designer's domain knowledge. Every
constraint associated with one or more fixes is accompanied by
a
group of rules. These rules have the following form:
-
(defrule change-<constraint name>-<order number>
-
(declare (salience <constraint priority>))
(job change)
(not (result ?))
(object (is-a constraint)
(cons-name <constraint name>)
(cons-violation yes)
(viol-param ?a $?))
...
=>
-
...
(assert (result success))
)
The rule for the correction of some constraint violation can be
used only if no constraint with higher priority is violated.
The
reason is that every used rule in this task asserts the fact
(result <result>) into the database. In this way the
use of the
rule
with higher priority prevent the use of the rule with lower
priority. If in the current situation there is no applicable rule
which can remove a constraint violation with the highest
priority,
the rule
-
(defrule change-<constraint name>-no
-
(declare (salience <constraint priority - 1>))
(job change)
(not (result ?))
(object (is-a constraint)
(cons-name <constraint name>)
(cons-violation yes))
=>
-
(assert (result failure))
(assert (constraint-to-relax <constraint name>))
)
is fired. This rule should have lower priority than any rule for
the
correction of the same constraint and at the same time higher
priority than rules for the correction of constraints with lower
priority. Thus the difference between priorities of two arbitrary
constraints (with different priorities) should be at least 2.
Every constraint should be accompanied by knowledge of how to
satisfy it. This knowledge can be located in the task initialize
(parameters are initialized in such a way that this constraint
is
not violated by these parameters). Another possibility is to put
knowledge into the task change in order to remove the
violations of this constraint. The last possibility is to use
this
knowledge in the task relax.