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.01.1988 - 

Software-Entwicklung ähnelt industriellen Fertigungsprozessen:

Für komplexe Projekte sind flexible Tools notwendig

Vielschichtige Software-Projekte können nicht mit eindimensionalen Methoden realisiert werden. Differenziertes Vorgehen erfordert aber den Einsatz unterschiedlicher Sprachen und Werkzeuge, beziehungsweise verlangt den Tools eine Flexibilität ab, über die sie erst ansatzweise verfügen. Ein Vergleich von Software Entwicklung und industrieller Fertigung macht Schwachstellen und Verbesserungsmöglichkeiten deutlich.

Software-Entwicklung läßt sich von mehreren verschiedenen Standpunkten aus betrachten. Mit Sicherheit handelt es sich dabei um eine soziale Aktivität; Entwickler, Kunden und Anwender der Software treten dabei in eine Beziehung, die sowohl durch Konflikt als auch durch Kooperation gekennzeichnet ist. Daneben ist Software-Entwicklung ein Zweig der Mathematik: Die hergestellten Programmtexte können als mathematische Objekte gelten; sie benötigen eine axiomatische Basis, auf der die für ihre korrekte Konstruktion erforderlichen Theoreme, Hilfssätze und Beweise aufbauen.

Ebenso ist Software-Entwicklung aber auch ein Teilbereich - oder vielleicht eine ganze Gruppe von Bereichen - der Ingenieurwissenschaften. Erfahrene Software-Entwickler wenden dabei bewährte praktische Techniken an, deren theoretische Grundlage möglicherweise in Vergessenheit geraten ist oder niemals von ausgebildet wurde.

Außerdem kann man sich die Software-Entwicklung auch als einen Fertigungsprozeß vorstellen; die Entwicklungsabteilung ähnelt dann einem Akkordarbeiter im Maschinenbau-Unternehmen. Der Vergleich mit einem Automobil-Betrieb hinkt allerdings:

Dort wird nämlich ein in den Grundzügen immer gleiches Produkt in großen Stückzahlen ständig aufs neue hergestellt. Ein Software-Projekt hingegen fällt jedesmals so verschieden aus, daß die Entwickler das Gefühl haben, ein einzigartiges neues Produkt herzustellen. Dieser Aspekt der Software-Entwicklung, nämlich ihre Darstellung als quasi-industrielle Fertigung, steht im Mittelpunkt der folgenden Betrachtung.

Wenn die Entwicklung eines Software-Projekts abgeschlossen ist, so gibt es zunächst einige ausführbare Programmtexte, dann ein paar Betriebssystembefehle, vielleicht die interpretierbare Definition einer Datenbankstruktur oder eine Handvoll Dateien mit veränderlichen Parametern für die Programmausführung.

Darüber hinaus ist irgendeine Art von Benutzerhandbuch und eine Einführung in den Umgang mit der Software vorhanden. Schon während des Entwicklungsprozesses existierten möglicherweise ein Pflichtenheft sowie Spezifikationen für die verschiedenen Aspekte und Teilbereiche der Software und ihrer Umgebung, ferner vielleicht Beschreibungen der zugrunde liegenden Sachverhalte sowie eine Menge anderer Dokumentations-Teilstücke.

Jedes Statement läßt sich als Beschreibung auffassen

Alle diese Komponenten können mit Recht als "Beschreibungen" bezeichnet werden: Ein Programmtext in "C", "Ada", "Pascal" oder "Cobol" ist die Beschreibung der auszuführenden Rechneroperation; bei einem Datenmodell handelt es sich um die Beschreibung der Daten, mit denen die Programme arbeiten sollen, und um die Beschreibung der Realität, die das System abbildet.

Das Benutzerhandbuch enthält Beschreibungen des Menüs, das dem User angeboten wird, und der erlaubten Übergänge von einem Menü zu einem anderen; das Pflichtenheft umfaßt eine Beschreibung der Datenbankumfänge und der Antwortzeiten für verschiedene Funktionen. Die Spezifikationen setzen sich aus den Beschreibungen der Ausgabedokumente und der Bildschirmoufbauten zusammen, die das System hervorbringt.

Möglicherweise wirkt der Ausdruck "Beschreibung" etwas befremdlich: Er wird hier auf alles angewandt, was während der gesamten Entwicklungsarbeit entsteht - egal, ob in verbaler oder grafischer Form, ob es auf Papier oder auf magnetischen Speichermedien festgehalten oder auch nur auf dem Bildschirm ausgegeben wird. Selbstverständlich können einige der genannten Statements unter Umständen auch als "Befehle" an den Rechner oder das Entwicklungs-Team bezeichnet werden; andere lassen sich als "Warnungen", als dringende Aufforderungen oder als "Regeln" betrachten.

