13 Die Implementierungsphase 13 Die Implementierungsphase Zur ...

SWT - Implementierung 

1 

Inhalt 

13 Die Implementierungsphase 

13.1 Einführung und Überblick 

13.2 Prinzipien der Implementierung 

13.2.1 Prinzip der Verbalisierung 

13.2.2 Prinzip der problemadäquaten Datentypen 

13.2.3 Prinzip der Verfeinerung 

13.2.4 Prinzip der integrierten Dokumentation 

13.3 Methode der schrittweisen Verfeinerung 

13.4 Zur Psychologie des Programmierens 

13.5 Selbstkontrolliertes Programmieren 


2 

13 Die Implementierungsphase 

 

Zur Historie 

Prof. Dr. Niklaus Wirth 

*15.2.1934 in Winterthur, Schweiz 

Professor an der ETH Zürich 

Erfinder der Programmiersprachen 

Pascal (1970), Modula-2 (1982) 

und Oberon (1989) 

Erfinder der Computersysteme Lilith (1980) 

und Ceres (1986) zusammen mit ihren 

Betriebssystemen 

Wegbereiter der strukturierten 

Programmierung und der schrittweisen 

Verfeinerung.


3 


 

 

Aufgabe des Programmierens: 

Aus vorgegebenen Spezifikationen für eine 

Systemkomponente die Systemkomponente zu 

implementieren, d.h. die geforderten 

Leistungen in Form eines oder mehrerer 

Programme zu realisieren 

Implementierungsphase: 

Durchführung der Programmiertätigkeiten 

Eingebettet zwischen 

• der Entwurfsphase und 

• der Abnahme- und Einführungsphase. 


4 


 

Voraussetzungen 

In der Entwurfsphase wurde eine Softwarearchitektur 

entworfen, die zu geeigneten 

Systemkomponenten geführt hat 

Abhängig von der Entwurfsmethode kann eine 

Systemkomponente folgendermaßen aussehen: 

• Strukturierter Entwurf: 

◦ funktionales Modul 

• Modularer Entwurf: 

◦ funktionales Modul 

◦ Datenobjekt-Modul 

◦ Datentyp-Modul 

• Objektorientierter Entwurf: 

◦ Klassen.

5 



 

Voraussetzungen 

Für jede Systemkomponente existiert eine 

Spezifikation 

Die Softwarearchitektur ist so ausgelegt, daß die 

Implementierungen umfangsmäßig pro Funktion, 

Zugriffsoperation bzw. Operation wenige Seiten 

nicht überschreiten. 

6 

Planungsphase 


Legende: 

Phase 

13.1 Lastenheft Einführung und Überblick 

Phasenergebnis 

Weitergabe von 

Teilprodukten 

Definitionsphase 

Produkt-Definition 

Entwurfsphase 

Produkt-Entwurf 

Softwarearchitektur 

Spezifikation der Systemkomponenten 

Programme, Gesamtprodukt 

Implementierungsphase 

Abnahme- und 

Einführungsphase 

Installiertes Produkt 

Implementierungsprozeß 

Quellprogramme inkl. Dokumentation 

Objektprogramme 

Testplanung und Testprotokoll 

bzw. Verifikationsdokumentation


7 


 

 

Aktivitäten 

Konzeption von Datenstrukturen und Algorithmen 

Strukturierung des Programms durch geeignete 

Verfeinerungsebenen 

Dokumentation der Problemlösung und der 

Implementierungsentscheidungen 

Umsetzung der Konzepte in die Konstrukte der 

verwendeten Programmiersprache 

Angaben zur Zeit- und Speicherkomplexität 

Test oder Verifikation des Programmes einschl. 

Testplanung und Testfallerstellung 

Auch »Programmieren im Kleinen« genannt. 


8 


 

 

Teilprodukte 

Quellprogramm einschl. integrierter Dokumentation 

Objektprogramm 

Testplanung und Testprotokoll bzw. 

Verifikationsdokumentation 

Alle Teilprodukte aller Systemkomponenten 

müssen integriert und einem Systemtest 

unterzogen werden.


9 


 

Basiskonzepte zur Implementierung der 

Systemkomponenten: 

Kontrollstrukturen 

• nur »lineare Kontrollstrukturen« 

• »Strukturiertes Programmieren i. e. S.« 

Entscheidungstabellen. 


10 

13.2 Prinzipien der Implementierung 

 

Bei der Implementierung sollten folgende 

Prinzipien eingehalten werden: 

Prinzip der Verbalisierung 

Prinzip der problemadäquaten Datentypen 

Prinzip der Verfeinerung 

Prinzip der integrierten Dokumentation.


11 


 

 

Verbalisierung 

Gedanken und Vorstellungen in Worten 

ausdrücken und damit ins Bewußtsein bringen 

Gute Verbalisierung 

Aussagekräftige, mnemonische 

Namensgebung 

Geeignete Kommentare 

Selbstdokumentierende Programmiersprache. 


12 


 

Bezeichnerwahl 

Problemadäquate Charakterisierung 

Konstanten, Variablen, Prozeduren usw. 

Soll die Funktion dieser Größe bzw. ihre 

Aufgabe zum Ausdruck bringen 

Bezeichner, die problemfrei sind oder 

technische Aspekte z.B. der Repräsentation 

bezeichnen, sind zu vermeiden 

Die in der Mathematik übliche Verwendung 

einzelner Buchstaben ist ebenfalls ungeeignet.

13 



Beispiel 1 

• Feld1, Feld2, Zaehler 

◦ problemfreie, technische Bezeichner 

• Besser: 

• Messreihe1, Messreihe2, Anzahlzeichen 

◦ problembezogene Bezeichner 

Beispiel 2 

• P = G2 + Z1 * D 

◦ Bezeichner ohne Aussagekraft, zu kurz 

• Besser: 

• Praemie = Grundpraemie2 + Zulage1 * 

Dienstjahre;. 

14 



Beispiel 3 

• Praemie = 50.0 + 10.0 * Dienstjahre 

◦ unverständliche Konstanten 

• Besser: 

• const float Grundpraemie2 = 50.0; 

• const float Zulage1 = 10.0; 

• Praemie = Grundpraemie2 + Zulage1 * 

Dienstjahre; 

