© Helmut Balzert 1998 LE 32 1 Software-Technik 4 Die Implementierungsphase Prof. Dr. Helmut Balzert...

© Helmut Balzert 1998

LE 32

1Software-Technik

4 Die Implementierungsphase

Prof. Dr. Helmut Balzert

Lehrstuhl für Software-Technik

Ruhr-Universität Bochum

I SWT - Die Implementierungsphase

LE 32

2Einführung und Überblick

LE 1

V Unternehmensmodellierung

2 LE

1 Grundlagen

LE 24

2 ObjektorientierteUnternehmensmodellierung

LE 25

I SW-Entwicklung

32 LE

6 Die Wartungs- & Pflegephase

LE 33

5 Die Abnahme- undEinführungsphase

LE 33

4 Die Implementierungsphase

LE 32

3 Die Entwurfsphase

LE 23 – 31

2 Die Definitionsphase

LE 4 – 22

1 Die Planungsphase

LE 2 – 3

III SW-Qualitäts-sicherung

11 LE

6 Produktqualität– Systeme

LE 18 – 19

5 Produktqualität– Komponenten

LE 14 – 17

4 Prozeßqualität

LE 12 – 13

3 ManuellePrüfmethoden

LE 11

2 Qualitäts-sicherung

LE 10

1 Grundlagen

LE 9

II SW-Management

8 LE

6 Kontrolle

LE 8

5 Leitung

LE 6 – 7

4 Personal

LE 5

3 Organisation

LE 3 – 4

2 Planung

LE 2

1 Grundlagen

LE 1

IV Querschnitte und Ausblicke

4 LE

4 Sanierung

LE 23

1 Prinzipien& Methoden

LE 20

3 Wieder-verwendung

LE 22

2

LE 21


LE 32

3Lernziele Ein gegebenes Programm überprüfen

können, ob die vorgestellten Implementierungsprinzipien eingehalten wurden

Die vorgestellten Implementierungsprinzipien bei der Erstellung eines Programms berücksichtigen können

Die Methode der schrittweisen Verfeinerung bei der Erstellung eines Programms anwenden können

Die beschriebenen Regeln und Richtlinien bei der Erstellung von Programmen beachten können.


LE 32

4Inhalt

4 Die Implementierungsphase4.1 Einführung und Überblick

4.2 Prinzipien der Implementierung

4.2.1 Prinzip der Verbalisierung

4.2.2 Prinzip der problemadäquaten Datentypen

4.2.3 Prinzip der Verfeinerung

4.2.4 Prinzip der integrierten Dokumentation

4.3 Methode der schrittweisen Verfeinerung

4.4 Zur Psychologie des Programmierens

4.5 Selbstkontrolliertes Programmieren

4.6 Programmierrichtlinien am Beispiel von C++.


LE 32

54 Die Implementierungsphase Zur Historie

Prof. Dr. Niklaus Wirth*15.2.1934 in Winterthur, SchweizProfessor an der ETH Zürich

Erfinder der ProgrammiersprachenPascal (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.


LE 32

64.1 Einführung und Überblick 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.


LE 32

74.1 Einführung und Überblick Voraussetzungen

In der Entwurfsphase wurde eine Software-architektur 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.


LE 32

84.1 Einführung und Überblick 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.


LE 32

94.1 Einführung und Überblick

Implementierungsprozeß

Quellprogramme inkl. DokumentationObjektprogrammeTestplanung und Testprotokollbzw. Verifikationsdokumentation

Planungsphase

Definitionsphase

Lastenheft

Produkt-Definition

Produkt-Entwurf

Programme, Gesamt-produkt

Installiertes Produkt

Entwurfsphase

Implementierungs-phase

Abnahme- undEinführungsphase

SoftwarearchitekturSpezifikation der Systemkomponenten

Legende:

Phasenergebnis

Weitergabe vonTeilprodukten

Phase


LE 32

104.1 Einführung und Überblick 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.


LE 32

114.1 Einführung und Überblick Teilprodukte

Quellprogramm einschl. integrierter Dokumentation Objektprogramm Testplanung und Testprotokoll bzw.

Verifikationsdokumentation

Alle Teilprodukte aller Systemkomponenten müssen integriert und einem Systemtest unterzogen werden.


LE 32

124.1 Einführung und Überblick Basiskonzepte zur Implementierung der

Systemkomponenten: Kontrollstrukturen

nur »lineare Kontrollstrukturen« »Strukturiertes Programmieren i. e. S.«

Entscheidungstabellen.


LE 32

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


LE 32

144.2.1 Prinzip der Verbalisierung Verbalisierung

Gedanken und Vorstellungen in Worten ausdrücken und damit ins Bewußtsein bringen

Gute Verbalisierung Aussagekräftige, mnemonische

Namensgebung Geeignete Kommentare Selbstdokumentierende Programmiersprache.


LE 32

154.2.1 Prinzip der Verbalisierung 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.


LE 32


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


LE 32


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.


LE 32


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.


LE 32

194.2.1 Prinzip der Verbalisierung 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

{ ...}.


LE 32

204.2.1 Prinzip der Verbalisierung 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.


LE 32

214.2.1 Prinzip der Verbalisierung 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.


LE 32

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


LE 32

234.2.2 Prinzip der problemadäquate Datentypen 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.


LE 32

244.2.2 Prinzip der problemadäquate Datentypen

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);.