Aber der einheitliche Terminus "Beschreibung" hat zweierlei Vorteile: Zum einen ermöglicht er die Auseinandersetzung mit einer Reihe von grundsätzlichen Betrachtungen, die alles betreffen, was bei der Entwicklungsarbeit entsteht. Zum anderen ist es didaktisch wertvoll, jedes Statement, das dieser Prozeß hervorbringt, unter dem Aspekt zu sehen, daß es etwas beschreibt: einen speziellen Gesichtspunkt oder Bereich der Software beziehungsweise ihres Zwecks, ihrer Wirkung, ihres Verhaltens, ihrer Umgebung oder des Projektablaufs, in dessen Rahmen sie produziert wird.

Software-Entwicklung ist also die Herstellung von Beschreibungen. Wer ein fertiggestelltes Projekt ansieht, kann seine Geschichte zurückverfolgen, indem er feststellt, welche Beschreibungen in welcher Reihenfolge entstanden sind und wie sich jede Beschreibung aus vorhandener oder aus neuer Information ableiten läßt. Die Aktivitäten während des Fertigungsprozesses dienen dazu, neue Beschreibungen hervorzubringen. Und dieser Prozeß wird fortgesetzt, bis genügend korrekte Beschreibungen entstanden sind, um den Ansprüchen des Kunden gerecht zu werden.

Der Computer wird dabei - soweit möglich - als Werkzeug für die Erstellung von Beschreibungen genutzt: Einige Fertigungsschritte, zum Beispiel die Übersetzung eines Quellprogrammtextes in ein Objektprogramm, sind von automatisierbar; andere, wie die Herstellung einer vollständig neuen Beschreibung auf der Grundlage aktueller Information, nutzen den Rechner lediglich als Handwerkszeug, das bei der Ausarbeitung der Beschreibung hilft. Außerdem gibt es auch solche Tätigkeiten, die teils automatisch, teils manuell ausgeführt werden.

Der Rohstoff für die Beschreibungen sind die Sprachen. Der Ausdruck "Sprache" ist dabei in einem ebenso umfassenden Sinn zu gebrauchen wie der Begriff "Beschreibung". Einige Beschreibungen entstehen aus Programmiersprachen; andere können beispielsweise von einer natürlichsprachlichen Basis ausgehen Wieder andere fußen auf einer Datenmodellsprache, auf Maschinen-Code oder einer logischen Sprache wie den Horn-Klauseln beziehungsweise irgendeiner anderen nützlichen mathematischen Darstellungsweise. Strukturdiagramme können ebenfalls so aufgefaßt werden, daß sie aus einer Diagramm-Sprache zusammengesetzt sind.

Eine Analogie zwischen den Ausgangsmaterialien für Maschinenteile wie bei der Automobilproduktion und dem Rohstoff für die Beschreibungen der Software-Entwicklung ist durchaus zulässig. Autohersteller wissen, daß sie für die Einzelteile den Jeweils richtigen Werkstoff verwenden müssen: Die Fenster werden aus Glas gemacht, nicht etwa aus Stahl oder Gummi; die Speichen hingegen stellt man zweckmäßigerweise aus Stahl statt aus Glas oder Plastik her; für das Chassis wiederum wird Blech verwandt. Genauso muß auch ein Software-Entwickler das richtige Material, die richtige Sprache, für die jeweilige Beschreibung einsetzen.

Die beiden wichtigsten Kriterien bei der Auswahl einer Beschreibungssprache sind: Sie muß verständlich sein, und sie muß verarbeitet werden können. Verständlich ist eine Beschreibung dann, wenn sie ihre Bedeutung direkt und unmißverständlich an den menschlichen Empfänger weitergibt; verarbeitet werden kann sie, wenn ein Computer sie ohne weiteres in neue Beschreibungen umzuwandeln vermag.

Auf einige Beschreibungen kann nur eines dieser Kriterien angewandt werden: Eine erste Beschreibung der Systemauslegung sollte beispielsweise mit Sicherheit verständlich, kann und muß aber für gewöhnlich nicht verarbeitbar sein. Die Zwischendarstellung bei der Syntax-Analyse eines Compilers hingegen braucht keineswegs verständlich zu sein, muß aber unbedingt verarbeitet werden können.

