1. Kapitel
Erfassung der Strukturen von Kooperationssystemen in grafischen Plänen
= Fundamental Modelling Concepts (FMC)



Home
1.1
Zwei
Probleme
1.2
Lösungs-
konzept
1.3
Aufbau-
pläne
1.4
Ablauf-
pläne
1.5
Daten-
pläne
1.6
Interpreter-
schichtung
1.7
Phasen-
trennung

1.1 Zwei Probleme

1.1.1 Das primäre Problem

Dass die kommunikative Beherrschung der Komplexität großer Softwaresysteme ein schwerwiegendes Problem darstellt, wurde mir erstmals bewusst, als mich mein Studienfreund Dietrich Klugmann mit der Software bekannt machte, die von der Firma Siemens anlässlich der Olympiade 1972 in München entwickelt worden war. Mit der Entwicklung dieser Software waren ungefähr 150 Projektmitarbeiter über einen Zeitraum von fast drei Jahren beschäftigt. In dieser Software steckte also ein Aufwand von etwas mehr als 400 Personenjahren, und der Papierstapel mit dem ausgedruckten Programmcode hatte eine Höhe von ca. 2 Metern. Da brauchte man nicht viel Phantasie, um sich die folgenden drei Fragen zu stellen:

(1) Anhand welcher Dokumente können die Teilaufgaben abgegrenzt werden, falls das zu erstellende System nur mit hochgradiger Arbeitsteilung realisiert werden kann?
(2) Anhand welcher Lehrunterlagen können diejenigen Personen geschult werden, die im Laufe des Projekts neu in die Entwicklermannschaft aufgenommen werden sollen?
(3) Wie können sich Personen, die nicht an der Planung und Realisierung der ursprünglichen Software beteiligt waren, später das Wissen verschaffen, welches sie benötigen, um Fehler in der Software zu korrigieren oder um die Software um neue Funktionen zu erweitern?


Wenn es nicht um Software, sondern um Gebäude oder Maschinen ginge, ließen sich diese drei Fragen leicht beantworten, denn dann gäbe es Pläne, die vor Beginn der Systemrealisierung erstellt wurden und an denen sich die Realisierer orientierten. Es war mir klar, dass auch im Softwarewesen entsprechende Pläne benötigt werden, wobei aber damals noch niemand eine Vorstellung davon hatte, wie solche Pläne aussehen könnten. Heute sind Softwaresysteme im Einsatz, deren Programmcode, würde man ihn ausdrucken, einen Papierstapel ergäbe, der die Höhe des Eiffelturms erreicht. Solche Systeme kommunikativ zu beherrschen, ist ohne den Einsatz geeigneter grafischer Pläne völlig unmöglich.

1.1.2 Das sekundäre Problem

Das sekundäre Problem besteht im Desinteresse der akademischen Informatik am primären Problem.
Wenn man einem Ingenieur, der mit der Welt der Softwareentwicklung nicht vertraut ist, das oben beschriebene primäre Problem schildert, kann er es zuerst gar nicht glauben, dass die kommunikative Beherrschung der Komplexität großer Softwaresysteme mittels leicht lesbarer genormter grafischer Pläne in der Informatikausbildung im Jahre 2016 immer noch keine zentrale Rolle spielt. Bei meinem Bemühen, das primäre Problem zu lösen, war ich verständlicherweise auch immer auf der Suche nach Verbündeten in der akademischen Informatik. Diese jahrelange Suche blieb aber leider erfolglos, und deshalb fragte ich mich nach den Gründen für das Desinteresse der Informatiker an meinem Thema. Inzwischen glaube ich, drei Ursachen für dieses Desinteresse entdeckt zu haben.

(1) Der Stolz der Programmierer auf ihr laufendes Programm
Der Einstieg in das Programmieren erfordert keine überdurchschnittliche Begabung, so dass sehr viele Anfänger schon recht früh ihre ersten Erfolgserlebnisse haben können. Und diese Erfolgserlebnisse können süchtig machen, denn man erlebt sich nun als jemand, der dem Computer seinen Willen aufzwingen kann. In meinen Vorlesungen über das Programmieren habe ich es immer wieder erlebt, dass mich die Studenten drängten, meine in ihrer Sicht langweiligen einführenden Erklärungen abzukürzen und ihnen endlich beizubringen, ihr erstes Programm zu schreiben. Bei vielen Programmierern verfestigt sich schon sehr früh die Einschätzung, dass es nur darauf ankomme, das Programm "zum Laufen zu bringen", und dass jeglicher zusätzliche Aufwand ein unnötiger Ballast sei. In dieser Haltung werden sie auch noch durch den Beifall von Außenstehenden bestärkt, von denen sie wie Zauberer im Zirkus bestaunt werden.

