Implementierungsphase

Implementierungsphase
Software-Technik LE 32 4 Die Implementierungsphase Prof. Dr. Helmut Balzert Lehrstuhl für Software-Technik Ruhr-Universität Bochum

I SWT - Die Implementierungsphase

Lernziele LE 32 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.

4 Die Implementierungsphase
I SWT - Die Implementierungsphase Inhalt LE 32 4 Die Implementierungsphase 4.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++.

4 Die Implementierungsphase
I SWT - Die Implementierungsphase 4 Die Implementierungsphase LE 32 Zur Historie Prof. Dr. Niklaus Wirth * 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.

4.1 Einführung und Überblick
I SWT - Die Implementierungsphase 4.1 Einführung und Überblick LE 32 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.

I SWT - Die Implementierungsphase 4.1 Einführung und Überblick LE 32 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: Datenobjekt-Modul Datentyp-Modul Objektorientierter Entwurf: Klassen.

I SWT - Die Implementierungsphase 4.1 Einführung und Überblick LE 32 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.

I SWT - Die Implementierungsphase 4.1 Einführung und Überblick LE 32

I SWT - Die Implementierungsphase 4.1 Einführung und Überblick LE 32 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.

I SWT - Die Implementierungsphase 4.1 Einführung und Überblick LE 32 Teilprodukte Quellprogramm einschl. integrierter Dokumentation Objektprogramm Testplanung und Testprotokoll bzw. Verifikationsdokumentation Alle Teilprodukte aller Systemkomponenten müssen integriert und einem Systemtest unterzogen werden.

I SWT - Die Implementierungsphase 4.1 Einführung und Überblick LE 32 Basiskonzepte zur Implementierung der Systemkomponenten: Kontrollstrukturen nur »lineare Kontrollstrukturen« »Strukturiertes Programmieren i. e. S.« Entscheidungstabellen.

4.2 Prinzipien der Implementierung
I SWT - Die Implementierungsphase 4.2 Prinzipien der Implementierung LE 32 Bei der Implementierung sollten folgende Prinzipien eingehalten werden: Prinzip der Verbalisierung Prinzip der problemadäquaten Datentypen Prinzip der Verfeinerung Prinzip der integrierten Dokumentation.

4.2.1 Prinzip der Verbalisierung
I SWT - Die Implementierungsphase 4.2.1 Prinzip der Verbalisierung LE 32 Verbalisierung Gedanken und Vorstellungen in Worten ausdrücken und damit ins Bewußtsein bringen Gute Verbalisierung Aussagekräftige, mnemonische Namensgebung Geeignete Kommentare Selbstdokumentierende Programmiersprache.

I SWT - Die Implementierungsphase 4.2.1 Prinzip der Verbalisierung LE 32 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.

I SWT - Die Implementierungsphase 4.2.1 Prinzip der Verbalisierung 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 Praemie = Grundpraemie2 + Zulage1 * Dienstjahre;.

I SWT - Die Implementierungsphase 4.2.1 Prinzip der Verbalisierung LE 32 Beispiel 3 Praemie = * 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.

I SWT - Die Implementierungsphase 4.2.1 Prinzip der Verbalisierung 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.

I SWT - Die Implementierungsphase 4.2.1 Prinzip der Verbalisierung LE 32 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 { ...}.

I SWT - Die Implementierungsphase 4.2.1 Prinzip der Verbalisierung LE 32 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.

I SWT - Die Implementierungsphase 4.2.1 Prinzip der Verbalisierung LE 32 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.

4.2.2 Prinzip der problemadäquate Datentypen
I SWT - Die Implementierungsphase 4.2.2 Prinzip der problemadäquate Datentypen LE 32 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.

I SWT - Die Implementierungsphase 4.2.2 Prinzip der problemadäquate Datentypen LE 32 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.

I SWT - Die Implementierungsphase 4.2.2 Prinzip der problemadäquate Datentypen LE 32 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);.

I SWT - Die Implementierungsphase 4.2.2 Prinzip der problemadäquate Datentypen LE 32 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];

