Während viele den objektorientierten Ansatz als Königsweg aus der Methoden-Malaise begrüßen, kritisiert Hubert von Braun ihn als Ausdruck eines veralteten strukturell-funktionalen
Systemverständnisses und wegen seiner Komplexität, für deren Bewältigung keine Instrumente zur Verfügung stünden. Der Autor antwortet auf einen Beitrag von Thorsten Spitta, den wir unter dem Titel: "Herkömmliche Methoden haben nie wirklich funktioniert" in der CW Nr. 18 vom 1. Mai 1992 ab Seite 29 veröffentlicht haben.
Mit Vergnügen und Zustimmung habe ich Thorsten Spittas Philippika gegen die herkömmlichen Entwicklungsmethoden mitsamt ihren uneingelösten Verheißungen aufgenommen. Deren prinzipielle Gemeinsamkeiten - Top-down-Vorgehensweise und Hierarchisierung von Daten und Funktionen über den Prozeß der schrittweisen Verfeinerung - weisen folgenden Mangel auf Während sich die meisten Nachbardisziplinen über den System-funktionalen Ansatz von Buckley und Miller hin zu dem funktional-strukturellen von Luhmanns allgemeiner Systemtheorie bewegen, klebt die Informatik mit ihren Methoden immer noch an dem strukturell-funktionalen Systemsatz, den Parsons 1952 in die Welt gesetzt und selbst schon längst wieder aufgegeben hat.
Struktur darf nicht Vorrang vor Funktion haben
Bei diesem veralteten Systemverständnis ist der Strukturbegriff dem Funktionsbegriff vorgeordnet, der Funktionsbegriff bleibt auf die internen Leistungen des Systems beschränkt, und die Umwelt wird bei der Systemdefinition nicht beachtet beziehungsweise mitdefiniert. Die Frage: "Woraus besteht es?" hat Vorrang vor den Fragen: "Welchen Zweck (welche Funktion) hat es, und wann verhält es sich wie?" Die Ergebnisse der herkömmlichen Methoden, die alle eher aufbau- als ablauforganisatorische Merkmale haben, spiegeln genau diese Auffassung wider.
Ganz anders das Systemverständnis von Luhmann, für den der Bezugspunkt der Analyse außerhalb des betrachteten Systems liegt, nämlich in der Beziehung zwischen System und Umwelt: "Systeme stabilisieren ... eine Differenz zwischen sich und der Umwelt, zwischen Innen und Außen; sie bilden ein sinnhaftes Regulativ zwischen anfallender und jeweils verarbeitbarer Komplexität." (zitiert nach Willke: "Systemtheorie. Eine Einführung in die Grundprobleme", Stuttgart/New York 1987).
Für eine Software-Entwicklungsmethode bedeutet das folgendes: Aus der System-Umwelt-Beziehung ist ein konstruktives Element abzuleiten, das sich als Orientierungsmerkmal durch alle Phasen der Entwicklung hindurchziehen muß. Für uns als MSP sind das bei der Anforderungsdefinition die Umweltereignisse, auf der fachlichen Ebene die Auslöser und auf der technischen die Trigger, die die ablauforganisatorische Orientierung sowohl horizontal auf der jeweiligen Entwicklungsebene als auch vertikal- zwischen fachlicher und technischer Sicht - sicherstellen.
Thorsten Spitta schlägt als Königsweg aus der Methoden- Malaise den objektorientierten Ansatz vor. Doch welches Systemverständnis hat dieser Ansatz, sofern er überhaupt eines hat?
T. Németh gibt in seinem Fachbeitrag "Konzeptuelle Objektsysteme zur Modellierung von Informations- und Steuerungssystemen" (in "Mitteilungen der GI-Fachgruppe Entwicklungsmethoden für Informationssysteme und deren Anwendung", Heft 1, 1991) eine Systemdefinition aus objektorientierter Sicht. Sie lautet: "Systeme lassen sich ... durch die Menge ihrer möglichen Zustände und durch die Menge ihrer möglichen Zustandsübergänge beschreiben. Bei einer Systemrepräsentation durch eine Menge von Objektklassen müssen die globalen Systemzustände und Zustandsübergänge auf die lokalen Zustände und Zustandsübergänge der Objektklassen abgebildet werden."
Die Betonung liegt hier auf "beschreiben". Wie aber lassen sich mit Hilfe dieses Ansatzes die Systeme bestimmen? Ist es Zufall oder typisch für den objektorientierten Ansatz, daß dieses Zitat eher ein strukturell-funktionales Systemverständnis - Struktur geht vor Funktion - wiedergibt? Eben diesem Systemverständnis wollen wir doch aber nicht mehr folgen.
Die wichtigsten Prinzipien des objektorientierten Ansatzes sind die Datenverkapselung, die Vererbung und die Polymorphie. Alle drei Konzepte erhöhen - verglichen mit herkömmlichen Methoden - die Komplexität, ohne zu deren Bearbeitung kontrollierbare Verfahren anzubieten.
Das liegt wohl daran, daß das Verhältnis zwischen Teil und Ganzem - übrigens auch ein Leitthema der neueren Systemtheorie - noch zuwenig Aufmerksamkeit findet. Ungeklärt ist beispielsweise die Frage, welches Kriterium denn nun die selektive Verknüpfung von Einzelobjekten zu einem Ganzen steuert. Die Konzepte Vererbung und Polymorphie sind aber, wenn sie tatsächlich handhabbar sein sollen, auf die Beantwortung dieser Frage dringend angewiesen.
Darüber hinaus gibt der objektorientierte Ansatz keine Anwort auf die Frage, warum Teile (Objekte) sich überhaupt zu einem Ganzen fügen sollen und warum jeweils genau zu diesem und nicht zu einem anderen. Dem Prinzip der Trennung von Funktion und funktionserfüllender Struktur folgend, stellt dieser Systemansatz dagegen als erstes die Frage nach dem Sinn, nach der Funktion des Systems. Die Antwort darauf führt zur Abgrenzung des Systems von seiner Umwelt - im Sinne einer Außen-Innen-Differenzierung - mit dem Zweck, ausgewählte anfallende Komplexität zu verarbeiten. Erst an zweiter Stelle interessiert die funktionserfüllende Struktur, auf die sich der objektorientierte Ansatz derzeit zu beschränken scheint.
Ereignis und Ziel sind zu berücksichtigen
Damit stellt sich also die Frage nach dem Geltungsanspruch und nach der Reichweite dieses Ansatzes. Ist die Objektorientierung nur eine Teiltheorie beispielsweise der Systemtheorie? Die Zwischenergebnisse eines Forschungsprojekts, die O. Ferstl und E. Sinz in dem Aufsatz "Ein Vorgehensmodell zur Objektmodellierung betrieblicher Informationssysteme im Semantischen Objektmodell (SOM)" (in: Wirtschaftsinformatik 6/91, Seite 477 bis 491) veröffentlicht haben, lassen diesen Schluß zu - auch wenn die Ganzheit, die man landläufig ein System nennen würde, von den beiden Autoren mit einer Verbeugung vor der Objektorientierung als "Vorgangsobjekt" bezeichnet wird.
Die Arbeiten von Ferstl und Sinz stellen den derzeit überzeugendsten Vorschlag dar, wie die Objektorientierung, kombiniert mit einem hochgradig systemisch strukturierten betriebswirtschaftlichen Aufgabenbegriff, nutzbar zu machen ist. Letzterer soll dabei all das leisten, was der objektorientierte Ansatz allein nicht vermag, zum Beispiel mit den Dimensionen Ereignis und Ziel das jeweilige System abzugrenzen.
Andere Autoren scheinen den Geltungsanspruch des Ansatzes umfassender zu sehen, eventuell sogar im Sinne eines Methodenmonismus Beispielsweise schreibt W. Hesse im dem Beitrag "Objektorientierte Anwendungsmodellierung. Ein Weg zur (Re-) Strukturierung von Software-Awendungssystemen " (1990 als Bericht Nr. 4 der Reihe "Informatik" vom Fachbereich Mathematik der Philipps-Universität Marburg herausgeben), ein Anwendungssystem sei "... nichts andres als eine spezielle Klasse oder ein Komplex, die/der sich aus vorhandenen Klassendefinitionen zusammenstellen läßt, indem man die benötigten Leistungen von den bereitstellenden Klassen importiert". Dabei läßt der Autor nicht erkennen, ob er noch andere als objektorientierte Kriterien für die Gestaltung von Anwendungssystemen heranzieht.
Der OOP-Ansatz bedarf der Weiterentwicklung
Das Systemverständnis hängt wesentlich davon ab, wie der betreffende Autor das Verhältnis von Teil und Ganzen sieht. Bei Hesse und anderen ist das Ganze - basierend auf dem Vererbungsprinzip - als eine Zusammenstellung, als Aggregation der Eigenschaften seiner Teile zu verstehen und nicht als deren Relationierung, die zu emergenten Systemeigenschaften führt, wodurch ein System als solches überhaupt erst wahrnehmbar wird.
Die Gründe also, warum wir bei MSP den objektorientierten Ansatz nicht zum Leitansatz für unsere Methode gewählt haben, liegen zum einen in der veralteten strukturell-funktionalen Systemauffassung, mit der er verbunden ist, zum anderen in dem Mangel an Kontrollkriterien für die Verarbeitung der Binnenkomplexität infolge von Vererbung und Polymorphie. Ist der Geltungsanspruch dieses Ansatzes umfassend, so ist er noch ein Torso, der dringend der Weiterentwicklung bedarf - nach Maßgabe der allgemeinen Systemtheorie, vor allem in bezug auf die System-Umwelt-sowie auf die Teil-Ganzes-Beziehung.
Das hindert uns allerdings nicht, so weit wie irgend möglich von der bereits entwickelten Idee zu profitieren, beispielsweise wenn es darum geht, Kontrollstrukturen für Programme nur noch aus Datenstrukturen abzuleiten. Ferner gibt das Datenverkapselungs-Prinzip sicherlich ein hervorragendes Instrument für die Behandlung von Systemteilen ab. Nur befaßt sich die Systemanalyse eben nicht nur mit Teilen, sondern vor allem mit der Bestimmung des Ganzen; und hier läßt uns dieser Ansatz völlig im Stich.