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.

12.09.1986 - 

Benutzeranforderungen an das könftige SW-System stehen im Mlttelpunkt: .

Methoden müssen auch für DV-Laien klar sein

Eine moderne Softwareentwicklungsumgebung erfaßt sämtliche Phasen der SW-Produktion und nicht nur einzelne Bereiche. Sie verbessert bereits bewährte Techniken und führt neue Komponenten ein. Am Beispiel des vom BMFT geförderten Entwicklungsprojekts "Innovator" beschreiben Günther Ruck* und Reinhold Sauber* die wichtigsten Methoden und Werkzeuge einer Entwicklungsumgebung.

Die Methoden und Werkzeuge einer SW-Entwicklungsumgebung

müssen in natürlicher Weise die Tätigkeitsbereiche (Phasen) unterstützen, für die sie eingesetzt werden. In der Phase der Anforderungsanalyse und des Grobentwurfs sind Benutzeranforderungen an das zukünftige System zu erfassen und zu analysieren. In der Implementierungsphase sollen die Systementwickler komfortable Werkzeuge zur Programmierung und zum Programmtest erhalten. Aufgabe des Projektmanagements schließlich ist es, Projekte zu planen und zu kontrollieren.

Ergebnis der Phase "Anforderungsanalyse und Entwurf" ist das sogenannte Pflichtenheft beziehungsweise der grobe Entwurf. An die Methode zur Erfassung und Analyse der Benutzeranforlderungen werden folgende Forderungen gestellt:

-Die Methode muß auch für die Nicht-DV-Spezialisten verständlich sein, damit die entsprechenden Unterlagen als Ziskussionsgrundlage zwischen Auftraggeber und Auftragnehmer eingesetzt werden können.

-Sie muß trotzdem möglichst präzise und eindeutig sein.

-Sie darf keinesfalls programmsprachliche beziehungsweise algorithmische Aspekte enthalten. Solche Angaben würden das Wesentliche der Aufgabenstellung unübersichtlich machen und die Implementierungsmöglichkeiten so einschränken, daß eine erfolgreiche Lösung des Problems gefährdet wäre.

Diese Anforderungen lassen sich am besten durch die "informationsflußorientierte" Methode berücksichtigen. Danach werden zunächst die Informationsflüsse zwischen relativ groben Funktions- beziehungsweise Aktionseinheiten eines Systems festgelegt. Unter Systemen werden hier beliebige organisatorische, technische und softwaretechnologische Einheiten verstanden. So könnte man zum Beispiel das in Abbildung I dargestellte Gebilde als ein System auffassen. Es besteht aus einer Paketverteilanlage und einem Steuersystem.

Die Tools, die diese Methode unterstützen, müssen folgende Komponenten enthalten:

-Grafischen interaktiven Editor zur Erstellung und Manipulation von Datenflußdiagrammen;

-Data Dietionary zur eindeutigen Definition von Begriffen und zum Verwendungsnachweis von Daten;

-Kontrollprogramme zur Konsistenzüberprüfung.

Diese Tools sollen unter anderem auch die schrittweise Verfeinerung von Aktionen und Datenflüssen ermöglichen.

Auftraggeber und Auftragnehmer können sich anhand solcher Dokumente über das zukünftige System - unterhalten und weitgehend verständigen. Naturgemäß gibt es aber in Pflichtenheften dieser Art viele Unvollständigkeiten, die im allgemeinen erst bei der Inbetriebnahme des Systems entdeckt und nur mit sehr großem Aufwand behoben werden können.

Es sind also weitere Methoden und Werkzeuge erforderlich, die es erlauben, das bisherige Pflichtenheft so genau zu validieren, daß möglichst viele Fehler dieser Phase rechtzeitig entdeckt und eliminiert werden. Zu diesem Zweck wird das bisherige Pflichtenheft in eine ablauffähige Form gebracht. Die folgenden Methoden und ihre Werkzeuge sollen diesem Zweck dienen. Abstrakte Datentypen bestehen aus einer Schnittstellenebene (Spezifikationsebene) und einer Implementienungsebene (siehe Abbildung 2).

Die Operationen der Spezifikationsebene werden dadurch beschrieben, daß man angibt, was zu tun ist und nicht wie dies geschieht (Implementierung). Operationen können sowohl übliche aufrufbare Operationen als auch sequentielle Prozesse sein, die von außen nur angestoßen, aber nicht aufgenufen werden können.

Informationsflüsse zwischen verschiedenen Modulen können nur mit Hilfe von Operationsaufrufen stattfinden. Im allgemeinen besitzen die Operationen Ein- und Ausgabeparameter. Parameterlose Optionen stellen Ereignisse dar. Informationsflüsse innerhalb eines Moduls finden nur über modullokale Größen statt.

Man braucht also spezielle Werkzeuge, die es dem Systemdesigner ermöglichen, aus den Informationsflußdiagrammen abstrakte Datentypen beziehungsweise abstrakte Objekte abzuleiten. Im ersten Schritt werden hier nur die Schablonen, also die Schnittstellen der oben genannten Objekte abgeleitet. Diese Schablonen müssen anschließend mit Hilfe einer nichtprozeduralen Beschreibungssprache ausgefüllt und vervollständigt werden.

Mit Hilfe solcher Sprachen werden die Ausführungsbedingungen und die Wirkungen der einzelnen Operationen eines abstrakten Datentyps unabhängig von der Implementiemng (nichtprozedural) formuliert.Sprachen dieser Art besitzen einen höheren Abstraktionsgrad als höhere Programmiersprachen.

