Entscheidungsunterstützung durch GIS und Simulation in der Forstwirtschaft
Implementierung von Entscheidungsunterstützungssystemen auf Komponentenbasis
Martin Döllerer
Einführung
Zunehmende Kundenorientierung, steigender Kostendruck und der Trend hin zu einer nachhaltigen und multifunktionalen Waldbewirtschaftung sorgen im Forstbereich für ständig steigende Anforderungen. Im Bereich der Holzernte sind unter anderem beispielsweise Gesichtspunkte aus aus folgenden Bereichen relevant:
Derart komplexe Fragestellungen können nur dann einer Lösung zugeführt werden, wenn moderne Informationstechnologie zum Einsatz kommt. Dies ist ein klassisches Einsatzfeld so genannter „Entscheidungsunterstützungssysteme“. Darunter versteht man DV-Systeme, die dem Management objektive und nachvollziehbare Entscheidungshilfen an die Hand geben, die Entscheidungen selbst aber nicht vorweg nehmen.
Gründe für den Einsatz von Komponenten
Ein Entscheidungsunterstützungssystem (EUS), das bei oben skizzierter Fragestellung zum Einsatz kommen soll, wird mit Sicherheit sehr komplex. Darin sind Einzelprobleme aus unterschiedlichen Teilbereichen forstlicher Forschung vertreten, beispielsweise:
Das EUS muss in Module zerlegt werden, um zum einen die Komplexität des Systems in einem überschaubaren Rahmen zu halten und zum anderen die einzelnen Forschungsrichtungen zu integrieren. Zwischen den einzelnen Modulen sind Schnittstellen erforderlich, um die Gesamtfunktionalität sicherzustellen. Darüber hinaus muss die Möglichkeit bestehen, fremde Anwendungen einzubinden, zum Beispiel forstliche Standardsoftware und Geografische Informationssysteme.
Sollten sich die Anforderungen an das EUS im Laufe seines Einsatzes verändern, ist es von Vorteil, die Software von Anfang an so zu gestalten, dass Erweiterungen der Funktionalität bzw. Änderungen am Programm leicht vollzogen werden können.
Es bietet sich an, Entscheidungsunterstützungssysteme in einem Software-Engineering-Prozess (siehe z.B. [Sommerville, 1992]) mit Hilfe eines komponentenorientierten Ansatzes zu entwerfen, um diese Anforderungen zu erfüllen.
Komponentenorientierte Softwareentwicklung
Hinter dem komponentenorientierten Paradigma verbirgt sich die Idee, Software aus wiederverwendbaren Bausteinen zusammenzusetzen. Diese Bausteine werden Softwarekomponenten genannt. Die Softwareentwicklung läuft in zwei Schritten ab: Der Komponentenentwicklung zum einen und der Anwendungsentwicklung zum anderen.
Komponenten sind charakterisiert durch:
Einzelne Komponenten können während der Laufzeit des Programms ausgetauscht werden, bzw. es können neue Komponenten zum Gesamtsystem hinzugefügt werden. Durch geeignete Kommunikationsmechanismen stehen bereits Schnittstellen zum Informationsaustausch zwischen Komponenten bereit. Durch die Eigenständigkeit der Komponenten werden Seiteneffekte und Fernwirkungen auf ein Minimum reduziert, was für eine bessere Wartbarkeit der Software sorgt. Komponenten sind per Definition zu einem gewissen Grad wiederverwendbar und anpassbar, so dass neue Systeme aus bestehenden Komponenten aufgebaut werden können. [Griffel, 1998] und [Szyperski, 1999] geben einen guten Überblick über das komponentenorientierte Paradigma.
Rahmenwerke (Frameworks), die Basisdienste für die Komponenten bereitstellen, sind notwendig, um zu gewährleisten, dass für den Komponenteneinsatz eine definierte Systemumgebung zur Verfügung steht. Ein solches Rahmenwerk wird im Folgenden in Form eines Systemkerns für räumliche Entscheidungsunterstützungssysteme vorgestellt.
[Lemm et al., 2002] sehen vielversprechende Einsatzmöglichkeiten von komponentenorientierter Software bei Fragestellungen aus dem Bereich Forstlogistik.
Architektur des EUS
Komplexe Softwaresysteme besitzen (ähnlich wie Bauwerke) eine innere Struktur, eine Architektur. Die Architektur des vorgestellten komponentenorientierten Entscheidungsunterstützungssystems ist in mehreren Schichten aufgebaut. Dieser Aufbau erfüllt die Forderung der Aufteilung in
Ein Systemkern bildet die Schnittstelle zwischen Daten- und Modellebene. Die einzelnen Problemlösungskomponenten (im Folgenden als Solver bezeichnet) benötigen eine Reihe von Eingangsdaten und erzeugen viele Ausgabedaten. Diese werden in Metadaten katalogisiert und verwaltet. So ist es den einzelnen Komponenten möglich, über eine zusätzliche Abstraktionsschicht auf Daten anderer Komponenten zuzugreifen, ohne deren internes Datenhaltungskonzept zu kennen. Einzige Voraussetzung ist die Speicherung der Daten in einem einheitlichen relationalen Datenbankmanagementsystem (DBMS). Ein solches DBMS besitzt bereits eine Client/Server-Schnittstelle, so dass die Komponenten ihre eigenen Daten effizient über diese verwalten können. Der Zugriff auf Daten anderer Komponenten erfolgt indirekt über den Systemkern. Abbildung 1 zeigt die Systemarchitektur schematisch.
Der Systemkern stellt für die Solver Dienste bereit, die im Folgenden näher beschrieben werden.
Dienste des Systemkerns
Die bereitgestellten Dienste des Systemkerns orientieren sich an den Metadaten, die als zusätzliche Abstraktionsebene die Daten der Solver beschreiben. Sie sind in Form eines Solverkatalogs, eines Tabellenkatalogs und eines Spaltenkatalogs organisiert. Abbildung 2 zeigt ein Entity-Relationship-Diagramm der Metadaten.
Für die Organisation und das Auslesen der Metadaten stellt der Systemkern folgende Dienste bereit:
Die Metadaten werden durch die Solver-Registrierung aufgefüllt. Bevor ein Solver vom System erkannt wird, muss er sich registrieren und sich selbst und seine Untersolver sowie die Ergebnisdaten in Form von Spalten und Tabellen in die Metadaten eintragen. Es wird auch vermerkt, welche Datenspalten anderer Solver benötigt werden. Listing 1 zeigt Codefragmente der Objektmethoden zur Registrierung der Solver.
public class MetaDB extends Datenbank {
public intregistriereSolver(String id, String name) {
PreparedStatement pstmt;
String cmd = null;
intr = -1;
Connection verbindung = verbinden();
if(verbindung != null) {
//Solverdaten in die DB schreiben
try {
cmd = "INSERT INTO modell (id, name) VALUES ( ?,? );";
pstmt = verbindung.prepareStatement(cmd);
pstmt.setString(1, id);
pstmt.setString(2, name);
r = pstmt.executeUpdate();
}
catch (SQLException e) {
System.out.println("FEHLER: ausgefuehrtes Kommando: " + cmd);
System.out.println("FEHLER: " + e.getMessage());
}
schliessen(verbindung);
}
return r;
}
public int registriereSolver(String id, String name, String modell) {
//Funktionskörper
}
public int registriereTabelle(String id, String name, String modell) {
//Funktionskörper
}
public int registriereSpalte(String id, String name, String tabelle,
int istSchluessel) {
//Funktionskörper
}
...
}
|
Durch die Organisation der Metadaten ist es beispielsweise möglich, dem Anwender die Ergebnisse der einzelnen Solver als hierarchische Struktur zu präsentieren, die er von seiner Betriebssystemumgebung her gewöhnt ist (wie beim Windows Explorer). Dies erledigt der Dienst „Ergebnis-Präsentation“. Abbildung 3 zeigt eine Baumansicht verschiedener Solver.
Falls ein Solver Daten eines anderen Solvers benötigt, kann er Informationen über deren Standort in der Datenbank über den Dienst „Daten-Präsentation“ erhalten. Damit ist es dem Solver möglich, die Daten aus der Datenbank zu selektieren.
Die Solver können in der richtigen Reihenfolge ausgeführt werden, da vermerkt ist, welcher Solver Daten eines anderen Solvers benötigt. Die Startreihenfolge kann so festgelegt werden, dass sichergestellt ist, dass die Daten, die ein bestimmter Solver benötigt, auch zum Zeitpunkt seiner Ausführung zur Verfügung stehen. Es ist auch möglich, zu bestimmen, welche Solver keine Daten voneinander benötigen. Diese Solver können in geeigneten Systemumgebungen parallel ausgeführt werden.
Integrationsplattform
Die vorgestellte Systemarchitektur stellt eine Integrationsplattform für komponentenorientierte Entscheidungsunterstützungssysteme dar. Sie bietet eine Reihe von Vorteilen:
Ausblick
Ein Entscheidungsunterstützungssystem, das auf der vorgestellten Architektur basiert, ist in der Lage, Teilergebnisse erst bei Bedarf zu berechnen und dem Anwender zu präsentieren. Dabei ist es durch die Metadaten in der Lage, herauszufinden, welcher Solver diese Ergebnisse berechnet. Diese Informationen können an eine andere Software, beispielsweise eine internetbasierte Benutzeroberfläche, weitergegeben werden. Man spricht in solchen Szenarien von einem so genannten „Trader Service“.
Die Berechnungsergebnisse der Solver können durch eine Erweiterung des Metadaten-Kataloges zusätzlich mit Hilfe eines einheitlichen Vokabulars gekennzeichnet werden. Dadurch ist ein flexibler Einsatz der Solver möglich. Die Solver können ihre interne Nomenklatur auf einheitlich definierte Namen umsetzen und im Tabellen- bzw Spaltenkatalog ablegen. Dem Systemkern ist es dann möglich, zwischen den einzelnen Namensgebungen zu vermitteln („Naming Service“).
Literatur
Griffel, Frank (1998): Componentware – Konzepte und Techniken eines Softwareparadigmas, dpunkt-Verlag, Heidelberg
Lüthy, Denise (1998): Entwicklung eines "Spatial Decision Support"-Systems (SDSS) für die Holzernteplanung in steilen Geländeverhältnissen Zürich, Disseratation an der ETH Zürich, vdf Hochschulverlag AG, Zürich
Lemm, Renato; Erni, Vinzenz; Thees, Oliver (2002): Komponentenbasierte Software-Entwicklung neue Perspektiven für forstliche Modellierung und Informationsverarbeitung In: Schweizerische Zeitschrift für Forstwesen, 153. Jg., H. 1, S. 3-9
Sommerville, Ian (1992): Software-Engineering, Fourth Edition, Addison-Wesley, Workingham, Reading, Menlo Park u.a.
Szyperski, Clemens (1999): Component Software – Beyond Object-Oriented Programming, Addison-Wesley, New York