Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "© Helmut Balzert 1998 LE 32 1 Software-Technik 4 Die Implementierungsphase Prof. Dr. Helmut Balzert Lehrstuhl für Software-Technik Ruhr-Universität Bochum."—  Präsentation transkript:

1

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

3 I SWT - Die Implementierungsphase LE 32 2

4 I SWT - Die Implementierungsphase LE 32 3 Lernziele s Ein gegebenes Programm überprüfen können, ob die vorgestellten Implementierungsprinzipien eingehalten wurden s Die vorgestellten Implementierungsprinzipien bei der Erstellung eines Programms berücksichtigen können s Die Methode der schrittweisen Verfeinerung bei der Erstellung eines Programms anwenden können s Die beschriebenen Regeln und Richtlinien bei der Erstellung von Programmen beachten können.

5 I SWT - Die Implementierungsphase LE 32 4 Inhalt 4 Die Implementierungsphase 4.1 Einführung und Überblick 4.2 Prinzipien der Implementierung Prinzip der Verbalisierung Prinzip der problemadäquaten Datentypen Prinzip der Verfeinerung 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++.

6 I SWT - Die Implementierungsphase LE Die Implementierungsphase s 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.

7 I SWT - Die Implementierungsphase LE Einführung und Überblick s 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 s Implementierungsphase: Durchführung der Programmiertätigkeiten Eingebettet zwischen der Entwurfsphase und der Abnahme- und Einführungsphase.

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

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

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

11 I SWT - Die Implementierungsphase LE Einführung und Überblick s 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 s Auch »Programmieren im Kleinen« genannt.

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

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

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

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

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

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

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

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

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

21 I SWT - Die Implementierungsphase LE Prinzip der Verbalisierung s 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; s Besonders wichtige Kommentare In einen Kommentarkasten.

22 I SWT - Die Implementierungsphase LE Prinzip der Verbalisierung s Grad der Kommentierung Abhängig davon, ob Programmiersprache selbstdokumentierend ADA gilt in dieser Beziehung als vorbildlich C++ ist ein schlechtes Beispiel s Vorteile der Verbaliserung + Leichte Einarbeitung in fremde Programme bzw. Wiedereinarbeitung in eigene Programme + Erleichtert »code reviews«, Modifikationen und Wartung + Verbesserte Lesbarkeit der Programme.

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

24 I SWT - Die Implementierungsphase LE Prinzip der problemadäquate Datentypen s Aufgabe des Programmierers Angebot an Konzepten einer Programmiersprache optimal zur problemnahen Lösungsformulierung verwenden s 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.

25 I SWT - Die Implementierungsphase LE 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);.

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

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

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

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

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

31 I SWT - Die Implementierungsphase LE Prinzip der Verfeinerung s Verfeinerung Dient dazu, ein Programm durch Abstraktionsebenen zu strukturieren s 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.

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

33 I SWT - Die Implementierungsphase LE Prinzip der Verfeinerung // refinements: 1. Verfeinerung: // Eingabe cout > Datum1; cout > 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;.

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

35 I SWT - Die Implementierungsphase LE Prinzip der Verfeinerung s Da die meisten Programmiersprachen eine solche Darstellung nicht erlauben, müssen die Verfeinerungen substituiert werden: void berechneZinstage() { int Datum1, Datum2; // Eingabedaten, Form TTMM int Tage; // Ausgabedaten //Voraussetzung: Die Daten liegen innerhalb eines Jahres int Tag1, Tag2; // Hilfsgroessen int Monat1, Monat2; // Hilfsgroessen // Eingabe cout > Datum1; cout > Datum2; cout << endl;.

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

37 I SWT - Die Implementierungsphase LE 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.

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

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

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

41 I SWT - Die Implementierungsphase LE Prinzip der integrierten Dokumentation s 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 s Die Version kennzeichnet zusammen mit dem Status den Bearbeitungszustand des Programms.

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

43 I SWT - Die Implementierungsphase LE 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.

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

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

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

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

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

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

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

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

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

53 I SWT - Die Implementierungsphase LE 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;.

54 I SWT - Die Implementierungsphase LE 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;.

55 I SWT - Die Implementierungsphase LE 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).

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

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

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

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

60 I SWT - Die Implementierungsphase LE Methode der schrittweisen Verfeinerung 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; s Damit ist dieses Problem mit Hilfe der schrittweisen Verfeinerung vollständig gelöst s Eine Substitution ergibt ein »klassisches Programm«.

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

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

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

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

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

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

67 I SWT - Die Implementierungsphase LE Zur Psychologie des Programmierens s Klassifizierung von Programmierfehlern

68 I SWT - Die Implementierungsphase LE Zur Psychologie des Programmierens s »Schnitzer« sind Tippfehler, Versprecher usw. Sie werden vor allem durch eine schlechte Benutzungsoberfläche verursacht s Irrtümer sind der Kategorie »Wissen« zuzuordnen Diesen Fehlern ist gemeinsam, daß der Programmierer den Fehler auch beim wiederholten Durchlesen seines Programms nicht sieht.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