LE 32


Typkonstruktor Feld verwenden, wenn:a Zusammenfassung gleicher Datentypenb Zugriff wird dynamisch berechnet (während der

Laufzeit)c Hohe Komponentenanzahl möglichd Feldgrenzen statisch, dynamisch oder unspezifizierte Mittlere Zugriffszeit auf eine Komponente,

unabhängig vom Wert des Indexf 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];


LE 32


Typkonstruktor Verbund verwenden, wenn:a Zusammenfassung logischer Daten mit

unterschiedlichen Typenb Zugriff wird statisch berechnet (zur

Übersetzungszeit)c Anzahl der Komponenten ist immer festd Jede Komponente ist einzeln benannt, daher ist

der Umfang begrenzte Kurze Zugriffszeit auf Komponente erwünschtf Bei varianten Verbunden ist die Mehrfach-

auswahl die geeignete Kontrollstruktur.


LE 32


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;

};.


LE 32

284.2.2 Prinzip der problemadäquate Datentypen 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.


LE 32

294.2.2 Prinzip der problemadäquate Datentypen 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.


LE 32

304.2.3 Prinzip der Verfeinerung 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.


LE 32

314.2.3 Prinzip der Verfeinerung 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

}.


LE 32

324.2.3 Prinzip der Verfeinerung// refinements: 1. Verfeinerung:

// Eingabe

cout << "1. Zinsdatums:"; cin >> Datum1;

cout << "2. Zinsdatums:"; cin >> Datum2; cout << endl;


// Aufgliederung in Tag

// Aufgliederung in Monat


if (Tag1 == 31) Tag1 = 30;

if (Tag2 == 31) Tag2 = 30;


Tage = (Monat2 - Monat1) * 30 + Tag2 - Tag1;

// Ausgabe

if (Tage < 0) cout << "Fehler: 1. Datum liegt vor dem 2. Datum!“ << endl;

else cout << "Anzahl der Zinstage = " << Tage;.


LE 32

334.2.3 Prinzip der Verfeinerung// refinements: 2. Verfeinerung:



int Tag1, Tag2; // Hilfsgroessen

Tag1 = Datum1 / 100;



int Monat1, Monat2; // Hilfsgroessen

Monat1 = Datum1 % 100;


// end berechneZinstage()

+ Sowohl der Kern des Algorithmus als auch die Verfeinerungsstufen sind deutlich sichtbar

+ Die Verfeinerungen muß man sich nur ansehen, wenn man sich für die Details interessiert.


LE 32

344.2.3 Prinzip der Verfeinerung 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 << "1. Zinsdatums:"; cin >> Datum1;

cout << “2. Zinsdatums:"; cin >> Datum2; cout << endl;.


LE 32

354.2.3 Prinzip der Verfeinerung// Aufgliederung in Tag und Monat








if (Tag1 == 31) Tag1 = 30;

if (Tag2 == 31) Tag2 = 30;


Tage = (Monat2 - Monat1) * 30 + Tag2 - Tag1;

// Ausgabe

if (Tage < 0) cout << "Fehler: 1. Datum liegt vor dem 2. Datum!" << endl;

