CASE/SA - Ein Software-Entwicklungswerkzeug für den ATARI

„Software and cathedrals are much the same - first we build them, then we pray“ S. Redwine

CASE - Computer Aided Software Engineering - ist ein heute gar nicht mal mehr so neuer Begriff, der in der ATARI-Szene bisher jedoch keinen Eingang gefunden hat. Mit der vorliegenden Version 2.0 des CASE/SA-Tools der Firma Softwaretechnik U. Böhnke scheint sich dies nun zu ändern.

Bevor an dieser Stelle auf das genannte Programm eingegangen wird, erscheint es sinnvoll, den für die meisten Leser vermutlich unbekannten Begriff CASE und dessen Hintergründe zu erläutern. Außerdem wird noch kurz auf die Grundlagen von Structured Analysis (SA) eingegangen, da sie für das Verständnis der Arbeitsweise des CASE/SA-Tools wichtig sind.

CASE

Mit der zunehmenden Verbreitung und immer weiter steigenden Komplexität von Computerprogrammen für die unterschiedlichsten Zwecke nehmen die Kosten für Software-Projekte ständig zu; Software-Entwicklungsprojekte sprengen regelmäßig ihre Budgets, und Terminüberschreitungen sind an der Tagesordnung. Besonders teuer sind dabei die Auswirkungen von Qualitätsmängeln und Fehleranfälligkeit bei großen Projekten, die zu immens hohen Folgekosten führen.

Deshalb werden schon seit geraumer Zeit heute unter dem Begriff CASE zusammengefaßte Methoden und Software-Werkzeuge angeboten, die zahlreiche Möglichkeiten zur Abschwächung der Kosten und zur Verringerung der Entwicklungsrisiken bieten. Manchmal steht CASE auch als Abkürzung für „Computer Aided Systems Engineering“, was das ganze Umfeld etwas besser verständlich macht, denn mit „Software“ bzw. „Systems“ ist die Gesamtheit aller Objekte und Dokumente gemeint, die während des vollständigen Lebenszyklus’ eines Software-Produkts (siehe Abbildung 1) anfallen. Dazu gehören die Zielvorgaben, Programm- und Datenentwürfe ebenso wie Testprotokolle oder der Programmcode selbst. Damit steht CASE als Oberbegriff für alle Methoden und Werkzeuge, die eine ingenieurmäßige

Abbildung 1: Software-Life-Cycle

Nach [1] läßt sich CASE in vier Kategorien einteilen:

Unter „Upper CASE“ versteht man Hilfsmittel, die hauptsächlich für Systemanalytiker und Designer gedacht sind, da in den frühen Phasen des Lebenszyklus (Systemanalyse, Systementwurf, Software-Anforderungen und Software-Grobentwurf) nachweislich die schwerwiegendsten und kostspieligsten Fehler gemacht werden. Wenn man also den Gesamtprozeß der Software-Erstellung optimieren will, kann Werkzeugunterstützung hier die beste Wirkung erzielen.

Unter „Lower CASE“ werden Hilfsmittel für den Feinentwurf von Programmen, für die Codierung, das Testen, Debuggen und zum Umgang mit dem Quelltext und mit Programmiersprachen zusammengefaßt. Vieles davon gehört zum täglichen Handwerkszeug eines Entwicklers, wie zum Beispiel Editoren oder Compiler. In den letzten Jahren wurden jedoch auch diese Werkzeuge verbessert, um inhaltlich mehr Unterstützung zu geben (wie beispielsweise sprachsensitive Editoren, die Syntaxfehler sofort beim Editieren erkennen und sogar konstruktiv richtige Programmteile vorschlagen können, oder auch Struktogramm-Editoren, die aus einem eingegebenen Struktogramm fertigen Quelltext erzeugen).

Für Projektleiter, Qualitätssicherung, Manager u.a. stehen Werkzeuge des „projektbegleitenden CASE“ zur Verfügung. In dieses Gebiet fallen zum Beispiel Projektplanung, Projektkontrolle, Konfigurationsmanagement, Versionsverwaltung und Qualitätssicherungsmaßnahmen. Oftmals stehen diese Werkzeuge jedoch noch losgelöst oder unabhängig von Upper und Lower CASE da; gut integriert sind meistens nur Dokumentationswerkzeuge, die die Entwicklungsergebnisse aller Phasen und Tätigkeiten geordnet aufbereiten helfen.