Durch die Verwendung benannter Konstanten wird 

die Lesbarkeit eines Programmes deutlich 

verbessert 

• Zusätzlich wird das Programm dadurch auch 

änderungsfreundlicher.


15 


Kurze Bezeichner sind nicht aussagekräftig und 

außerdem wegen der geringen Redundanz 

anfälliger gegen Tippfehler und Verwechslungen 

Der erhöhte Schreibaufwand durch lange 

Bezeichner wird durch die Vorteile mehr als 

ausgeglichen. 


16 


 

Verbalisierung wird durch geeignete 

Kommentare unterstützt 

Als vorteilhaft hat sich erwiesen, den else-Teil 

einer Auswahl zu kommentieren 

• Als Kommentar wird angegeben, welche 

Bedingungen im else-Teil gelten 

• Beispiel 

if (A < 5) 

{ ...} 

else //A >= 5 

{ ...}.


17 


 

 

Kurzkommentare sollten vermieden 

werden 

Die in ihnen enthaltene Information ist meist 

besser in Namen unterzubringen 

Beispiel 

• I = I + 1; //I wird um Eins erhöht 

• Besser: 

Lagermenge = Lagermenge + 1; 

Besonders wichtige Kommentare 

In einen Kommentarkasten. 


18 


 

 

Grad der Kommentierung 

Abhängig davon, ob Programmiersprache 

selbstdokumentierend 

ADA gilt in dieser Beziehung als vorbildlich 

C++ ist ein schlechtes Beispiel 

Vorteile der Verbaliserung 

+ Leichte Einarbeitung in fremde Programme 

bzw. Wiedereinarbeitung in eigene Programme 

+ Erleichtert »code reviews«, Modifikationen und 

Wartung 

+ Verbesserte Lesbarkeit der Programme.


19 

13.2.2 Prinzip der problemadäquate Datentypen 

 

Problemadäquate Datentypen 

Daten- und Kontrollstrukturen eines Problems 

sollen sich in der programmiersprachlichen 

Lösung möglichst unverfälscht widerspiegeln 

Programmiersprache sollte folgende 

Eigenschaften bezogen auf Datenstrukturen 

besitzen: 

• Umfangreiches Repertoire an Basistypen 

• Geeignete Typkonstruktoren 

• Benutzerdefinierbare Typen. 


20 


 

 

Aufgabe des Programmierers 

Angebot an Konzepten einer 

Programmiersprache optimal zur 

problemnahen Lösungsformulierung 

verwenden 

Regeln: 

Können die Daten durch Basistypen 

beschrieben werden, dann ist der geeignete 

Basistyp auszuwählen 

• Der Wertebereich sollte so festgelegt 

werden, daß er möglichst genau das 

Problem widerspiegelt – unter Umständen 

durch Einschränkungen des Basistyps.

21 



Beispiele 

• enum FamilienstandT {ledig, 

verheiratet, geschieden, verwitwet}; 

• enum GeschlechtT {weiblich, maennlich}; 

• enum AmpelT {rot, gruen, gelb}; 

• enum SteuerschluesselT {ohne_Steuer, 

Vorsteuer, halbe_MwSt,volle_MwSt}; 

• enum WeinpraedikateT {Kabinett, 

Spaetlese, Auslese, Beerenauslese, 

Trockenbeerenauslese}; 

• enum BauteiltypT {R, L, C, U, I}; 

• n! ist nur für nichtnegative ganze Zahlen definiert 

◦ Der Basistyp sollte entsprechend gewählt werden: 

unsigned long NFAK (unsigned long n);. 

22 



Typkonstruktor Feld verwenden, wenn: 

a Zusammenfassung gleicher Datentypen 

b Zugriff wird dynamisch berechnet (während der 

Laufzeit) 

c Hohe Komponentenanzahl möglich 

d Feldgrenzen statisch, dynamisch oder 

unspezifiziert 

e Mittlere Zugriffszeit auf eine Komponente, 

unabhängig vom Wert des Index 

f Als zugehörige Kontrollstruktur wird die zählende 

Wiederholung eingesetzt 

• Beispiel 

◦ In einem Textsystem wird eine Textseite 

folgendermaßen beschrieben: 

◦ typedef char TextzeileT[Zeilenlaenge]; 

◦ typedef TextzeileT TextseiteT[Zeilenanzahl];

23 



Typkonstruktor Verbund verwenden, wenn: 

a Zusammenfassung logischer Daten mit 

unterschiedlichen Typen 

b Zugriff wird statisch berechnet (zur 

Übersetzungszeit) 

c Anzahl der Komponenten ist immer fest 

d Jede Komponente ist einzeln benannt, daher ist 

der Umfang begrenzt 

e Kurze Zugriffszeit auf Komponente erwünscht 

f Bei varianten Verbunden ist die Mehrfachauswahl 

die geeignete Kontrollstruktur. 

24 



Typkonstruktor Verbund: Beispiele 

• Der Datentyp eines Adreßverwaltungsprogramms 

sieht problemadäquat folgendermaßen aus: 

struct AdresseT 

const char * Strasse; 

int PLZ; 

const char * Wohnort; 

• Es sollen komplexe Zahlen verarbeitet werden; 

der geeignete Datentyp ist: 

struct ComplexT 

{ 

float Re, Im; 

};.


25 


 

Vorteile problemadäquater Datentypen 

+ Gut verständliche, leicht lesbare, 

selbstdokumentierende und wartbare 

Programme 

+ Statische und dynamische Typprüfungen 

verbessern die Qualität des jeweiligen 

Programms 

+ Die Daten des Problems werden 1:1 in 

Datentypen des Programms abgebildet, d.h. 

Wertebereiche werden weder über- noch 

unterspezifiziert. 


26 


 

Voraussetzungen: 

Möglichst optimale Unterstützung durch 

geeignete Konzepte in der verwendeten 

Programmiersprache 

Anwendung des Prinzips der Verbalisierung, 

insbesondere bei der Namenswahl 

Bei fehlenden modernen Sprachkonzepten 

ausführliche Kommentierung 

Definition geeigneter Datenabstraktionen bzw. 

Klassen mit problemangepaßten Operationen.


27 


 

 

Verfeinerung 

Dient dazu, ein Programm durch 

Abstraktionsebenen zu strukturieren 

