In dieser dritten Folge geht der Autor Dr. Peter Hruschka in seinem Beitrag zu Software-Engineering-Environments detailliert auf die Methoden zur Softwareentwicklung ein - hier auf "Structured Analysis". Die Folgen eins und zwei befaßten sich mit den Grundlagen des Software-Engineering und der Bedeutung der verschiedenen Konzepte. Verschiedene Methoden und Möglichkeiten der Modellbildung wurden vorgestellt und in ihren Vorzügen und Schwachstellen durchleuchtet.
Structured Analysis ist eine Methode, die speziell dafür geschaffen wurde, die Probleme der Anforderungsanalyse und -definition in den Griff zu bekommen /DeM79/. Die Methode stellt dem Systemanalytiker
- ein Denkschema,
- Ausdrucksmittel zur Definition von Problemen und
- ein Verfahrensschema zur Verfügung.
Das Wesentliche ist das Denkschema. Betrachtet man die übliche Gliederung für Pflichtenhefte, so findet man mehr oder weniger gut beschriebene Funktionen (Aufgaben), die das System ausführen soll. Die Zusammenstellung dieser Funktionen und die Beschreibung des Inhalts der Funktionen erfolgt nach vielfältigen Gesichtspunkten.
Meist ist jede Funktion für sich betrachtet gut verständlich. Die Schwierigkeiten treten beim Betrachten von Zusammenhängen auf. Bei dem funktionalen Ansatz übersieht man oft, wie die Funktionen zusammenspielen, über welche Schnittstellen sie kommunizieren.
Deshalb ist das Hauptanliegen von Structured Analysis das Denken in Datenflüssen. Als Datenflüsse bezeichnet man die Informationskanäle, durch die Nachrichten vom Benutzer an das System weitergegeben werden oder zwischen den einzelnen Systemkomponenten (Funktionen) ausgetauscht werden und die das System als Lösung (Antwort) dem Benutzer anbietet.
Dieses datenorientierte Denken ist in den letzten Jahren in der Literatur sehr oft zu finden. N. Wirth wies darauf hin, daß Programme nicht nur aus Algorithmen, sondern auch aus Datenstrukturen bestehen /Wir76/. M. Jackson, J. D. Warnier und K. Orr entwickelten Entwurfsmethoden, deren Kernidee die Datenstrukturen sind /Jac75/, /Orr77/. Für den Entwurf großer Systeme entwickelten DeRemer und Kron eine Module Interconnection Language /DeR76/, mit der insbesondere die Schnittstellen zwischen Moduln klar beschrieben werden konnten. Edward Yourdon und Tom de Marco waren es, die dieses Konzept in die Anforderungsanalyse und -definitionsphase übertragen haben /DeM79/. Sie haben dabei erkannt, daß nicht so sehr die Datenstrukturen interessant sind, sondern vor allem die Datenflüsse.
Beginnt man eine Analyse damit, die Datenflüsse in einem System zu untersuchen, so erhält man eine relativ natürliche Gliederung in Funktionen; die Funktionen fallen nahezu von selbst ab. Dadurch, daß man sich auf die Schnittstellen eines Systems konzentriert, hat man ein Kriterium an der Hand, wie man ein System in kleinere Teile zerlegt.
Da alle ein- und ausgehenden Datenflüsse explizit angegeben werden, ist das Auffinden von Fehlern oder vergessenen Aspekten sehr einfach möglich. Der Kunde erhält bereits in der Analysephase die Möglichkeit, auf solche Stellen hinzuweisen oder nach bestimmten Daten zu fragen.
Ein "Verstecken" von relevanten Systemteilen in irgendwelchen Funktionen ist nicht möglich, da zumindest alle von der Funktion verwendeten und produzierten Informationen als Schnittstelle angegeben werden müssen.
Ein weiterer Vorteil des datenflußorientierten Ansatzes ist folgender: Interviewe man in einer größeren Organisation der Reihe nach verschiedene Personen, so ist die Wahrscheinlichkeit, daß man unvollständige Informationen erhält, relativ groß. Versucht man hingegen, "die Daten zu interviewen", das heißt, ausgehend von den Daten, die in der gesamten Organisation fließen, die Struktur der Organisation abzuleiten, so erhält man von vornherein ein konsistenteres Bild.
Structured-Analysis-Modelle bestehen aus drei wesentlichen Komponenten, die zusammen ein mächtiges Werkzeug zur Beschreibung von Systemen bilden. Im Mittelpunkt stehen die Datenflußdiagramme. Ein Datenflußdiagramm (Dataflow-Diagramm, DFD) ist eine grafische Darstellung von Funktionen und den Schnittstellen zwischen den Funktionen, den Datenflüssen. Es stellt das System durch seine Teilkomponente dar. Abbildung 4 zeigt ein (abstraktes) Datenflußdiagramm.
Ein Datenflußdiagramm besteht aus vier Elementen: Datenflüssen, Knoten, Datenspeicher und Endknoten.
Ein Datenfluß (Dataflow) ist ein Kanal, durch den Informationspakete, deren Aufbau man kennt, fließen. Der Pfeil XXX in Abbildung 7 stellt einen Datenfluß dar.
Ein Knoten (Node) ist eine (komplexe) Aktion, die einen oder mehrere Eingangsdatenflüsse in einen oder mehrere Ausgangsdatenflüsse umformt. In der Abbildung stellen die Kreise T1 und T2 Knoten dar.
Ein Datenspeicher (Store) ist eine Ablage für Information (für eine bestimmte Zeitspanne). (X-Datei in der Abbildung.) Datenspeicher kann man sich als manuelle oder automatisierte Dateien, als Datenbanken oder jede andere Ansammlung von Informationen vorstellen.
Ein Endknoten (Terminator) ist eine Stelle, wo Information in das Netzwerk einfließt oder es verläßt (QUELLE und SENKE in Abbildung 4 sind Endknoten). Zweck dieser Endknoten ist es, die Schnittstellen des Modells zur Außenwelt darzustellen. Man verwendet sie zur Darstellung von Personen, Organisationen und anderen Systemen außerhalb des betrachteten Kontexts.
Alle Datenflüsse und alle Funktionen in einem DFD sind mit einem Namen versehen. Zur näheren Erläuterung dieser Begriffe verwendet man die beiden anderen Komponenten. Das Datenlexikon (Data-Dictionary, DD) dient zur Überwindung der Sprachbarriere zwischen Systemanalytiker und Benutzer. Wie in einem gewöhnlichen Lexikon findet man hier die Definition all der Daten, die für das Projekt von Bedeutung sind. Somit wird sichergestellt, daß bei Gesprächen und Verhandlungen im Projekt die Terminologie geklärt ist. Im Datenlexikon erläutert man, wie die Datenflüsse strukturell aufgebaut sind Ein Beispiel für eine Eintragung im Datenlexikon ist in Abbildung 5 dargestellt. Die Komponenten in den Strukturen können ihrerseits wieder Datenflüsse sein oder auch Datenelemente. Ein Datenelement ist ein einfacher Datenfluß, der nicht weiter (sinnvoll) zerlegt werden kann.
Die Aufgaben, die die einzelnen Funktionen erfüllen, sind in Kurzinfos (Minispec, Transformationsbeschreibung, Transformation Description, TD) beschrieben. Zu jeder Funktion gibt es eine kurze, möglichst einfach abgefaßte Beschreibung, die angibt, nach welcher Strategie die eingehenden Datenflüsse in die Ausgaben transformiert werden.
Als Systemmodell bezeichnen wir die Zusammenfassung von Datenflußdiagrammen, Datenlexikon und Kurzinfos.
Teile und beherrsche
Natürlich fällt so ein konsistentes und vollständiges Systemmodell nicht vom Himmel.
Zur Erstellung dieses Modells gibt Structured Analysis ein Verfahrensschema an, das seit 1972 /Dah72/ vielen EDV-Fachleuten geläufig ist. Nach dem Motto "Teile und beherrsche" zerlegt man sein Problem ausgehend von einer sehr einfachen und groben Übersicht schrittweise so weit, bis Systemanalytiker und Benutzer über das Ziel des Projektes einig sind. Dabei entstehen mehrstufige Datenflußdiagramme, die hierarchisch aufgebaut sind und gewissen Konsistenzregeln genügen müssen.
Das Ergebnis eines jeden Analyseschrittes wird mit den obenbeschriebenen Ausdrucksmitteln festgehalten und dient sofort als Rückkopplung zum Benutzer. Falls Mißverständnisse darin enthalten sind, werden diese geklärt, bevor man sich mit weiteren Details beschäftigt.
Beispiel: Hotel
Die oben angeführten Punkte - das Denkschema, die Ausdrucksmittel und die Vorgehensweise von Structured Analysis - sollen an einem einfachen Beispiel demonstriert werden. Das Problem:
Ein Hotelbetrieb mit 150 Betten will die Bereiche
- Zimmerreservierungen und
- Rechnungsschreibung automatisieren.
Die Zimmer lassen sich in drei Kategorien einteilen:
1) Einzelzimmer, WC, Dusche (50 Zimmer)
2) Doppelzimmer, WC, Bad (70 Zimmer)
3) Appartements, 4 Betten, WC, Bad (30 Zimmer)
Kategorie 2 und 3 können auch als Einzelzimmer vermietet werden. Kategorie 3 als Doppelzimmer, Dreibettzimmer oder Vierbettzimmer.
Der erste Schritt besteht darin, die Systemschnittstellen ausfindig zu machen - die Datenflüsse zu finden, die vom Benutzer zu dem System oder vom System zu dem Benutzer fließen. Der Hotelier und der Systemanalytiker halten fest, welche Informationen als Eingabe dienen können und was an Angaben und Reaktionen erwartet wird.
Als nächstes versucht man, die gefundenen Datenflüsse miteinander zu verbinden. Man zeichnet die ersten, groben Vorstellungen über Funktionen des Systems ein.
Nun muß man natürlich darangehen, das entstandene Bild näher zu erläutern und die Begriffe, die in dem Datenflußdiagramm verwendet wurden, zu beschreiben. Für die Datenspeicher sieht der Eintrag im Datenlexikon beispielsweise folgendermaßen aus (siehe Abbildung 8).
Auch die Funktionen werden näher beschrieben. Hat man alle drei Teile - Datenflußdiagramme, Datenlexikon und Kurzinfos - vollständig beschrieben, so liegt ein erstes, konstistentes Systemmodell vor. Vieles in diesem Modell wird noch unklar sein. Deshalb bildet es nur den Ausgangspunkt für weitere sachliche Erhebungen und Korrekturen. Jetzt beginnt die Iterations- und Verfeinerungsphase. Die Vorgehensweise bleibt aber dieselbe wie bei der ersten Version. Aus Platzgründen kann das Beispiel hier nicht vollständig wiedergegeben werden. Eine ausführliche Beschreibung findet man in /Hru82/.
Wenig Überraschungen beim Test
Der Hauptvorteil von Structured Analysis besteht darin, daß die Analytiker und Benutzer präziser und früher verstehen, was das neue System leisten wird und wie es sich in den bestehenden Rahmen einfügt. Dadurch erlebt man beim Abnahmetest weniger Überraschungen und reduziert die Fülle von Änderungswünschen des Kunden während der ersten Monate des Einsatzes eines neuen Systems. Außerdem hat dieser etwas formalere Ansatz noch folgende Vorteile für den Analytiker:
- Es gibt eine konkrete und gut definierte Menge von Aufgaben (Vorgehensweisen) und Produkten der Analysephase.
- Von der Papiermenge her betrachtet, wird das Pflichtenheft dünner (ungefähr ein Drittel der klassischen funktionalen Beschreibungen).
- Man verwendet iterative Schritte, wobei der Zusatzaufwand pro Iteration sehr klein ist.
- Man spart die Zeit, die man sonst zum Schreiben der ausführlichen, bald überholten Dokumentation braucht. Fortsetzung folgt
Literaturverzeichnis
(Boe 76) B. Boehm, Software Engineering, IEEE Trans. on Electr. Comp., Dec. 1976.
(Cai75) S. H. Caine, E. W. Gordon. PDL: A Tool for Software Design, in: AFIPS, Proc., NCC, Vol. 44, 1975.
(Dah72) O. J. Dahl, E. W. Dijkstra, C. A. R. Hoare, Structured Programming, Academic Press, 1972.
(DeM79) T. DeMarco, Structured Analysis and System Specification, Yourdon Press, 1979.
(DeR76) F. DeRemer, H. H. Kron, Programming-in-the-Large versus Programming-in-the-Small, IEEE Trans. on SE, Vol. 2, No. 2, 1976.
(Fre77) P. Freeman, Fundamentals of Design, in: P. Freeman, A. Wasserman, Tutorial on Software Design Techniques, 3rd Ed., IEEE, 1980.
(GEI79) GEI mbH, PDL Entwurfshandbuch, GEI interne Notiz, 1979.
(Hru82) P. Hruschka, Fallstudie: Die Software-Produktionsumgebung PROMOD, GEI Kursunterlagen.
(Jac75) M. A. Jackson. Principles of Program Design, Academic Press, 1975.
(Ker81) P. Kerola, P. Freeman, A Comparison of Life Cycle Models, in: IEEE Proc. 5th ICSE, p.90-99. 1981
(Keu81) H. Keutgen, DARTS - Design Aid for Real Time Systems, KfK-PFT 17, Januar 1982 Kernforschungszentrum Karlsruhe.
(Lau80) R. Lauber et al., EPOS - A Specification and Design Technique For Computer Controlled Real-Time Automation Systems, in: IEEE Proc. 4th ICSE. p.245-250,1980.
(Lis74) B. Liskov. S. Zilles, Programming with Abstract Data Types, ACM Sigplan Notices, Apr. 1974.
(Loe81) S. Loeffler, U. Satthoff. PROMOD-Transformator. GEI interne Notiz. 1981.
(Mil71) H. D. Mills, Top-down Development in Large Systems, in: R. Rustin (ed.), Debugging Techniques in Large Systems Englewood Cliffs. N. J.: Prentice Hall, 1971.
(Mye75) G. J. Myers Reliable Software Through Composite Design, Van Nostrand Reinhold, 1975
(Orr77) K. T. Orr, Structured System Development, Yourdon Press, 1977.
(Par71) D. Parnas, Information Distribution Aspects of Design Methodology, Proc. IFIP Congress 71, North Holland, 1971.
(Par72) D. L. Parnas. On the Criteria To Be Used in Decomposing Systems Into Modules. CACM. Vol. 5, No. 12, Dec. 1972.
(Ros77) D. T. Ross, K. E. Schoman, Jr., Structured Analysis for Requirement Definition, IEEE Trans. on SE, Jan. 1977.
(Sch81) R. Schaede. Eine Methode zum modularen Systementwurf, Software Technik Trends, Heft 1-2, 1981.
(Tei77) D. Teichroew, E. A. Hershey III, PSL/PSA: A Computer-Aided Technique For Structured Documentation and Analysis of Information Processing Systems, IEEE Trans. on SE, Vol. 3, No. l, Jan. 1977.
(Wil80) R. R. Willis, Computer Aided Design of Software Systems, in: Proc. 4th ICSE, p.116-125, 1980.
(Wir76) N. Wirth. Algorithms + Data Structures = Programs. Prentice Hall, 1976,