83 I SWT - Die Implementierungsphase LE Selbstkontroliertes Programmieren s Der Regelkreis des selbstkontrollierten Programmierens

84 I SWT - Die Implementierungsphase LE Typische Programmierfehler (1) s 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ägnanzprinzipPrä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.

85 I SWT - Die Implementierungsphase LE Typische Programmierfehler (2) s 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, SparsamkeitsprinzipKausalitätserwartung Sparsamkeitsprinzip Beispiele: »Um eins daneben« Fehler Indexzählfehler.

86 I SWT - Die Implementierungsphase LE Typische Programmierfehler (3) s 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ägnanzprinzipPrägnanzprinzip Beispiele: Multiplikationen dauern wesentlich länger als Additionen Potenzieren ist aufwendiger als Multiplizieren.

87 I SWT - Die Implementierungsphase LE Typische Programmierfehler (4) s 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ägnanzprinzipPrä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.

88 I SWT - Die Implementierungsphase LE Typische Programmierfehler (5) s Irreführende Namen Wahl eines Namens, der eine falsche Semantik vortäuscht Daraus ergibt sich eine fehlerhafte Anwendung Ursache: AssoziationstäuschungAssoziationstäuschung s 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.Kausalitätserwartung.

89 I SWT - Die Implementierungsphase LE Typische Programmierfehler (6) s Unverhoffte Variablenwerte Die Komplexität von Zusammenhängen wird nicht erfaßt Ursache: Scheinwerferprinzip, KausalitätserwartungScheinwerferprinzip, Kausalitätserwartung Beispiele: Verwechslung global wirksamer Größen mit Hilfsgrößen Falsche oder vergessene Initialisierung von Variablen.

90 I SWT - Die Implementierungsphase LE Typische Programmierfehler (7) s 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ägnanzprinzipPrägnanzprinzip Beispiel: Fehler bei der Plazierung von Kontrollausdrucken täuschen Fehler im Programm vor.

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

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

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

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

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

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

97 I SWT - Die Implementierungsphase LE Regelkatalog zur Vermeidung von Fehlern (2) Das Programm und seine Teile gliedern in: Initialisierung, Eingabe, Verarbeitung, Ausgabe Verwendung linearer Kontrollstrukturen Sequenz, Auswahl, Wiederholung, Aufruf s Regeln gegen das Prägnanzprinzip Fehlerkontrolle durchführen Sorgfalt besonders bei Diskretisierung kontinuierlicher Größen Bei numerischen Programmen Maschinenarithmetik beachten.

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

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

100 I SWT - Die Implementierungsphase LE Regelkatalog zur Vermeidung von Fehlern (5) Ist ein Fehler gefunden: weitersuchen In der Umgebung von Fehlern sind meist weitere ETn und Entscheidungsbäume beim Aufstellen komplexer logischer Bedingungen verwenden s Regeln gegen die Überschätzung bestätigender Informationen Alternativen suchen Stets davon ausgehen, daß es noch bessere Lösungen gibt Aktivierung von Heuristiken s Regeln gegen irreführende Assoziationen Bezeichner wählen, die Variablen und Operationen möglichst exakt bezeichnen.

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

102 I SWT - Die Implementierungsphase LE Heuristiken für die Programmierung (1) s Basisheuristik Kann ich in der Liste der Heuristiken eine finden, die mir weiterhilft? s Analogie Habe ich ein ähnliches Problem schon einmal bearbeitet? Kenne ich ein verwandtes Problem? s Verallgemeinerung Hilft mir der Übergang von einem Objekt zu einer Klasse von Objekten weiter? s Spezialisierung Bringt es mich weiter, wenn ich zunächst einen leicht zugänglichen Spezialfall löse?

103 I SWT - Die Implementierungsphase LE Heuristiken für die Programmierung (2) s Variation Komme ich durch eine Veränderung der Problemstellung der Lösung näher? Kann ich die Problemstellung anders ausdrücken? s Rückwärtssuche Ich betrachte das gewünschte Ergebnis Welche Operationen können mich zu diesem Ergebnis führen? s Teile und herrsche Läßt sich das Problem in leichter lösbare Teilprobleme zerlegen?

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

105 I SWT - Die Implementierungsphase LE Programmierrichtlinien für C++ s 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 s Empfehlungen Sollen nach Möglichkeit eingehalten werden Abweichungen sind in Ausnahmefällen erlaubt Sie müssen durch entsprechende Kommentare im Quellprogramm begründet werden.

106 I SWT - Die Implementierungsphase LE Programmierrichtlinien für C++ s 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 für portables, d.h. plattform- und compilerübergreifendes Programmieren Richtlinien zur Projektorganisation. Richtlinien zur Projektorganisation

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