Innerhalb derjenigen Entwicklungsphasen, die gemeinhin "Anforderungsanalyse", "Spezifikation" oder "Entwurf" genannt werden, sollten die Beschreibungen immer verständlich ausfallen; um so besser, wenn sie auch noch verarbeitet werden können, so daß sie für mechanische Ableitungen oder wenigstens Überprüfungen von anderen Beschreibungen einsetzbar sind.

Wegen der zur Zeit noch recht primitiven Entwicklungswerkzeuge treten die beiden Kriterien Verständlichkeit und Verarbeitungsfähigkeit unglücklicherweise oft in Konflikt miteinander. Grob vereinfacht können der formale und der formlose Entwicklungsansatz folgendermaßen unterschieden werden: Beim formalen Ansatz ist alles verarbeitungsfähig, aber nichts verständlich, wohingegen beim formlosen Entwurf alles verstanden, aber nichts verarbeitet werden kann.

Beziehungen treten an die Stelle der Ereignisse

Ein formaler Ansatz, an dem viel gearbeitet wurde, ist das "Entity-Relationship" - Modell und die Technik der assoziativen relationalen Datenbeschreibung. Wer darüber verfügen kann und außerdem noch geschickte Entwickler sowie geeignete Werkzeuge zur Hand hat, neigt selbstverständlich dazu zu glauben, dieses sei der einzige oder beste Weg, um den Gegenstand eines Informationssystems zu beschreiben.

Aber darin steckt ein Problem. Ursache dafür ist die Diskrepanz zwischen der statischen, zeitlosen Beschaffenheit der für die Beschreibung gewählten Sprache und der dynamischen, zeitabhängigen Natur der beschriebenen Wirklichkeit.

Der springende Punkt ist, daß die verständlichste Beschreibung für den Systemanwender diejenige ist, die mit der Formulierung von Ereignissen arbeitet. Die Software-Entwickler bieten aber eine Beschreibung von Beziehungen an; denn diese Beschreibung paßt in ihre Datenbank-Technik und entspricht der einzigen Sprache, zu deren Anwendung für die Beschreibung der Wirklichkeit sie sich entschlossen haben.

So sieht unglücklicherweise die allgemeine Situation der Software-Entwicklung aus: Entwickler, die Prolog einsetzen, offerieren eine regelbasierte Beschreibung der Realität; für Lisp-Entwickler besteht die Welt aus rekursiv definierten Funktionen; Entwickler mit Smalltalk-Praxis begreifen die Wirklichkeit als eine Ansammlung von Objekten, die auf die Nachrichten von anderen Objekten reagieren.

Jede nicht-triviale Software-Entwicklung setzt die Herstellung von vielen verschiedenen Beschreibungen voraus. Beschrieben werden müssen die Realität, die dem System zugrunde liegt; die Art und Weise, wie das System Inputs in Outputs umwandelt; die modulare Struktur der Software selber und die Eigenheiten jedes Moduls; außerdem die zulässige Reihenfolge der von den Anwendern gewünschten Operationen. Und innerhalb jeder dieser Hauptkategorien ist wiederum mehr als eine Beschreibung nötig.

In einigen Fällen besteht über die Notwendigkeit, mehr als eine Beschreibung herzustellen, keinerlei Zweifel. Zum Beispiel erkennen Datenmodell-Entwickler an, daß verschiedene Benutzer eines Datenbanksystems auch unterschiedliche Sichten auf dieselben Daten benötigen; und wer Spezifikationen gedruckter Berichte erstellt, weiß, daß zweierlei definiert werden muß: die "logische Struktur" des Berichts, also die Frage nach der darin enthaltenen Information mit ihrer Organisation, sowie die physische "Struktur", das heißt die Anordnung dieser Information in Linien und Seiten. Aber in beiden Fällen sind die Beschreibungen von derselben Art: Sie können danach aus einer einzigen Sprache gefertigt werden.

Die schwierigeren Fälle sind jene, in denen Beschreibungen in verschiedenen Sprachen zusammengestellt werden müssen, um unterschiedliche Aspekte desselben Gegenstands zu beschreiben. Für die Beschreibung der Wirklichkeit, wie sie den meisten Informationssystemen zugrunde liegt, sind beispielsweise sowohl statische als auch dynamische Beschreibungen nötig: Also müssen verschiedene Beschreibungen sowohl in der Sprache des Entity-Relationship-Modells als auch in einer Sprache zeitabhängiger Ereignisse hergestellt werden.