else cout << "Anzahl der Zinstage = " << Tage;.


LE 32

364.2.3 Prinzip der Verfeinerung

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.


LE 32

374.2.3 Prinzip der Verfeinerung 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.


LE 32

384.2.4 Prinzip der integrierten Dokumentation Dokumentation

Integraler Bestandteil jedes Programms

Ziele der Dokumentation: Angabe von Verwaltungsinformationen Erleichterung der Einarbeitung Beschreibung der Entwicklungs-

entscheidungen Warum wurde welche Alternative gewählt?.


LE 32

394.2.4 Prinzip der integrierten Dokumentation Richtlinie

Folgende Verwaltungsinformationen sind am Anfang eines Programms aufzuführen (Vorspann des Programms):

1 Name des Programms

2 Name des bzw. der Programmautoren (Vor- und Nachname)

3 Versionsnummer, Status und Datum

4 Aufgabe des Programms: Kurzgefaßte Beschreibung

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


LE 32

404.2.4 Prinzip der integrierten Dokumentation 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.


LE 32

414.2.4 Prinzip der integrierten Dokumentation 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.


LE 32

424.2.4 Prinzip der integrierten Dokumentation

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.


LE 32

434.2.4 Prinzip der integrierten Dokumentation 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).


LE 32

444.2.4 Prinzip der integrierten Dokumentation 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.


LE 32

454.2.4 Prinzip der integrierten Dokumentation 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.


LE 32

464.3 Methode der schrittweisen Verfeinerung 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.


LE 32

474.3 Methode der schrittweisen Verfeinerung Beispiel:

Zur Konzentration der Einkaufs-, Vertriebs- und 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.


LE 32


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);.


LE 32


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.


LE 32

504.3 Methode der schrittweisen Verfeinerung1. 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).


LE 32


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.


LE 32

524.3 Methode der schrittweisen Verfeinerung// 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;.


LE 32

534.3 Methode der schrittweisen Verfeinerung// 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;.


LE 32

544.3 Methode der schrittweisen Verfeinerung// 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).


LE 32


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.


LE 32


3. Schritt: Weitere Verfeinerung// 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“ };.


LE 32

574.3 Methode der schrittweisen Verfeinerung3. Schritt: Weitere Verfeinerung// Umsetzung der verbal beschriebenen Anweisungen

// in die verwendete Zielsprache

// Vorbereitung: (1)

for (Gebiet = BADEN; Gebiet <= AUSLAND; Gebiet++)

{

TabelleUmsatzProGebiet[Gebiet].UmsatzNeu=0.0;

TabelleUmsatzProGebiet[Gebiet].ProzentAbweichung=0;

}

// for alle Weinartikel do: (2a)

for (ArtikelNr = 1; ArtikelNr <= 2000; ArtikelNr++)

// Weinumsatz pro Artikel lesen: (2b)

ErmittleWeinumsatz(ArtikelNr, Umsatz, Gebiet, Ok);

// Umsatz in TabelleUmsatzProGebiet aufaddieren: (2c)

if (Ok)

TabelleUmsatzProGebiet[Gebiet].UmsatzNeu += Umsatz;.


LE 32


3. Schritt: Weitere Verfeinerung// Alte Umsatzstatistik lesen:

(3a)

UmsatzAltLesen(UmsatzListeAlt);

// for alle Anbaugebiete do: (3b)


// Umsatzwerte vergleichen; (3c)

// Prozentuale Abweichung ausrechnen

// und in TabelleUmsatzProGebiet speichern: (3d)

TabelleUmsatzProGebiet[Gebiet].ProzentAbweichung =

TabelleUmsatzProGebiet[Gebiet].UmsatzNeu * 100 /

UmsatzListeAlt[Gebiet] - 100;.


LE 32


3. Schritt: Weitere Verfeinerung// Neue Werte in alte Liste eintragen: (4a)


UmsatzListeAlt[Gebiet] =

TabelleUmsatzProGebiet[Gebiet].UmsatzNeu;

// Drucke Ueberschrift: (5a)

cout << "Umsatzstatistik nach Anbaugebieten" << endl;

// Drucke(Anbaugebiet,Umsatz, Prozentabweichung): (5b)