108 I SWT - Die Implementierungsphase LE C++-Richtlinien für Bezeichner (2) s Deutsche oder englische Namensgebung Ausnahme: Allgemein übliche englische Begriffe, z.B. push s Länge des Bezeichners Allgemein zwischen 5 und 15 Zeichen s Für Laufvariablen in for-Schleifen und als array-Indizes Kleinbuchstaben erlaubt, z.B. i, j, k s Für Zeiger-»Laufvariablen« Man kann p und q benutzen.

109 I SWT - Die Implementierungsphase LE C++-Richtlinien für Bezeichner (3) s Bezeichner aus mehreren Worten Jedes Wort beginnt mit einem Großbuchstaben Beispiel: AnzahlWorte Unterstriche werden nicht zur Trennung eingesetzt s 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();.

110 I SWT - Die Implementierungsphase LE C++-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() s 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.

111 I SWT - Die Implementierungsphase LE C++-Richtlinien für Bezeichner (5) Folgendes Postfix besitzt eine spezielle Bedeutung: -Z/-Ptr Zeigervariable Beispiele: anObjectPtr, AnkerZ s 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.

112 I SWT - Die Implementierungsphase LE C++-Richtlinien für Bezeichner (6) s Alle Typbezeichner Erhalten das Postfix T Beispiel: enum FarbeT {blau, rot, weiss}; s Mit typedef aussagefähige Typbezeichnungen einführen Beispiel: typedef unsigned int ArtikelnrT; ArtikelnrT Artikelnr; s Variablen vom Typ bool Jeder Bezeichner wie folgt: Richtig, EingabeRichtig, Gefunden, ZahlGefunden, Offen, TuerOffen.

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

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

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

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

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

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

119 I SWT - Die Implementierungsphase LE C++-Richtlinien für den OO-Teil (2) s Inline-Funktionen Verletzen das Geheimnisprinzip, daher nur bei erheblichen Leistungsverbesserungen verwenden extern inline-Funktionen bieten die gleichen Vorteile, bewahren aber das Geheimnisprinzip s 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:.

120 I SWT - Die Implementierungsphase LE C++-Richtlinien für den OO-Teil (3) class B class D: public B {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

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

122 I SWT - Die Implementierungsphase LE C++-Richtlinien für den OO-Teil (5) class B class D: public B {public: virtual ~B(); virtual ~D();... }; D d; B*bptr = &d; delete (bptr); //ruft Destruktor von D, // wenn Destruktor // virtuell, //sonst Destruktur von B.

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

124 I SWT - Die Implementierungsphase LE C++-Richtlinien für den OO-Teil (7) s Generische Klassen Von generischen Klassen sind nicht direkt Objekte zu bilden, sondern es sind zuvor Typen oder Klassen zu bilden: Nicht: Node aNode; Sondern: typedef Node Char_Node; Char_Node aNode; class Char_Node: public Node {}; Char_Node aNode.

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

126 I SWT - Die Implementierungsphase LE C++-Richtlinien für den prozeduralen Teil (2) Felder immer vollständig initialisieren Beispiel: int Matrix[2][2] = { {1,0}, {1,0} }; s 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.

127 I SWT - Die Implementierungsphase LE C++-Richtlinien für den prozeduralen Teil (3) s Variablendeklaration Variablen sind zu Beginn eines Blocks zu vereinbaren Laufvariablen sind immer im Initialsierungsteil zu deklarieren for int (i=0; i < 10; i++) {}; s 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};.

128 I SWT - Die Implementierungsphase LE C++-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; s 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);.

129 I SWT - Die Implementierungsphase LE C++-Richtlinien für portables Programmieren (1) s 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: int32vorzeichenbehaftete 32-Bit Integer-Zahl uint32 vorzeichenlose 32-Bit Integer-Zahl short16 vorzeichenbehaftete 16-Bit Integer-Zahl ushort16vorzeichenlose 16-Bit Integer-Zahl char8 ein Zeichen (vorzeichenbehaftete 8-Bit Integer-Zahl) uchar8 vorzeichenlose 8-Bit Zahl String Objekt der Klasse String.

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

131 I SWT - Die Implementierungsphase LE C++-Richtlinien für portables Programmieren (3) s 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: Hder einfache Windows-Editor (notepad.exe) Hder vi von Linux (elvis).

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

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

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

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

136 I SWT - Die Implementierungsphase LE C++-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 s 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.

137 I SWT - Die Implementierungsphase LE s Danke! s Aufgaben Aufgaben s 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


Herunterladen ppt "© Helmut Balzert 1998 LE 32 1 Software-Technik 4 Die Implementierungsphase Prof. Dr. Helmut Balzert Lehrstuhl für Software-Technik Ruhr-Universität Bochum."

Ähnliche Präsentationen


Google-Anzeigen