Verfeinerungsstruktur kann auf 2 Arten im 

Quellprogramm sichtbar gemacht werden 

Die oberste Verfeinerungsebene – bestehend 

aus abstrakten Daten und abstrakten 

Anweisungen – ist kompakt beschrieben 

• Die Realisierung jeder Verfeinerung wird an 

anderer Stelle beschrieben 

Alle Verfeinerungsebenen sind substituiert 

• Die übergeordneten Verfeinerungen werden 

als Kommentare gekennzeichnet. 


28 


Ein Algorithmus soll aus zwei eingegebenen 

Daten die Anzahl der Zinstage berechnen: 

void berechneZinstage() 

{ 

int Datum1, Datum2; // Eingabedaten, Form TTMM 

int Tage; // Ausgabedaten 

// Voraussetzung:Daten liegen innerhalb eines Jahres 

// Algorithmus ------------------------------------- 

// Eingabe 

// Aufgliederung in Tag und Monat 

// Beruecksichtigung der Sonderfaelle 

// Berechnung der Tage 

// Ausgabe 

}.


29 


// refinements: 1. Verfeinerung: 

// Eingabe 

cout > Datum1; 

cout > Datum2; cout


31 


 

Da die meisten Programmiersprachen eine 

solche Darstellung nicht erlauben, müssen die 

Verfeinerungen substituiert werden: 

void berechneZinstage() 