cout << GText[Anbaugebiet] << " "<< Umsatz << " "

<< Prozentabweichung << endl;

Damit ist dieses Problem mit Hilfe der schrittweisen Verfeinerung vollständig gelöst

Eine Substitution ergibt ein »klassisches Programm«.


LE 32

604.3 Methode der schrittweisen Verfeinerung 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.


LE 32


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.


LE 32

624.3 Methode der schrittweisen Verfeinerung 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.


LE 32

634.3 Methode der schrittweisen Verfeinerung 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.


LE 32

644.4 Zur Psychologie des Programmierens 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.


LE 32

654.4 Zur Psychologie des Programmierens 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.


LE 32

664.4 Zur Psychologie des Programmierens Klassifizierung von Programmierfehlern

Programmierfehler

Irrtümer Schnitzer

individuell

Begabung Ausbildungerlerntes Verhalten(Tradition)

angeborenesVerhalten

überindividuell(Denkfallen)


LE 32

674.4 Zur Psychologie des Programmierens »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.


LE 32

684.4 Zur Psychologie des Programmierens 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.


LE 32

694.4 Zur Psychologie des Programmierens 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.


LE 32


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.


LE 32


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.


LE 32


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.


LE 32


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.


LE 32


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.


LE 32


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.


LE 32


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.


LE 32


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.


LE 32


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.


LE 32


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


LE 32


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.


LE 32

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


LE 32

824.5 Selbstkontroliertes Programmieren Der Regelkreis des selbstkontrollierten

Programmierens

Programmspezifikation Katalog von Programmierregeln

Programmieren

Programm

Fehleranalyse

korrekte Ergebnisse

Versagen


LE 32

83Typische 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.


LE 32

84Typische Programmierfehler (2) 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.


LE 32

85Typische Programmierfehler (3) 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

Ursache: Prägnanzprinzip Beispiele:

Multiplikationen dauern wesentlich länger als Additionen

Potenzieren ist aufwendiger als Multiplizieren.


LE 32

86Typische Programmierfehler (4) 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 Ursache: Prägnanzprinzip 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.


LE 32

87Typische Programmierfehler (5) 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.


LE 32

88Typische Programmierfehler (6) 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.


LE 32

89Typische Programmierfehler (7) 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

Ursache: Prägnanzprinzip Beispiel:

Fehler bei der Plazierung von Kontrollausdrucken täuschen Fehler im Programm vor.


LE 32

90Typische Programmierfehler (8) 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.


LE 32

91Typische Programmierfehler (9) 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).


LE 32

924.5 Selbstkontroliertes Programmieren 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.


LE 32

934.5 Selbstkontroliertes Programmieren 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.


LE 32

944.5 Selbstkontroliertes Programmieren 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.


LE 32

95Regelkatalog 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.


LE 32

96Regelkatalog zur Vermeidung von Fehlern (2)

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.


LE 32


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.


LE 32

98Regelkatalog zur Vermeidung von Fehlern (4) 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.


LE 32


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.


LE 32

1004.5 Selbstkontroliertes Programmieren 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.


LE 32

101Heuristiken 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?


LE 32

102Heuristiken für die Programmierung (2) 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?


LE 32

103Heuristiken für die Programmierung (3) 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?


LE 32

1044.6 Programmierrichtlinien für C++ Richtlinien

Sind für den Programmierer verbindlich und müssen unbedingt eingehalten werden

Die Einhaltung muß überwacht werden Wenn möglich durch Werkzeuge Wenn nötig manuelle Überprüfung

Die Einhaltung der Richtlinien muß eine echte Qualitätsverbesserung bewirken

Empfehlungen Sollen nach Möglichkeit eingehalten werden Abweichungen sind in Ausnahmefällen erlaubt Sie müssen durch entsprechende Kommentare

im Quellprogramm begründet werden.


LE 32

1054.6 Programmierrichtlinien für C++ C++-Richtlinien als Beispiele:

Richtlinien für Bezeichner Richtlinien für die Formatierung Richtlinien für den OO-Teil Richtlinien für den prozeduralen Teil Richtlinien für portables, d.h. plattform- und

compilerübergreifendes Programmieren Richtlinien zur Projektorganisation.


LE 32

106C++-Richtlinien für Bezeichner (1) Bezeichner

