FH München, FB 07 Informatik/Mathematik
Prof. Dr. R. Schiedermeier - Vorlesung "Programmieren I"
[Previous]
[Title page]
[Up]
[Next]
Inhaltsverzeichnis dieser Seite:
- Trennung zwischen Algorithmus und Programm spiegelt sich
im zeitlichen Ablauf der Softwareentwicklung wieder:
Software wird
- zuerst entworfen
(Ergebnis ist Algorithmus,
z.B. in Form eines Struktogramms),
- anschließend implementiert
(Ergebnis ist fehlerfrei übersetzbares Programm);
- Entwurf findet auf dem Reißbrett (im Kopf) statt;
Programmtechnische Details bleiben unberücksichtigt;
Im Idealfall neutral gegenüber der Implementierungssprache;
- Implementierung hält sich strikt an den Entwurf;
Findet am Rechner statt, nutzt die vorhandene Infrastruktur
(in erster Linie die Entwicklungswerkzeuge);
- In früheren Jahren war das "Wasserfallmodell"
populär.
Dieses ordnet die oben beschriebenen Phasen
linear an:
Jede Phase mündet in ein Zwischen- oder Endprodukt,
das (zeitlich) anschließend von der nachfolgenden Phase aufgegriffen wird;
Es gibt keinen Rückweg!
Das hat z.B. die Konsequenz,
daß der Entwurf komplett abgeschlossen werden muß,
bevor mit der Implementierung begonnen werden kann.
Dieses Wasserfallmodell hat sich bald als unrealistisch entpuppt,
wird aber oft noch weiterhin propagiert,
weil es sich vordergründig leicht verwalten und planen läßt.
- Als viel wirklichkeitsnäher hat sich das "Spiralmodell"
herausgestellt.
Im Spiralmodell folgen die Phasen nicht linear aufeinander,
sondern wiederholen sie mehrfach reihum.
Mit jedem Umlauf nähert man sich näher dem angestrebten Endprodukt an,
bis letztendlich der Aufwand für die nächste Runde den zu erwartenden Fortschritt überwiegt.
Das Unangenehme am Spiralmodell ist die kaum vorhersagbare Anzahl Umläufe
bis zur ausreichenden Nähe zum Idealprodukt.
Die Problemanalyse kämpft als Hauptproblem mit der Mehrdeutigkeit und
Unvollständigkeit einer umgangssprachlichen Problembeschreibung.
Auch Versuche, die Problemanalyse zu formalisieren, haben daran wenig geändert.
Eine weitere Schwierigkeit ist das oft unterschiedliche Vokabular
zwischen dem Informatiker, der die Problemanalyse betreibt,
und dem Auftraggeber als Nicht-Informatiker, der die Lösung des Problems sucht.
Die Resultate der Problemeanalyse werden in einer Problembeschreibung
gesammelt.
Diese Problembeschreibung kann z.B. in Form eines
"Pflichtenheftes" schriftlich niedergelegt werden.
Beim Fixieren der Problembeschreibung muß darauf geachtet werden,
daß keine stillschweigenden Annahmen gemacht werden oder
scheinbare Selbstverständlichkeiten als beschlossen angenommen werden.
Ein allgemeines Rezept zur Abwicklung der Problemanalyse läßt sich nicht
angeben.
Die Art des Problems hat zu großen Einfluß auf die notwendigen Gewichte.
Interaktive Probleme können z.B. einigermaßen erschöpfend in
sogenannten "Szenarios" beschrieben werden,
in denen typische oder kritische Abläufe als Sequenz von
Dialog-Schnappschüssen vorgegeben werden.
Für andere Problemstellungen, wie z.B. Systemsoftware, ist
eine derartige Dialogbeschreibung weitgehend uninteressant.
In der Problemanalyse soll noch alle Alternativen bezüglich
des weiteren Vorgehens offen lassen.
Es werden lediglich die Fazetten des Problems untersucht, gesammelt
und festgehalten.
Ziel ist eine Bestandsaufnahme.
Der Entwurf spielt sich im Grunde auf dem Papier ab
(auch wenn dabei graphische Software zur Unterstützung herangezogen werden kann).
Im Entwurf werden die groben Entscheidungen über die Struktur des
Produktes gefällt.
Dabei werden implementierungstechnische Einzelheiten bewußt übergangen.
Die Grenze zwischen Entwurfs- und Implementierungsentscheidungen ist aber
verwaschen und nicht leicht zu ziehen.
Natürlich wird ein Entwurf schon mit Blick auf die nachher bei der
Implementierung verfügbaren Möglichkeiten durchgeführt werden.
Es hat nicht viel Sinn,
Strukturen zu entwerfen,
die nachher mit den verfügbaren Programmiersprachen und Systemmerkmale
überhaupt nicht umgesetzt werden können.
Entwürfe haben Probleme mit Anforderungen,
die nicht die Logik des Produktes betreffen.
Ein Beispiel sind zeitliche Aspekte, wie etwa geforderte maximale
Anwortzeiten im Dialog.
Ein anderes Beispiel sind ergonomische Aspekte,
die die leichte Bedienbarkeit betreffen.
Derartige Randbedingungen sind nur mit sehr viel Erfahrung im
Entwurf einzuhalten.
In der Praxis läßt sich ein gewisses Maß an Experimentieren nicht umgehen.
Dabei haben Methoden wie das "Rapid prototyping" Erfolg,
bei denen Teile des Endproduktes schon frühzeitig bis
zur Ausführbarkeit fortentwickelt werden,
um erste Abschätzungen über das spätere Verhalten zu gewinnen.
Die Implementierung baut auf den Entwurfsdokumenten der Entwurfsphase auf
und führt zu einem ausführbaren Programm.
Dieser Phase wird meist ein zu hohes Gewicht eingeräumt,
weil sie äußerlich den am leichtesten wahrnehmbaren Fortschritt mit sich bringt.
Die Implementierungphase erfordert weit mehr als bloß Kenntnisse
der Syntax und Semantik
einer Programmiersprache.
Ganz ähnlich wie in natürlichen Sprachen lebt jede Programmiersprache
von einem Schatz an Idiomen,
d.h. Redewendungen, Ausdrucksweisen, stilistischen Regeln.
Bezogen auf Programmiersprachen beschreiben Idiome funktionierende und bewährte Muster,
nach denen sich Teilaufgaben lösen lassen.
Im Gegensatz zu Syntax und Semantik sind Idiome kaum irgendwo ausdrücklich beschrieben,
sondern werden von jedem Benutzer einer Programmiersprache im Laufe der
Zeit durch Erfolge und Fehlschläge selbst zusammengetragen.
Dieser Lernprozeß durch praktische Erfahrungen ist sehr mühsam, zeitraubend und kostspielig.
In neuerer Zeit werden deshalb Ansätze unternommen,
Programmieren von der syntaktischen und semantischen Ebene
auf die höhere Ebene der Idiome zu verlagern.
In diesem Gebiet findet gegenwärtig rege Forschungstätigkeit statt.
Endprodukt der Implementierungphase ist ein ausführbares Programm,
das meist einige wenige grundlegende Tests bestanden hat.
Die Testphase geht von einem in Grundzügen funktionierenden Programm aus
und versucht,
durch systematische Tests alle Schwachstellen aufzudecken.
Die Testphase wird oft als destruktiv empfunden und daher mit innerlichen Vorbehalten angegangen.
Man ist sich aus diesem Grund darüber einig, daß der
Programmierer selbst den Test des eigenen Programms nicht in angemessener Tiefe durchführen kann.
Statt dessen wird ein neutrale Instanz bemüht,
die ohne Kontakt zu den Programmierern testet,
um personenbezogene Beweggründe fernzuhalten.
Systematische Tests lassen sich grob in "black box tests" und
"white box tests" einteilen.
- "Black box tests"
-
betrachten das Programm als atomaren schwarzen Kasten
ohne Innenstruktur,
der auf gegebene Eingabedaten vorgeschriebene Reaktionen zu zeigen hat,
wie es in der Problembeschreibung festgehalten ist.
Auf dieser Grundlage werden Testdaten zusammengestellt,
die systematisch Variationen und Grenzfälle von Eingabedaten durchspielen.
Für jeden Testdatensatz wird die gezeigte mit der geplanten Reaktion
verglichen.
- "White box tests"
-
gehen von einer detaillierten Kenntnis des Entwurfs bzw.
der Implementierung aus.
Die Innenstruktur des Produktes liegt offen.
Testeingaben werden gezielt so konstruiert,
daß nacheinander jede Ecke des Programms ausgereizt und belastet wird.
Für Kontrollstrukturen heißt das z.B.,
daß jede Abzweigung einer Alternative wenigstens einmal ausgeführt wird.
Tests sollten ausführlich samt den Ergebnissen dokumentiert werden,
so daß bei Korrekturen, Modifikationen oder Erweiterungen
ein Vergleich gezogen werden kann.
Im einfachsten Fall können Testeingaben sowie gelieferte Ausgaben
in den Quelltext selbst in Form von Kommentaren eingebaut werden.
Eine andere Möglichkeit wäre das Programm um zusätzlichen Testcode
zu erweitern,
der mit einfachen Mitteln ein- oder ausgeblendet werden kann
(z.B. bedingte Übersetzung mit Compilerschaltern).
Ein und derselbe Code kann dann mit wenig Aufwand zum Selbsttest oder
zum Einbau in das Gesamtprodukt verwendet werden.
Für größere Softwareprodukte, wie Compiler und Datenbanken,
gibt es unabhängige Testsuites bzw. Institutionen,
die auf kommerzieller Basis testen.
So können z.B. neue C-Compiler einer Validierung unterzogen werden,
die ihre Kompatibiltät mit dem ANSI-C-Sprachstandard überprüft.
Nach einiger Zeit und einigen Kosten darf der Hersteller den Compiler
als "ANSI-C-Compiler" bezeichnen.
Die Wartung reiht sich nahtlos in die Reihe der vorangegangenen Phasen
ein,
auch wenn sie keine abgegrenzte Phase im Sinne von Entwurf
oder Implementierung ist.
Im Idealfall fällt sie einfach aus,
weil keine Anlaß zu Wartungsarbeiten besteht.
Diese Vorstellung ist natürlich illusorisch.
Software (insbesondere Systemsoftware) lebt i.d.R. viel länger
als ursprünglich geplant.
Mit Sicherheit übersteigt die Lebensdauer von Programmen
die von Prozessoren.
Anpassungsarbeiten an neue Umgebungen (Hardware und andere Software)
ist nicht vermeidlich
und sollte als Kostenfaktor von vorne herein eingeplant werden.
[Previous]
[Top of page]
[Next]
Letzte Änderung: Thu Sep 26 13:58:29 1996