In die letzte Kategorie „Reengineering-Werkzeuge“ fallen schließlich noch Werkzeuge, die nicht die Neuentwicklung von Systemen, sondern Modifikationen, Erweiterungen oder Neukonzeption von bereits vorhandenen Systemen bzw. Programmen unterstützen.

Abbildung 2: Ein Systemmodell der strukturierten Analyse

Structured Analysis

Structured Analysis bzw. Strukturierte Analyse (kurz: SA) ist eine Methode für die Analyse und Spezifikation fachlicher Anforderungen an ein Software-Projekt und als solche dem Bereich „Upper CASE“ zuzuordnen.

CASE/SA wählt wie viele andere Programme auch für die möglichst anschauliche Darstellung eines Projekts bzw. - allgemeiner ausgedrückt - eines Systems die Methode der Datenflußdiagramme aus. Da-tenflußdiagramme haben den Vorteil, daß sie auf einfache Weise vermitteln, welche Daten durch das System fließen, welche Prozesse bzw. Transformationen die Daten durchlaufen und welches die Ein- und Ausgaben dieser Prozesse sind. Dabei wird jedoch bewußt von der technischen Realisierung abstrahiert, um sich nicht auf eine bestimmte Hardware festlegen zu müssen oder von ihren Einschränkungen in vorgegebene Bahnen zwängen zu lassen.