(2) Das an Formalismen orientierte Wissenschaftsverständnis der Informatikprofessoren
In der Entstehungszeit der akademischen Informatik war das Fassungsvermögen der Computerspeicher noch so beschränkt, dass höchstens so viel Software eingebracht werden konnte, wie ein einziger Programmierer in einem halben Jahr entwickeln konnte. Deshalb gab es damals noch kein "Komplexitätsbeherrschungsproblem." Die damaligen Probleme im Zusammenhang mit der Programmentwicklung waren ausschließlich mathematisch-logische Probleme. Deshalb war es ganz selbstverständlich, dass die akademische Informatik von Mathematikern aus der Taufe gehoben wurde und dass diese die Lehrinhalte und Forschungsthemen der neuen Disziplin festlegten. So ist es auch nicht verwunderlich, dass das wissenschaftliche Vorgehen gegen das Komplexitätsbeherrschungsproblem in der Suche nach geeigneten Formalismen und Automatismen besteht und die Erfahrung der klassischen Ingenieure mit leicht lesbaren genormten grafischen Plänen nicht herangezogen wird. Ein renommierter Informatikprofessor sagte mir einmal, meine Arbeiten gehörten in den Bereich der Managementmethoden und hätten mit der wissenschaftlichen Informatik nichts zu tun.

In diesem Zusammenhang wird auch immer wieder darauf hingewiesen, dass es doch inzwischen die genormten Begriffs- und Symbolwelten UML (Unified Modeling Language) und SysML (System Modeling Language) gebe, für deren Anwendung eine reiche Palette an unterstützenden Tools zur Verfügung stünden. Und diese toolunterstützten Methoden würden das hier vorgestellte FMC entbehrlich machen. Es ist hier nicht der Raum für die zwingenden Argumente, die ich gegen diese Behauptung anführen kann. Denn dazu müsste ich ausführlich auf die Inhalte von UML und SysML eingehen, was den Umfang dieser Darstellung sprengen würde.

(3) Die fehlende natürliche Sichtbarkeit der geplanten Strukturen
Im Bauwesen und im Maschinenbau geht es bei den zu planenden Systemen um Gebilde, die eine natürliche Sichtbarkeit haben, so dass auf den grafischen Plänen nur das dargestellt werden muss - in leicht abstrahierter und symbolisierter Form -, was man später bei der Betrachtung des realisierten Systems sehen wird. Dies gilt im Softwarewesen jedoch nicht, denn da ist das Einzige später Sichtbare der lesbare Programmcode. Die grafischen Pläne müssen hier das verständliche Gedankengebäude zeigen, welches bei den Planungsüberlegungen in den Köpfen der Systemarchitekten entstand. Selbst auf die Gefahr hin, als überheblich zu gelten, behaupte ich, dass nur ein recht kleiner Anteil aller im Softwarebereich Tätigen die nötige Abstraktionsfähigkeit und das ebenso nötige didaktische Geschick besitzt, die hier geforderten grafischen Pläne in ausreichender Qualität zu gestalten. Ich bin sogar überzeugt, dass auch viele der in der Informatik Lehrenden die für die Planerstellung nötigen Fähigkeiten nicht besitzen.

Gibt es eine positive Perspektive?
Die beschriebenen drei Sachverhalte legen die Frage nahe, ob denn die kommunikative Beherrschung der Komplexität großer Softwaresysteme mittels leicht lesbarer genormter grafischer Pläne überhaupt eine Chance hat, eines Tages zur Selbstverständlichkeit im Softwarewesen zu werden. Ich sehe durchaus gute Gründe dafür, die Hoffnung noch nicht aufzugeben. So ist insbesondere die Tatsache, dass nur wenige Fachleute die Fähigkeit haben, brauchbare grafische Pläne zu gestalten, kein ernsthafter Hinderungsgrund, denn die wenigen, die das können, reichen zur Deckung des Bedarfs völlig aus. Alle anderen in der Softwarebranche brauchen ja keine Pläne zu zeichnen, sondern müssen sie nur lesen können, und das gelingt fast jedem.

Meine optimistische Meinung bezüglich der Perspektiven von FMC beruht auch auf meinen Erfahrungen mit Führungskräften in der Softwareindustrie. Ich hatte oft die Gelegenheit, solchen Führungskräften das Konzept von FMC vorzustellen, und meistens haben diese das Konzept mühelos verstanden und sahen den Nutzen sofort ein. Manche von ihnen haben anschließend die Möglichkeiten ausgelotet, FMC in ihrem Unternehmen einzuführen. Sie mussten aber bald erkennen, dass sie den passiven Widerstand ihrer Untergebenen nicht überwinden konnten. Diese Untergebenen wollen verständlicherweise die Vorteile, die ihnen aus der Intransparenz ihres Tuns erwachsen, nicht widerstandslos aufgeben. Und sie wissen sehr wohl, dass sie für das Unternehmen nicht ersetzbar sind, so dass ihre Vorgesetzten sie nicht zwingen können, FMC einzusetzen.

Ich vermute zwar, dass es tatsächlich unmöglich ist, die Situation heute schon positiv zu verändern. Ich bin aber überzeugt, dass die Probleme, die aus der kommunikativ nicht beherrschten Komplexität großer Softwaresysteme erwachsen, immer offenkundiger und teurer werden, so dass die Verantwortlichen in der Softwareindustrie eines Tages nach den Schuldigen suchen werden. Und diese werden sie in der akademischen Informatik bei denen finden, die für die Lehrinhalte verantwortlich sind. Diese werden sich dann nicht mehr länger dagegen sträuben können, der kommunikativen Beherrschung der Komplexität großer Softwaresysteme mittels leicht lesbarer genormter grafischer Pläne das angemessene Gewicht in den Lehrplänen einzuräumen.

zum Seitenanfang