"Mehr Produktivität" und "Verbesserung der Qualität" - auf diesen gemeinsamen Nenner läßt sich das Anforderungsprofil an ein SW-Entwicklungs-Tool bringen. Möglicherweise wird jedoch die Kreativität des Entwicklers durch vorgefertigte Werkzeuge eingeschränkt. Hans Ruef* skizziert einen Weg aus diesem Dilemma.
Ziel des Tool-Einsatzes bei der Software-Erstellung ist es, die Produktivität der Entwickler zu steigern und die Qualität der Systeme zu verbessern (Zuverlässigkeit, Wartbarkeit, Anpaßbarkeit). Um diesen Anforderungen zu genügen, muß ein Werkzeug alle Phasen des Produktionsprozesses durchgängig unterstützen. Diese These ist anerkannt und gilt als Hauptgrund für die Verwendung von Tools bei der Software-Produktion.
Schichtenmodell als Systemrahmen
Auf den ersten Blick scheinen jedoch die meisten Entwickler gar kein Interesse an solchen Effekten zu haben: Schließlich müssen sie zusätzliche Qualifikationen erwerben, nur um Software zu konstruieren, die weniger individuell ist und deren Pflege nicht mehr vom Autor abhängt.
Doch der Einsatz sinnvoller Werkzeuge kann durchaus den Bedürfnissen des Softwerkers nach kreativer, fachlich anspruchsvoller Arbeit Rechnung tragen. Und es ist keineswegs erforderlich, ihn in ein bürokratisches Korsett von Vorschriften und Bildschirmformularen zu zwängen. Dies soll im folgenden an einem Beispiel gezeigt werden.
Ein Schichtenmodell bildet den Rahmen für die Zerlegung eines Systems in Komponenten und Module. Jede Komponente besteht aus beliebig vielen Modulen; diese werden durch drei Schichten dargestellt, um ihre Aufgabe innerhalb der Komponente zu charakterisieren: Unten liegt eine lokale Dienstleistungsebene, oben die Steuerschicht und dazwischen sind die Aktivitäten angesiedelt. In der Steuerebene befinden sich diejenigen Module oder Hauptprogramme, die die Schnittstelle zur Umgebung der Komponente bilden.
Dieses Schichtenmodell fungiert als Systemrahmen in der Entwicklungsumgebung und wird in Top-down-Richtung ausgearbeitet. Auch die Modulstruktur ist vorgegeben; es besteht die Möglichkeit, sie schrittweise auszufüllen. Im Modul befindet sich die Schnittstelle, die angibt, welche Prozeduren und Parameter externe Aufrufer des Moduls bekommen sollen - und zwar separiert von der Modul-internen Realisierung.
Wichtigstes Konzept innerhalb der Standardstruktur eines Moduls ist die Behandlung der Ausnahmefälle, die mit Bezeichner und zugehörigem Meldungstext deklariert werden. Die Meldungstexte sind in einer zentralen Datei der Produktionsumgebung gespeichert und damit ohne Eingriffe in den Quellcode abänderbar.
Im Rumpf des Moduls läßt sich mit Hilfe von Makroanweisungen angeben, wann diese Ausnahmefälle zu melden sind. Ist nicht explizit eine Ausnahmebehandlung festgelegt, so generiert das System automatisch eine Standardreaktion, die den Programmlauf im Fehlerfall mit einer aussagekräftigen Meldung abbricht. Danach können die Programmierer schrittweise eine verbesserte Fehlerbehandlung ohne Abbruch einführen.
Der Code-Generator expandiert die Makroanweisungen und erzeugt zusammen mit dem auf der untersten Baumebene eingegebenen freien Quellcode einen vollständigen und strukturierten Quellfile. Durch Optionen spezifiziert man, wieviel Information aus dem Entwurfsbaum in den Quellcode übernommen werden soll, um einen leicht verständlichen Code zu bekommen. Soweit vorhanden, läßt sich zusätzlich ein Generator für den Maskenentwurf in die Produktionsumgebung einbeziehen.
Klare Systemstruktur wird gewährleistet
Aus der Schnittstellenspezifikation wird ein Testrahmen für den Einzeltest des Moduls erzeugt. Bei Änderungen des Interface paßt sich somit die Testumgebung automatisch den neuen Gegebenheiten an.
Ein solches Konzept der Produktionsumgebung verbessert die Qualität der Software in zahlreichen Punkten: So ist beispielsweise eine klare Systemstruktur gewährleistet. Denn dem Anwender wird ein leicht erlernbarer "Rahmen" als Grundlage vorgegeben. Dies entspricht anerkannten Prinzipien des Software-Engineering.
Auch besteht eine deutliche Trennung der Spezifikation von Modulen und ihrer Realisierung. Zuerst wird nämlich nur die Schnittstelle spezifiziert. Dieser Teil steht allen hierarchisch höherliegenden Modulen zur Verfügung. Der interne Code des Moduls ist hingegen allen anderen Modulen verborgen. Die Realisierung erfolgt in einem zweiten, deutlich abgetrennten Entwicklungs-schritt. So wirken sich Änderungen im Inneren des Moduls nicht störend auf das gesamte System aus. Solange ein Modul noch nicht realisiert ist, kann es mit einem Teststumpf "simuliert" werden.
Ein weiterer Pluspunkt ist die einheitliche Ausnahmebehand-lung. Fehler und andere Ausnahmefälle werden über Makro-Anweisungen so codiert, daß sie durch die Hierarchie von Aufrufen weitergemeldet werden, bis eine sinnvolle Reaktion auf den Fehlerzustand erfolgen kann. Unbekannte Fehler meldet das System immer mit Angabe der Herkunft, bevor ein Programmabbruch erfolgt. Somit werden Ausnahmen bereits beim Entwurf berücksichtigt und nicht nachträglich eingebaut, was für gewöhnlich zu unüber-sichtlichen Strukturen führt. Als vorteilhaft erweist sich schließlich auch die Generierung von strukturiertem Quellcode mit Kommentaren. Das heißt, Programmlisten werden struktogrammähnlich eingerückt und mit senkrechten Blockgrenzen versehen. Im wählbaren Umfang läßt sich der Text aus der Entwurfsphase einblenden, und zwar entweder als Kommentar oder in gesonderten Dokumenten.
Generell fördert die Verwendung eines Tools eindeutige Aussagen bei schwierigen Entwurfsentscheidungen. Der Arbeitsfort-schritt und die gewählte Lösung sind für alle beteiligten Mitarbeiter transparent und auch nachprüfbar. Um die syntaktische Korrektheit eines Dokuments zu gewährleisten, werden die entsprechenden Prüfungen sinnvollerweise direkt interaktiv durchgeführt.
Eine Produktivitätssteigerung manifestiert sich natürlich erst nach der Einarbeitung jedes einzelnen Mitarbeiters und auch des gesamten Teams. Erfahrungsgemäß kann diese Ausbildung durchaus einige Wochen in Anspruch nehmen; außerdem hängt sie von den individuellen Vorkenntnissen der Betroffenen ab sowie von ihrer Einstellung zu Standardisierung und Teamarbeit.
Im Idealfall sollten die führenden Teammitglieder vor dem eigentlichen Projektbeginn zwei Wochen Zeit haben, um die Arbeitsweise der Produktionsumgebung kennenzulernen und die projektspezifische Nutzung vorzubereiten. Von einer solchen Vorgehensweise kann der Rest des Teams nur profitieren. Nach einer solchen Anfangsphase ist eine Reihe von positiven Einflüssen auf die Produktivität festzustellen: Codegenerierung spart Schreib-arbeit. Dies gilt insbesondere für Cobol und Assemblersprachen. Mit Hilfe der Produktionsumgebung wird deshalb ein Quellcode generiert, der durch seine Formatierung und die eingefügten Entwurfstexte gut verständlich ist.
Ferner bekommen die Programme mehr Transparenz. Die stan-dardisierte Systemstruktur und der generierte Quellcode machen es leicht, fremde Programme zu überprüfen und kleine Fehler selbst zu beseitigen. Auf höherer Ebene wiederum ist es möglich, halbfertige Arbeiten anderen Bearbeitern zu übergeben, weil der Projekt-standard allzu "persönliche" Entwürfe erfolgreich verhütet.
Eine solche Entwurfstechnik verhindert Fehler. Durch frühzeitige Spezifikation der Modulschnittstellen können alle Benutzer des Moduls Änderunyswünsche anmelden, bevor die unbrauchbare Version codiert und getestet ist. Das Modulkonzept bewirkt ferner, daß deutlich zwischen lokalen und globalen Daten getrennt wird und direkte Zugriffe auf Daten in benachbarten Modulen ausgeschlossen sind.
Für jedes Modul gibt es einen Testrahmen. Aus der Schnitt-stellendeklaration des Moduls wird ein Testprogramm generiert, das im Dialog die Prozedurparameter vor und nach dem Testlauf anzeigt oder ändert. Der Testlauf kann in Verbindung mit einem symbolischen Debugger des Betriebssystems auch schrittweise erfolgen.
Und schließlich kommt es auch auf die Flexibilität der Produktionsumgebung an. Sie macht Änderungen in der Codegenerierung oder in den erzeugten Dokumenten möglich und einfach. Ein Tool, das gemäß einem solchen Konzept arbeitet, ist somit offen für künftige Anpassungen und für die Erschließung neuer Einsatzgebiete.
--------------
*Hans Ruef ist Mitarbeiter bei der PSI Geschäftsstelle Aschaffenburg.