3.6.2 Constraint-Relationen

In ENGCON werden abstrakte, domänenunabhängige Constraints durch Constraint-Relationen beschrieben. Sie werden innerhalb der konzeptuellen Constraints definiert und sind Teil des Constraint-Wissens der Wissensbasis. Auch Constraint-Relationen haben per se keinen Bezug zu konkreten Konfigurierungsobjekten. Der Bezug wird erst durch die Zuordnung des Pattern-Matchers vorgenommen (vgl. Abschnitt 3.6.1). Es wird zwischen drei unterschiedlichen Klassen für Constraint-Relationen unterschieden (vgl. Ranze et al., 2002, S. 850):

1. Funktions- und Prädikat-Constraints
   Komplexe, funktionale Zusammenhänge können als Gleichungen formalisiert werden. Durch sie lässt sich z.B. physikalisches und mechanisches (Abhängigkeits-)Wissen beschreiben, dass je nach Anwendung einen wesentlichen Teil des Expertenwissens ausmachen kann. Funktions- und Prädikat-Constraints beinhalten Gleichungen und Ungleichungen ($=$, $\leq$, $\geq$, $<$, $>$) zur Beschreibung von Wertezuweisungen sowie Verhältnisabhängigkeiten und werden von ENGCON mit Hilfe eines externen Constraint-Solvers propagiert.

2. Extensionale Constraints/Tupel-Constraints
   Extensionale Constraints (Attribut-Wert-Tupel) sind relationale Abhängigkeiten, die als Aufzählung von Tupeln aller zulässigen Wertekombinationen der Constraint-Variablen in einer Tabelle abgelegt und von ENGCON dynamisch mit Hilfe einer externen Datenbank und entsprechenden Abfragemöglichkeiten ausgewertet werden.

3. Java-Constraints
   Keine Constraints im ursprünglichen Sinne sind die Java-Constraints von ENGCON, da sie nicht deklarativ sind und nicht per se eine bidirektionale Auswertung garantieren. Java-Constraints sind vielmehr ein flexibler Mechanismus, mit dem Funktionen und Berechnungen ausgeführt werden können, die sich mit den anderen Constraint-Arten nicht oder nur sehr umständlich realisieren lassen würden. Sie ergänzen die Constraint-Funktionalität von ENGCON durch die Möglichkeit der Implementierung von prozeduralen Constraints (ähnlich einer Berechnungsfunktion) auf der Ebene von Programm-Code in Form von Java-Methoden.

Die Definition eines Constraints sollte nach Möglichkeit so abstrakt wie möglich, d.h. als Funktions- bzw. Prädikat-Constraint, erfolgen. In Szenarien mit überschaubaren Lösungsmengen bietet es sich allerdings zweckmäßigerweise an, Constraints zu nutzen, die als Tupel von konkreten Attribut-Werten modelliert werden. Extensionale Constraints sollten entsprechend immer dann eingesetzt werden, wenn die Relation endlich ist und eine geringe Mächtigkeit aufweist, oder wenn sie sich nicht bzw. nur sehr aufwendig abstrakt spezifizieren lässt. Das Constraint kann in diesem Fall einfach durch Angabe aller zulässigen Wertekombinationen als Tupel definiert werden. Für nicht endliche oder sehr umfangreiche Relationen, d.h. für Relationen, die eine unendliche oder sehr große Lösungsmenge aufweisen, dienen Funktions- bzw. Prädikat-Constraints. Mit ihnen lassen sich Gleichungen und Ungleichungen angeben, aufgrund denen entschieden wird, welche Tupel zur Relation gehören und welche nicht, bzw. in welcher Form die Wertebereiche eingeschränkt werden müssen. Werden noch flexiblere Mechanismen benötigt, kann auf Java-Constraints zurückgegriffen werden. Sie erlauben es, beliebigen Programm-Code auf die übergebenen Attribute anzuwenden.^3.15 Java-Constraints können z.B. Verwendung finden bei der Aufsummierung der Attribut-Werte unterschiedlicher Konzeptinstanzen oder um Anfragen, z.B. die Verfügbarkeit von Komponenten betreffend, an externe Systeme zu stellen.

Abbildung 3.9: Constraint-Relationen

