Mit den Begriffen "Methodenbanksystem" und "Modellbanksystem" wird die gleiche Gattung von Softwaresystemen unter verschiedenartigen Betrachtungsschwerpunkten belegt. Unter "Methodenbanksystem" werden Systeme verstanden, die eine erweiterbare Sammlung von Programmbausteinen mit (mindestens) einer Datenverwaltungskomponente unter einem gemeinsamen Steuerteil vereinigen. Letzterer soll dem Benutzer einen leichten Zugang zu programmierten Funktionen und gespeicherten Daten ermöglichen.

Programmbausteine und Datenverwaltung(en) sollten dabei so autonom sein, daß sie sich aus dem Kontext des Gesamtsystems lösen und auch anderweitig verwenden lassen. Oder aber - und dies ist der wesentlichere Aspekt - sie können als vorgefertigte Softwarebausteine zur. Realisierung eines Softwaresystems a priori herangezogen werden. Solche Softwarebausteine können sein:

(1) Unterprogramme

(2) Hauptprogramme

(3) Programmsysteme

Definition nicht softwaretechnisch, sondern Modul-orientiert

Der Begriff "Methode" ist derzeit unterschiedlich weit gefaßt. Teilweise wird er mit dem des Softwarebausteins im obigen Sinne gleichgesetzt. Teilweise jedoch beschränkt er sich auf die beiden ersten Arten (1) und (2), während angeschlossene Programmsysteme als besondere Subsysteme (beispielsweise graphisches Ausgabesystem) bezeichnet werden. Beispiele für Methoden lassen sich also von einfachen Operationen der Matrixarithmetik über komplizierte Prognoseverfahren bis hin zu Texteditoren, Graphiksystemen oder Reportgeneratoren angeben.

Klar abzugrenzen ist der hier verwendete Methodenbegriff gegen die Deutung, die er im Software-Engineering-Bereich erfährt. Dort wird unter einer Methode ein systemtechnisch realisiertes Werkzeug zur Unterstützung des Softwareentwicklungsprozesses verstanden. Probleme der Methodenhandhabung liegen hier eher auf der organisatorischen als auf der technischen Seite.

Im Steuerteil eines Methodenbanksystems soll die Aufbereitung und Anpassung der genannten Grundbausteine an die vom Anwender gewünschte Form möglich sein und die Verknüpfung von Programmen und Daten geregelt werden können. Die Abwicklung der Kommunikation mit dem Benutzer erfolgt hingegen zweckmäßigerweise in einer eigenen Systemkomponente, die über eine Schnittstelle gegen das eigentliche Softwaresystem (dessen softwaretechnische Fähigkeiten durch Funktionen Dienstleistungen und Datentypen definiert sind) abgegrenzt ist. Es lassen sich dann unterschiedliche und gegeneinander austauschbare Sprachschnittstellen über dem gleichen "tragenden" System einrichten (Gewährleistung der sprachlichen Anpaßbarkeit).

Die Bezeichnung "Modellbanksystem" weist auf die Verwendung der Methoden in ihren Anwendungen hin. Methoden dienen hier dem Zweck, eine per Software nachgebildete, abstrahierte Umwelt, das sogenannte "ModelI", zu manipulieren Unter Modellbanksystem wird demnach ein System verstanden, das an seiner Benutzerschnittstelle mit entsprechenden Fähigkeiten zur Definition und Manipulation von Modellen ausgestattet ist. Ein Modell (der Umwelt) wird meist in Form von Datenstrukturen (lineare Gleichungssysteme, Zeitreihen etc.) wiedergegeben, die zumeist sehr großen Datenumfang haben. Der Schwerpunkt liegt demgemäß auf Modelldatenspeicherung und -retrieval sowie auf Qualität und Quantität der Manipulationsfunktionen.

Bisweilen steht "Modell" auch für "Kommandofolge", "Prozedur" oder "Makro", also für die algorithmische Beschreibung von Abläufen der erfaßten Umwelt (Beispiel: . Testmodelle). Methoden bilden hier zumeist Elementarfunktionen eines Modells. Zu derartigen Modellen gehören jedoch ebenso gewisse Modelldaten (etwa Testdaten), über denen sie definiert sind und ablaufen können.

Unscharfe Trennlinie

Eine präzise softwaretechnische Charakterisierung von Methoden-/ Modellbanksystemen (MMBS) ist derzeit noch schwierig. Dies liegt vor allem daran, daß solche Systeme in der Regel im Kontext ihrer jeweiligen Anwendung mit Betonung der anwendungsspezifischen Funktionsinhalte beschrieben werden. Für den DV-Entwickler müßten sich jedoch MMBS als Softwareprodukte unter rein systemtechnischen Gesichtspunkten, also weitgehend anwendungsneutral beschreiben lassen. Nur dann lassen sich einheitliche und systematische Konzeptionen für die Systementwicklung ableiten. Im Datenbankbereich beispielsweise beschreibt man heute DB-interne Abläufe und Systemarchitekturen streng getrennt von systematischen Anwendungen.