Das Problem dabei ist, daß es keine Werkzeuge und Techniken gibt, die gut genug für die Handhabung solcher multilingualer Sets von Beschreibungen wären. Deshalb nehmen die Entwickler oft Zuflucht zur Verwendung einer einzigen Sprache, wo sie eigentlich eine ganze Reihe bräuchten. Sie benehmen sich innerhalb jeder Haupt-Beschreibungskategorie wie Handwerker, die keine Techniken für die Kombination unterschiedlicher Materialien haben und gezwungen sind, jedes Produkt aus einem einheitlichen Material zu fertigen: Sie halten sich für Ingenieure, aber in dieser Hinsicht haben sie mehr Ähnlichkeit mit einem Töpfer oder Steinmetz.

Jedes SW-Teil erfordert ein adäquates Werkzeug

Eine bemerkenswerte Eigenschaft etablierter Fertigungspraxis ist ihr Repertoire an gut durchdachten Verfahren und an Werkzeugen, mit deren Hilfe diese Operationen durchgeführt werden können. Werkstücke kann man modellieren, schmieden, pressen; man kann sie drehen, schneiden, schleifen, bohren, hobeln und mahlen; miteinander verbinden lassen sie sich, indem man sie klebt, nietet oder schweißt. Für verschiedene Materialien sind unterschiedliche Verfahrensweisen nötig: Plastik und weiche Metalle können gepreßt werden, Stahl muß man walzen.

Analog dazu geht es bei der Bearbeitung der Beschreibungen zu, die die Teile der Software-Fertigung darstellen; und genauso muß man auch mit dem Werkzeugkasten umgehen, der bei der Ausführung dieser Arbeitsvorgänge Hilfestellung leisten soll. Ein wichtiges Prinzip scheint folgendes zu sein: Die anfänglichen Absichten müssen eingegrenzt werden. Zu suchen sind Operationen, die zwar einfach, aber von weitreichendem Nutzen sind. Wenn diese auf breiter Basis nützlichen Verfahren bestimmt sind, kann man sich überlegen, wie sie sich kombinieren lassen, um die umfassenden und komplexen Arbeitsschritte zu erledigen, deren augenfälligstes Beispiel die Programm-Kompilierung ist.

Die vorhandenen komplexen Werkzeuge, wie zum Beispiel die Compiler, treten dem Software-Entwickler zumeist als eine einzige unsichtbare Operation entgegen: Vom Standpunkt des Entwicklers ist der Prozeß, in dem ein Quelltext dem Compiler angeboten und von diesem in das gewünschte Objekt-Programm umgewandelt wird, ein unteilbarer Schritt, der nicht unterbrochen werden kann. Dieser Ansatz führt zu einer schnellen und effizienten Kompilierung, was unleugbar ein wichtiger Vorteil ist. Aber er erzeugt auch eine Starrheit, die der Brauchbarkeit des Werkzeugs unter Umständen enge Grenzen setzt.

Zwar erlauben die Sprache "Ada" und ihre Compiler es, Paket-Spezifikationen unabhängig von den Paketimplementierungen zu übersetzen. Und einige Compiler gestatten dem Entwickler eine Unterdrückung der Code-Erzeugung, so daß Syntax-Fehler schnell entdeckt werden können. Aber das reicht nicht aus.

Traditionell wird Software-Entwicklung oft als das Zerlegen von Beschreibungen betrachtet. Will man beispielsweise ein Programm schreiben, das die ersten 1000 Primzahlen ausdruckt, dann fängt man vielleicht mit dieser Beschreibung an:

BEGIN

build table of 1000 primes;

print table of 1000 primes;

END;

Im folgenden werden die Statements "build table" und "print table" ausgeweitet. Diese Methode ist die traditionelle "funktionale Dekomposition" oder "schrittweise Verfeinerung". Sie setzt eine hierarchische Struktur voraus, in der die früheren Beschreibungen auf einer höheren Stufe stehen als die späteren.

Als Alternative kann dieselbe hierarchiche Struktur mit einem "Bottom-up"- statt eines "Top-down" - Ansatzes erzeugt werden. Dabei befinden sich die früheren Beschreibungen dann auf der tieferen Ebene der Hierarchie, die späteren hingegen auf der höheren.

Egal, ob man Top-down oder Bottom-up oder mit irgendeiner Mischform aus beiden operiert, immer setzt man eine hierarchische Struktur voraus, in der die Kompositionsform dem Schema "Das Ganze und der Teil" folgt.

