Die derzeitige Aufgabe des internen Constraint-Managers innerhalb von ENGCON beschränkt sich auf die Verwaltung des Constraint-Netzes in der Form, dass der Reihe nach immer wieder die in ENGCON zum Einsatz kommenden Constraint-Klassen (Tupel-Constraints, Java-Constraints und Funktions- bzw. Prädikat-Constraints, vgl. Abschnitt 3.6.2), mit Hilfe der zur Verfügung stehenden Constraint-Lösungskomponenten propagiert werden, bis keinerlei Wertebereichsänderungen bei den beteiligen Constraint-Variablen mehr auftreten. In einer sequentiellen Abfolge werden jeweils die Instanzen der drei Constraint-Klassen als ,,Block`` unabhängig von den übrigen propagiert. Es werden temporär drei lokale, unabhängige Constraint-Netze generiert, die wiederum von den jeweiligen Constraint-Lösungskomponenten verarbeitet werden. In einer ,,Metapropagation`` werden die Wertebereichsänderungen der Teilpropagationen in das übergeordnete Constraint-Netz von ENGCON übertragen. Wertebereichsänderungen innerhalb eines Sub-Netzes werden so in den jeweils anderen Sub-Netzen berücksichtigt.
Benötigt wird eine Komponente an der Schnittstelle zwischen der vorhandenen, internen Constraint-Verwaltung von ENGCON und dem YACS-Framework, der die Verwaltung der neu hinzukommenden unterschiedlichen Constraint-Netze, der Constraint-Lösungsstrategien, der Constraint-Solver und letztendlich der Steuerung des Lösungsprozesses obliegt. Diese Verwaltungs- und Steuerungsaufgabe wird von dem ,,YACS Constraint-Manager`` (YCM) wahrgenommen (vgl. Abbildung 6.4).
Von dem aufrufenden System, in diesem Fall ENGCON, erhält der Constraint-Manager YCM die Informationen, welche Constraints mit welcher Strategie aufzulösen sind. Der Constraint-Manager aktiviert die entsprechenden Constraint-Lösungskomponenten und übergibt in der jeweiligen Bearbeitungsphase das entsprechende Constraint-Netz zur Verarbeitung an die dafür vorgesehene Komponente.
Der Prozess des Constraint-Lösens ist analog zum Aufbau der Constraint-Lösungsstrategien in drei Phasen unterteilt. In jeder Phase werden sequentiell jeweils die Constraint-Netze aller Strategien der Reihe nach bearbeitet.6.5 Das heißt die in den Strategien angegebenen Constraint-Verfahren werden in den entsprechenden Phasen auf die zugehörigen Constraint-Netze angewendet (vgl. Abbildung 6.5):
Eine Ausnahme, wenn sich z.B. ein Constraint-Netz nicht konvertieren lässt oder eine Inkonsistenz festgestellt wird, führt zum Abbruch des Lösungsvorgangs. Ein Beispiel für einen Lösungsprozess mit unterschiedlichen Strategien, deren Constraint-Verfahren in den jeweiligen Phasen der Reihe nach abgearbeitet werden, ist in Abbildung 6.5 zu sehen. Für eine Realisierung dieses Strategiekonzepts kommen zwei unterschiedliche Szenarien in Frage:
Abschließend erfolgt die Rückmeldung der neuen Wertebereiche der Constraint-Variablen sowie die möglichen Lösungen an das Constraint-System von ENGCON.
Vorteile dieses einfachen Szenarios sind die schnelle und einfache Realisierbarkeit und der geringe Overhead, der in Bezug auf die Verwaltung innerhalb des Constraint-Managers von YACS entsteht. Flexibilität bzgl. des Einsatzes von Constraint-Lösungsverfahren ist dadurch gewährleistet, dass für jede Wissensbasis und dem darin enthaltenen Konfigurierungs- und Constraint-Problem erneut entschieden werden kann, welche Strategien respektive Constraint-Verfahren angewendet werden sollen. Nachteilig hinsichtlich der Flexibilität wirkt sich dieses Szenario möglicherweise bei komplexen Constraint-Problemen aus. Innerhalb von umfangreichen Problemstellungen kann es sinnvoll sein, Unterprobleme, d.h. Teile des Constraint-Netzes, aus Effizienzgründen mit speziellen Constraint-Lösungstechniken zu verarbeiten. Für andere Bereiche des Constraint-Problems wiederum können dieselben Constraint-Verfahren unnötigen Overhead bedeuten.
Ob dieser Weg eine angemessene Umsetzung darstellt, ist abhängig von der Komplexität des Constraint-Netzes innerhalb der Wissensbasis. Bei überschaubaren Problemstellungen werden ggf. nicht mehr als zwei Strategien (je eine für finite und infinite Domänen) benötigt.
Die Strategien werden separat von ENGCON definiert. ENGCON übergibt die Constraints jeweils mit dem Namen der zugehörigen Strategie an den YACS Constraint-Manager. Dieser generiert daraus die unterschiedlichen Constraint-Netze und wendet die entsprechenden Constraint-Lösungsstrategien an (vgl. Abbildung 6.7):
Abschließend erfolgt auch hier die Rückmeldung der neuen Wertebereiche der Constraint-Variablen sowie die möglichen Lösungen an das Constraint-System von ENGCON.
Da für jedes Constraint theoretisch eine eigene Constraint-Lösungsstrategie angegeben werden kann, ist in diesem Szenario die maximale Flexibilität bzgl. des Einsatzes unterschiedlicher Constraint-Lösungsverfahren für unterschiedliche Topologien von Constraint-Netzen sichergestellt. Nachteilig ist der höhere Aufwand für die Realisierung dieses Szenarios. Zudem ist mit höherem Overhead als in dem erstgenannten Szenario zu rechnen. Dies betrifft sowohl die Verwaltung im Constraint-Manager von YACS, als auch die Erstellung und Pflege der Wissensbasis von ENGCON.
Der zusätzliche Overhead in diesem Szenario ist allerdings nicht sehr hoch und kann weiter verringert werden, indem bei überschaubaren Problemstellungen weniger Strategien eingesetzt werden. So gesehen ist dieses Szenario in Abhängigkeit von der Problemstellung ,,skalierbar``, und kann ggf. auf das Szenario 1 mit lediglich zwei unterschiedlichen Strategien reduziert werden. Das Szenario 2 stellt demnach eine Verallgemeinerung von Szenario 1 dar, und umgedreht das Szenario 1 eine Spezialisierung von Szenario 2.
Unabhängig von den diesen beiden Szenarien ist optional aus Gründen der Vereinfachung die Anwendung von Default Strategien für finite und infinite Domänen in Erwägung zu ziehen. Default Strategien könnten immer dann angewendet werden, wenn durch den Nutzer keine spezielle Constraint-Lösungsstrategie spezifiziert wurde.
Werden innerhalb eines strategiebasierten Constraint-Systems unterschiedliche Teilprobleme von unterschiedlichen Constraint-Solvern verarbeitet, so stellt sich die Frage, wie zu verfahren ist, wenn Constraints über Variablen definiert sind, die in unterschiedlichen Teilproblemen auftauchen. Innerhalb eines hybriden Systems ist darüberhinaus relevant, ob die Überlappung von Teilproblemen mit unterschiedlichen Wertedomänen (finit/infinit) zulässig ist oder nicht. Im Folgenden werden diese Fragen untersucht und Lösungsansätze aufgezeigt.
![\begin{figure}\index{YCM}
\centering
\includegraphics[width=7.75cm]{images/konzept_constraint-manager}
\ifx\pdfoutput\undefined
\fi
\end{figure}](img517.png)
![\begin{figure}\centering
\includegraphics[width=14.9cm]{images/konzept_phasen}
\ifx\pdfoutput\undefined
\fi
\end{figure}](img518.png)
![\begin{figure}\centering
\includegraphics[width=14.8cm]{images/konzept_modell_1}
\ifx\pdfoutput\undefined
\fi
\end{figure}](img519.png)
![\begin{figure}\centering
\includegraphics[width=14.8cm]{images/konzept_modell_2}
\ifx\pdfoutput\undefined
\fi
\end{figure}](img520.png)