Bestehende Werkzeuge zur Behandlung von Constraint-Problemen erfüllen nicht die konkreten Anforderungen bzgl. einer Integration in das Konfigurierungswerkzeug ENGCON. Es konnte kein System ermittelt werden, welches zusammen die relevantesten Forderungen erfüllt, d.h. es muss ,,hybrid`` sein und damit sowohl finite Domänen als auch reellwertige Intervalle unterstützen, beliebige Relationen in Form von algebraischen Constraints sowie den inkrementellen Aufbau des Constraint-Netzes ermöglichen und von der Programmiersprache Java aus unter Microsoft Windows nutzbar sein. Eine einfache, stringbasierte Schnittstelle wird außer vom IASolver von keinem System angeboten.
Auch wenn im Bereich CLP durchaus hybride Systeme
existieren (z.B. BNR Prolog,
CLP(BNR), ECL
PS
), besteht das Problem, dass
sich diese Systeme i.d.R. nur schwer adaptieren lassen, da eine
Java-Schnittstelle häufig nicht enthalten ist, bzw. weil diese Systeme für die (logische) Programmierung mit Constraints
ausgelegt sind.4.73 Damit wird zwar üblicherweise eine
Schnittstelle zur Nutzung von in diesem Kontext benötigten
global constraints angeboten, aber
keine einfach zu nutzende (stringbasierte) Schnittstelle für beliebige
Relationen. Für die Integration in ENGCON sind allerdings
generische Constraint-Solver zur Auflösung derartiger Constraints
erforderlich, anstatt
generische,
d.h. wiederverwendbare, Constraints aus dem
CP-Bereich.
Um dies zu ermöglichen scheint eine Eigenentwicklung am Ehesten geeignet. Die Erfahrungen hinsichtlich der eingeschränkten Funktionalität und Skalierbarkeit bei der prototypischen Integration von GNU Prolog in ENGCON bestärken dies: Der Aufwand für die komplexe Integration eines Fremdsystems gestaltet sich u.U. größer, als die Implementierung eigener Algorithmen zur Constraint-Verarbeitung. Vorausgesetzt das Know-How bzgl. der entsprechenden Constraint-Lösungsverfahren ist vorhanden (vgl. Kapitel 5).
Eine Schnittstelle zur Anbindung an ENGCON muss in jedem Fall entwickelt und implementiert werden. Die durch diese Schnittstelle bereitgestellte Umgebung ist maßgeblich für die Integration von Constraint-Verfahren in ENGCON, seien es Fremdsysteme oder Eigenentwicklungen. Der Nutzen einer möglicherweise komplizierten Anbindung eines Fremdsystems an diese Schnittstelle kann sich dagegen im Vergleich zur Eigenimplementierung von Lösungsalgorithmen als recht gering erweisen, besonders wenn die im Fremdsystem vorhandenen Constraint-Lösungsverfahren nicht sehr anspruchsvoll sind (siehe z.B. JACK oder firstcs innerhalb von POOC). Dabei würde von einem Fremdsystem ausschließlich der Zugriff auf dessen Constraint-Verarbeitung benötigt. Relevant für ENGCON ist nicht die Deklarativität z.B. einer Prolog-Umgebung oder des CHR-Frameworks, sondern der stringbasierte Zugriff auf deren Constraint-Lösungsverfahren und die möglichst flexible Einbettung in ENGCON.4.74
Eine Eigenimplementierung für ENGCON hätte außerdem den Vorteil der Erweiterbarkeit des Constraint-Systems, z.B. hinsichtlich Constraint-Hierarchien oder Constraint-Relaxierung. Der verfügbare Quellcode würde die Plattformunabhängigkeit bzw. die Möglichkeit der Portierung des Systems sicherstellen. Zudem kann bei einer Eigenentwicklung dafür Sorge getragen werden, dass die Anforderungen von ENGCON erfüllt werden, soweit dies entsprechend dem Aufwand und der verfügbaren Kapazitäten möglich ist.
Um je nach Problemstellung flexibel geeignete Lösungsverfahren einsetzen zu können, bietet sich für die zu entwickelnde Constraint-Komponente ein objektorientierter Framework-Ansatz an. Da für ENGCON ein hybrides Constraint-System, sowohl für finite als auch infinite Constraint-Domänen benötigt wird, sind in jedem Fall unterschiedliche Constraint-Solver erforderlich. Neben eigenen implementierten Constraint-Solvern können in ein derartiges Framework über einen Wrapper-Mechanismus zudem bestehende Constraint-Systeme eingebunden werden, die, wenn sie die Anforderungen von ENGCON auch nicht vollständig erfüllen, für bestimmte Problemstellungen ausreichend (oder gar notwendig) sind. Ein Framework bietet die notwendige Umgebung, um relativ einfach neue Lösungsverfahren direkt implementieren bzw. Fremdsysteme integrieren zu können. Es bietet weiterhin den Vorteil der modularen Erweiterbarkeit und allgemeine Schnittstellen für den flexiblen Einsatz in unterschiedlichen Anwendungen auch außerhalb von ENGCON.
Zur Verarbeitung von Constraints mit finiten und infiniten Domänen müssen von den unter Abschnitt 4.4 ff. angesprochenen Ansätzen für eine Eigenentwicklung in jedem Fall das klassische CSP und das ICSP berücksichtigt werden. Da innerhalb eines hybriden Systems grundsätzlich auch heterogene Constraints auftreten können, ist das Mixed CSP ebenfalls als ein sinnvolles Konzept bezgl. einer Eigenentwicklung anzusehen. Die genannten übergeordneten Constraint-Verfahren zur Konfigurierung sind weniger relevant, da für das existierende, interne Constraint-System in ENGCON dynamische Mechanismen durch die inkrementelle Instantiierung von Constraint-Relationen durch den Pattern-Matcher bereits vorgesehen sind. Die weitergehend angesprochenen Verfahren zur Behandlung von überbestimmten Constraint-Problemen sind insbesondere für ein interaktives Konfigurierungssystem wie ENGCON sehr interessant, müssten aber ebenfalls konzeptionell übergeordnet behandelt werden. Da dies massive Eingriffe in das interne Constraint-System von ENGCON beinhalten würde, die über den Austausch des Constraint-Solvers bzw. der Erstellung einer Schnittstelle oder Frameworks hinausgehen, kommt eine Bearbeitung innerhalb dieser Arbeit nicht in Frage. Die genannten weiterführenden Konzepte, insbesondere das OCSP4.75 und ACSP, sind in Bezug auf ENGCON ebenfalls sehr interessant, eine Bearbeitung würde allerdings auch hier über den Rahmen dieser Arbeit hinausgehen. Für eine Integration von übergeordneten und weiterführenden Konzepten zur Constraint-Verarbeitung müsste eine ausführliche Evaluierung erfolgen, in der geklärt wird, inwieweit diese Konzepte für den Einsatz in ENGCON bzw. innerhalb der Konfigurierung allgemein geeignet sind.
In dem nachfolgenden Kapitel 5 werden die für eine hybride Constraint-Verarbeitung in ENGCON benötigten Verfahren für klassische CSPs und ICSPs im Detail vorgestellt. Auf das Mixed CSP zur Verarbeitung von heterogenen Constraints wird in Kapitel 6 bei der Vorstellung des Konzepts für ein hybrides Constraint-System eingegangen.