Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

08.04.1983 - 

Richtige Methodenwahl verlangt gutes Feeling, Folge 2:

Information Hiding-Modul kommuniziert gezielt

In der ersten Folge seiner Serie zu Software Engineering Environments und ihrem praktischen Einsatz erläuterte Dr. Peter Hruschka die junge Entwicklungsgeschichte des Software Engineering und des Einsatzes rechnergestützter Methoden zur industriellen Softwareerstellung. Er empfahl, in den verschiedenen Phasen eines Projektes. die im einzelnen erklärt wurden, verschiedene Methoden gezielt einzusetzen, wies jedoch gleichzeitig auf die Schwierigkeiten hin, die damit zusammenhängen. Ein Methodenbündel unter Berücksichtigung der Mitarbeiter, die in den unterschiedlichen Entwicklungsstadien die Hauptrolle spielen, macht die Erstellung eines Softwareprojekts rationeller und planbarer. In dieser zweiten Folge diskutiert der Autor den Stand der Technik einzelner Phasen, bevor auf die Methoden direkt eingegangen wird.

Die klassischen Methoden zur Systemanalyse sind Interviews, Fragebogen und Beobachtung. Die Aufzeichnung ihrer Ergebnisse erfolgt auf unterschiedliche Weise, als Tabellen, Matrizen oder in graphischer Form. Die graphischen Darstellungen sind jedoch meist keinen festen Regeln unterworfen und richten sich nach dem Geschmack des Systemanalytikers. In den letzten Jahren entstanden einige Verfahren, die die Systemanalyse unterstützen sollen. Man muß dabei Methoden unterscheiden, die nur zur Aufzeichnung des Ergebnisses der Analysephase dienen (Spezifikation, Pflichtenheft) und solche, die die Analyse selbst auch unterstützen. Zur letzten Gruppen zählen sicherlich SADT (Structured Analysis and Design Technique) /Ros77/, SA (Structured Analysis) /DeM79/ und PSL/PSA (Problem Statement Language/Analyzer) /Tei77/.

Modellbildung im Vordergrund

PSL/PSA beruht darauf, Objekte und Relationen aus informellen Texten herauszufiltern, diese auf genormte Objekte und Relationen abzubilden und in einer Datenbank abzulegen. Danach kann man das in der Datenbank gesammelte Wissen in verschiedenster Form analysieren, aufbereiten und interpretieren.

Sowohl SADT, als auch SA hingegen stellen die Modellbildung in den Vordergrund. Ziel der Analysephase ist es, ein verständliches und leicht lesbares Modell der wirklichen Probleme zu schaffen. Dazu beinhalten beide eine Reihe von Methoden und Techniken, die folgende Komponenten einschließen:

- Kriterien zur Entwicklung von Modellen,

- eine graphische Sprache zur Darstellung von Modellen,

- Managementpraktiken zur Kontrolle der Entwicklung.

Beide Methoden sind sehr ähnlich in ihrer Art, Modelle zu entwickeln.

Die grundsätzliche Vorgehensweise ist eine Top-down Zerlegung des Problems, das Suchen nach geeigneten Abstraktionen und die Durchführung von Reviews und Iterationen. Top-down Entwicklung bedeutet nicht, wie oft angenommen wird, daß man ein grobes Modell entwirft und dieses dann bis zur Programmierung verfeinert, sondern daß man mit einer groben Vorstellung des Modells beginnt. Dann sammelt man weitere, genauere Informationen.

Aufgrund des neu erworbenen Wissens betrachtet man sein Grobmodell noch einmal, korrigiert es, ändert es oder paßt es an. Außerdem ergänzt man die neuen Teile. Auf jeder Stufe erfolgt der gleiche Prozeß. Das dabei entstehende Modell läßt sich als Top-down Zerlegung darstellen, der Prozeß selbst schließt jedoch viele Iterationsschritte und Reviews mit Änderungen ein.

Das Suchen nach geeigneten Abstraktionen bedeutet, daß man auf jeder Stufe nur so viel vom System darstellt, wie zum Verständnis auf dieser Stufe notwendig ist. Irrelevante Details, wie Initialisierungs- und Terminierungsoperationen oder triviale Fehlerfälle sollen unterdrückt werden.

Es gilt das "Lump-Law": Wenn man irgend etwas über ein System lernen will, darf man nicht versuchen, gleich alles zu lernen.

Irrelevante Details unterdrücken