I SWT - Die Implementierungsphase 4.2.2 Prinzip der problemadäquate Datentypen LE 32 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 Mehrfach-auswahl die geeignete Kontrollstruktur.

I SWT - Die Implementierungsphase 4.2.2 Prinzip der problemadäquate Datentypen 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; };.

I SWT - Die Implementierungsphase 4.2.2 Prinzip der problemadäquate Datentypen LE 32 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.

I SWT - Die Implementierungsphase 4.2.2 Prinzip der problemadäquate Datentypen LE 32 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.

4.2.3 Prinzip der Verfeinerung
I SWT - Die Implementierungsphase 4.2.3 Prinzip der Verfeinerung LE 32 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.

I SWT - Die Implementierungsphase 4.2.3 Prinzip der Verfeinerung LE 32 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 }.

I SWT - Die Implementierungsphase 4.2.3 Prinzip der Verfeinerung LE 32 // refinements: 1. Verfeinerung: // Eingabe cout << "1. Zinsdatums:"; cin >> Datum1; cout << "2. Zinsdatums:"; cin >> Datum2; cout << endl; // Aufgliederung in Tag und Monat // Aufgliederung in Tag // Aufgliederung in Monat // Beruecksichtigung der Sonderfaelle if (Tag1 == 31) Tag1 = 30; if (Tag2 == 31) Tag2 = 30; // Berechnung der Tage 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;.

I SWT - Die Implementierungsphase 4.2.3 Prinzip der Verfeinerung LE 32 // refinements: 2. Verfeinerung: // Aufgliederung in Tag und Monat // Aufgliederung in Tag int Tag1, Tag2; // Hilfsgroessen Tag1 = Datum1 / 100; Tag2 = Datum2 / 100; // Aufgliederung in Monat int Monat1, Monat2; // Hilfsgroessen Monat1 = Datum1 % 100; Monat2 = Datum2 % 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.

I SWT - Die Implementierungsphase 4.2.3 Prinzip der Verfeinerung LE 32 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;.

I SWT - Die Implementierungsphase 4.2.3 Prinzip der Verfeinerung LE 32 // Aufgliederung in Tag und Monat // Aufgliederung in Tag Tag1 = Datum1 / 100; Tag2 = Datum2 / 100; // Aufgliederung in Monat Monat1 = Datum1 % 100; Monat2 = Datum2 % 100; // Beruecksichtigung der Sonderfaelle if (Tag1 == 31) Tag1 = 30; if (Tag2 == 31) Tag2 = 30; // Berechnung der Tage 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;.

I SWT - Die Implementierungsphase 4.2.3 Prinzip der Verfeinerung LE 32 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.

I SWT - Die Implementierungsphase 4.2.3 Prinzip der Verfeinerung LE 32 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.

4.2.4 Prinzip der integrierten Dokumentation
I SWT - Die Implementierungsphase 4.2.4 Prinzip der integrierten Dokumentation LE 32 Dokumentation Integraler Bestandteil jedes Programms Ziele der Dokumentation: Angabe von Verwaltungsinformationen Erleichterung der Einarbeitung Beschreibung der Entwicklungs-entscheidungen Warum wurde welche Alternative gewählt?.

I SWT - Die Implementierungsphase 4.2.4 Prinzip der integrierten Dokumentation LE 32 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.

I SWT - Die Implementierungsphase 4.2.4 Prinzip der integrierten Dokumentation LE 32 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.

I SWT - Die Implementierungsphase 4.2.4 Prinzip der integrierten Dokumentation LE 32 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.

I SWT - Die Implementierungsphase 4.2.4 Prinzip der integrierten Dokumentation LE 32 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.

I SWT - Die Implementierungsphase 4.2.4 Prinzip der integrierten Dokumentation LE 32 Beispiel: Programmvorspann // Programmname: XYZ //**************************************************** // Autor 1: Vorname Nachname // Autor 2: Vorname Nachname // Version: V1.0 in Bearbeitung // vorgelegt // akzeptiert // V1.1 in Bearbeitung // vorgelegt // Aufgabe: Aufgabenbeschreibung // Zeitkomplexitaet: O(n log 2n) // Speicherkomplexitaet O(2n).