Natürlichsprachige oder problemnahe Namen oder verständliche Abkürzungen solcher Namen

Kein Bezeichner beginnt mit einem Unterstrich _ Für Bibliotheksfunktionen oder

Präprozessornamen reserviert Generell Groß-/Kleinschreibung

2 Bezeichner dürfen sich nicht nur bzgl. der Groß-/Kleinschreibung unterscheiden

Klassennamen beginnen immer mit einem Großbuchstaben.

Präprozessornamen immer groß.


LE 32

107C++-Richtlinien für Bezeichner (2) Deutsche oder englische Namensgebung

Ausnahme: Allgemein übliche englische Begriffe, z.B. push

Länge des Bezeichners Allgemein zwischen 5 und 15 Zeichen

Für Laufvariablen in for-Schleifen und als array-Indizes Kleinbuchstaben erlaubt, z.B. i, j, k

Für Zeiger-»Laufvariablen« Man kann p und q benutzen.


LE 32

108C++-Richtlinien für Bezeichner (3) Bezeichner aus mehreren Worten

Jedes Wort beginnt mit einem Großbuchstaben Beispiel: AnzahlWorte

Unterstriche werden nicht zur Trennung eingesetzt Funktionen und Operationen

Führen Aktionen aus, daher sollte der Namen ein Verb enthalten Beispiele: void Sortiere(int Zahlen [ ]);

Geht das relevante Objekt, mit dem die Aktion ausgeführt wird, nicht aus der Parameterliste hervor, dann ist es in den Namen aufzunehmen Beispiele:

void DruckeRechnung(int Nr) int LesePosZahl();.


LE 32

109C++-Richtlinien für Bezeichner (4)

Wenn Operation nur Instanzvariable liest oder schreibt Namen soll mit Get bzw. Set beginnen Ausnahme: Anderer Namen bringt bessere

Lesbarkeit Beispiel: int GetXKoord()

Variablen detailliert beschreiben Beispiele: ZeilenZaehler, WindGeschw, DateiStatus Folgende Präfixe besitzen eine spezielle Bedeutung:

a-/ein- irgendeine Instanz einer Klasse Beispiele: aStack, einKunde

global- globale Variable Beispiel: globalError.


LE 32

110C++-Richtlinien für Bezeichner (5)

Folgendes Postfix besitzt eine spezielle Bedeutung: -Z/-Ptr Zeigervariable

Beispiele: anObjectPtr, AnkerZ

Bei Strukturen unnötige Redundanz vermeiden Variablenbezeichner und Member-Bezeichner müssen

einen aussagefähigen Namen ergeben Beispiel:

struct PersonT{ char Name[ ]int Alter;};

PersonT Person;

Person.Name = "Hans";

Person.Alter = 24;

Der Strukturbezeichner erhält das Postfix T.


LE 32

111C++-Richtlinien für Bezeichner (6) Alle Typbezeichner

Erhalten das Postfix T Beispiel: enum FarbeT {blau, rot, weiss};

Mit typedef aussagefähige Typbezeichnungen einführen Beispiel:

typedef unsigned int ArtikelnrT;ArtikelnrT Artikelnr;

Variablen vom Typ bool Jeder Bezeichner wie folgt:

Richtig, EingabeRichtig, Gefunden, ZahlGefunden, Offen, TuerOffen.


LE 32

112C++-Richtlinien für die Formatierung (1) Leerzeichen

Bei binären Operatoren Operanden und Operator durch jeweils ein

Leerzeichen trennen, z.B. Zahl1 + Zahl2 * 3 Keine Leerzeichen innerhalb von Referenzen

Beispiele: Adresse.Name, AdressPtr–>Name, Angestellter[10], Matrix[10] [2]

Zwischen Funktionsname und Klammer Kein Leerzeichen, z.B. ZinsBerechnen()

Nach der öffnenden und vor der schließenden Klammer Kein Leerzeichen: GGT(123,124);clrscr();

Nach Schlüsselwörtern 1 Leerzeichen, z. B. if (....).


LE 32

113C++-Richtlinien für die Formatierung (2) Leerzeilen

Leerzeilen sollen Blöcke von logisch zusammenhängenden Anweisungen trennen