Der Unterschied der beiden Methoden SADT und SA liegt in der Betrachtungsweise, die den Modellen zugrundeliegt. SADT stellt Zwecküberlegungen und den Standpunkt des Betrachters in den Vordergrund. Die entstehenden Modelle werden unterschiedlich sein, je nachdem, ob man ein System neu entwickelt oder ein bestehendes System dokumentiert oder versucht, Probleme in Systemen aufzufinden. Für den Aufbau dieser Modelle gibt SADT Richtlinien und Ratschläge.

Structured Analysis betont die Rolle des Datenflusses in Systemen. Durch Konzentration auf diesen Aspekt kann die Vorgehensweise beim Aufbau des Modells präziser definiert werden als bei SADT, die Richtlinien und Ratschläge sind zielstrebiger und weniger allgemein gehalten.

Actigrams und Diagrams

Die graphischen Darstellungen der entscheidenden Modelle sind ähnlich den Blaupausen von Architekten, Bauingenieuren oder Maschinenbauingenieuren, eine Sammlung von Zeichnungen mit teils genormten, teils freien Beschriftungen. Bei SADT heißen sie Actigrams oder Datagrams, bei SA Data Flow Diagrams (DFDs),

Während bei SADT die Beschriftungen der Zeichnungen relativ informell sind, bietet das SA-Modell zusätzlich zu den DFDs noch zwei weitere Werkzeuge: Ein Data Dictionary (DD) und die Transformationsbeschreibungen (TDs), um die graphische Darstellung zu ergänzen und zu präzisieren.

In den Händen der richtigen Personen sind SADT und SA sicherlich vergleichbar hilfreiche Methoden; aufgrund der leichteren Erlernbarkeit und der detaillierten Führung des Benutzers durch die Methode haben wir jedoch Structured Analysis den Vorzug eingeräumt.

Für die Phase des Systementwurfs gibt es unter anderem zwei anerkannte, moderne Methoden: Strukturen, Design /Mye75/ und Modularisierung mit abstrakten Datentypen /Par72, Lis74/.

Die Vorteile von Structured Design liegen darin, daß Ableitungstechniken aus den Ergebnissen der Structured Analysis existieren und Bewertungskriterien für internen Modulzusammenhalt und externe Modulkopplung aufgeführt werden können.

Ersteres ist dadurch zu erklären, daß Structured Analysis aus den bereits bekannten und erprobten Techniken des Structured Design entwickelt wurden. Daher ist der Übergang zwischen den beiden Methoden fließend: Es muß kein Umdenkprozeß zwischen den Phasen stattfinden.

Structured Design basiert auf der Idee, Programm-Moduln zu bilden die intern sehr starken Zusammenhang haben, zu anderen Moduln jedoch möglich wenig Querbeziehungen aufweisen. Das angestrebte "Idealmodul" ist die Funktion im mathematischen Sinn: y + f(x).

Funktionale Module mit Schwächen behaftet

Dieser "funktionale" Modulbegriff birgt einige Schwächen und Gefahren in sich. Bei größeren Systemen wird eine Zerlegung in derartige Funktionen leicht unübersichtlich, da Kriterien wie logische Zusammengehörigkeit von Funktionen, gemeinsam benutzte Daten, . . . erst als Maß für die Güte des entstandenen Entwurfs und nicht von vornherein als Kriterium für die Gestaltung des Entwurfs verwendet werden.

Ein anderer Modulbegriff wurde von D.L. Parnas /Par71/ entwickelt. Die Grundidee ist das Information Hiding. Ein Modul ist so konzipiert, daß es nur über definierte Schnittstellen von anderen Parts benutzt werden kann; die interne Struktur von Daten bzw. Funktionen auf diesen Daten bleibt dem Benutzer verborgen. Derartige Moduln werden auch als abstrakte Datentypen bezeichnet: Sie realisieren einen Datentyp und dafür benötigte Zugriffsfunktionen.

Die Zusammenfassung der Ideen aus Structured Design und dem Prinzip des Information Hiding bezeichnen wir als "Modular Design".

Methoden des Programmentwurfs

Auch Modular Design ist wie Structured Analysis eine iterative Technik. Nach Aufbau des ersten Entwurfs geht man an dessen Bewertung und korrigiert vielleicht einige Teile durch Umformung der Hierarchie. Danach bearbeitet man die Moduln weiter.

Nach jeder Überarbeitung setzt aber wieder der Bewertungs- und Korrekturvorgang ein. Die Iteration bricht ab, sobald man die Schnittstellen aller Moduln für das Gesamtsystem geschaffen hat.

Hat man die Grobstruktur eines Systems einmal festgelegt, so können in der Phase des Programmentwurfs die Algorithmen genau festgeschrieben werden. Für diese Phase sind Methoden, die auf Pseudocode und schrittweise Verfeinerung basieren, wie PDL (Program Design Language) / Cai75/ und DARTS (Design Aid for Real-Time Systems) /Keu82/, ideal. Durch die vorhandene Festlegung der Aufgaben und Schnittstellen können hier mehrere Personen weitgehend unabhängig voneinander arbeiten.