I SWT - Die Implementierungsphase 4.2.4 Prinzip der integrierten Dokumentation LE 32 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.

I SWT - Die Implementierungsphase 4.2.4 Prinzip der integrierten Dokumentation LE 32 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.

4.3 Methode der schrittweisen Verfeinerung
I SWT - Die Implementierungsphase 4.3 Methode der schrittweisen Verfeinerung LE 32 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.

I SWT - Die Implementierungsphase 4.3 Methode der schrittweisen Verfeinerung LE 32 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.

I SWT - Die Implementierungsphase 4.3 Methode der schrittweisen Verfeinerung 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);.

I SWT - Die Implementierungsphase 4.3 Methode der schrittweisen Verfeinerung 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.

I SWT - Die Implementierungsphase 4.3 Methode der schrittweisen Verfeinerung LE 32 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).

I SWT - Die Implementierungsphase 4.3 Methode der schrittweisen Verfeinerung 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.

I SWT - Die Implementierungsphase 4.3 Methode der schrittweisen Verfeinerung LE 32 // 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;.

I SWT - Die Implementierungsphase 4.3 Methode der schrittweisen Verfeinerung LE 32 // 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;.

I SWT - Die Implementierungsphase 4.3 Methode der schrittweisen Verfeinerung LE 32 // 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).

I SWT - Die Implementierungsphase 4.3 Methode der schrittweisen Verfeinerung 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.

I SWT - Die Implementierungsphase 4.3 Methode der schrittweisen Verfeinerung 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“ };.

I SWT - Die Implementierungsphase 4.3 Methode der schrittweisen Verfeinerung LE 32 3. 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;.

I SWT - Die Implementierungsphase 4.3 Methode der schrittweisen Verfeinerung LE 32 3. Schritt: Weitere Verfeinerung // Alte Umsatzstatistik lesen: (3a) UmsatzAltLesen(UmsatzListeAlt); // for alle Anbaugebiete do: (3b) for (Gebiet = BADEN; Gebiet <= AUSLAND; Gebiet++) // Umsatzwerte vergleichen; (3c) // Prozentuale Abweichung ausrechnen // und in TabelleUmsatzProGebiet speichern: (3d) TabelleUmsatzProGebiet[Gebiet].ProzentAbweichung = TabelleUmsatzProGebiet[Gebiet].UmsatzNeu * 100 / UmsatzListeAlt[Gebiet] - 100;.

I SWT - Die Implementierungsphase 4.3 Methode der schrittweisen Verfeinerung LE 32 3. Schritt: Weitere Verfeinerung // Neue Werte in alte Liste eintragen: (4a) for (Gebiet = BADEN; Gebiet <= AUSLAND; Gebiet++) 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«.

I SWT - Die Implementierungsphase 4.3 Methode der schrittweisen Verfeinerung LE 32 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.

I SWT - Die Implementierungsphase 4.3 Methode der schrittweisen Verfeinerung 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.

I SWT - Die Implementierungsphase 4.3 Methode der schrittweisen Verfeinerung LE 32 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.

I SWT - Die Implementierungsphase 4.3 Methode der schrittweisen Verfeinerung LE 32 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.

4.4 Zur Psychologie des Programmierens
I SWT - Die Implementierungsphase 4.4 Zur Psychologie des Programmierens LE 32 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.

I SWT - Die Implementierungsphase 4.4 Zur Psychologie des Programmierens LE 32 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.

I SWT - Die Implementierungsphase 4.4 Zur Psychologie des Programmierens LE 32 Klassifizierung von Programmierfehlern

I SWT - Die Implementierungsphase 4.4 Zur Psychologie des Programmierens LE 32 »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.

I SWT - Die Implementierungsphase 4.4 Zur Psychologie des Programmierens LE 32 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.

