Nach Berücksichtigung dieser Dinge und einer begrenzten Überarbeitung der bisherigen Entwürfe möge das Petrinetz von Bild 9 entstanden sein.
Man sieht, daß außer den erwähnten Ergänzungen gegenüber dem Petrinetz von Bild 8, noch einige Präzisierungen auf der Kunden- und Bestandsführungsseite vorgenommen wurden. Es ist leicht, alle Festlegungen im einzelnen zu verfolgen und eventuell noch offene Fragen zu lokalisieren.
So entnimmt man dem Petrinetz von Bild 9 unmittelbar, daß beim Auftrag eines bereits bekannten Kunden dessen Kreditwürdigkeit zunächst geprüft wird; jedoch ist dabei nicht präzisiert, wovon sie abhängig gemacht werden soll: - von der Höhe des Zahlungsrückstandes, dessen Dauer oder der Höhe des Auftrages. Darauf stößt man, automatisch bei der Analyse der Transition "Kundenkonto prüfen". Es ist dem Petrinetz zufolge beabsichtigt, dem Kunden, falls er nicht vertrauenswürdig ist, nicht direkt abzusagen, sondern den Fall zunächst einer höheren Instanz zur Entscheidung vorzulegen.
Bei einem Neukunden wird dagegen, gemäß dem Petrinetz von Bild 9 ein Auftrag ohne Prüfung beliefert falls die gewünschte Ware vorrätig ist. Ein konkretes Beispiel hierfür wäre der Zeitungsversand. Die Diskussion zwischen Systementwickler und Auftraggeber klärt schnell, ob diese Vorgehensweise wünschenswert ist.
Der Entwurf von Bild 9 muß durch weitere Detaillierungen auf mehreren Ebenen immer weiter präzisiert werden, bis eine fundierte Entscheidung über die durch die Datenverarbeitung zu automatisierenden Teilabläufe und entsprechende Programmentwürfe möglich wird. Ich will die weitere Behandlung des Gesamtentwurfes hier abbrechen, da dessen Erarbeitung ganz beträchtlichen Aufwand kosten und auch den Rahmen dieser Einführung sprengen würde. Ich will vielmehr am Beispiel einiger Detailuntersuchungen die Brauchbarkeit des vorgeschlagenen Entwurfsverfahrens weiter untermauern. Die
Übersichtlichkeit dieser Darstellungsmethode sowie die konkrete Anwendbarkeit jeder Transition, jedes Zustandes und jeder Abhängigkeitsbeziehung, dürfte als Fortschritt bereits jetzt erkannt worden sein.
Zur Demonstration soll ein weiterer Aufgabenbereich des in Bild 9 erwähnten Versandhauses dienen. Bisher wurden nur die Auftragsbearbeitung und die Warenlieferung behandelt. Zu einem Handelsunternehmen gehört aber - ebenso wichtig - die Überwachung und Buchung der eingehenden Kundenzahlungen. Dann natürlich auch die Nachbestellung der Waren, deren Bezahlung, die Entlohnung der Mitarbeiter und schließlich die Regelung der allgemeinen Verbindlichkeiten, wie Steuern, Mieten, Gebühren für öffentliche Versorgungsleistungen und dergleichen.
Betrachten wir also jetzt die Überwachung der eingehenden Zahlungen (Bild 10).
Man sieht, daß bei einer vom Kunden eingehenden Zahlung zunächst die Vollständigkeit der Rechnungsangaben geprüft, im positiven Fall die entsprechende Rechnung herausgesucht und dann die Forderung mit der Zahlung verglichen wird. Bei unvollständigen Rechnungsangaben ist der dann zu befolgende Ablauf angegeben. Man bemerkt aber sofort, daß in diesem Netz beispielsweise nicht berücksichtigt ist, daß ein Rechnungsbetrag auch überzahlt sein kann. Weiter ist unberücksichtigt, daß man bei
ganz geringfügiger Differenz zwischen Rechnungsbetrag und Zahlung vielleicht abweichend verfahren möchte. Wir wollen das jedoch nicht verfolgen, sondern das Petrinetz in anderer Hinsicht ergänzen und zwar um die wichtige Überwachung der ausstehenden Zahlungen. Dazu bedarf es einer Transition "Prüfen der ausstehenden Zahlungen". Diese Transition kann angreifen an dem Zustand "Verzeichnis der ausstehenden Zahlungen und Zahlungsziele".
Einen möglichen Ablauf dieser Ergänzung zeigt das Petrinetz auf Bild 11. Auch dieses Netz muß noch weiter präzisiert werden, bis alle für einen Programmentwurf wichtigen Aufgaben eindeutig festgelegt sind.
4. Petrinetze als dauernde Systemdokumentation
Mit der Beschreibung eines Systementwurfs in Form von Petrinetzen ist nicht nur eine tragfähige Grundlage für die weitere Entwicklung des Systems gewonnen worden, sondern zugleich eine verständliche und implementierungsunabhängige Beschreibung eines Systems, zunächst zu Beginn seiner Realisierung. Es ist von entscheidender Bedeutung für die weitere Entwicklung des Systems, daß dieser Aspekt - nämlich in den Petrinetzen des Systems eine einfache, implementierungsunabhängige und gültige Beschreibung zu besitzen - auch während der Implementierung und im weiteren Verlauf bei nachfolgenden Änderungen und Erweiterungen beibehalten wird. Nur dann kann nämlich die Petrinetzdarstellung bei Änderungen jeweils die volle Hilfe leisten, zu der sie imstande ist, ähnlich den Bauplänen im Hausbau. Auch dort müssen Änderungen der Konzeption nachgetragen werden. Anderenfalls würden die bestehenden Pläne veralten und wertlos werden.
Da jedes "lebende" Software-System im Laufe seiner Existenz den sich verändernden Umweltanforderungen angepaßt werden muß, bedeutet das, daß alle derartigen Änderungen zunächst in den Petrinetzen eingetragen und erst anschließend realisiert werden dürfen. Das gilt auch schon während der Implementierung, wenn sich etwa herausstellt, daß noch diese oder jene Änderung am ursprünglichen Entwurf vorgenommen werden muß.
Die beim Systementwurf entwickelten Petrinetze stellen also nicht nur ein Hilfsmittel für die Anfangsphase dar, von dem man sich nach und nach immer mehr entfernt, sondern müssen im ganzen Verlauf des Entwicklungsprozesses dauernd mitgeführt und angepaßt werden. Für die Entwicklung von Programmsystemen und ihre nachfolgende Wartung gewinnt man dadurch noch einen weiteren Vorteil. Verhältnismäßig leicht kann neues Personal nachträglich eingearbeitet und damit die vorhandene Mannschaft verstärkt oder entstandene Ausfälle ersetzt werden.