Pseudocode ist eine funktional orientierte Methode zum Entwerfen von Algorithmen in einer eindeutigen, natürlichen Sprache. Die natürliche Sprache wird verwendet, um die Lesbarkeit des Systemmodells auch im Entwurf noch zu gewährleisten. Die Kommunikation unter den Teammitgliedern und die Rückkopplung vom Benutzer sind auch in dieser Phase das angestrebte Ziel. Die Eindeutigkeit der natürlichen Sprache wird durch Vorgabe einiger Grundkonstrukte aus der strukturierten Programmierung erreicht. Eine Wiederholung (Schleife) wird beispielsweise folgendermaßen ausgedrückt:

DO für alle Elemente der Umsatzliste lies Tagesumsatz addiere Tagesumsatz zum Gesamtumsatz

ENDDO

In ähnliche Weise lassen sich auch Entscheidungen (Abfragen) ausdrücken. Die Verwendung dieser Grundkonstrukte erlaubt im Anschluß an den Programmentwurf eine sehr einfache Umsetzung in alle gängigen Programmiersprachen .

Als Alternative zum Pseudocode könnte man - bei stärker datenorientierten Projekten - auch die Michael Jackson Designmethode /Jac75/ anwenden.

Bei Structured Analysis erhält man jeweils einzelne Prozeßdarstellungen mit allen ein- und ausgehenden Daten. Im Data Dictionary ist deren Struktur teilweise schon aufgeschlüsselt. Durch weitere, genauere Darstellung dieser Datenstrukturen und durch Abbildung von Eingabestrukturen auf Ausgabestrukturen kommt man zu einem Entwurf für die Programmstruktur des Prozesses. Diese kann dann in der 'schematic logic'-Notation von Jackson niedergeschrieben werden.

Durch die in den Vorphasen angewandten Methoden, insbesonders durch die Verwendung von Pseudocode in der Programmentwurfsphase kommt man zu einer Codiervorgabe, die bereits nach den Regeln der strukturierten Programmierung /Dah72/ gestaltet ist.

Eine saubere Umsetzung in die elementaren Konstrukte Sequenz, Selektion und Iteration gelingt nicht nur für Sprachen wie Pascal, die die strukturierte Programmierung ohnehin stark unterstützen; auch Programme in Assembler, Fortran oder Cobol erhalten eine wesentlich bessere und übersichtlichere Struktur wenn man nach der Vorgabe des Programmentwurfs umsetzt.

Die Gliederung in einzelne Funktionen und Moduln erleichtert auch den Test der einzelnen Programmteile, da man für jeden Einzelteil aufgrund der Überschaubarkeit und Einfachheit mit wenigen, systhematischen Tests auskommt.

Faßt man die bisherigen Feststellungen zusammen, so kommt man zu Bild 3. Horizontal sind die erläuterten Methoden aufgetragen und vertikal die Phasen des Software Life Cycles. Die Längen der Pfeile geben die Phasen an, in denen die Methoden (sinnvoll) eingesetzt werden können, ihre Dicke drückt unsere Einschätzung der Effizienz der Methode in der jeweiligen Phase aus.

Akzeptiert man diese Bewertung, so kann man einige Modelle herleiten, in denen die Methoden so aneinandergereiht sind, daß jede ihren besten Einsatz findet. Außerdem muß man darauf achten, daß die im Modell verwendeten Methoden schnittstellenverträglich sind, so daß die in der Einleitung behandelten Probleme nicht auftreten. Ein Beispiel für ein solches Modell zeigt Tabelle 1.

Viele Erfahrungen und grundlegende Untersuchungen deuten darauf hin, daß beim heutigen Stand der Softwaretechnik die in der Tabelle aufgeführten Methoden zumindest eine optimale Konfiguration für die Bewältigung der Projektarbeit darstellen. Aus diesem Grund - und um mehr in die Tiefe, nicht so sehr in die Breite zu gehen - spezialisiert sich diese Serie im folgenden auf die in der Tabelle aufgeführten Methoden und die darauf basierenden Werkzeuge.

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,1970,

(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-Produktionsamgebung PROMOD, GEI Kursunterlagen,

(Jae75) 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. Loefller. 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) C. J. Myers, Reliable Software Through Composite Design, Van Nostrand Reinhold, 1975.

(Orr77) K. T. Orr, Structured Sydem Development, Yourdon Press,1977.

(Par71) D, L, 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.1, 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.