Die Veranstaltung der GI-Fachgruppe "Methoden- und Modellbanksysteme" am 1./2. Juni in Frankfurt unterstrich nochmals, daß die Entwickler von komplexen Anwendungssystemen der Neuimplementierung von Systemkomponenten für immer wiederkehrende Aufgaben wie etwa das tabellarische Ausgeben von Datenmengen äußerst kritisch gegenüberstehen. Das - zumindest teilweise - Zusammensetzen von Softwaresystemen aus vorgefertigten Bausteine ist heute zur selbstverständlichen misse für die Erstellung solcher Systeme unter tragbarem Kostenaufwand geworden.

Auf der technische Seite jedoch sind noch massive Probleme zu lösen, die das Herstellen der Aufrufbarkeit von Baustein und das Anpassen von Datenschnittstellen unter minimalen einschränkenden Konventionen betreffen. Für die MMBS-Entwicklung werden deshalb

- der (bereits viel diskutierte) Umgang mit Schnittstellen von Softwarebausteinen

- die Handhabung und Anpassung unterschiedlicher Datenstrukturen, insbesondere dann, wenn Daten zwischen mehreren miteinander gekoppelten Systemen ausgetauscht werden sollen, sowie

- Entwurfs- und Realisierungskonzepte für Methoden-/Modellbanksysteme unter dem Aspekt der Wiederverwendbarkeit zentrale Themen der kommenden Jahre bleiben.

Dem Aspekt der Wiederverwendbarkeit wird im Laufe der achtziger Jahre angesichts des überproportional steigenden Softwareanteils an den DV-Kosten eine überaus wichtige Bedeutung zukommen. Allerdings muß der Systementwerfer der Versuchung widerstehen, daß bei der Abbildung von Anwendungsproblem auf bereits vorhandene Software nicht der Rechner an die Benutzerwünsche, sondern vielmehr umgekehrt die Benutzerwünsche an die Software angepaßt werden; eine Gefahr, die aufgrund von Akzeptanzproblemen die beabsichtigte Kosteneinsparung sich leicht ins Gegenteil verkehren ließe.

Dieser Gefahr kann jedoch entgegengewirkt werden, wenn sowohl Anwenderwünsche als auch Softwarebausteine hinreichend beschrieben und gegeneinander verglichen werden können. So kann im Rahmen eines MMBS die Auswahl eines gespeicherten Softwarebausteines anhand einer geeigneten Auskunftkomponente unterstützt werden, die für den praktischen Einsatz sogar noch gekoppelt werden kann mit einer Auskunftkomponente über gespeicherte Datenmengen (beispielsweise durch den Anschluß eines Data-Dictionary).

Angesichts der derzeitigen Mittelkürzungen vor allem im öffentlichen Bereich und angesichts des Auslaufens einiger bisher vom Bund geförderter Projekte könnten die Systematisierungsbestrebungen im Bereich der MMBS verstärkt an Bedeutung gewinnen. Zur Weiterführung oder sogar zur Neuentwicklung von MMBS (unter drastischen finanziellen Reaktionen) müssen sich Anwender und Entwickler stärker als bisher zusammenfinden, um Wissen und Softwareleistungen miteinander auszutauschen. Erste Schritte in diese Richtung wurden beispielsweise vom Statistischen Landesamt und Umweltbundesamt in Berlin gemacht.

Ziel in endlicher Reichweite

Es steht zu erwarten, daß in der Zukunft Aspekte der Portabilität, Erweiterbarkeit, Anpaßbarkeit von MMBS kurz: Entwurfs- und Realisierungskonzepte für MMBS eine dominierende Rolle spielen werden im Vergleich zu den (austauschbaren) Funktionsinhalten solcher Systeme. Nur so erscheint es möglich, Gemeinsamkeiten hinsichtlich der Schnittstellen zu

- Endbenutzern

- (anschließbaren) Softwarebausteinen und

- Datenverwaltungssystemen

So weit zu formalisieren, daß dem Softwarehersteller entsprechende Auflagen zur Einhaltung von Systemschnittstellen oder zur Bereitstellung von Kopplungs- oder Anpassungsmechanismen gemacht werden können.

Von diesem Ziel sind wir heute sicher noch weit entfernt. Erste Erfolge vergleichbarer Bemühungen für Belange der Anwendungsprogrammierung, bekannt geworden unter dem Schlagwort "Kompatible Schnittstellen" (vergleiche CW von 30. November 1979 und vom 18. Januar 1980); lassen jedoch auf eine "endliche" Reichweite dieses Ziels hoffen. Die Erfahrungen aus Projekten, die bisher an Universitäten, Forschungsinstituten und in der öffentlichen Verwaltung gewonnen wurden, werden hier sicherlich wertvolle Anregungen geben oder sogar eine tragfähige Grundlage für künftige Arbeiten schaffen können.

*Dipl.-lng. Rainer Huber ist wissenschaftlicher Mitarbeiter am Institut für Informatik der Universität Karlsruhe und Sprecher der Fachgruppe "Methoden- und Modellbanksysteme" innerhalb der Gesellschaft für Informatik (Gl).