Enthalten diese Sprachen auch Sprachkonstnukte zur Formulierung von Synchronisations- oder Kommunikationsproblemen, so werden sie auch als nichtprozedurale Systembeschreibungssprachen bezeichnet. Bei "Innovator" wird auf die Prädikatenlogik erster Ordnung zurückgegriffen, so daß hier Ausführbarkeitsbedingungen und Wirkungen von Operationen mit Hilfe von logischen Ausdrücken formuliert werden.

Werkzeuge, die diese Methode unterstützen, sollten trotzdem eine komfortable Benutzeroberfläche zur Verfügung stellen, die auch mit den üblichen Programmierkenntnissen verstanden werden kann. Daß dies auch möglich ist, zeigen die relationalen Datenbanksysteme, deren Oberfläche auf die Prädikatenlogik zurückgeht und die trotzdem große Akzeptanz in der Praxis finden.

Zu den Werkzeugen dieser Phase gehören die Syntax und Semantik der zugrunde gelegten Systembeschreibungssprache sowie der entsprechende Compiler, der aus den angegebenen Beschreibungen ablauffähigen Code erzeugen kann. Mit den bisher genannten Werkzeugen kann man also Benutzeranfordenungen zuerst grafisch darstellen (Informationsflußdiagramme) und anschließend genau beschreiben (Systembeschreibungssprache); so sind Pflichtenhefte oder Grobentwürfe zu einem Zeitpunkt ablauffähig, zu dem nur Beschreibungen, aber noch keine Programme vorliegen. Dies ist für den Systemdesigner eine sehr große Hilfe, denn er kann seinen Entwurf validieren und konzeptionelle Fehler rechtzeltig entdecken.

Fur einen Nicht-DV-Spezialisten (Auftraggeber) ist diese Darstellungsform weniger verständlich. Um trotzdem den Auftraggeber in dieser frühen Phase einzubeziehen, ist die bereits erwähnte Darstellung in eine grafische Form umzuwandeln.

Als Methode dafür kommt die aus der Automatisierungstechnik bekannte "Prozeßvisualisierung" zum Einsatz. Danach wird das zukünftige System nach den Vorstellungen des Auftraggebers grafisch dargestellt. Außerdem muß noch die Verbindung zwischen grafischer Darstellung und präzisem Entwurf festgelegt werden. Als Werkzeuge fiir diese Tätigkeiten braucht man einen interaktiven Grafik-Editor zur Prozeßvisualisierung und eine Projektierungskomponente zur Verbindungsherstellung.

Mit Hilfe dieser Tools können nun Auftraggeber und Auftragnehmer sehen, wie sich das zukünftige System verhalten wird, wenn dieser Entwurf realisiert ist. Obwohl das vorhandene System eine Art "Prototyp" darstellt, kann man trotzdem das logische Verhalten beobachten, gewisse Situationen einstellen und probieren. Änderungen des Pflichtenheftes lassen sich zu diesem Zeitpunkt leicht berücksichtigen.

Haben sich Auftraggeber und Auftragnehmer auf eine Version des Pflichtenheftes geeinigt, so dient diese als Grundlage bei späteren Meinungsverschiedenheiten. Verhält sich das reale System anders als in der gültigen Pflichtenheftversion vereinbart, so liegt ein Implementierungsfehler vor. In Abbildung 3 werden Methoden und Werkzeuge der Phase "Anforderungsanalyse und Entwurf" dargestellt.

Für die Methoden und Werkzeuge der Implementierungsphase gibt es allgemein anerkannte Ansätze. Die Begriffe strukturierte Programmierung, Pseudocode, schrittweise Verfeinerung und High-Level-Debugging können als allgemeinbekannt angenommen werden. Das Wichtigste an dieser Stelle ist der Konsfort und die Effizienz der entsprechenden Werkzeuge. Abbildung 4 enthält eine Zusammenfassung der Methoden und Werkzeuge der Implementierungsphase.

Von diesen Werkzeugen werden folgende Eigenschaften erwartet:

-Menügesteuerte Benutzerführung;

-Struktogramme können beliebig groß sein(Overlay-Technik);

-Einzelne Blöcke in den Struktogrammen werden wie ganze Bildschirme behandelt (Fenstertechnik).

Von den Werkzeugen Precompiler und Parser erwartet man, daß sie semantische und syntaktische Fehler im edierten Programm aufspüren und eine aussagefähige Erklärung über den Grund des Fehlers geben. In Abbildung 5 wird die Verwendung der nichtdeklarierten Variablen "b" angezeigt.

Die Möglichkeit, Programme symbolisch zu testen, stellt einen hohen Komfort dar, der wesentlich zur Kostenreduktion und Qualitätssteigerung beiträgt. Ein dementsprechender symbolischer Debugger ist somit ein wichtiges Werkzeug und soll in der Lage sein, zum Beispiel Strukturen, Felder und Felder von Strukturen per Knopfdruck anzuzeigen und zu verändern. Physikalische Adressen oder Hexaformate gehören somit der Vergangenheit an.

Methoden und Werkzeuge für das Projekt- und Konfigurationsmanagement unterstützen den Benutzer dabei, Projektabläufe (Netzpläne), Produktstrukturen (Bäume), Kommunikationswege, Zugriffsrechte und Zustandsübergangsmechanismen zu planen und zu kontrollieren. In Abbildung 6 werden die wichtigsten Werkzeuge des "Innovators" hierzu aufgeführt.

Interaktive Grafik-Editoren und Manipulatoren von Arbeitsplänen und Produktstrukturen erhöhen wesentlich den Komfort eines solchen Systems. Besonders wichtig für die Zuverlässigkeit von Kostenschätzungen ist die Fähigkeit eines Systems, aus vergangenen Projekten Erfahrungen und Teilnetze zu ermitteln und zu übernehmen, die gewisse Sihnlichkeiten zu anstehenden Tätigkeiten aufweisen.