Der Deklarationsteil soll stets durch eine Leerzeile von den Anweisungen getrennt werden

Jeder Funktionsdeklaration soll eine Leerzeile vorausgehen

Umfangreiche Kontrollstrukturen sind durch eine Leerzeile zu trennen

Umfangreiche Deklarationen sind durch eine Leerzeile zu trennen.


LE 32

114C++-Richtlinien für die Formatierung (3) Einrücken und Klammern von Strukturen

Bei allen Kontrollstrukturen gilt eine Einrücktiefe von 4 Leerzeichen

Läßt Platz für aussagefähige Bezeichner, z.B.

if (Bedingung1) {

{ Anweisung4;

Anweisung1; Anweisung5;

if(Bedingung2) }

Anweisung2; do

else {

Anweisung3; Anweisung;

}}while(Bedingung);

else.


LE 32

115C++-Richtlinien für die Formatierung (4) Funktionen/Operationen

Jede Funktion/Operation ist wie folgt zu deklarieren:

//--------- Point::MoveTo ---------------

void Point::MoveTo(int newX, int NewY)

{

Hide();

X = NewX;

Y = NewY;

Show();

}.


LE 32

116C++-Richtlinien für die Formatierung (5) Einheitlicher Aufbau einer Klasse

Folgende Reihenfolge ist einzuhalten: public-Member-Funktionen

aus dem objektorientierten Entwurf

protected-Daten und -Funktionen alle verkapselten Daten sind protected zu vereinbaren

private-Deklarationen Alle Member-Funktionen sind in folgender Gruppierung

aufzuführen: Konstruktoren Destruktoren Operatoren, z.B. Zuweisung, Vergleich Operationen mit schreibendem ZugriffOperationen

mit lesendem Zugriff.


LE 32

117C++-Richtlinien für den OO-Teil (1) Zugriffsrechte

Verkapselte Daten (Member-Daten) sind generell als protected zu definieren

Member-Funktionen sind als public zu definieren Friend-Funktionen sind nur in begründeten

Ausnahmefällen zu verwenden Friends werden weder vererbt noch sind sie

transitiv

Operationen mit lesendem Zugriff Damit die Operation keine Veränderung auf den

verkapselten Daten durchführen kann, ist sie mit const zu vereinbaren Beispiel: const char* get_name() const;.


LE 32

118C++-Richtlinien für den OO-Teil (2) Inline-Funktionen

Verletzen das Geheimnisprinzip, daher nur bei erheblichen Leistungsverbesserungen verwenden

extern inline-Funktionen bieten die gleichen Vorteile, bewahren aber das Geheimnisprinzip

Virtuelle Funktionen Operationen einer Klasse, die in einer Unterklasse

detailliert werden, sind grundsätzlich als virtuell zu vereinbaren

Dann ist sichergestellt, daß immer die Operation der Unterklasse aufgerufen wird, auch wenn der Zugriff über einen Zeiger der Oberklasse erfolgt ist Beispiel: .


LE 32

119C++-Richtlinien für den OO-Teil (3)

class B class D: public B

{public: {public:

virtual void f1(); void f1();

void f2() void f2();

... ...

}; };

D d; B*bptr = &d;

bptr–>f1();//ruft D::f1

bptr–>f2();//ruft B::f2


LE 32

120C++-Richtlinien für den OO-Teil (4) Konstruktoren

Ein Default-Konstruktor ist ein Konstruktor, der ohne Argumente aufgerufen werden kann, z.B. Complex ().

Ist für eine Klasse ein Konstruktor definiert, dann muß ein Default-Konstruktor definiert sein, oder sein Fehlen begründet werden

Destruktoren Wird kein Destruktor angegeben, dann erzeugt der

Compiler automatisch einen Default-Destruktor, der nicht virtuell ist

Um den Polymorphismus auszunutzen, ist der Destruktor stets virtuell zu deklarieren

Beispiel: .


LE 32

121C++-Richtlinien für den OO-Teil (5)

class B class D: public B

{public: {public:

virtual ~B(); virtual ~D();

... ...

}; };

D d; B*bptr = &d;

delete (bptr); //ruft Destruktor

von D, // wenn Destruktor// virtuell,//sonst Destruktur

von B.


LE 32

