7.2 Das Framework-Konzept

Der objektorientierte Framework-Entwurf zählt zu den anspruchsvollsten Entwurfsaufgaben. Im Gegensatz zu (Klassen-)Bibliotheken, für die eine ,,Codewiederverwendung`` im Vordergrund steht, muss für ein Framework die ,,Entwurfswiederverwendung`` für bestimmte Klassen von Software gewährleistet sein (vgl. Gamma et al., 1996, S. 37).

Im Falle von YACS stellt sich dies übersichtlich dar: Neben einer einfachen Benutzung durch den Anwender bzw. Wissensingenieur auf der einen Seite, muss es innerhalb von YACS möglich sein, neue Lösungskomponenten für Constraint-Probleme zu entwickeln. Die Schnittstelle hierfür ist, wie im Folgenden ersichtlich wird, denkbar schlank gehalten. Jeder Constraint-Solver muss eine abstrakte Solver-Klasse mit einer aufrufenden Methode implementieren. Dieser Methode werden zur Laufzeit die benötigten Informationen zu einem bestimmten Teilproblem übergeben. Der Constraint-Solver arbeitet als Black Box und liefert seine Ergebnisse, je nach Kategorie (Preprozessing, Konsistenzherstellung, Lösungssuche), an den aufrufenden Constraint-Manager bzw. an das Teilproblem.

Die Domäneninformationen zu einem bestimmten Problem sind wiederum durch generische (abstrakte) Framework-Klassen gekapselt. Das YACS-Framework ist damit sowohl in Bezug auf die Constraint-Solver als auch auf die zu verarbeitenden Domänen erweiterbar. Neben reellwertigen Intervalldomänen sind Domänenklassen für finite Domänen mit Integer-Werten und für symbolische, d.h. stringbasierte, Domänen implementiert.^7.6 Dabei ist festzuhalten, dass sich durch die implementierten FD-Solver aufgrund der Kapselung durch die Framework-Klassen, sowohl numerische als auch symbolische Domänen verarbeiten lassen.

Durch YACS vorgegeben ist neben den zu implementierenden Klassen lediglich die Ausführungskontrolle. Dies entspricht ebenfalls der klassischen Definition eines Frameworks (vgl. Gamma et al., 1996, S. 37). In Bezug auf YACS bezeichnet Ausführungskontrolle die Steuerung des phasenweisen Lösungsprozesses, während dessen die in den Strategien definierten Lösungsverfahren auf die jeweiligen Teilprobleme angewendet werden (vgl. Abschnitt 6.4.1).

Im Folgenden wird der Softwareentwurf für das YACS-Framework vorgestellt. Zur Dokumentation werden Diagramme in der Modellierungssprache UML verwendet (vgl. Fowler und Scott, 2000).^7.7 Für die Implementierung von YACS wurde auf eine Reihe von Design Patterns bzw. ,,Entwurfsmuster`` zurückgegriffen (vgl. Gamma et al., 1996), auf die an den jeweiligen Stellen eingegangen wird. Eine ausführliche Beschreibung der angesprochenen Klassen und insbesondere der darin enthaltenen Methoden befindet sich in der API-Dokumentation in Anhang E ff.

Fußnoten

...^7.6

Denkbare Erweiterungen der mit dem YACS-Framework verarbeitbaren Wertebereiche könnten z.B. spezielle Implementierungen für boolesche oder reellwertige Domänen sein. Beide Domänen lassen sich derzeit bereits verarbeiten: Boolesche-Constraints können als Sonderfall von Integer-Constraints, reellwertige Constraints entsprechend als Sonderfall von reellwertigen Intervall-Constraints (in diesem Fall Punktintervalle) gesehen werden. Eine explizite Implementierung dieser Domänen ist allerdings ebenso möglich.

...^7.7

Eine Besonderheit der in dieser Arbeit verwendeten UML-Diagramme liegt in Bezug auf die Darstellung von Klassendiagrammen vor. Entgegen der üblichen Konvention zur Darstellung von UML-Klassendiagrammen, die ausschließlich Attribute und Operationen kennt (vgl. Fowler und Scott, 2000), sind die Diagramme in dieser Arbeit um ein drittes Feld, den ,,Eigenschaften`` einer Klasse, ergänzt. Eine Eigenschaft liegt immer dann vor, wenn einem Methodennamen, der einem Attributnamen entspricht, ,,is``, ,,get`` oder ,,set`` vorausgeht. Der Attributname value bspw. mit der Methode getValue() ist eine Eigenschaft. Eigenschaften haben die Sichtbarkeit der jeweiligen Getter-/Setter-Methoden. Die Notation der Klassen und Interfaces, die derartige Eigenschaften aufweisen, wird außerdem um ein kleines Rechteck am linken Rand ergänzt. Diese Art der Darstellung ist, bedingt durch die Verwendung der Komponente zur Generierung von UML-Diagrammen ,,Borland Together Developer 2005`` in Kombination mit der frei verfügbaren Entwicklungsumgebung JBuilder Foundation, fest vorgegeben und kann ausschließlich in der Enterprise-Edition der IDE beeinflusst werden.