Aber es gibt auch Strukturformen, die einen umfassenderen und mächtigeren Ansatz der Software-Herstellung unterstützen. Bemerkenswert ist, daß Beschreibungen sich besser in einem parallelen als in einem hierarchischen Aufbau zusammenfügen lassen. Viele Programmiersprachen ermöglichen die gleichberechtigte Zusammenstellung von Kontrollstrukturen in der Form paralleler Verarbeitung und Prozeß-Kommunikation mit Mechanismen wie Message-Passing, Co-Routinen-Aufruf oder dem "Ada-Rendezvous".

Gleichberechtigter Entwurf von Datenstrukturen bedeutet: das Design eines Programmaufbaus durch Strukturentwurf seines Input- und Output-Datenflusses; oder in bezug auf Datenbanken: die Konstruktion eines übergeordneten Blickwinkels durch Zusammenstellung der vielen Anwender-Sichten auf die Daten.

Unzweifelhaft warten viele andere Formen der parallelen Strukturierung von Beschreibungen noch auf ihre Entdeckung und Weiterentwicklung zu normierten Techniken die für alle Software-Entwickler verfügbar sind und von entsprechenden Tools unterstützt werden.

Synthese von Datenströmen erfordert oft Kreativität

Die Abstraktion einer Beschreibung erhält man, indem man einfach einige Teile oder Aspekte dieser Beschreibung wegläßt. Bei einem Programmtext in einer prozeduralen Sprache beispielsweise entsteht eine Abstraktion dadurch, daß alle Deklarationen, Operationen und Ausdrücke bis auf die, die sich auf eine ausgewählte Variable beziehen, unter den Tisch fallen.

Das Resultat ist die Beschreibung dessen, wie sich das Programm im Hinblick auf eine bestimmte Variable verhält; damit kann man zum Beispiel feststellen, ob das Programm jemals mit dem Wert der Variablen arbeiten kann, ohne sie vorher einzuführen. Handelt es sich bei der gewählten Variablen um einen sequentiellen Datenstrom mit seinen Records, so wird die Abstraktion eine Strukturbeschreibung des Datenflusses sein, so wie er dem Programm zur Verfügung gestellt wird.

In diesem Sinne ist die Abstraktion das Gegenteil der Gesamtstruktur: Werden von einer Beschreibung genug Abstraktionen hergestellt, so entsteht daraus wiederum eine Anzahl von Beschreibungen; man kann das durchaus auch so betrachten, als wäre die ursprüngliche Beschreibung durch eine Zusammenstellung der Abstraktionen erzeugt worden. Abstraktion ist die Analyse, die der als Strukturierung dargestellten Synthese gegenübersteht.

Manchmal ist es notwendig, Abstraktionen auf diese Weise zu benutzen, denn die Strukturaufgabe ist einfach zu schwierig, um sie auf vollkommen systematische Weise zu lösen. So kann die Zusammenstellung von Datenflußstrukturen zur Herstellung einer Programmstruktur bisweilen einen hohen Grad von Erfindungsgabe und Kreativität erfordern. Aber wenn die Programmstruktur einmal beschrieben ist, dann ist es eine geradlinige und einfache Arbeit, für jeden Datenfluß eine Abstraktion zu erzeugen. Man wird dann feststellen, daß die Programmstruktur in der Tat eine korrekte Zusammenstellung der Datenflußstrukturen bildet.

Hier noch ein Beispiel, in dem die gleichzeitige Berücksichtigung unterschiedlicher Anforderungen extrem schwierig ist. Gemeint ist die Aufgabe, den Antwortzeit-Forderungen in einem Dialog- oder Echkeit-Programm nachzukommen: Sobald man etwas entworfen hat, von dem man hofft, daß es ein passender Programmtext ist, kann man eine Abstraktion für jedes kritische Ein-/ Ausgabe-Paar formulieren.

Auch eine Abstraktion ist ein Herstellungsverfahren

Dann wird jede Abstraktion wiederum mit der Ausführungszeit für die darin enthaltenen Anweisungen versehen, um zu untersuchen, wie lange es dauert, bis ein Input einen entsprechenden Output auslöst. Ganz offensichtlich ist für Abstraktionen, wie für alle Herstellungsverfahren, Unterstützung durch angemessene Werkzeuge notwendig.

Software-Entwicklung kann also als ein Fertigungsprozeß betrachtet werden, wobei einiges Nützliche von der herkömmlichen Herstellungstechnik in anderen Bereichen zu lernen ist. Insbesondere kann man daraus erkennen, daß eine Menge verschiedener Materialen für die Produktion unterschiedlicher Beschreibungen eines Software-Produkts und eine Reihe verschiedener Herstellungsverfahren für diese Beschreibungen gebraucht werden.