Von Roy et al. (2000) wird ein Constraint-Framework als Möglichkeit beschrieben, eine flexible und erweiterbare Implementierung des Constraint-Mechanismus anzubieten. Anstatt wie bei CP- bzw. CLP-Systemen eine Domäne, nämlich die der (logischen) Programmierung mit Constraints zu fokussieren, bietet ein Constraint-Framework allgemeine Mechanismen, die eine Anpassung für spezielle Problemstellungen erlauben. In einem Framework werden demnach kollaborierende Komponenten integriert, die auf diese Weise eine wiederverwendbare Architektur für eine Vielzahl von Anwendungen zur Verfügung stellen. Weil ein Framework üblicherweise bereits funktionsfähige Mechanismen beinhaltet, kann es häufig auch out of the box wie eine Bibliothek eingesetzt werden.
In dem in der Programmiersprache Smalltalk implementierten Constraint-Framework BackTalk (Backtracking in Smalltalk) erfolgt die konsequente Ausnutzung der Eigenschaften der objektorientierten Entwicklung bzw. Programmierung (Vererbung, Polymorphie, etc.). BackTalk erlaubt die intensionale Definition von Constraints mit finiten Domänen und stellt zu deren Auflösung eine Reihe unterschiedlicher Such- und Konsistenzalgorithmen zur Verfügung. Constraints sind z.T. vorgegeben, können aber auch in einer einfachen Syntax algebraisch als Gleichung bzw. Ungleichung angegeben werden (auch n-äre Constraints). Die Erweiterbarkeit von BackTalk wird gewährleistet durch eine objektorientierte Schnittstelle, an der durch Vererbungsmechanismen sowohl neue Constraints als auch Lösungsverfahren integriert werden können. Zusätzliche Such- und Konsistenzalgorithmen werden in das Framework eingebunden, indem innerhalb einer Klassenhierarchie die Default-Lösungsverfahren einer übergeordneten Kontrollschleife von spezialisierten Unterklassen überschrieben werden können. Die Mechanismen der Vererbung werden hier genutzt, um Anpassungen an spezielle Problemstellungen vornehmen zu können. Lösungsalgorithmen sind demnach eine Bibliothek von austauschbaren Smalltalk-Klassen (vgl. Roy et al., 1999; Roy und Pachet, 1997; Roy et al., 1997).
Im Gegensatz zu BackTalk implementiert GIFT (Generic Interface for FilTers) kein eigenes Constraint-System, sondern bietet die Möglichkeit, Algorithmen zur Constraint-Propagation über eine einheitliche C++-Schnittstelle verfügbar zu machen (vgl. Ka Boon, 2000). Durch diese allgemeine Schnittstelle wird eine Wiederverwendung existierender Lösungsalgorithmen in unterschiedlichen Constraint-Systemen erleichtert, die ansonsten für jedes spezielle System reimplementiert werden müssten. Anstatt Lösungsalgorithmen direkt für ein bestimmtes System zu implementieren, muss für jedes spezielle Constraint-System lediglich eine C++-Schnittstelle für GIFT erstellt werden, welche den Zugriff auf unterschiedliche Lösungsverfahren erlaubt. Allerdings ist GIFT kein Framework im eigentlichen Sinn, sondern lediglich eine Schnittstelle zur Vereinheitlichung des Zugriffs auf Constraint-Lösungsalgorithmen. Zudem liegt der Fokus wiederum auf Systemen zur Programmierung mit Constraints, dh. GIFT ist darauf beschränkt, den Zugriff auf spezielle Constraints für CP- bzw. CLP-Systeme zu vereinheitlichen.
Wie GIFT ist POOC aus dem Gedanken heraus entstanden, eine einheitliche Schnittstelle für den Zugriff auf bestehende Constraint-Lösungsverfahren anzubieten (vgl. Schlenker und Ringwelski, 2003). Im Fall von POOC geschieht dies allerdings nicht für spezielle C(L)P-Systeme, sondern allgemein für die Programmiersprache Java.4.63 Über eine objektorientierte Schnittstelle werden von POOC wie in BackTalk insbesondere Vererbungsmechanismen genutzt, um in einer Java-Umgebung den einheitlichen Zugriff auf unterschiedliche Constraint-Solver zu gewährleisten. Bestehende Constraint-Systeme können über einen Wrapper an POOC angebunden werden. Ein einfacher Solver namens firstcs ist in POOC enthalten (vgl. Hoche et al., 2003). Für SICStus Prolog existiert bereits eine Wrapper-Klasse. Die Anbindung von GNU Prolog wurde nicht fertig gestellt, aber konzeptionell über das JNI dargelegt (vgl. Schlenker und Ringwelski, 2003, S. 160 u. 169). Der Schwerpunkt von POOC liegt ebenfalls auf der (objektorientierten) Programmierung mit Constraints (CP). POOC ist daher entsprechend optimiert auf die Verarbeitung spezieller Constraint-Typen (global constraints), wobei auch die Verarbeitung n-ärer Constraints möglich ist. Die Wertebereiche von Constraint-Variablen sind allerdings auf finite Domänen beschränkt.
Kein Framework im objektorientierten Sinn, aber ebenfalls ein
Rahmenwerk zur Constraint-Verarbeitung sind die
Constraint Handling Rules (CHR) von
Thom
Frühwirth.4.64
CHR sind ein flexibles Mittel zur Implementierung von
benutzerdefinierten Constraints bzw. Constraint-Solvern.4.65
Sie sind eine Spracherweiterung, die als Bibliothek in existierende
Programmiersprachen wie Prolog, Lisp,
Haskell und Java eingebunden werden
können. Umfangreiche Implementierungen von
CHR-Bibliotheken werden für SICStus Prolog (Referenzimplementierung,
vgl. SICStus, 2004, S. 493 ff.) und ECL
PS
(vgl. Frühwirth, 1998, S. 112 ff.)
angeboten.4.66 In der
Basissprache implementierte Programme sind in der Lage, die in
CHR implementierten Constraints zu nutzen. Umgekehrt
lassen sich von CHR-Programmen in der Basissprache
implementierte Prozeduren als Hilfsprozeduren verwenden.
CHR stellen dabei eine höhere deklarative Sprache zur
Spezifikation und Implementierung von Constraint-Lösungsmechanismen
dar. Dies geschieht innerhalb von CHR-Programmen in
Form von Regeln, mit denen beschrieben wird, wie sich Constraints zu
neuen Constraints vereinfachen lassen und wie durch Constraints andere
Constraints propagiert werden. Fortlaufende Vereinfachung bzw. Propagierung führt letztendlich zu einer Lösung der Constraints
vgl. Frühwirth, 1995;
Frühwirth und Abdennadher, 1997, S. 78 ff..
CHR sind aus der Problemstellung entwickelt worden, dass unterschiedliche Klassen von Anwendungen im Bereich CP oftmals unterschiedliche Constraints benötigen.4.67 Neuartige Constraints, bzw. neue global constraints, können u.U. nur mit viel Aufwand in existierende, einfachere Constraints übersetzt werden. Zur Kompensation dieser Problematik lassen sich mit CHR auf hohem Abstraktionsniveau Constraint-Solver für spezifische Constraints innerhalb von bestehenden C(L)P-Systemen implementieren. Neben einer Vielzahl spezieller Constraints werden von den vorhandenen CHR-Bibliotheken auch Constraint-Solver mit allgemeinen Such- und Konsistenzverfahren zur Verfügung gestellt (vgl. Frühwirth, 1998, S. 26 ff.).
Neben CHR-Bibliotheken für logische und funktionale Programmiersprachen ist mit JACK (Java Constraint Kit)4.68 eine CHR-Implementierung für die objektorientierte Sprache Java verfügbar. JACK enthält neben der CHR-Implementierung JCHR ein Framework JASE (Java Abstract Search Engine) zur die Einbindung unterschiedlicher Constraint-Lösungsalgorithmen, sowie die Komponente VisualCHR zur Visualisierung der Vereinfachungs- und Propagationsschritte (vgl. Abdennadher et al., 2001,2002b,a). Die Funktionalität von JACK ist allerdings im Vergleich zu anderen CHR-Bibliotheken sehr beschränkt, da es sich bei der einzig verfügbaren und bereits im Jahr 2001 veröffentlichten Version lediglich um ein Pre-Release handelt. Im Wesentlichen wird von JACK die Programmierung von Constraints mit finiten Domänen unterstützt. Die Komponente JASE bietet allerdings beim derzeitigen Versionsstand auch hier lediglich einfache Suchstrategien für ausschließlich binäre Constraints an.4.69 Die eingeschränkte Funktionalität erklärt sich z.T. mit den fehlenden vorhandenen Möglichkeiten zur Constraint-Verarbeitung in Java, und zum anderen mit dem derzeit prototypischen Status der Implementierung von JACK.4.70
Zusammenfassend kann festgestellt werden, dass keiner der bestehenden
Framework-Ansätze für eine Integration in das Konfigurierungswerkzeug
ENGCON in Frage kommt. Das Smalltalk-Framework
BackTalk geht konzeptionell in die richtige
Richtung, ist allerdings auf finite Domänen beschränkt. Einer Nutzung
im Rahmen von ENGCON steht zudem die Sprachbarriere im Weg
(Smalltalk
Java). Im
Gegensatz zu BackTalk ist GIFT kein
Constraint-System, sondern eine reine Schnittstelle zur
Vereinheitlichung des Zugriffs auf existierende
Constraint-Lösungsverfahren. Das POOC-Framework ist
ebenfalls auf finite Domänen beschränkt und fokussiert zudem den
Bereich CP. In POOC enthalten ist lediglich
ein einfacher Constraint-Solver. Bei CHR steht die
Implementierung spezieller Constraints im Vordergrund, wodurch
ebenfalls der Bereich C(L)P, im Fokus steht.
Leistungsfähige CHR-Bibliotheken benötigen ein in Bezug auf die
Constraint-Verarbeitung ebenso leistungsfähiges ,,Wirtssystem`` wie
SICStus Prolog oder ECLPS. Für eine
mögliche Integration dieser Systeme in ENGCON ist mit Problemen und
erhöhtem Aufwand wie in
Abschnitt 4.5.1 ff. beschrieben zu
rechnen. Zudem sind derartige Systeme i.d.R. im Gegensatz zu
CHR nicht frei verfügbar. Für die
Java-basierte CHR-Implementierung
JACK würde der Integrationsaufwand geringer ausfallen,
allerdings weist JACK mit seinem bisherigen Stand als
Forschungsprototyp lediglich eine stark eingeschränkte Funktionalität
auf.