Software-Entwicklung wird von zwei Problemen beherrscht: Aufwand und Qualität. Software als System zu behandeln und industriell zu erstellen, wäre ein geeigneter Weg, diese Schwierigkeiten zu lösen. Doch bisher fehlte dafür eine wirkungsvolle, Iehrbare Vorgehensweise. Professor Dr. Helmut Groh von der Fachhochschule des Saarlandes, Saarbrücken, und Kurt H. Lutz von der Siemens AG München beschreiben in diesem Beitrag Möglichkeiten der durchtechnisierten Softwareerstellung. Dabei fordern sie eine stärkere Berücksichtigung der Prozeßträger und seiner Komponenten in einem System sowie der gegenseitigen Wechselwirkungen.
Man braucht viel Gespür beim Festlegen der Aufbruchkriterien auf den verschiedenen Ebenen. Insbesondere dann, wenn eine solche Baumstruktur von verschiedenen Personen detailliert wird, kommt es zu erheblichen Schwierigkeiten.
Teilaufgaben lassen sich auf der Basis von Baumstrukturen nicht gut abgrenzen. Da man kaum allgemeingültige Kriterien für die Untergliederung angeben kann, bleibt das Gliedern weitgehend der Intuition der Interpretation des einzelnen Konstrukteurs überlassen. "Übergriffe" und "Lücken" sind fast unvermeidbar. Man kann auch nur schwerlich den Arbeitsprozeß so beschreiben, daß der Ablauf in etwa vorgegeben, also lehrbar wäre. Vor allem aber die mögliche Diskrepanz zwischen den beiden Baumstrukturen hemmt und verunsichert. Baumstrukturen haben einen hohen Abstraktionsgrad. Sie sind zwar als Ordnungsstrukturen geeignet, weniger aber als Leitlinie für die Systemmodellierung. Die Entwicklung von Baumstrukturen im Sinne einer Systemmodellierung wird als Top-down-Methode bezeichnet.
Outside-in als abbildende Modellierung
Ein System ist eine abgegrenzte Anordnung von aufeinander einwirkenden Gebilden (DIN 19226). Nach dieser Definition entspricht dem System eine Netzstruktur als Abbild. Darin sind die Gebilde als Knoten und die Einwirkungen als Pfeile (Bild 4) dargestellt. Da die Einwirkungen ein zeitliches Geschehen voraussetzen, sind die Gebilde Träger von Prozessen, die wechselseitig interagieren. Es entspricht dieser Betrachtungsweise, daß man bei neueren Software-Konstruktionsverfahren
die Systeme durch Netzstrukturen statt durch Baumstrukturen darstellt. Auch solche systemabbildenden Interaktionsnetze werden schrittweise verfeinert - allerdings nicht, wie die Baumstrukturen, für ein Ordnungsschema, sondern für das Abbilden der Interaktiosstruktur des Systems.
Zu diesem Zweck untergliedert man die Knoten, indem man ihnen Teilnetze zuordnet. In Bild 5 ist der Knoten 3 in dieser Weise "aufgebrochen". Beim Aufbrechen entstehen Subsysteme, die nicht mehr geschlossen sind. Die ursprünglichen Interaktionsanschlüsse des aufgebrochenen Prozeßträgers erscheinen jetzt als hängende beziehungsweise "äußere" Kanten. Sie sind in dieser Abbildung gestrichelt gezeichnet. Bevor ein Prozeßträger sinnvoll aufgebrochen werden kann, muß man seine Funktion, das heißt, den Zusammenhang zwischen seinem Output und seinem Input sowie die Anforderungen an sein Zeitverhalten analysieren. Dazu bedarf es einer mehr oder weniger detaillierten Darstellung der Prozesse, die im Prozeßträger ablaufen. Zu diesem Zweck braucht man geeignete Darstellungsmittel für Prozesse.
Die Systemmodellierung mittels Interaktionsnetzen ist ein lehrbares Verfahren (Bild 6). Man geht vom Zielsystem und seiner Umwelt aus. Zu dieser Umwelt gehört auch die DV-technische Systembasis, insbesondere aber die Benutzer oder die Kommunikationspartner (zum Beispiel auch andere Softwaresysteme, die man von vornherein formalisiert miterfassen kann). Man betrachtet das Zielsystem von außen, stellt fest, wer mit ihm kommuniziert und beschreibt die dabei ausgetauschten Daten. Auf diese Weise sind für das System und seine Kommunikationspartner jeweils der Input und der Output definiert. Aber vor allem ist dadurch auch das erste Stück Datenstrukturierung geleistet; die Daten werden also nicht separat strukturiert. Ferner werden in der Beschreibung der zugehörigen Prozesse auch die Zeitbedingungen spezifiziert.
Beim Aufbrechen eines Prozeßträgers definiert man Komponenten, die seinen Input aufnehmen, seinen Output erzeugen und untereinander in Kommunikation treten können. Nachdem die Interaktionen und die zwischen den Komponenten auszutauschenden Daten definiert sind, beschreibt man Funktion und Zeitverhalten der Komponenten. Funktion bedeutet das Erzeugen der Outputs aus den Inputs. Funktion und Zeitverhalten der neuen Komponenten müssen konsistent zu den entsprechenden Festlegungen für den Prozeßträger sein, aus dem sie entstanden sind. Man muß also prüfen, ob Daten, Funktion und Zeitanforderungen der Komponenten in sich und untereinander konsistent sind. Widrigenfalls muß man versuchen, Anpassungen zu erreichen. Dies kann dazu führen, daß man umstrukturieren muß.
Gegenüber der Top-down-Methode hat man hier allerdings die Chance, Strukturkonflikte überwiegend lokal zu erkennen und zu beheben da man Funktion und Zeitverhalten integriert strukturiert hat.
Die "Komponente" in Bild 6 bezeichnet nicht nur einen Prozeßträger, sondern auch einen Prozeß. Die Funktion eines Prozeßträgers wird dadurch definiert, daß man den in ihm ablaufenden Prozeß beschreibt. Gibt man dabei Subprozeßaufrufe an, so wird eben dadurch der Prozeß selbst in Komponenten zerlegt.
Vorteil von Outside-in im Sinne der hier angebotenen Philosophie ist das integrierte Aufbrechen von Prozeßträgern, Prozessen, Daten, Zeitbedingungen und Testfällen.
Zunächst betrachtet man das Zielsystem und seine Interaktionspartner als Komponenten. Diese bricht man soweit erforderlich in Tochterkomponenten auf, wobei man gleichzeitig deren Interaktionen, Funktionen und Zeitverhalten definiert. Dies wird fortgesetzt, bis die Prozesse in den Komponenten für die Realisierung hinreichend überschaubar geworden sind. Eventuell werden dabei Restrukturierungsschritte erforderlich.
Die hier geschilderte Outside-in-Methode hat Vorteile nicht nur hinsichtlich Effizienz, Lehrbarkeit und Überwinden von Strukturkonflikten. Die Darstellung des Interaktionsnetzes zusammen mit den Datenvereinbarungen für die Interaktionswege lassen auch klare Schnittstellen für die Abgrenzung von Teilaufgaben erkennen. Dadurch wird arbeitsteiliges Vorgehen in der Systemkonstruktion möglich. Die Voraussetzungen für ein industrielles Verfahren sind erfüllt.
Der hier gekürzt wiedergegebene Beitrag der Autoren Groh und Lutz ist in vollem Wortlaut enthalten im Siemens Data Report "3/84" vom Juni 1984.