Implementierung von Entscheidungsunterstützungssystemen ... - TUM

27
Implementierung von Entscheidungsunterstützungssystemen auf
Komponentenbasis
Martin Döllerer
Departement für Ökosystem- und Landschaftsmanagement der TU München
Fachgebiet für Biometrie und Angewandte Informatik
Am Hochanger 13, DE-85354 Freising
E-Mail: doellerer@wzw.tum.de
Zusammenfassung
Entscheidungsunterstützungssysteme stellen umfangreiche Sortwaresysteme dar, die sowohl von
Komplexität als auch von Flexibilität geprägt sind. Deshalb wird man die Software zweckmäßigerweise
in spezialisierte Teilsysteme zerlegen, die zusammenarbeiten, um die Problemstellung als Ganzes
abzudecken. Solche zusammenarbeitende Teilsysteme werden am besten durch eine
komponentenorientierte Vorgehensweise realisiert. Es wird eine mehrschichtige Software-Architektur
vorgestellt, die in Form von Grunddiensten und Rahmenbedingungen eine Infrastruktur für die
Integration interagierender Komponenten zu einem forstlichen Entscheidungsunterstützungssystem
bereitstellt. Zentraler Bestandteil dieser Infrastruktur ist ein Metadaten-Konzept, das die vom
Komponentenparadigma geforderte Selbstdokumentation der teilnehmenden Komponenten realisiert.
Darauf setzt ein Systemkern auf, der die Grunddienste zur Verfügung stellt.
Summary
Decision support systems are big software systems based on both complexity and flexibility. A good
way to design such systems is to divide them into specialized parts that work together to solve the
problem as a whole. The parts can be realized by using a component oriented approach. A multi tiered
software architecture is presented that provides an integration platform through basic services and
constraints. Interacting components can be integrated to act as a forestry decision support system.
The main part of this infrastructure is a metadata concept that realizes self documentation of the
participating components required by the component paradigm. A system kernel based on this
concept provides the basic services.
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 folgenden Bereichen relevant:
I. Ökonomie
a) Welche Sortimente werden vom Kunden nachgefragt?
b) Welche Sortimente fallen bei einer Holzerntemaßnahme an?
c) Durch welche Holzerntemaßnahmen können die nachgefragten Sortimente
am besten abgedeckt werden?
d) Welche Kosten entstehen bei der Ernte von Bestand „X“?
e) Welche Kosten entstehen bei der Durchforstung von Bestand „Y“?
II. Ökologie
a) In welchen Beständen ist der Boden bei maschineller Holzernte gefährdet?
b) Wie verändern sich bestimmte Strukturmerkmale im Boden?
III. Sozioökonomie
a) In welcher Reihenfolge sollen die Bestände geerntet werden, um die
Waldarbeiter auszulasten?

28
Derart komplexe Fragestellungen können nur dann gelöst 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:
• Waldwachstumskunde (Wuchsmodell)
• Forstliche Verfahrenstechnik (Holzerntetechnik)
• Forstliche Arbeitswissenschaft (Einsatzplanung)
• Bodenmechanik (Befahrung)
• Forstliche Wirtschaftslehre (Holzmarkt)
• Waldbau und Forsteinrichtung (Forstliche Planung)
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:
• Eigenständigkeit
• Kommunikationsmechanismen
• Geeignete Granularität
• Wiederverwendbarkeit
• Anpassbarkeit in gewissen Grenzen

29
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
• Datenebene
• Modellebene
• Dialogeben
(vgl. [Lüthy, 1998]). Diese Aufteilung findet sich in vielen großen Systemen wieder
und wird häufig als „multi tiered architecture“ bezeichnet. Einer der prominentesten
Vertreter solcher Softwaresysteme ist das System R/3 der Firma SAP.
Holzernteschäden
Holzernteschäden
Entscheidungs-Unterstützungs-System
Risiko
Risiko
Systemkern
Meta-Daten
Planungskomponente
Waldbehandlung
Waldbehandlung
Abb. 1: Schematische Darstellung der Systemarchitektur

30
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.
ist
Untersolver
von
1
N
Solver
M
Besitzt
Abb. 2: Entity-Relationship-Diagramm der Metadaten
1
Benötigt
Tabelle
Für die Organisation und das Auslesen der Metadaten stellt der Systemkern folgende
Dienste bereit:
• Solver-Registrierung
• Ergebnis-Präsentation
• Daten-Präsentation
• Solver-Startreihenfolge
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.
N
N
1
Besitzt
Spalte
M
N
Verbindet
N

31
public class MetaDB extends Datenbank {
public int registriereSolver(String id, String name) {
}
PreparedStatement pstmt;
String cmd = null;
int r = -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
}
...
}
Listing 1: Codefragemente der Objektmethoden zur Solver-Registrierung
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.

Abb. 3: Programmfenster mit Baumansicht
32
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:
• Es handelt sich um eine flexible Client/Server-fähige Softwarearchitektur
• Sie bietet eine einheitliche Datenhaltung
• Es besteht die Möglichkeit der parallelen Ausführung von Solvern
• Solver, die zu den Spezifikationen der Softwarearchitektur konform sind,
können zwischen verschiedenen Systemen ausgetauscht werden.
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“.

33
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