Software-Entwicklungshilfe bestCASE: Schnell & sauber...
CASE — das ist das Zauberwort der Software-Entwickler, die Hoffnung auf weniger durchgemachte Nächte, das Mittel gegen das böse Erwachen kurz vor Abschluß eines Software-Projekts. CASE steht für »Computer Aided Software Engineering«, also computergestützte Software-Entwicklung.
Doch was ist eigentlich computergestützte Software-Entwicklung? Da die Not so groß ist, gibt es viele Mittel, um der Software-Misere abzuhelfen. Programmgeneratoren und 4-GL-Sprachen, Debugger und komfortable Software-Entwicklungsumgebungen. CASE schließt alle diese Mittel begrifflich ein, aber am wichtigsten sind nicht die Mittel, sondern die Methoden, um die Programmentwicklung in den Griff zu bekommen. Die »strukturierte Programmierung« ist eine solche Methode, doch CASE setzt früher an — bei der Analyse der Aufgabenstellung und dem Zerlegen der Software in überschaubare »Häppchen«, bevor mit der eigentlichen Codierung begonnen wird.
Programme geben einem Werkzeuge an die Hand, mit denen das methodische Arbeiten unterstützt wird. Ähnlich, wie ein CAD-Programm dem Architekten hilft, sein Wissen gezielt und effektiv einzusetzen, bietet beST CASE Unterstützung bei der strukturierten Analyse von Aufgaben und beim Entwurf von Programmen an.
beST CASE wird von den Autoren des Programms, Mike Cronin und Sunna Darcy, direkt vertrieben. Der Lieferumfang besteht aus einem einfachen DIN-A5-Ringordner, der den User Guide und ein »Buch« mit einer Einführung in die Methoden enthält. Dazu gehören zwei Disketten, je eine für das Analyse- und eine für das Entwurfsprogramm. Die Aufmachung ist einfach, aber die prompte Lieferung und der Aufbau der Dokumentation lassen engagierte Autoren vermuten.
Beide Programme arbeiten unter GEM im monochromen Modus. Die Dokumentation ist in leicht verständlichem Englisch geschrieben. Für die Programme werden deutsche Ressource-Files mitgeliefert, so daß Menüs und Dialoge wahlweise in Deutsch oder Englisch auf dem Bildschirm erscheinen können.
Grafisch Aufgaben analysieren
Bevor man an die Programmentwicklung geht, sollte man sich darüber im klaren sein, was das neue Programm eigentlich leisten soll. Die Aufgabe muß beschrieben und dann im Rahmen einer Analyse soweit verfeinert werden, daß Fußangeln und Widersprüchlichkeiten aufgedeckt werden, bevor man tausende Zeilen Code geschrieben hat. Die strukturierte Analyse bietet hierzu einfache, auf wenigen Grundelementen basierende Grafiken, ergänzt durch textuelle Beschreibungen.
Grafische Grundelemente sind Prozesse, Datenflüsse, Speicher und Terminatoren. Prozesse beschreiben Tätigkeiten, Datenflüsse die zwischen den Prozessen ausgetauschten Daten und Speicher — nun, das sind die »Datentöpfe«. Ein Programm (im Sinne der strukturierten Analyse eigentlich ein System, das nicht nur aus einem Programm bestehen muß) hat aber auch eine Umgebung, aus der es Daten erhält und an die es Resultate ausgibt. Diese Systemumgebung wird durch Terminatoren beschrieben.
Bild 1 zeigt die Beschreibung einer Aufgabe auf oberster Ebene. Die Aufgabe besteht im hier gewählten Beispiel darin, Textdateien auf dem Bildschirm anzuzeigen — ähnlich, wie es der GEM-Desktop tut, wenn ein Dokument mit Doppelklick angewählt wird. Das heruntergeklappte Menü zeigt die eben genannten Grundelemente der strukturierten Analyse. Der Kreis in der Mitte zeigt den Prozeß »Anzeigen«, der über die Datenflüsse »Eingaben«, »Ausgaben« und »Dateien« mit der Umgebung verbunden ist. Dabei zeigt die Richtung der Pfeile die Richtung der Datenflüsse an. Die Umgebung besteht aus den Terminatoren »Eingabegeräte«, »Dateisystem« und »Bildschirm«, die durch Rechtecke dargestellt werden.
Einen Speicher, symbolisiert durch zwei parallele Striche finden Sie in Bild 4 dargestellt.
Eine solche Grafik kann man natürlich mit jedem Zeichenprogramm erzeugen. Doch beST CASE unterstützt das Erstellen gerade dieser Grafik. Es stellt die benötigten Grundelemente fertig zur Verfügung und erfragt bei der Plazierung eines Elements automatisch die nötigen zusätzlichen Angaben. Erzeugt man z.B. einen .Datenfluß, erscheint auch eine Dialogbox, die zur Eingabe des Namens und eines Kommentars auffordert. Das Programm weiß, welche Prozesse und Speicher durch die Datenflüsse verbunden werden. Verschiebt man beispielsweise einen Prozeß, so werden die Datenflüsse automatisch nachgezogen. Beschriftungen werden automatisch getrennt und in die Symbole eingepaßt, bei Datenflüssen lassen sie sich wahlfrei positionieren. Die Bedienung läßt sich unter GEM noch eleganter gestalten, aber sie ist insgesamt einfach und in ein paar Minuten gelernt. Für die Menüeinträge gibt es einprägsame Abkürzungen über die Tastatur. Dabei fällt auf, daß das Programm von einer amerikanischen Tastatur ausgeht — die Abkürzung Alternate-Y läßt sich auf der deutschen Tastatur nur mit Alternate-Z erreichen.
Doch die Grafik allein ist nicht alles — sie bietet die Übersicht und den Einstieg in textuelle Beschreibungen. Für jeden Prozeß entwickelt man entsprechend der Methode eine textuelle Beschreibung — die Prozeßspezifikation. Dazu ist das entsprechende Kommando und ein Prozeß zu wählen — daraufhin verschwindet die Grafik, und der Bildschirm wird weiß. Bye, bye GEM, man ist in einem einfachen Texteditor, der sich nach Druck auf die HELP-Taste selbst vorstellt, auf deutsche Sonderzeichen aber gar nicht reagiert. Ob mit GEM oder ohne ist bei Texteditoren vielleicht Geschmackssache, Fenstertechnik ist es in diesem Fall nicht. Es wäre doch praktisch, wenn sich die Grafik so in einem Fenster darstellen ließe, daß man den zu beschreibenden Prozeß und die ein- und ausgehenden Datenflüsse sehen könnte, während man in einem zweiten Fenster die Beschreibung dazu fertigt. Das Programm bietet Abhilfe mit der ESCAPE-Taste, durch die sich blitzschnell zwischen der Grafik und dem Text wechseln läßt.
Läßt man beST CASE aber einen anderen Texteditor — Tempus oder 1st Word z.B. — aufrufen, ist diese Möglichkeit natürlich dahin.
Doch wenden wir uns wieder der eigentlichen Analysearbeit zu: Nachdem das Programm mit seiner Umgebung skizziert ist, verfeinert man diese erste Darstellung. Ein Doppelklick auf den »Anzeiger-Prozeß eröffnet im Fenster eine neue, anfänglich leere Grafik. Auch hier keine Möglichkeit, die übergeordnete Grafik noch zu sehen, denn das Grafikfenster wird immer in voller Größe dargestellt. Nun wird für den »Anzeige«-Prozeß eine genaue Grafik — und damit eine detailliertere Beschreibung der Aufgabe — erstellt.
Diese Grafik enthielt im ersten Entwurf nur einen Speicher, nämlich den für die geladene »Datei«. Als dann die Prozesse »Datei laden und anzeigen« und »Anzeige beenden« beschrieben wurden, stellte sich heraus, daß »Anzeige beenden« den zuletzt benutzten Dateipfad benutzen sollte, um eine neue File-Select-Box zu öffnen. Also flugs einen Speicher »Aktueller Pfad« eingeführt, um diesen Sachverhalt wiederzugeben. Ähnlich ging es mit den »Daten für Textpositionierung«, allerdings hat man Speicher erst eingeführt, als die Prozesse nochmals in eigenen Grafiken verfeinert wurden. Das ist der Vorteil, den diese Analysemethode verspricht: Anforderungen an das Programm so genau zu spezifizieren, daß böse Überraschungen und umfangreiche Änderungen im Entwurf oder der Programmierung erspart bleiben.
Natürlich schlägt sich nicht jedes neue Detail in einer Änderung der Grafik nieder. Der Speicher »Daten für Textpositionierung« soll beispielsweise nicht nur vermerken, welcher Ausschnitt des Textes gerade sichtbar ist, sondern auch die Länge des gesamten Textes. Hier reicht ein Eintrag im Data Dictionary, dem Datenhandbuch, das automatisch durch die Eingabe der Datenflüsse erstellt wird und im Editor verändert werden kann.
Im Umgang mit dem Data Dictionary wird der gravierendste Nachteil des Analyseteils von beST CASE deutlich. Der Kommentar ist auf 54 Zeichen begrenzt — zu wenig für eine detaillierte Datenbeschreibung. Hier wurde ein Kompromiß mit der Schnelligkeit eingegangen, denn da Änderungen von Datenflußnamen sofort in die Grafik übertragen werden (und umgekehrt), wird das Data Dictionary immer im Hauptspeicher gehalten — deshalb wohl die Entscheidung, die Kommentare sehr knapp zu halten.
Professionelle Tools gehen hier weiter — sie erlauben, die Daten durch eine formale Syntax zu beschreiben, vergleichbar den »RECORD«-oder »struct-Anweisungen« in Pascal bzw. C. Der Vorteil dieses Vorgehens ist, daß das CASE-Tool dann prüfen kann, ob alle Datenflüsse eines Diagramms in seiner Verfeinerung auch berücksichtigt wurden, und daß keine neuen Daten auf wundersame Weise ins System gelangen.
Bleibt zum Schluß die Ausgabe der Analyse, denn auch bildschirmgewohnte Entwickler wollen gerne das Ergebnis ihrer Arbeit schwarz auf weiß sehen. Man kann alle oder ausgewählte Diagramme drucken oder als Snapshots auf Dateien ausgeben lassen; man kann die Prozeßspezifikationen und das Data Dictionary drucken. All das ist recht mager: Die Grafikausgabe nutzt nur die Möglichkeiten einfacher 9-Nadel-Drucker, Texte erscheinen nicht im Blocksatz, und das Ergebnis der Prüfung einzelner Diagramme läßt sich nur mühsam ausdrucken, da jede einzelne Prüfung ihre Ergebnisse unter demselben Dateinamen ablegt, und so das Ergebnis der vorherigen Prüfung überschreibt. Am gravierendsten ist, daß man kein zusammenhängendes Dokument erzeugen kann, das Grafiken, Texte und Prüfergebnisse in sinnvoller Ordnung enthält. Abhilfe bietet hier nur die Zusammenfassung von Texten und Snapshots mit 1st Word — eine mühsame Lösung.
Nachdem durch die Analyse geklärt wurde, was das Programm zu leisten hat, geht es im nächsten Schritt an den Entwurf. Hier kommt das zweite Programm von beST CASE, »Structured Design«, zum Zug.
Das Werkzeug unterstützt den strukturierten Entwurf mit ähnlichen Hilfsmitteln wie die Analyse. Wieder gibt es grafische Grundelemente und textuelle Beschreibungen. Doch die Fragestellung, die hinter einem Entwurf steht, ist ja eine andere, als bei der Analyse. Ging es dort um das »was«, geht es hier um das »wie«. Wie können die beschriebenen Leistungen am besten implementiert werden, welche Programmteile lassen sich sinnvoll in Modulen zusammenfassen, wie erhält man möglichst einfache Schnittstellen zwischen Modulen?
Entsprechend der unterschiedlichen Fragestellung sind auch die Darstellungsmittel anders. Die Grundelemente sind hier Module, Modulaufrufe, Daten, Schleifen und Verzweigungen.
Auf Anhieb werden jetzt sicherlich einige Leser an Datenflußdiagramme erinnert — doch weit gefehlt. Datenflußdiagramme werden von den Programmautoren in der Zeit der »GOTO-Programmierung« angesiedelt und als ungeeignete Beschreibung für strukturierten Programmaufbau betrachtet.
Der strukturierte Entwurf stellt Module und ihre Beziehungen untereinander in den Vordergrund. Es soll gezeigt werden, welches Modul welche anderen Module aufruft, und welche Daten dabei ausgetauscht werden. Die Beschreibung von Abläufen, Schleifen und Verzweigungen steht erst an zweiter Stelle und wird auch nicht so detailliert ausgeführt, wie dies bei Datenflußdiagrammen möglich ist.
Grafischer Editor und Texteditor lassen sich genauso bedienen, wie im Analyseprogramm. Die Grafiken können allerdings größer werden als der Bildschirm, so daß Scrollen nötig (und möglich) wird. Als schwerwiegender Nachteil stellte sich heraus, daß Teilbilder oder -bäume, also mehrere Module mit ihren Verbindungen untereinander, nicht aus einer Grafik herausgelöst und in eine andere Grafik eingesetzt werden können. Dadurch wird es sehr aufwendig, Umstrukturierungen vorzunehmen und Grafiken aus anderen Entwürfen können nicht wiederverwendet werden.
Die Prüfungen und Druckmöglichkeiten sind, wie im Analyseprogramm, zwar vorhanden, aber mager.
Jeder, der schon einmal mit einem CASE-Werkzeug gearbeitet hat, kennt die Gefahr, daß das endgültige Programm nur noch geringe Ähnlichkeit mit dem ursprünglichen Entwurf hat. Denn kein Entwurf ist perfekt; Implementierung, Test und Pflege führen immer wieder zu Änderungen. Doch auch hierfür hat CASE ein Zauberwort im Schatzkästlein: »Single Source« — nur eine Quelle (also nur eine Textdatei) für Entwurf und eigentlichen Programmcode.
beST CASE versucht dies zu unterstützen. Für die Modulspezifikationen sind die Dateinamen frei wählbar. Zusätzlich lassen sich beliebige Textdateien, z.B. Pascal »in-clude«-Dateien oder C-Headerfiles editieren und zusammen mit dem beST CASE-Entwurf ablegen. Schreibt man die Modulspezifikationen nun in der Syntax der Programmiersprache, erstellt man unter beST CASE letztlich seine Programme.
Um auch gleich übersetzen und binden zu können, erlaubt es beST CASE, entsprechende Kommandos zu speichern und über ein Menü abzurufen. So ist es theoretisch möglich, beST CASE während Implementierung und Test mit einer beliebigen Programmiersprache zu nutzen.
Wer sich ernsthaft mit Software-Entwicklung auseinandersetzen will, erhält mit Buch und Programm eine ideale Kombination, um sich lesend und probierend mit Software-Engineering auseinanderzusetzen und eigene Erfahrungen zu sammeln.
Für professionellen Einsatz fehlen beST CASE noch ein ausgefeiltes Data Dictionary, Modularisierung des Entwurfs und einige Komforteigenschaften, wie Fenstertechnik und umfassende Ausgabemöglichkeiten, (mb)
Wertung
Positiv:
+ Alle Elemente der Methode vorhanden
+ Guter Grafikeditor
+ Texteditor eigener Wahl verwendbar
+ Anschluß an beliebige Compiler
+ Integrierter Drucker-Spooler, auch für Grafik
+ Sehr gute und leicht verständliche Einführung in die Methodik
Negativ:
- Data Dictionary zu knapp
- Kein Unterschied zwischen Modulen und Prozeduren
- Kein Verschieben von Bildteilen zwischen verschiedenen Grafiken möglich
- Nur ein Fenster
- Editor ohne deutsche Zeichen
- Druckmöglichkeiten primitiv
Fazit:
Empfehlenswert zum praktischen Kennenlernen von Analyse- und Entwurfsmethoden. Für professionellen Einsatz noch nicht geeignet.
Klaus Liebenwald