Nach Tom DeMarco (siehe [21), worauf sich auch CASE/SA bezieht, besteht das logische Modell eines Systems aus drei Arten von Objekten, die hierarchisch und netzwerkartig miteinander verknüpft sind:

Die aus dem CASE/SA-Handbuch übernommene Abbildung 2 zeigt ein solches Systemmodell. Um die dort dargestellten Elemente verstehen zu können, nachfolgend nun einige kurze Erläuterungen.

Abbildung 3: Die Menüs von CASE/SA

Datenflußdiagramme

Unter einem Datenflußdiagramm versteht man nichts anderes als die grafische Darstellung eines Systems, das durch seine Elemente und deren Beziehungen untereinander beschrieben wird. Nach DeMarco gibt es vier solcher Elemente:

Für Dokumentationszwecke ist es sinnvoll, Diagramme so zu gestalten, daß sie auf einer DIN-A4-Seite abgebildet werden können. Außerdem kann ein Mensch nur relativ wenige Symbole (im allgemeinen nicht mehr als sieben) gleichzeitig erfassen, so daß man zur Darstellung von Datenflußdiagrammen ein hierarchisches System mit verschiedenen Ebenen benutzt. Die oberste Ebene wird dabei als Kontextdiagramm bezeichnet und enthält nur einen einzigen Prozeß, den „Superprozeß“. Dabei handelt es sich um das zu spezifizierende System und dessen Schnittstellen zur Außenwelt. Dieser Prozeß wird schrittweise im Top-Down-Verfahren zerlegt, und die so entstehenden Subsysteme werden wiederauf Ebenen angeordnet, bis eine weitere Zerlegung keinen Sinn mehr macht; als Beispiel kann hier Abbildung 2 dienen.

Spezifikationen

Eine Spezifikation (bei DeMarco als Mini-Spec bezeichnet) beschreibt üblicherweise in Pseudo-Code-Notation das interne Verhalten eines Prozesses. Falls komplexe Entscheidungsvorgänge formuliert werden müssen, werden jedoch mitunter auch Entscheidungstabellen oder -bäume eingesetzt.

In CASE/SA besteht jede Spezifikation aus drei Abschnitten: einem INPUT-, einem OUTPUT- und einem PROCESS-Block (siehe dazu wieder Abbildung 2).

Datenlexikon

Das Data Dictionary enthält Informationen über die Zusammensetzung der für das System relevanten Daten, wobei die Beschreibungen der Daten mit den zugehörigen Datenflüssen wie die Beschreibungen der Prozesse eine hierarchische Struktur aufweisen.

CASE/SA

Das CASE/SA-Tool der Firma Softwaretechnik Uwe Böhnke baut nun auf genau diesen Elementen auf und ermöglicht durch Darstellung und Auswertung von Datenflußdiagrammen die Analyse auch von komplexen Systemen.

Für 449,- DM (ATARI ST/TT-Version) bzw. 549,- DM (PC-Version) erhält man eine Diskette mit der notwendigen Software (Version 2.0) und ein dünnes, 42seitiges Handbuch. Außerdem ist noch zum Preis von 49,- DM eine Demoversion von CASE/SA erhältlich, die den gesamten Funktionsumfang der Vollversion enthält und nur in der Größe des Systemmodells eingeschränkt ist; die maximale Anzahl von Einträgen im Datenlexikon ist bei der Demoversion auf 36 festgelegt. Bei Kauf der Vollversion bekommt man den Preis der Demoversion voll angerechnet.

Das Handbuch

Das Handbuch stellt den ersten - und wie sich zeigen wird - auch den größten Kritikpunkt am ganzen System dar. Auf gerade einmal dreieinhalb Seiten erhält der Anwender eine Einführung in die Thematik der strukturierten Analyse und wird anschließend mit ein paar Literaturangaben alleingelassen. Gerade auf dem ATARI-Sektor, wo die Themen CASE und SA bisher keinen bzw. kaum Einzug gehalten haben, wäre es empfehlenswert, im Handbuch näher darauf einzugehen. So kommt der Anwender, der sich zum ersten Mal damit beschäftigt, nicht umhin, zusätzlich noch ein oder zwei Bücher zu kaufen, die den Kaufpreis nicht gerade unbeträchtlich in die Höhe treiben.

Der übrige Teil des Handbuchs ist nicht weniger kurz geraten. Auf 17 Seiten findet der interessierte Benutzer eine Bedienungsanleitung für das Programm, die sich jedoch auf die Erklärung der einzelnen Menü-Einträge und sonstigen Bedienungskomponenten in der Reihenfolge ihres Auftretens beschränkt. Nach einer Beschreibung der Vorgehensweise für die Erstellung und Analyse eigener Systemmodelle sucht man vergeblich.

Der Rest des Handbuchs besteht aus einigen Anhängen, die unter anderem recht ausführlich den Aufbau des Druckertreibers und das verwendete Dateiformat beschreiben.

Die Diskette enthält das 227 KByte lange Programm, einige Beispieldateien und diverse Druckertreiber für 9- und 24-Nadel-Drucker, für den HP-Deskjet und den HP-Laserjet.

Die Installation von CASE/SA verläuft völlig problemlos. Das Programm wird einfach von Diskette gestartet oder kann auch auf die Festplatte kopiert werden; ein Kopierschutz existiert nicht.

Abbildung 4: Ein Kontextdiagramm mit Elementbox und Pop-Up-Menü für einen Prozeß

Arbeitsweise

Nach dem Start des Programms findet man sich in einem leeren Desktop wieder, nur die in Abbildung 3 dargestellten Menüs stehen dem Anwender zur Verfügung. Unverständlicherweise sind alle Menüs und sonstigen Elemente der Oberfläche in Englisch gehalten; schließlich handelt es sich um ein deutsches Produkt. Außerdem sollte es eigentlich unter GEM kein Problem darstellen, unterschiedliche Resource-Dateien für verschiedene Sprachen zur Verfügung zu stellen. Außerdem zeigt beispielsweise Harlekin II, daß es auch anders geht.

Wie arbeitet man grundsätzlich mit CASE/SA? Was das Handbuch verschweigt, soll hier einmal kurz dargestellt werden, wobei gleichzeitig auch die einzelnen Programmteile näher beleuchtet werden.

Zunächst einmal muß man das oben bereits erwähnte Kontextdiagramm anlegen, das einen groben Überblick über das zu erstellende System bietet. Dazu wählt man im Menü „Edit“ den Eintrag „System Tree“ an, wodurch sich ein Fenster mit allen vorhandenen Einträgen des Systembaums öffnet.

Wird ein neues Modell angelegt, trägt dieses Fenster automatisch den Titel „Context Diagram“ und enthält nur die zwei Einträge „Create Data Flow Diagram“ und „Create Specification“. Durch Anwahl des ersteren öffnet sich ein weiteres Fenster, in dem man sich sein Datenflußdiagramm „zusammenbasteln“ kann. Dazu steht innerhalb des Fensters eine Element-Box zur Verfügung, die die oben aufgeführten Symbole für Datenflüsse, Prozesse, Speicher und Endknoten anbietet. Die Element-Box ist innerhalb des Fensters frei positionierbar und kann bei Bedarf auch geschlossen werden. Leider kann die Element-Box anschließend nur im Umweg über den Dialog „DFD-Editor“ wieder geöffnet werden. Außerdem ist die Element-Box durchsichtig, was oftmals zur Verwirrung Anlaß gibt, wenn sie zufällig über irgendwelchen Objekten liegt und diese dann durchscheinen. Besser wäre deshalb eine Element-Box, die, wie bei vielen anderen Programmen auch, in einer senkrechten Leiste am linken Fensterrand ständig zur Verfügung stünde. Abbildung 4 zeigt das Kontextdiagramm eines mitgelieferten Beispiels zusammen mit der Element-Box und dem Pop-Up-Menü für Prozeßbearbeitung.

Abbildung 5: Das Datenlexikon mit zwei Definitionen

Der DFD-Editor

Um ein Datenflußdiagramm (DFD) zu erstellen, muß man einfach mit der Maus ein Objekt aus der Element-Box anklicken und bei gedrückter Maustaste im Fenster positionieren. Dabei wird von CASE/SA gleichzeitig ein provisorischer Name für das Objekt vergeben, der sich anschließend jedoch problemlos ändern läßt. Datenflüsse lassen sich ebenso problemlos anlegen; nach dem Einfügen in das Datenflußdiagramm können die Anfangs- und Endpunkte der Pfeile einfach durch Anklicken und Ziehen mit der Maus positioniert werden. Alle Objekte können außerdem beliebig oft umpositioniert oder in der Größe verändert werden; beim Verschieben von Objekten bleiben die Datenflüsse dabei automatisch mit den einzelnen Objekten verknüpft. Auch das Löschen oder Ändern von Objekten und Datenflüssen ist jederzeit möglich. Ob ein Datenfluß plötzlich in die andere Richtung verlaufen oder ein Objekt nur einen anderen Namen bekommen soll, für alle Änderungen (soweit sie nicht das Verschieben betreffen) genügt einfach ein Doppelklick auf das betreffende Objekt. Daraufhin öffnet sich je nach Objekttyp ein entsprechendes Pop-Up-Menü, das dem Anwender alle Möglichkeiten zum Editieren des Objekts offeriert.

Ebenso existiert ein Pop-Up-Menü für Änderungen, die das gesamte Flußdiagramm betreffen. Es öffnet sich bei Doppelklick auf den Diagrammhintergrund. Hier kann man unter anderem auch einstellen, daß das gesamte Flußdiagramm verkleinert dargestellt werden soll, so daß es auch auf einem kleinen Monitor komplett sichtbar ist und nicht ständig gescrollt werden muß. Leider fehlt in der verkleinerten Darstellung die Beschriftung, was man jedoch nicht CASE/SA ankreiden kann, da dafür die Monitorauflösung einfach nicht ausreicht. Trotzdem kann man auch in der verkleinerten Darstellung alle Manipulationen am Datenflußdiagramm vornehmen, die sich in der normalgroßen Darstellung durchführen lassen.

Das Scrollen innerhalb eines Fensters erscheint verbesserungsbedürftig, da jedesmal der komplette Fensterinhalt neu gezeichnet, statt nur verschoben wird. Bei komplexen Diagrammen kann der Bildaufbau nach dem Anklicken des Scroll-Balkens im Fensterrahmen so schon einmal kurze Zeit dauern, bleibt jedoch noch in einem erträglichen Rahmen.

Wie bereits erwähnt, besteht ein Datenflußdiagramm üblicherweise aus verschiedenen Ebenen, die im Top-Down-Entwurf, ausgehend vom Kontextdiagramm, ständig verfeinert werden. Um zwischen diesen Ebenen wechseln zu können, reicht es bei CASE/SA aus, einfach in das entsprechende (offene) Fenster zu klicken. Möchte man zu einem Prozeß einen Unterprozeß, bei CASE/SA als „Child DFD“ bezeichnet, anlegen, klickt man den entsprechenden Prozeß an und wählt im erscheinenden Pop-Up-Menü den Eintrag „Create Child DFD“ an, wodurch sich ein neues Fenster öffnet, in dem alle ein- und ausfließenden Datenflüsse bereits eingetragen sind. So müssen nur noch die einzelnen Unterprozesse angelegt und die Datenflüsse entsprechend konfiguriert werden; durch die automatische Übernahme der Datenflüsse wird die Konsistenz zwischen den einzelnen Ebenen gewährleistet. Zurück zum Elternprozeß gelangt man durch Auswahl des Eintrags „Edit Parent DFD“ im Pop-Up-Menü des gesamten Diagramms.

Zusätzlich zu den bisher erwähnten Möglichkeiten des DFD-Editors stehen auch noch eine Anzahl weiterer Editiermöglichkeiten wie das Löschen und Verbinden von DFDs oder Cross-Referenz zur Verfügung. Darauf soll an dieser Stelle jedoch nicht weiter eingegangen werden, da die Bedienung im Prinzip immer gleich ist; alle Möglichkeiten werden nach einem Doppelklick mit der Maus in einem Pop-Up-Menü zur Auswahl angeboten.

Der Spezifikationseditor

Nachdem man mit Hilfe des DFD-Editors die groben Datenflüsse und Prozesse definiert hat, müssen für alle Prozesse durch Spezifikationen noch solche Details festgelegt werden, die in der grafischen Darstellung bewußt vernachlässigt werden. Es handelt sich dabei insbesondere um Regeln, wie die Eingangsdaten in die Ausgangsdaten transformiert werden müssen, ohne dabei jedoch näher auf die Implementation der Regeln einzugehen.

Dazu bietet CASE/SA einen besonderen Spezifikationseditor an, der ebenfalls über die bereits bekannten Pop-Up-Menüs erreichbar ist. Bei Anlegen einer Spezifikation nimmt CASE/SA dem Anwender dabei einen Teil der Arbeit ab, indem die durch das Datenflußdiagramm bereits definierten Datenflüsse automatisch in die Spezifikation eingetragen werden. Alle weiteren Angaben wie die Beschreibung der Datentransformation müssen jedoch (natürlich) vom Anwender selbst vorgenommen werden; die Art und Weise der Beschreibung bleibt dabei dem Anwender selbst überlassen. Vorgegeben wird lediglich die Struktur der Spezifikation, die aus einem INPUT-, einem OUTPUT- und einem PROCESS-Block besteht (siehe dazu auch Abbildung 6).

Abbildung 6: Eine Spezifikation mit einem Pop-Up-Menü

Der Spezifikationseditor läuft zwar komplett in einem Fenster, ist ansonsten jedoch leider nicht sonderlich komfortabel zu bedienen. Im Gegensatz zum Rest des Programms wurde hier von der GEM-Philosophie der Mausbedienung abgewichen; das Editieren wie Löschen, Einfügen oder Kopieren von Zeilen ist nur über bestimmte Kommandos (insgesamt 16) möglich, die am Anfang einer Zeile eingegeben und anschließend über CONTROL + RETURN ausgeführt werden müssen. Wenn man diese Kommandos beherrscht, ist der Editor zwar problemlos zu bedienen, eine Überarbeitung zur Mausbedienung wäre jedoch sehr angebracht.

Das Data Dictionary

Der gleiche Editor - mit einer anderen Eingabestruktur - wird auch benutzt, um Einträge im Datenlexikon vorzunehmen oder zu ändern. Das Datenlexikon sollte alle Namen und Bezeichnungen enthalten, die im Systemmodell verwendet werden, damit gewährleistet ist, daß die Namen ausschließlich in ihrer eindeutigen Form verwendet werden. Einmal vorgenommene Einträge können beliebig oft im Systemmodell verwendet werden, weshalb sie auch von jedem Objekt aus über die bekannten Pop-Up-Menüs erreichbar sind. Für die Kontrolle der Eintragungen im Data Dictionary steht eine Cross-Referenz-Funktion zur Verfügung, die das gesamte Systemmodell durchsucht und anschließend Art und Ort der Verwendung der Namen auflistet und in einem Fenster darstellt. Ein Beispiel für ein Datenlexikon ist mit zwei Einträgen in Abbildung 5 dargestellt.

Analysefunktionen

Wie der Name „Strukturierte Analyse“ schon sagt, liegt der Schwerpunkt von SA auf der Analyse eines zuvor erstellten Systemmodells. CASE/SA bietet dazu insgesamt drei Analysefunktionen an: die Datenflußdiagramm-, Spezifikationen-und Datenlexikon-Analyse. Bei Ausführung einer der Analysen stellt man zunächst einmal fest, daß deren Ergebnisse scheinbar auf Nimmerwiedersehen in den Tiefen des Rechners verschwinden. Erst nach Anwahl eines der drei Einträge aus dem Menü „View“ wird das korrespondierende Analyseergebnis auf dem Bildschirm in einem Fenster sichtbar gemacht; eine automatische Darstellung am Ende der Analyse wäre erwägenswert. Die Ergebnisse der Analysen des mitgelieferten Beispiels zeigt Abbildung 7.

Abbildung 7: Die verschiedenen Analyseergebnisse

Laut Handbuch werden bei der Analyse des Systemmodells folgende Einzelprüfungen durchgeführt:

Analyse der Datenflußdiagramme

Bei Anwahl des entsprechenden Menü-Eintrags werden automatisch alle im Systemmodell vorhandenen Datenflußdiagramme geprüft; für jedes DFD werden dabei die Einzelprüfungen „Connection“, „Connectivity“ und „Balancing“ durchgeführt. Die Connection- und Connectivity-Prüfungen sind dabei verhältnismäßig einfach; während bei der Connection-Prüfung festgestellt wird, ob jedes Diagramm mit Ausnahme des Kontextdiagramms mit einem Prozeß verbunden ist, wird bei der Connectivity-Prüfung getestet, ob jedes Diagramm mindestens einen Prozeß enthält und ob alle Elemente auch durch Datenflüsse miteinander verbunden sind.

Das Balancing gestaltet sich schon wesentlich komplexer. Hier muß bei der Verbindung eines Prozesses mit einem übergeordneten Flußdiagramm geprüft werden, ob die Datenflüsse zwischen über und untergeordneten Flußdiagrammen konsistent sind. Bei einer solchen Balancing-Prüfung müssen zwei Regeln eingehalten sein. Zum einen muß jeder Datenfluß, der mit dem übergeordneten Prozeß verbunden ist, im tieferliegenden Flußdiagramm ein offener ein- bzw. ausgehender Datenfluß sein, wobei Name und Richtung des Datenflusses natürlich übereinstimmen müssen. Zum anderen dürfen im tieferliegenden Diagramm keine zusätzlichen offenen Datenflüsse existieren, die nicht auch mit dem übergeordneten Prozeß verbunden sind.

Bei der Überprüfung des Balancings wird das Konzept der „Parallel Decomposition of Data and Function“ angewendet. Findet CASE/SA nämlich Datenflüsse des übergeordneten Prozesses nicht im tieferliegenden Datenflußdiagramm, versucht es mit Hilfe der Definitionen im Data Dictionary die Komponenten dieser Datenflüsse im untergeordneten Datenflußdiagramm aufzufinden.

Außerdem werden noch verschiedene grundlegende Regeln für Datenflußdiagramme überprüft. So muß jeder Datenfluß mit mindestens einem Prozeß verbunden sein. Weiterhin sind Datenflüsse zwischen Speicher und Speicher, Endknoten und Endknoten oder Speicher und Endknoten nicht erlaubt. Jeder Prozeß muß mindestens einen eingehenden und einen ausgehenden Datenfluß haben; nur für Speicher und Endknoten ist ein einseitiger Datenfluß zulässig.

Für das Kontextdiagramm gelten noch weitere Regeln. Hier sind keine offenen Datenflüsse erlaubt. Jedes Kontextdiagramm muß außerdem mindestens einen nur in Kontextdiagrammen zulässigen Endknoten enthalten. Deshalb wäre es sinn-voll, wenn die Elementbox Endknoten auch nur im Kontextdiagramm zulassen würde, was zur Zeit nicht der Fall ist. Nichts hindert den Anwender daran, Endknoten auch in anderen DFDs einzubauen; erst die Analyse zeigt, daß hier ein Fehler vorliegt.

Analyse der Spezifikationen

Hier werden automatisch alle im Systemmodell vorhandenen Spezifikationen durch drei verschiedene Prüfungen analysiert. Bei der „Connection“-Prüfung wird getestet, ob jede Spezifikation auch mit einem Prozeß verbunden ist.

Beim „Balancing“ müssen die Namen der Datenflüsse im INPUT- und OUTPUT-Block der Spezifikation mit den entsprechenden Datenflüssen des zugehörigen Prozesses übereinstimmen.

Schließlich wird noch Analyse der„Processdescription“ durchgeführt. Dabei wird überprüft, ob in der Prozeßbeschreibung nur Datenflüsse verwendet werden, die auch Eingabe oder Ausgabe für diesen Prozeß sind. Andererseits muß von jedem ein- oder ausgehenden Datenfluß mindestens eine Komponente in der Prozeßbeschreibung benutzt werden.

Analyse des Datenlexikons

Die dritte und letzte Analyse ist im Vergleich mit den anderen beiden Analysen sehr einfach. Hier wird die Anzahl der definierten und Undefinierten Einträge im Data Dictionary ermittelt. Für jeden Eintrag wird dabei lediglich festgestellt, ob er im Systemmodell verwendet wird oder nicht.

Der ganze Rest

Hat man nun mit viel Mühe ein eigenes Systemmodell erstellt, und es wurde von den Analysefunktionen sogar als korrekt ermittelt (oder auch nicht), kann man das gesamte Modell natürlich auch abspeichern und/oder ausdrucken. Zum Abspeichern bzw. Einladen verwendet CASE/ SA ein ausführlich dokumentiertes ASCII-Dateiformat, was zwar vorteilhaft für den Datenaustausch mit anderen Programmen ist, ansonsten das Laden und Speichern, insbesondere bei großen Systemmodellen, aber sehr langsam macht. Besser wäre vielleicht, das ASCII-Format nur als Import- und Exportmöglichkeit anzubieten und für die eigene Verwaltung ein normales und somit schnelleres Dateiformat zu verwenden. Dafür spricht auch, daß es bisher kein Programm gibt, daß die ausgegebenen Daten in irgendeiner Form weiterverarbeiten könnte. Zum Drucken ist noch zu sagen, daß alle Teile des Systemmodells, also auch die Analysen, Spezifikationen und das Datenlexikon, ausgedruckt werden können; die entsprechenden Funktionen werden in den jeweiligen Pop-Up-Menüs angeboten.

Als für GEM-Programme unüblich, erweist sich das Vorgehen von CASE/SA, den „Quit“-Eintrag im „File“-Menü zu disablen, solange sich ein Systemmodell im Speicher befindet. Erst nach Löschen oder Abspeichern (inklusive Löschen) des Systemmodells ist das Verlassen des Programms möglich. Diese Vorgehensweise ist, wie bereits erwähnt, äußerst unüblich und zumindest für den Anfänger ziemlich verwirrend; ein Programm sollte man immer und jederzeit - nach einer Sicherheitsabfrage und einem eventuellen automatischen Speichern - verlassen können. Weiterhin schreibt CASE/SA bei Verlassen des Programms seltsamerweise „STOP“ auf den Bildschirm, ohne daß sich das verhindern ließe.

Fazit

Trotz einiger kleiner Mängel bei der Bedienung des Programms und dem zu kurz geratenen Handbuch kann man CASE/SA grundsätzlich empfehlen. Bei dem Test haben sich keinerlei Fehler bemerkbar gemacht, von Abstürzen ganz zu schweigen. Es handelt sich bei CASE/SA um ein ausgereiftes Produkt, worauf u.a. auch die Versionsnummer 2.0 hinweist. Da es zusätzlich noch das vermutlich einzige Werkzeug dieser Art für den ATARI darstellt, kommt man auf diesem Rechner sowieso nicht darum herum - sofern man sich damit beschäftigen möchte, versteht sich. Wen der relativ hohe Preis von 449,- DM abschreckt, dem sei gesagt, daß man im PC-Bereich für durchgängige CASE-Anwendungen von der Anforderungsanalyse bis hin zum Reengineering ohne weiteres 20.000 bis 30.000 DM bezahlen kann (oder auch muß).

Das einzige größere Manko von CASE/ SA liegt in der Tatsache begründet, daß es sich um ein alleinstehendes Produkt handelt. Für weitere CASE-Stufen wie die automatische Quellcode-Erzeugung oder Struktogrammeditoren, die auf den mit CASE/SA erzeugten Daten aufsetzen, gibt es zumindest auf dem ATARI-Sektor keine weiteren Anwendungen. Diese Tatsache kann man aber schwerlich CASE/SA zuschreiben; es stellt immerhin den ersten Schritt in die Richtung des Computer Aided Software Engineering dar und ist somit auf jeden Fall zu begrüßen.

Uwe Hox

Literatur:

[1] Peter Hruschka (Hrsg.), CASE in der Anwendung, Hanser Verlag 1991

[2] Tom De Marco, Structured Analysis and System Specification, New York, Yourdon Press 1978

Bezugsquelle:
Softwaretechnik Dipl.-Ing. U. Böhnke Tengstr. 43 D-8000 München 40


Aus: ST-Computer 07 / 1992, Seite 64
Links
Copyright-Bestimmungen: siehe Über diese Seite