I SWT - Die Implementierungsphase 4.4 Zur Psychologie des Programmierens LE 32 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.

I SWT - Die Implementierungsphase 4.4 Zur Psychologie des Programmierens 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.

I SWT - Die Implementierungsphase 4.4 Zur Psychologie des Programmierens 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.

I SWT - Die Implementierungsphase 4.4 Zur Psychologie des Programmierens 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.

I SWT - Die Implementierungsphase 4.4 Zur Psychologie des Programmierens 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.

I SWT - Die Implementierungsphase 4.4 Zur Psychologie des Programmierens 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.

I SWT - Die Implementierungsphase 4.4 Zur Psychologie des Programmierens 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.

I SWT - Die Implementierungsphase 4.4 Zur Psychologie des Programmierens 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.

I SWT - Die Implementierungsphase 4.4 Zur Psychologie des Programmierens 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.

I SWT - Die Implementierungsphase 4.4 Zur Psychologie des Programmierens 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.

I SWT - Die Implementierungsphase 4.4 Zur Psychologie des Programmierens 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).

I SWT - Die Implementierungsphase 4.4 Zur Psychologie des Programmierens 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.

4.5 Selbstkontroliertes Programmieren
I SWT - Die Implementierungsphase 4.5 Selbstkontroliertes Programmieren LE 32 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.

I SWT - Die Implementierungsphase 4.5 Selbstkontroliertes Programmieren LE 32 Der Regelkreis des selbstkontrollierten Programmierens

Typische Programmierfehler (1)
I SWT - Die Implementierungsphase Typische Programmierfehler (1) LE 32 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.

I SWT - Die Implementierungsphase Typische Programmierfehler (2) LE 32 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.

I SWT - Die Implementierungsphase Typische Programmierfehler (3) LE 32 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.

I SWT - Die Implementierungsphase Typische Programmierfehler (4) LE 32 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.

I SWT - Die Implementierungsphase Typische Programmierfehler (5) LE 32 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.

I SWT - Die Implementierungsphase Typische Programmierfehler (6) LE 32 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.

I SWT - Die Implementierungsphase Typische Programmierfehler (7) LE 32 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.

I SWT - Die Implementierungsphase Typische Programmierfehler (8) LE 32 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.

I SWT - Die Implementierungsphase Typische Programmierfehler (9) LE 32 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).

I SWT - Die Implementierungsphase 4.5 Selbstkontroliertes Programmieren LE 32 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.

I SWT - Die Implementierungsphase 4.5 Selbstkontroliertes Programmieren LE 32 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.

I SWT - Die Implementierungsphase 4.5 Selbstkontroliertes Programmieren LE 32 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.

Regelkatalog zur Vermeidung von Fehlern (1)
I SWT - Die Implementierungsphase Regelkatalog zur Vermeidung von Fehlern (1) LE 32 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.

I SWT - Die Implementierungsphase Regelkatalog zur Vermeidung von Fehlern (2) LE 32 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.

I SWT - Die Implementierungsphase Regelkatalog zur Vermeidung von Fehlern (3) 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.

I SWT - Die Implementierungsphase Regelkatalog zur Vermeidung von Fehlern (4) LE 32 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.

I SWT - Die Implementierungsphase Regelkatalog zur Vermeidung von Fehlern (5) 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.

I SWT - Die Implementierungsphase 4.5 Selbstkontroliertes Programmieren LE 32 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.

Heuristiken für die Programmierung (1)
I SWT - Die Implementierungsphase Heuristiken für die Programmierung (1) LE 32 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?

I SWT - Die Implementierungsphase Heuristiken für die Programmierung (2) LE 32 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?

I SWT - Die Implementierungsphase Heuristiken für die Programmierung (3) LE 32 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?

4.6 Programmierrichtlinien für C++
I SWT - Die Implementierungsphase 4.6 Programmierrichtlinien für C++ LE 32 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.