122C++-Richtlinien für den OO-Teil (6) Abstrakte Klassen

Jede abstrakte Klasse ist durch einen Kommentar zu kennzeichnen, z.B. class Abstract //abstrakte Klasse

Eine abstrakte Klasse muß mindestens eine pure virtual member function besitzen

Dadurch wird sichergestellt, daß von dieser Klasse keine Objekte gebildet werden können, z.B. virtual void do_something() = 0; //pure virtual member function.


LE 32

123C++-Richtlinien für den OO-Teil (7) Generische Klassen

Von generischen Klassen sind nicht direkt Objekte zu bilden, sondern es sind zuvor Typen oder Klassen zu bilden: Nicht: Node<char> aNode; Sondern: typedef Node<char> Char_Node; Char_Node aNode;

class Char_Node: public Node <char> {}; Char_Node aNode.


LE 32

124C++-Richtlinien für den prozeduralen Teil (1) Ein-/Ausgabe in C++

Bei Ein-/Ausgabefunktionen sind grundsätzlich die Routinen der iostream-Bibliothek zu verwenden

Die entsprechenden C-Routinen sind weder typsicher noch erlauben sie die Integration benutzerdefinierter Klassen in das E/A-System

Verwendung von Feldern (arrays) Zugriff über Feldname & Index Liste[Index] ist

besser lesbar, als Zeigerzugriff *(Liste + Index) Zeigerzugriff ist bei mehrdimensionalen Feldern

effizienter, jedoch nur marginal Wichtiger ist die bessere Lesbarkeit und die

einfachere Indexüberprüfung beim Indexzugriff.


LE 32

125C++-Richtlinien für den prozeduralen Teil (2)

Felder immer vollständig initialisieren Beispiel:int Matrix[2][2] = { {1,0}, {1,0} };

Verwendung von Zeigern Zeiger sind ein mächtiges, aber auch ein gefährliches

Sprachkonzept Ein Zeiger wird häufig auf den Feldanfang gesetzt:

int *pWert;

int Werte [Max];

...

pWert = &Werte[0]; oder pWert = Werte; Während die 1. Form lesbarer ist, ist die 2. Form

verbreiteter und kann daher auch gewählt werden.


LE 32

126C++-Richtlinien für den prozeduralen Teil (3) Variablendeklaration

Variablen sind zu Beginn eines Blocks zu vereinbaren Laufvariablen sind immer im Initialsierungsteil zu

deklarieren

for int (i=0; i < 10; i++) {}; Verwendung von Konstanten

Offenkundige Konstanten sind als Konstanten zu definieren, z.B.

const int MaxZeilen = 24,

MaxSpalten = 80; Für Aufzählungen Aufzählungstypen verwenden

enum StatusT = {ok, SchreibFehler, LeseFehler, DisketteVoll};.


LE 32

127C++-Richtlinien für den prozeduralen Teil (4)

Voneinander abhängige Konstanten durch Formeln wiedergeben, z.B.

const int Hoehe = 10,

Breite = 25,

Flaeche = Hoehe * Breite; Call-by-reference Parameter

Immer wählen, wenn eine Funktion Werte zurückgibt Bei umfangreichen Datenstrukturen call-by-reference

auch bei Eingabeparametern Unbeabsichtigte Veränderung der Eingabeparameter

mit const verhindern, z.B.

void DruckeAdresse(const AdresseT& Adresse);.


LE 32

128C++-Richtlinien für portables Programmieren (1) Ganzzahlige Datentypen

Verfügen in C/C++ über keinen garantierten Wertebereich

Daher selbstdefinierte Datentypen verwenden, die auf jeder Plattform exakt denselben Wertebereich abdecken In einer Datei folgende Datentypen vereinbaren:

int32 vorzeichenbehaftete 32-Bit Integer-Zahl uint32 vorzeichenlose 32-Bit Integer-Zahl short16 vorzeichenbehaftete 16-Bit Integer-Zahl ushort16 vorzeichenlose 16-Bit Integer-Zahl char8 ein Zeichen

(vorzeichenbehaftete 8-Bit Integer-Zahl)

uchar8 vorzeichenlose 8-Bit Zahl String Objekt der Klasse String.


LE 32

129C++-Richtlinien für portables Programmieren (2) Die Klasse String

