next up previous contents index
Nächste Seite: 1.3 Aufbau der Arbeit Aufwärts: 1. Einleitung Vorherige Seite: 1.1 Motivation   Inhalt   Index

1.2 Angestrebte Ergebnisse

Das Ziel dieser Arbeit besteht in dem Entwurf einer modularen und flexiblen Architektur, welche den problemlosen Austausch bzw. den domänenabhängigen Einsatz von Constraint-Lösungstechnologien ermöglicht. Daneben sollen eine Reihe geeigneter Lösungsverfahren zur Constraint-Verarbeitung innerhalb von ENGCON zur Verfügung gestellt werden, die möglichst robust sind und auch für unterschiedliche Problemstellungen eine möglichst stabile Performanz bieten.

Der hohe Integrationsaufwand und die Erfahrungen hinsichtlich der eingeschränkten Funktionalität und Skalierbarkeit, die bei der prototypischen Integration von Fremdsystemen zum Constraint-Lösen in ENGCON gemacht wurden, sprechen für eine Eigenentwicklung: 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. Ein wesentlicher Teil dieser Arbeit beschäftigt sich daher mit Verfahren für das effiziente Auflösen von Constraint-Problemen, sowohl über finite als auch über infinite Domänen. Dabei geht es weniger darum ,,das beste`` Lösungsverfahren zu ermitteln, auch nicht für eine bestimmte Anwendung von ENGCON.1.4 Es wird vielmehr verdeutlicht, dass die Effizienz eines Constraint-Lösungsverfahrens abhängig von der in der Wissensbasis definierten Problemstellung ist. Es ist daher das Ziel, eine modulare und erweiterbare Umgebung zur Implementierung von Constraint-Solvern zur Verfügung zu stellen.

Aufgrund unterschiedlicher Domänen und der Vielfältigkeit der Problemstellungen gibt es kein generell anwendbares bzw. effizientes Constraint-Lösungsverfahren. Um innerhalb von ENGCON möglichst viele Problemstellungen behandeln zu können, sind mehrere Constraint-Lösungsverfahren erforderlich. Der modulare Aufbau der Software-Architektur, in der diese Verfahren eingesetzt werden, ist dabei entscheidend für die Austauschbarkeit einzelner Komponenten. Auf diese Weise wird nicht nur sichergestellt, dass sich Lösungsmechanismen flexibel einsetzen und ggf. optimierte Constraint-Solver einbinden lassen, sondern es wird auch Raum für künftige Erweiterungen gelassen. Im Zuge einer möglichen produktiven Verwendung des Systems ist so eine Erweiterung um zusätzliche Constraint-Solver jederzeit möglich. Dies ist umso leichter zu bewerkstelligen, da die Constraint-Solver nach dem Black-Box-Prinzip gekapselt und unabhängig vom restlichen System arbeiten sollen.

Neben der Kombination mehrerer voneinander unabhängiger Constraint-Solver kann es weiterhin sinnvoll sein, dass Constraint-Solver aus Effizienzgründen bei der Lösung eines Problems miteinander kooperieren. Soll zudem die Problembeschreibung hinsichtlich der Wertebereiche der Constraint-Variablen domänenübergreifend möglich sein, so ist auch eine domänenübergreifende Kooperation von Constraint-Solvern in Bezug auf unterschiedliche Domänen erforderlich.

Für den Konfigurierungsvorgang von ENGCON wird eine Komponente benötigt, die während der Konfigurierung die Zuweisungen übernimmt, welche Constraints von welchem konkreten Constraint-Solver verarbeitet werden sollen bzw. können. Hier liegt der Schwerpunkt der Arbeit: Die intelligente Anbindung unterschiedlicher Constraint-Lösungsverfahren in einer möglichst einfachen und erweiterbaren Architektur. Vor dem Hintergrund der Konfigurierung ist jeweils abzuwägen, welche Lösungsverfahren für welche Constraints eingesetzt werden. Für den Wissensingenieur soll sich dabei eine Abstraktion von den tatsächlich eingesetzten Lösungsverfahren ergeben. Das heißt der Wissensingenieur soll bei der Spezifikation der Constraints in der Wissensbasis aus einer frei definierbaren Liste ein Constraint-Lösungsverfahren bzw. eine Kombination von Lösungsverfahren auswählen können, mit der sich eine bestimmte Klasse von Constraint-Problemen effizient verarbeiten läßt.

Als praktische Umsetzung soll am Ende dieser Arbeit ein Prototyp stehen, an dem beispielhaft anhand implementierter Constraint-Lösungsverfahren die Funktionsweise des entwickelten Konzepts aufgezeigt und validiert werden kann.



Fußnoten

...1.4
Hierfür wäre jeweils eine Analyse der spezifischen Wissensbasis und des darin enthaltenen Constraint-Netzes sowie empirische Tests mit unterschiedlichen Lösungsverfahren notwendig.

next up previous contents index
Nächste Seite: 1.3 Aufbau der Arbeit Aufwärts: 1. Einleitung Vorherige Seite: 1.1 Motivation   Inhalt   Index