Constraint-Relationen werden mittels einer deklarativen Beschreibung in einer Meta-Modellierungssprache innerhalb der Wissensbasis definiert. Sie können dadurch relativ einfach modifiziert bzw. erweitert werden. Zur Verdeutlichung sind in Abbildung 3.9 mehrere Constraint-Relationen aufgeführt. Das Funktions-Constraint mit dem Namen func_CD_Rom aus berechnet beispielhaft die Datentransfer-Rate A für ein CD-ROM-Laufwerk anhand des Multiplikators B für die CD-ROM-Geschwindigkeit.^3.16 Das entsprechende konzeptuelle Constraint, welches den Aufruf für die Constraint-Relation func_CD_Rom enthält, übergibt bei der Instantiierung zwei Parameter, die den externen Pins, bzw. den Constraint-Variablen, A und B zugewiesen werden. Der in ENGCON derzeit eingesetzte externe Constraint-Solver verwendet intern zur Repräsentation und Auswertung der Wertebereiche von Constraint-Variablen reellwertige Intervalle und Methoden der von Hyvönen (1992) vorgestellten ,,Toleranzpropagation`` (vgl. Abschnitt 5.3.4 ff.).

Ebenfalls in Abbildung 3.9 ist ein Tupel-Constraint mit dem Namen tpc_FSB_Rate spezifiziert. Dieses Constraint dient dazu, bei einer PC-Konfigurierung von der Taktfrequenz des Front-Side-Bus des Mainboards entsprechend auf die Taktfrequenzen für die CPU und den RAM-Speicher schließen zu können und umgekehrt, bzw. um selbige eingrenzen zu können. Die externen Pins MB_FSB_Rate, P_FSB_Rate und S_FSB_Rate stehen entsprechend für die Taktfrequenzen von Mainboard, Prozessor und Speicher. In Tabelle 3.1 sind die Abhängigkeiten der Taktfrequenzen dargestellt. Eine ebensolche Tabelle muss zur Nutzung und Auswertung für ENGCON unter dem Namen des Constraints (tpc_FSB_Rate) in einer relationalen Datenbank hinterlegt werden.^3.17 Jede Constraint-Relation vom Typ tupel entspricht einer Tabelle innerhalb der Datenbank. Eine Spalte der Datenbank-Tabelle entspricht jeweils einem Pin des Constraints. Es sind ausschließlich atomare Datentypen (String, Integer, Float) erlaubt. Im Gegensatz zu Funktions- bzw. Prädikat-Constraints sind keine intervallwertigen Wertebereiche möglich. Die Datenbank muss dem System unter dem in der Constraint-Relation angegebenen (ODBC-)Namen (hier: PC_DB) bekannt sein, damit eine Auswertung durch ENGCON erfolgen kann.

Tabelle 3.1: Datenbank-Tabelle für ein Tupel-Constraint

#	MB_FSB_Rate	P_FSB_Rate	S_FSB_Rate
1.	66	66	66
2.	66	66	100
3.	66	66	133
4.	100	100	100
5.	100	100	133
6.	133	133	133

Beispiel 3.6.2   Eine SQL-Anfrage zur Auswahl bzw. Einschränkung der Wertebereiche für die Parameter, die an die Constraint-Variablen der Tabelle 3.1 gebunden sind, könnte folgendermaßen aussehen:

SELECT * FROM tpc_FSB_Rate WHERE (MB_FSB_Rate IN (66, 100, 133)) AND
                                 (P_FSB_Rate EQ 100) AND
                                 (S_FSB_Rate IN (100, 133))

Die Anfrage würde als Ergebnis die Zeilen 4 und 5 aus der Tabelle 3.1 zurückgeben, aus denen entsprechend die neuen, eingeschränkten Wertebereiche der Constraint-Variablen abgeleitet werden können.

Das Java-Constraint mit dem Namen jc_Price in Abbildung 3.9 wird dazu genutzt, den Gesamtpreis mehrerer Komponenten zu summieren, in diesem Beispiel der beiden Instanzen, die an die Constraint-Variablen A und B gebunden sind. Der letzte externe Pin (hier: C) nimmt jeweils den berechneten Rückgabewert der Java-Methode auf. In diesem Fall heißt die Methode partialPriceForPC, die sich innerhalb der Klasse PC_AdvancedLib befinden muss. Der Pfad zu dem Java-Package, in dem sich die Klasse PC_AdvancedLib befindet, wird über classpath spezifiziert.

Fußnoten

...^3.15

Da die Korrektheit eines Java-Constraints von der jeweiligen Implementierung abhängig ist, können Java-Constraints bei intensiver Nutzung eine nicht unerhebliche, potentielle Fehlerquelle darstellen.

...^3.16

150kB/s entsprechen 1-facher CD-ROM-Geschwindigkeit (sog. Single-Speed).

...^3.17

Extensional repräsentierte Constraints müssen keinesfalls zwingend in einer Datenbank verwaltet bzw. ausgewertet werden, wie in Kapitel 5 ersichtlich wird. Aufgrund des unkonventionellen und zugleich pragmatischen Ansatzes in ENGCON bzgl. der Auswertung extensionaler Constraints durch Datenbank-Abfragen, wird an dieser Stelle eine ausführliche Erläuterung der praktischen Umsetzung dieses Ansatzes gegeben.