Verschiedene Compiler besitzen verschiedene Implementierungen der Klasse String, die teilweise nicht zueinander kompatibel sind Daher sollte eine selbstentwickelte String-Klasse

oder die dem ANSI-Standard entsprechende benutzt werden

Definieren von Aufzählungstypen Viele Compiler erlauben folgende Definition:

typedef enum x {...}; typedef ist an dieser Stelle überflüssig und wird

von einigen Compilern nicht akzeptiert.


LE 32

130C++-Richtlinien für portables Programmieren (3) Zeichensätze

Auf verschiedenen Rechnern sind Zeichen mit einem Code >127 und damit alle Umlaute unterschiedlich kodiert Umlaute auf keinen Fall in Kommentaren

benutzen! Sind Zeichenketten mit Umlauten notwendig

Den Programmtext mit einem Editor bearbeiten, der im ISO-Latin_1-Zeichensatz speichern kann

Beispiele: der einfache Windows-Editor (notepad.exe) der vi von Linux (elvis).


LE 32

131C++-Richtlinien für portables Programmieren (4) Initialisierung von Variablen

Die meisten Compiler weisen Variablen, die bei der Deklaration nicht explizit initialisiert werden, keinen Wert zu

Dies gilt besonders für lokale Variablen, die auf dem Keller angelegt werden und damit einen zufälligen Wert erhalten

Codeteile, die definierte Werte in definierten Variablen benötigen, erfordern eine ordnungsgemäße Initialisierung der Variablen.


LE 32

132C++-Richtlinien für portables Programmieren (5) Dateiverwaltung

DOS- und Unix-Dateisysteme sind ähnlich aufgebaut

Der Aufbau der Dateinamen ist jedoch unterschiedlich

Unix ist ein Mehrbenutzer-System Daher ist beim Anlegen bzw. Öffnen von Dateien

immer zu prüfen, ob der Benutzer die Berechtigung für die Operation hat

Objekte bzw. Operationen, die mit Dateien arbeiten, sollten immer einen aussagefähigen Fehlercode liefern.


LE 32

133C++-Richtlinien für portables Programmieren (6) Standardeingabe- und -ausgabekanäle

Statt in die Kanäle cout/cerr bzw. cin zu schreiben Referenzen auf Objekte der Klassen ostream

oder istream erzeugen Diese je nach Betriebssystem auf Standardkanäle

bzw. in eine Datei schreiben lassen.


LE 32

134C++-Richtlinien zur Projektorganisation (1) Projektverwaltung

Spezifikation und Implementierung auf 2 Dateien aufteilen, um das Geheimnisprinzip zu realisieren Beispiel:

Spezifikation in die Datei counter.h (Header-Datei) Implementierung in die Datei counter.cpp

// counter.h //counter.cpp

class Counter #include "counter.h"

{ { //––– Konstruktor––––

public: Counter::Counter()

Counter(); {...}

void up();

protected: //––– Counter::up ––––

int count; void up()

}; {...}.


LE 32

135C++-Richtlinien zur Projektorganisation (2)

Bei Klassenhierarchien können (bei kleinem Umfang) mehrere Spezifikationen und Implementierungen jeweils in einer Datei enthalten sein , z.B. Location –> Point –> Circle in den Dateien figures.h und figures.cpp

Präprozessor-Anweisungen Wird eine Header-Datei mehrfach inkludiert, dann treten

Fehlermeldungen auf Daher wird bei jeder Header-Datei (z.B. queue.h)

folgender Mechanismus verwendet: Sie beginnt stets mit

#ifndef QUEUE_H

#define QUEUE_H und endet mit

#endif //QUEUE_H.


LE 32

136

Danke! Aufgaben

Diese Präsentation bzw. Teile dieser Präsentation enthalten Inhalte und Grafiken des Lehrbuchs der Software-Technik (Band 1) von Helmut Balzert, Spektrum Akademischer Verlag, Heidelberg 1996

© Helmut Balzert 1998 LE 32 1 Software-Technik 4 Die Implementierungsphase Prof. Dr. Helmut Balzert...

Documents

Transcript of © Helmut Balzert 1998 LE 32 1 Software-Technik 4 Die Implementierungsphase Prof. Dr. Helmut Balzert...