{ 

int Datum1, Datum2; // Eingabedaten, Form TTMM 

int Tage; // Ausgabedaten 

//Voraussetzung: Die Daten liegen innerhalb eines Jahres 

int Tag1, Tag2; // Hilfsgroessen 

int Monat1, Monat2; // Hilfsgroessen 

// Eingabe 

cout > Datum1; 

cout


33 


In dieser Notation werden in Kommentarform die 

Verfeinerungsschichten aufgeführt 

Durch Einrücken nach rechts kann man die Tiefe 

der Verfeinerung hervorheben 

Bei diesen Kommentaren handelt es sich um 

Verfeinerungen, die bei der Konzeption des 

Programms entstanden sind und nur in 

Kommentarform notiert werden. 


34 


Vorteile 

+ Der Entwicklungsprozeß ist im Quellprogramm 

dokumentiert 

+ Leichtere und schnellere Einarbeitung in ein 

Programm 

+ Die Details können zunächst übergangen 

werden 

+ Die Entwicklungsentscheidungen können besser 

nachvollzogen werden 

+ Die oberen Verfeinerungsschichten können in 

natürlicher Sprache formuliert werden 

+ Ein Programm wird zweidimensional strukturiert: 

sowohl durch Kontrollstrukturen als auch durch 

Verfeinerungsschichten.


35 


 

 

Dokumentation 

Integraler Bestandteil jedes Programms 

Ziele der Dokumentation: 

Angabe von Verwaltungsinformationen 

Erleichterung der Einarbeitung 

Beschreibung der Entwicklungsentscheidungen 

• Warum wurde welche Alternative gewählt?. 


36 


 

Richtlinie 

Folgende Verwaltungsinformationen sind am 

Anfang eines Programms aufzuführen 

(Vorspann des Programms): 

1 Name des Programms 

2 Name des bzw. der Programmautoren (Vorund 

Nachname) 

3 Versionsnummer, Status und Datum 

4 Aufgabe des Programms: 

Kurzgefaßte Beschreibung 

5 Zeit- und Speicherkomplexität in O-Notation.


37 


 

 

Versionsnummer besteht aus 2 Teilen: 

Release-Nummer 

• I. allg. einstellig 

• Steht, getrennt durch einen Punkt, vor der 

Level-Nummer (maximal zweistellig) 

• Vor der Release-Nummer steht ein V 

Level-Nummer 

Beispiel: V1.2 

Die Version kennzeichnet zusammen mit 

dem Status den Bearbeitungszustand des 

Programms. 


38 


 

Bearbeitungszustände (V-Modell) 

geplant 

• Ein neues Programm enthält die 

Versionsnummer 1.0 und den Status 

»geplant« 

in Bearbeitung 

• Das Programm befindet sich im privaten 

Entwicklungsbereich des Implementierers 

oder unter seiner Kontrolle in der 

Produktbibliothek.

39 



vorgelegt 

• Das Programm ist aus Implementierersicht fertig 

und wird in die Konfigurationsverwaltung 

übernommen 

• Vom Status »vorgelegt« ab führen Modifikationen 

zu einer Fortschreibung der Versionsangabe 

akzeptiert 

• Das Programm wurde von der Qualitätssicherung 

überprüft und freigegeben 

• Es darf nur innerhalb einer neuen Version 

geändert werden. 

40 



Beispiel: Programmvorspann 

 

// Programmname: XYZ 

//**************************************************** 

// Autor 1: Vorname Nachname 

// Autor 2: Vorname Nachname 

//**************************************************** 

// Version: V1.0 in Bearbeitung 4.4.96 

// vorgelegt 6.4.96 

// akzeptiert 7.4.96 

// V1.1 in Bearbeitung 15.4.96 

// vorgelegt 16.4.96 

//**************************************************** 

// Aufgabe: Aufgabenbeschreibung 

// Zeitkomplexitaet: O(n log 2n) 

// Speicherkomplexitaet O(2n).


41 


 

Dokumentation muß integraler Bestandteil der 

Software-Entwicklung sein: 

Bei einer Nachdokumentation am Ende der 

Codeerstellung sind wichtige Informationen, die 

während der Entwicklung angefallen sind, oft nicht 

mehr vorhanden 

Entwicklungsentscheidungen (z.B.: Warum wurde 

welche Alternative gewählt?) müssen dokumentiert 

werden, um bei Modifikationen und 

Neuentwicklungen bereits gemachte Erfahrungen 

auswerten zu können 

Der Aufwand für die Dokumentation wird reduziert, 

wenn zu dem Zeitpunkt, an dem die Information 

anfällt von demjenigen, der sie erzeugt oder 

verarbeitet, auch dokumentiert wird. 


42 


 

 

Das Prinzips der integrierten Dokumentation... 

+ reduziert den Aufwand zur Dokumentenerstellung, 

+ stellt sicher, daß keine Informationen 

verlorengehen, 

+ garantiert die rechtzeitige Verfügbarkeit der 

Dokumentation, 

+ erfordert die entwicklungsbegleitende 

Dokumentation 

Eine gute Dokumentation bildet die 

Voraussetzung für 

leichte Einarbeitung in ein Produkt bei 

Personalwechsel oder durch neue Mitarbeiter 

gute Wartbarkeit des Produkts.


43 


 

Schrittweise Verfeinerung 

(stepwise refinement) 

Bietet einen methodischen Rahmen für die 

Anwendung der allgemeinen top-down- 

Methode auf das »Programmieren im Kleinen« 

Im Gegensatz zum Prinzip der Verfeinerung, 

das das zu erreichende Ziel beschreibt, gibt 

die schrittweise Verfeinerung einen 

methodischen Ansatz an, wie man dieses Ziel 

erreicht 

• Ausgehend von einer gegebenen und 

präzisen Problemstellung z.B. in Form einer 

Systemkomponenten-Spezifikation wird eine 

Problemlösung mit abstrakten Daten und 

abstrakten Anweisungen formuliert. 


44 


 

Beispiel: 

Zur Konzentration der Einkaufs-, Vertriebsund 

Marketingstrategie wird in einer 

Weinhandlung in vierteljährlichen Abständen 

eine Statistik benötigt, die die 

Umsatzverteilung der Weinanbaugebiete 

angibt 

Die Statistik soll den Umsatz in DM sowie die 

prozentuale Veränderung gegenüber der 

letzten Statistikperiode pro Anbaugebiet 

angeben.


45 


Datentypen und Prozeduren: 

// Typ fuer Artikelnummern 

typedef unsigned short ArtikelNrT; 

typedef float DMarkT; // Typ fuer Deutsche Mark 

enum GebietT {BADEN, RHEINPFALZ, WUERTTEMBERG, 

FRANKEN, RHEINHESSEN, HESSISCHEBERGSTR, RHEINGAU, 

NAHE, MITTELRHEIN, MOSELSAARRUWER, AHR, AUSLAND}; 

const int ANZAHLGEBIETE = AUSLAND + 1 

// Liste mit Umsatz in DM fuer jedes Anbaugebiet 

typedef DMarkT UmsatzlisteT[ANZAHLGEBIETE]; 

// Prozeduren 

void ErmittleWeinumsatz(int ArtikelNr, DMarkT 

&ViertelJahresUmsatz, GebietT &Anbaugebiet, 

bool &ArtikelNrBelegt); 

void UmsatzAltLesen(UmsatzlisteT &UListe); 

void UmsatzAltAktualisieren(UmsatzlisteT &UListe);. 


46 


1. Schritt: abstrakte Problemlösung 

Es werden problemspezifische Typen, Daten und 

Anweisungen eingeführt und in verbaler Form 

beschrieben 

Die Typen und Daten sollen problemrelevante 

Aspekte benennen 

Die Operationen sollen Teilaufgaben abgrenzen 

Beides soll losgelöst von programmiersprachlichen 

Formulierungen erfolgen.


47 


1. Schritt: abstrakte Problemlösung 

// Programmname: UmsatzProAnbaugebiet 

// Aufgabe: .... 

// Importierte Typen: 

// ArtikelNrT, DMarkT, GebietT, UmsatzListeT 

// Importierte Prozeduren: 

// ErmittleWeinumsatz, UmsatzAltLesen, 

UmsatzAltAktualisieren 

// Datenstrukturen ---------------------------------- 

// TabelleUmsatzProGebiet 

// Algorithmus -------------------------------------- 

// Vorbereitung (1) 

// Weinumsatz pro Anbaugebiet ermitteln (2) 

// Vergleich mit Umsatzstatistik der Vorperiode (3) 

// Umsatzstatistik Vorperiode durch neue ersetzen (4) 

// Druckaufbereitung und Ausgabe (5). 


48 


2. Schritt: Verfeinerung der abstrakten 

Problemlösung 

Typen, Daten und Anweisungen werden verfeinert 

• konkretisiert, präzisiert, detailliert, formalisiert 

Typen und Daten werden unmittelbar oder mittelbar 

durch Konstruktionskonzepte auf Standardtypen 

abgebildet 

Anweisungen werden auf primitivere Anweisungen 

oder Standardfunktionen, -prozeduren oder 

Datenabstraktionen zurückgeführt 

Reihenfolge der Verfeinerungen so wählen, daß 

zunächst die abstrakten Anweisungen bearbeitet 

werden, die auf Auswahl- oder 

Wiederholungsanweisungen abgebildet werden.


49 


// Verfeinerung der Datenstrukturen ------------------ 

// Datentyp fuer Tabelle mit 

// - Umsatz in DM und 

// - prozentuale Veraenderung pro Anbaugebiet 

// 

struct UmsatzT 

{ 

DMarkT UmsatzNeu; 

int ProzentAbweichung; 

}; 

typedef struct UmsatzT UmsatzTabT[AnzahlGebiete]; 

// Variablendefinition: 

UmsatzTabT TabelleUmsatzProGebiet;. 


50 


// Verfeinerung der abstrakten Anweisungen------------ 

// Vorbereitung (1) 

// Weinumsatz pro Anbaugebiet ermitteln: (2) 

// for alle Weinartikel do (2a) 

// Weinumsatz pro Artikel lesen; (2b) 

// Umsatz in TabelleUmsatzProGebiet aufaddieren; (2c) 

// Vergleich mit Umsatzstatistik der Vorperiode: (3) 

// Alte Umsatzstatistik lesen (3a) 

// for alle Anbaugebiete do (3b) 

// Umsatzwerte vergleichen; (3c) 

// Prozentuale Abweichung ausrechnen und (3d) 

// in TabelleUmsatzProGebiet speichern;.


51 


// Umsatzstatistik Vorperiode durch neue ersetzen: (4) 

// Neue Werte in alte Liste eintragen (4a) 

// UmsatzAltAktualisieren(UmsatzListeAlt); (4b) 

// Druckaufbereitung und Ausgabe: (5) 

// Drucke Ueberschrift; (5a) 

// for alle Anbaugebiete do (5b) 

// Drucke(Anbaugebiet, Umsatz, Prozentabweichung). 


52 


3. Schritt: Weitere Verfeinerung 

Die sukzessive Zerlegung oder Verfeinerung 

endet, wenn alle Typen, Daten und Anweisungen 

in Termen der verwendeten Programmiersprache 

beschrieben sind 

Nach jeder Verfeinerung können die verfeinerten 

Teile in die Problemlösung der übergeordneten 

Verfeinerungsschicht substituiert werden 

• Die abstrakten Typen, Daten und Anweisungen 

werden dann zu Kommentaren.


53 



// benoetigte Variablen 

ArtikelNrT ArtikelNr; 

DMarkT Umsatz; 

GebietT Gebiet; 

UmsatzlisteT UmsatzListeAlt; 

UmsatzTabT TabelleUmsatzProGebiet; 

bool Ok; 

char *GText[]={ „Baden“, „Rheinpfalz“, 

„Württemberg“, „Franken“, 

„Rheinhessen“, „Hessischebergstr”, 

„Rheingau“, „Nahe“, „Mittelrhein“, 

„Moselsaarruwer“, „Ahr“, „Ausland“ };. 


54 



// Umsetzung der verbal beschriebenen Anweisungen 

// in die verwendete Zielsprache 

// Vorbereitung: (1) 

for (Gebiet = BADEN; Gebiet


55 



// Alte Umsatzstatistik lesen: (3a) 

UmsatzAltLesen(UmsatzListeAlt); 

// for alle Anbaugebiete do: (3b) 

for (Gebiet = BADEN; Gebiet


57 


 

Merkmale der schrittweisen Verfeinerung: 

Daten und Anweisungen sollen parallel verfeinert 

werden 

Es soll solange wie möglich eine Notation benutzt 

werden, die das Problem in natürlicher Form 

beschreibt 

Abstrakte Anweisungen, die durch Auswahl- oder 

Wiederholungsstrukturen realisiert werden, sollten 

zuerst verfeinert werden 

Entscheidungen über die Datenrepräsentation 

sollten solange wie möglich aufgeschoben werden 

Während der Verfeinerung werden Hilfsobjekte 

eingeführt. 


58 


Jede Verfeinerung impliziert 

Implementierungsentscheidungen, die explizit 

dargelegt werden sollen 

Im Gegensatz zum Softwareentwurf sind alle Daten 

zwischen den verschiedenen Teilanweisungen 

bekannt und global (kein Geheimnisprinzip) 

Ausgeprägte Verbalisierung ist erforderlich 

Der Implementierungsprozeß wird in kleine 

inkrementelle Abstraktionsschritte unterteilt.


59 


 

Vorteile 

+ Realisiert das Prinzip der Verfeinerung 

+ Fördert eine problemorientierte Betrachtungsweise 

+ Ist für ein breites Anwendungsspektrum einsetzbar 

+ Der Entscheidungsprozeß ist nachvollziehbar 

+ Durch die systematische, dokumentierte 

Problemstrukturierung werden Änderbarkeit und 

Wartbarkeit erleichtert 

+ top-down-orientiert 

+ Führt zu einer gestuften algorithmischen 

Abstraktion 

+ Unterstützt systematisches Vorgehen. 


60 


Nachteile: 

– Keine ausgeprägte Methode mit definierten, 

problemunabhängigen Schritten 

– Anwendung erfordert Erfahrung und Intuition, 

insbesondere um zur ersten abstrakten 

Problemlösung zu gelangen 

– Bei mehreren Verfeinerungsstufen verliert man 

leicht den Überblick 

– Automatische Substitutionsmechanismen für 

verfeinerte Typen und Datenstrukturen stellt noch 

keine Sprache zur Verfügung.


61 


 

Jeder Programmierer macht Fehler! 

Viele dieser Fehler sind auf Eigenheiten der 

menschlichen Wahrnehmung und des 

menschlichen Denkens zurückzuführen 

Außerdem spielt die Denkpsychologie eine 

Rolle 

Assoziationen und Einstellungen des 

Menschen beeinflussen sein Denken 

Die meisten Programmierfehler lassen sich auf 

bestimmte Denkstrukturen und -prinzipien 

zurückführen 

Durch die Beachtung einiger Regeln lassen 

sich diese Fehler daher vermeiden. 


62 


 

Hintergrundwissen 

Jeder Mensch benutzt bei seinen Handlungen 

bewußt oder unbewußt angeborenes oder 

erlerntes Hintergrundwissen 

Dieses Hintergrundwissen ist Teil des 

Wissens, das einer Bevölkerungsgruppe, z.B. 

den Programmierern, gemeinsam ist 

Programmierfehler lassen sich nun danach 

klassifizieren, ob das Hintergrundwissen für 

die Erledigung der Aufgabe angemessen ist 

oder nicht.


63 


 

Klassifizierung von Programmierfehlern 

Programmierfehler 

Irrtümer 

Schnitzer 

überindividuell 

(Denkfallen) 

individuell 

angeborenes 

Verhalten 

erlerntes Verhalten 

(Tradition) 

Begabung 

Ausbildung 


64 


 

 

»Schnitzer« 

sind Tippfehler, Versprecher usw. 

Sie werden vor allem durch eine schlechte 

Benutzungsoberfläche verursacht 

Irrtümer 

sind der Kategorie »Wissen« zuzuordnen 

Diesen Fehlern ist gemeinsam, daß der 

Programmierer den Fehler auch beim 

wiederholten Durchlesen seines Programms 

nicht sieht.


65 


 

Denkfallen 

Überindividuelle Irrtümer 

• Sie treten auf, wenn das Hintergrundwissen 

der Aufgabenstellung nicht angemessen ist 

Individuelle Irrtümer 

• Ergeben sich durch unzureichende 

Begabung oder Ausbildung 

Denkfallen ergeben sich aus bestimmten 

Denkstrukturen und -prinzipien 

Diese führen zu einem Verhaltens- und 

Denkmodell, das das Verhalten eines 

Programmierers beeinflußt. 


66 


 

Prinzipien des Verhaltens- und Denkmodells 

1 Übergeordnete Prinzipien 

• Scheinwerferprinzip 

• Sparsamkeits- bzw. Ökonomieprinzip 

2 Die »angeborenen Lehrmeister« 

• Strukturerwartung 

(Prägnanzprinzip, kategorisches Denken) 

• Kausalitätserwartung 

(lineares Ursache-Wirkungs-Denken) 

• Anlage zur Induktion (Überschätzung 

bestätigender Informationen) 

3 Bedingungen des Denkens 

• Assoziationen 

• Einstellungen.


67 


1 Übergeordnete Prinzipien 

Beschreiben, wie unser Wahrnehmungs- und 

Denkapparat mit begrenzten Ressourcen fertig wird 

Scheinwerferprinzip 

• Aus den Unmengen an Informationen, die der 

Mensch ständig aus seiner Umwelt erhält, wählt 

er aus und verarbeitet er bewußt stets nur relativ 

kleine Portionen 

• Leider sind es oft die wichtigen Dinge, die 

unbeachtet bleiben 

• Viele Programmierfehler zeigen dies: 

◦ Ausnahme- und Grenzfälle werden übersehen 

◦ Die Initialisierung von Variablen wird vergessen 

◦ Funktionen besitzen unübersehbare Nebenwirkungen. 


68 


Sparsamkeits- bzw. Ökonomieprinzip 

• Es kommt darauf an, ein Ziel mit möglichst 

geringem Aufwand zu erreichen 

• Der Trend zum sparsamen Einsatz der 

verfügbaren Mittel birgt allerdings auch Gefahren 

in sich 

• Denk- und Verhaltensmechanismen, die unter 

normalen Umständen vorteilhaft sind, können 

dem Programmierer zum Verhängnis werden 

• Typische Fehler gehen auf falsche Hypothesen 

über die Arbeitsweise des Computers zurück 

◦ Insbesondere mit der Maschinenarithmetik kommt der 

Programmierer oft aufgrund zu einfacher 

Modellvorstellungen in Schwierigkeiten.


69 


2 Die »angeborenen Lehrmeister« 

Stellen höheres Wissen dar, das den weiteren 

Wissenserwerb steuert 

• Dieses höhere Wissen spiegelt den »Normalfall« 

wider 

• Mit ungewöhnlichen Situationen wird es nicht so 

gut fertig 

Strukturerwartung 

• Erleichtert dem Menschen die Abstraktion 

• Daraus folgt das Prägnanzprinzip, das besagt, 

daß es sich lohnt, Ordnung aufzuspüren und 

auszunutzen 

• Bilden von Kategorien zum Schaffen von 

Ordnung. 


70 


Strukturerwartung 

• Prägnanzprinzip und kategorisches Denken 

führen in außergewöhnlichen Situationen 

gelegentlich zu Irrtümern, zu unpassenden 

Vorurteilen oder zu Fehlverhalten 

• Eine Reihe von Programmierfehlern läßt sich 

darauf zurückführen 

• Beispiel 

◦ Für reelle Zahlen gilt das assoziative Gesetz 

◦ Für die Maschinenarithmetik gilt dies aber nicht 

• Allgemein gilt: 

◦ Fehler, die darauf beruhen, daß der Ordnungsgehalt der 

Dinge überschätzt wird oder den Dingen zu viele 

Gesetze auferlegt werden, lassen sich auf das 

Prägnanzprinzip zurückführen.


71 


Kausalitätserwartung 

• Führt zu einem linearen Ursache-Wirkungs- 

Denken und zu der übermäßigen Vereinfachung 

komplexer Sachverhalte 

◦ Der Mensch neigt dazu, irgendwelche Erscheinungen 

vorzugsweise nur einer einzigen Ursache zuzuschreiben 

◦ Er macht oft die Erfahrung, daß die gleichen 

Erscheinungen dieselbe Ursache haben, so daß dieses 

Vorurteil zum festen Bestandteil des menschlichen 

Denkens gehört und nur mit Anstrengung überwunden 

werden kann 

• Das lineare Ursache-Wirkungs-Denken kann in 

komplexen Entscheidungssituationen 

»fürchterlich« versagen 

• Gerade die Umwelt eines Programmierers ist 

aber ein vernetztes System. 


72 


Die Anlage zur Induktion 

• Der Mensch neigt zu induktiven Hypothesen 

• Die Fähigkeit, im Besonderen das Allgemeine, im 

Vergangenen das Zukünftige erkennen zu 

können, verleitet zur Überschätzung 

bestätigender Informationen 

• Beispiel 

◦ Ein Test, der das erwartete Ergebnis liefert, wird in 

seiner Aussagekraft überschätzt 

• Im Gegensatz zur Deduktion ist die Induktion 

kein zwingendes Schließen 

• Gesetzmäßigkeiten werden vorschnell als 

gesichert angesehen 

• Dadurch werden Dinge klargemacht, die 

eigentlich verwickelt und undurchsichtig sind.


73 


Die Anlage zur Induktion 

• In der Programmierung stößt man oft auf die 

Denkfalle, daß bestätigende Informationen 

überschätzt werden 

• Der Programmierer gibt sich oft schon mit 

einer schwachen Lösung zufrieden 

• Nach einer besseren wird nicht gesucht 

• Das Programm wird für optimal gehalten, nur 

weil es offensichtlich funktioniert. 


74 


3 Bedingungen des Denkens 

Die Bedingungen des Denkens betreffen die 

parallele Darstellung der Denkinhalte und den 

sequentiellen Ablauf der bewußten Denk-vorgänge, 

d.h. die raum-zeitliche Organisation des Denkens 

Assoziationen 

• Neue Denkinhalte werden in ein Netz von 

miteinander assoziierten Informationen 

eingebettet 

• Bei der Aktivierung eines solchen Denkinhalts 

wird das assoziative Umfeld mit aktiviert 

• Geht es beim Programmieren um die Zuordnung 

von Bezeichnern und Bedeutungen, dann spielen 

Assoziationen eine Rolle.


75 


Assoziationen 

• Mnemotechnische Namen können irreführend 

sein 

• Es wird eher an den Namen als an die Bedeutung 

geglaubt 

• Eine sorglose Bezeichnerwahl kann zur 

Verwirrung führen 

Einstellungen 

• Fehler im Problemlösungsprozeß führen dazu, 

daß... 

◦ entweder gar keine Lösung gefunden wird, obwohl sie 

existiert 

◦ oder daß nur eine mangelhafte Lösung erkannt wird, die 

noch weit vom Optimum entfernt ist. 


76 


Einstellungen 

• Einstellungen führen zu einer vorgeprägten 

Ausrichtung des Denkens 

• Sie können zurückgehen auf... 

◦ die Erfahrungen aus früheren Problemlöseversuchen in 

ähnlichen Situationen 

◦ die Gewöhnung und Mechanisierung durch wiederholte 

Anwendung eines Denkschemas 

◦ die Gebundenheit von Methoden und Werkzeugen an 

bestimmte Verwendungszwecke 

◦ die Vermutung von Vorschriften, wo es keine gibt 

(Verbotsirrtum).


77 


Einstellungen 

• Um Fehler durch Einstellungen zu verhindern, 

sollte das Aufzeigen von Lösungsalternativen 

und eine Begründung der Methodenwahl zum 

festen Bestandteil der Problembearbeitung 

gemacht werden 

• Einstellungen führen zu determinierenden 

Tendenzen beim Problemlösen: 

◦ Die Anziehungskraft, die von einem nahen (Teil-)Ziel 

ausgeht, verhindert das Auffinden eines 

problemlösenden Umwegs 

◦ Die vorhandenen Strukturen und Teillösungen lenken 

den weiteren Lösungsprozeß in bestimmte Bahnen. 


78 

13.5 Selbstkontroliertes Programmieren 

Der erfahrene Programmierer lernt aus 

seinen Fehlern 

Er hält sich an Regeln und Vorschriften, die 

der Vermeidung dieser Fehler dienen 

In diesem Sinne ist das Programmieren eine 

Erfahrungswissenschaft 

Jeder Programmierer sollte für sich einen 

Katalog von Programmierregeln aufstellen und 

fortlaufend verbessern 

Es entsteht ein Regelkreis des 

selbstkontrollierten Programmierens.


79 


 

Der Regelkreis des selbstkontrollierten 

Programmierens 

Programmspezifikation 

Katalog von Programmierregeln 

Programmieren 

Fehleranalyse 

Programm 

Versagen 

korrekte Ergebnisse 


80 

Typische Programmierfehler (1) 

 

Unnatürliche Zahlen 

Negative Zahlen werden oft falsch behandelt 

• In der täglichen Erfahrung tauchen negative 

Zahlen nicht auf, weil sie »unnatürlich« sind 

Ursache: Prägnanzprinzip 

Beispiel: 

• Oft werden für die Beendigung der Eingabe 

die Werte 0 oder negative Werte verwendet 

• Diese Verwendung »unnatürlicher Zahlen« 

als Endezeichen vermischt zwei Funktionen, 

nämlich das Beenden des 

Eingabevorganges und die Werteeingabe.


81 


 

Ausnahme- und Grenzfälle 

Vorzugsweise werden nur die Normalfälle 

behandelt 

Sonderfälle und Ausnahmen werden 

übersehen 

Es werden nur die Fälle erfaßt, die man für 

repräsentativ hält 

Ursachen: Kausalitätserwartung, 

Sparsamkeitsprinzip 

Beispiele: 

• »Um eins daneben« Fehler 

• Indexzählfehler. 


82 


 

Falsche Hypothesen 

Erfahrene Programmierer haben Faustregeln 

entwickelt, sich einfache Hypothesen und 

Modelle über die Arbeitsweise eines 

Computers zurechtgelegt 

Aber: Dieses Wissen veraltet, mit einer 

Änderung der Umwelt werden die Hypothesen 

falsch 


Beispiele: 

• Multiplikationen dauern wesentlich länger 

als Additionen 

• Potenzieren ist aufwendiger als 

Multiplizieren.


83 


 

Tücken der Maschinenarithmetik 

Sonderfall der falschen Hypothesen 

Der Computer hält sich nicht an die Regeln der 

Algebra und Analysis 

Reelle Zahlen werden nur mit begrenzter 

Genauigkeit dargestellt 


Beispiele: 

• Abfrage auf Gleichheit reeller Zahlen, statt 

abs(a – b ) < epsilon; 

• Aufsummierung unendlicher Reihen: 

Summanden werden so klein, daß ihre 

Beträge bei der Rundung verlorengehen. 


84 


 

 

Irreführende Namen 

Wahl eines Namens, der eine falsche Semantik 

vortäuscht 

Daraus ergibt sich eine fehlerhafte Anwendung 

Ursache: Assoziationstäuschung 

Unvollständige Bedingungen 

Das konsequente Aufstellen komplexer 

logischer Bedingungen fällt schwer 

Häufig ist die Software nicht so komplex, wie 

das zu lösende Problem 

Ursache: Kausalitätserwartung.


85 


 

Unverhoffte Variablenwerte 

Die Komplexität von Zusammenhängen wird 

nicht erfaßt 

Ursache: Scheinwerferprinzip, 

Kausalitätserwartung 

Beispiele: 

• Verwechslung global wirksamer Größen mit 

Hilfsgrößen 

• Falsche oder vergessene Initialisierung von 

Variablen. 


86 


 

Wichtige Nebensachen 

Die Unterteilung von Programmen in 

sicherheitskritische und sicherheitsunkritische 

Teile, in eigentliches Programm und 

Kontrollausdrucke führt oft zur 

Vernachlässigung der »Nebensachen« 

Dadurch entstehen Programme mit 

»abgestufter Qualität«, wobei Fehler in den 

»Nebensachen« oft übersehen werden 


Beispiel: 

• Fehler bei der Plazierung von 

Kontrollausdrucken täuschen Fehler im 

Programm vor.

87 



 

Trügerische Redundanz 

Durch achtloses Kopieren werden Strukturen 

geschaffen, die den menschlichen 

Denkapparat überfordern 

Übertriebene Kommentierung von 

Programmen erhöht die Redundanz eines 

Programms 

Ursache: Anlage zur Induktion 

Beispiele: 

• Weiterentwicklumg eines Programms 

geschieht nicht an der aktuellen Version, 

sondern an einem Vorläufer 

• Bei Programmänderungen wird vergessen, 

den Kommentar ebenfalls zu ändern. 

88 



 

Gebundenheit 

Boolesche Ausdrücke treten oft in Verbindung 

mit Entscheidungen auf 

Dies führt in anderen Situationen zu 

komplizierten Ausdrücken 

Ursache: funktionale Gebundenheit 

boolescher Ausdrücke 

Beispiel: 

• if B then x:=true else x:= false 

anstelle von 

• x:=B (B=beliebiger boolescher Ausdruck).


89 


 

Das Lernen aus Fehlern ist besonders gut 

geeignet, um Denkfallen zu vermeiden 

Im Laufe des Anpassungsprozesses wird der 

»Scheinwerfer der Aufmerksamkeit« auf die 

kritischen Punkte gerichtet 

Jeder Programmierer sollte einen Regelkatalog 

in einer Datei bereithalten und an seine 

Bedürfnisse anpassen 

Das Lernen aus Fehlern wird außerdem 

dadurch gefördert, daß man die Fehler 

dokumentiert 

• Es sollte ein Fehlerbuch angelegt werden, 

das eine Sammlung typischer Fehler enthält. 


90 


 

Ein Fehler sollte in ein Fehlerbuch 

eingetragen werden, wenn... 

die Fehlersuche lange gedauert hat 

die durch den Fehler verursachten Kosten 

hoch waren oder 

der Fehler lange unentdeckt geblieben ist.


91 


 

Folgende Daten sollten im Fehlerbuch 

erfaßt werden: 

Laufende Fehlernummer 

Datum (wann entstanden, wann entdeckt) 

Programmname mit Versionsangabe 

Fehlerkurzbeschreibung (Titel) 

Ursache (Verhaltensmechanismus) 

Rückverfolgung 

• Gab es schon Fehler derselben Sorte? 

• Warum war eine früher vorgeschlagene 

Gegenmaßnahme nicht wirksam? 

Programmierregel, Gegenmaßnahme 

Ausführliche Fehlerbeschreibung. 


92 

Regelkatalog zur Vermeidung von Fehlern (1) 

 

Grundsätze des Programmentwurfs 

Auf Lesbarkeit achten 

• Bedeutung der Prinzipien Verbalisierung, 

problemadäquate Datentypen, integrierte 

Dokumentation. 

Nach der Methode der schrittweisen 

Verfeinerung vorgehen 

Sparsamkeit bei Schnittstellen- und 

Variablendeklarationen 

• Globale Variablen vermeiden 

• kurze Parameterlisten 

• Gültigkeitsbereiche von Variablen möglichst 

stark beschränken.


93 


 

Das Programm und seine Teile gliedern in: 

• Initialisierung, Eingabe, Verarbeitung, 

Ausgabe 

Verwendung linearer Kontrollstrukturen 

• Sequenz, Auswahl, Wiederholung, Aufruf 

Regeln gegen das Prägnanzprinzip 

Fehlerkontrolle durchführen 

• Sorgfalt besonders bei Diskretisierung 

kontinuierlicher Größen 

• Bei numerischen Programmen 

Maschinenarithmetik beachten. 


94 


Nie reelle Zahlen auf Gleichheit oder 

Ungleichheit abfragen 

Keine temporäre Ausgabebefehle verwenden 

• Ausgabebefehle zur Unterstützung von 

Tests in Auswahlanweisungen plazieren und 

global ein- und ausschalten 

Faustregeln von Zeit zu Zeit überprüfen 

• Effizienzsteigernde Tricks können durch 

neue Hardware unnötig werden.


95 


 

Regeln gegen das lineare Kausaldenken 

Redundanz reduzieren 

• Prozeduren verwenden, anstatt mehrfach 

verwendete Teile zu kopieren 

• Kommentare sparsam verwenden, besser 

gute Bezeichner und passende 

Datenstrukturen wählen 

Zusicherungen ins Programm einbauen 

• Als Kommentare ins Programm einfügen 

else-Teil einer Auswahl kommentieren 

• Als Kommentar angeben, welche 

Bedingungen für einen else-Teil gelten. 


96 


 

 

Ist ein Fehler gefunden: weitersuchen 

• In der Umgebung von Fehlern sind meist weitere 

ETn und Entscheidungsbäume beim Aufstellen 

komplexer logischer Bedingungen verwenden 

Regeln gegen die Überschätzung 

bestätigender Informationen 

Alternativen suchen 

• Stets davon ausgehen, daß es noch bessere 

Lösungen gibt 

• Aktivierung von Heuristiken 

Regeln gegen irreführende Assoziationen 

Bezeichner wählen, die Variablen und Operationen 

möglichst exakt bezeichnen.


97 


 

Heuristiken 

Hat man ein Problem und keine Lösungsidee, 

dann kann die bewußte Aktivierung von 

Heuristiken helfen, Denkblockaden 

aufzubrechen und gewohnte Denkbahnen zu 

verlassen 

Heuristiken sind Lösungsfindeverfahren, die 

auf Hypothesen, Analogien oder Erfahrungen 

aufgebaut sind. 


98 

Heuristiken für die Programmierung (1) 

 

 

 

 

Basisheuristik 

Kann ich in der Liste der Heuristiken eine 

finden, die mir weiterhilft? 

Analogie 

Habe ich ein ähnliches Problem schon einmal 

bearbeitet? 

Kenne ich ein verwandtes Problem? 

Verallgemeinerung 

Hilft mir der Übergang von einem Objekt zu 

einer Klasse von Objekten weiter? 

Spezialisierung 

Bringt es mich weiter, wenn ich zunächst einen 

leicht zugänglichen Spezialfall löse?


99 


 

 

 

Variation 

Komme ich durch eine Veränderung der 

Problemstellung der Lösung näher? 

Kann ich die Problemstellung anders 

ausdrücken? 

Rückwärtssuche 

Ich betrachte das gewünschte Ergebnis 

• Welche Operationen können mich zu diesem 

Ergebnis führen? 

Teile und herrsche 

Läßt sich das Problem in leichter lösbare 

Teilprobleme zerlegen? 


100 


 

Vollständige Enumeration 

Ich lasse einen Teil der Bedingungen weg 

• Kann ich mir Lösungen verschaffen, die 

wenigstens einen Teil der Zielbedingungen 

erfüllen? 

• Kann ich mir alle Lösungen verschaffen, die 

diese Bedingungen erfüllen?

13 Die Implementierungsphase 13 Die Implementierungsphase Zur ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?