4.6 Programmierrichtlinien für C++
I SWT - Die Implementierungsphase 4.6 Programmierrichtlinien für C++ LE 32 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.

C++-Richtlinien für Bezeichner (1)
I SWT - Die Implementierungsphase C++-Richtlinien für Bezeichner (1) LE 32 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ß.

I SWT - Die Implementierungsphase C++-Richtlinien für Bezeichner (2) LE 32 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.

I SWT - Die Implementierungsphase C++-Richtlinien für Bezeichner (3) LE 32 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();.

I SWT - Die Implementierungsphase C++-Richtlinien für Bezeichner (4) LE 32 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.

I SWT - Die Implementierungsphase C++-Richtlinien für Bezeichner (5) LE 32 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.

I SWT - Die Implementierungsphase C++-Richtlinien für Bezeichner (6) LE 32 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.

C++-Richtlinien für die Formatierung (1)
I SWT - Die Implementierungsphase C++-Richtlinien für die Formatierung (1) LE 32 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 (....).

I SWT - Die Implementierungsphase C++-Richtlinien für die Formatierung (2) LE 32 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.

I SWT - Die Implementierungsphase C++-Richtlinien für die Formatierung (3) LE 32 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.

I SWT - Die Implementierungsphase C++-Richtlinien für die Formatierung (4) LE 32 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(); }.

I SWT - Die Implementierungsphase C++-Richtlinien für die Formatierung (5) LE 32 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.

C++-Richtlinien für den OO-Teil (1)
I SWT - Die Implementierungsphase C++-Richtlinien für den OO-Teil (1) LE 32 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;.

I SWT - Die Implementierungsphase C++-Richtlinien für den OO-Teil (2) LE 32 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: .

I SWT - Die Implementierungsphase C++-Richtlinien für den OO-Teil (3) LE 32 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

I SWT - Die Implementierungsphase C++-Richtlinien für den OO-Teil (4) LE 32 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: .

I SWT - Die Implementierungsphase C++-Richtlinien für den OO-Teil (5) LE 32 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.

I SWT - Die Implementierungsphase C++-Richtlinien für den OO-Teil (6) LE 32 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.

I SWT - Die Implementierungsphase C++-Richtlinien für den OO-Teil (7) LE 32 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.

C++-Richtlinien für den prozeduralen Teil (1)
I SWT - Die Implementierungsphase C++-Richtlinien für den prozeduralen Teil (1) LE 32 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.

I SWT - Die Implementierungsphase C++-Richtlinien für den prozeduralen Teil (2) LE 32 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.

I SWT - Die Implementierungsphase C++-Richtlinien für den prozeduralen Teil (3) LE 32 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};.

I SWT - Die Implementierungsphase C++-Richtlinien für den prozeduralen Teil (4) LE 32 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);.

C++-Richtlinien für portables Programmieren (1)
I SWT - Die Implementierungsphase C++-Richtlinien für portables Programmieren (1) LE 32 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.

I SWT - Die Implementierungsphase C++-Richtlinien für portables Programmieren (2) LE 32 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.

I SWT - Die Implementierungsphase C++-Richtlinien für portables Programmieren (3) LE 32 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).

I SWT - Die Implementierungsphase C++-Richtlinien für portables Programmieren (4) LE 32 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.

I SWT - Die Implementierungsphase C++-Richtlinien für portables Programmieren (5) LE 32 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.

I SWT - Die Implementierungsphase C++-Richtlinien für portables Programmieren (6) LE 32 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.

C++-Richtlinien zur Projektorganisation (1)
I SWT - Die Implementierungsphase C++-Richtlinien zur Projektorganisation (1) LE 32 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() }; {...}.

C++-Richtlinien zur Projektorganisation (2)
I SWT - Die Implementierungsphase C++-Richtlinien zur Projektorganisation (2) LE 32 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.

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

Implementierungsphase

Ähnliche Präsentationen

Präsentation zum Thema: "Implementierungsphase"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Implementierungsphase

Ähnliche Präsentationen

Präsentation zum Thema: "Implementierungsphase"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback