Effizientes Programmieren - Methoden und Werkzeuge ...

Effizientes Programmieren - Methoden und 

Werkzeuge 

Dipl.-Inf. Martin Barbisch, Dipl.-Inf. Ursula Vollmer 

WS 2006/2007 

1 Martin Barbisch, Ursula Vollmer Effizientes Programmieren - Methoden und Werkzeuge 

Vorgehensmodelle 

Konsistenz / Style Guides 

DRY-Prinzip / Wiederverwendung 

Orthogonalität 

Automatisierung 

Refaktorisieren 

Software-Ergonomie 

Teil 1 - Methoden und Techniken 

1 Vorgehensmodelle 

2 Konsistenz / Style Guides 

3 DRY-Prinzip / Wiederverwendung 

4 Orthogonalität 

5 Automatisierung 

6 Refaktorisieren 

7 Software-Ergonomie 


Organisatorisches 

Kontakt: 

Martin Barbisch (Raum 3.5): 

martin.barbisch@ims.uni-stuttgart.de 

Ursula Vollmer (Raum 3.3): 

ursula.vollmer@ims.uni-stuttgart.de 

Sprechstunde(n): 

Martin Barbisch: nach Vereinbarung 

Ursula Vollmer: Mi, 10 - 11 Uhr 

Scheinbedingungen: 

Bearbeitung und Abgabe der Übungsaufgaben 

Bestehen des Abschlusstests (benoteter Schein) 

http://www.ims.uni-stuttgart.de/lehre/teaching/2006-WS/Effizientes-Programmieren 









Motivation (Thematik) 

Programmieren sehr komplex 

hoher Frustfaktor 

Verlässlichkeit (vor allem bei großen 

Projekten) 

4 Martin Barbisch, Ursula Vollmer Effizientes Programmieren - Methoden und Werkzeuge








Motivation (Zielgruppe) 

Erleichterung von größeren und kleineren 

Programmiertätigkeiten 

bereits während der Studienzeit (Aufgaben aus Seminaren, 

Studien-, Diplomarbeit, ...) 

Industrie 

Forschungsprojekte 









Überblick (Teil 2 - Werkzeuge) 

Programmiersprachen: 

Welche Programmiersprache für welche Aufgabenstellung? 

Editoren 

Versionskontrolle 

Fehlersuche 

Quellcode erzeugen / anpassen 

Dokumentationserstellung 

Tests 









Überblick (Teil 1 - Methoden / Techniken) 



DRY-Prinzip 

Wiederverwendung 




Exkurs: Software-Ergonomie 










Familien von Vorgehensmodellen 










Motivation Vorgehensmodelle 



Code and Fix: Codierung oder Korrektur im Wechsel mit 

Ad-hoc-Tests (unwirtschaftlich, aber weit verbreitet) 

Einarbeitung neuer Mitarbeiter 

externe Zertifizierung eines Unternehmens 


Phasenmodelle 








Zuordnung von Aktivitäten zu Phasen 



Phasen werden sequenziell hintereinander durchgeführt 

Übergang zur nächsten Phase setzt Abschluss der vorigen 

Phase voraus 

Ergebnisse einer Phase werden 

in der nächsten Phase weiterverarbeitet 

Meilenstein, um Projektfortschritt zu überprüfen 

(Projektmanagement) 









Gruppierung von Vorgehensmodellen 



Phasen- / Wasserfallmodelle: 

Object Modeling Technique (OMT) 

Prototypische und iterativ-inkrementelle Vorgehensmodelle: 

Spiralmodell 

Unified Process 

Extreme Programming 

Iterativ-inkrementelle Vorgehensmodelle: 

Booch 

Objectory 

Fusion 

Catalysis 

KobrA 









Meilenstein (Definition) 



Meilensteine sind Teilziele, 

die nicht durch geplante Zeitpunkte, 

sondern durch inhaltliche Kriterien definiert sind. 









Exkurs - Kernprozesse 

1 Planung 

2 Analyse 

3 Entwurf 

4 Programmierung 

5 Validierung & Verifikation 











Kernprozesse - Analyse 

Anforderungsanalyse 



Datenanalyse: Aufbereitung / Auswertung gesammelter Daten 

Prozessanalyse / Prozessmodell 

Systemanalyse: Black-Box-Modell (Ist- / Soll-Zustand) als 

Data Flow Diagram (Datenflussd.): 

Verarbeitung und Speicherung der Datenströme 

State Transition Diagram (Zustandsübergangsd.): 

zeitliches Verhalten 

Entity Relationship Diagram (Gegenstands-Beziehungs-D.): 

Datenverknüpfungen 









Kernprozesse - Planung 

Lastenheft (Anforderungsdefinition) 



Pflichtenheft (mit technischen Ansätzen verfeinertes 

Lastenheft) 

Aufwandsschätzung 

Vorgehensmodell 









Kernprozesse - Entwurf 



Softwarearchitektur: 

strukturierte oder hierarchische Anordnung der Komponenten 

Beschreibung der Beziehungen zwischen den Komponenten 

Strukturiertes Design: 

Strukturdiagramme 

Schnittstellenbeschreibung 

Aufrufhierarchien der Module 

Unified Modeling Language (UML) 









Entwurfsmuster - Motivation 



Lösungen für wiederkehrende Design-Probleme gesucht. 

Organisation/Struktur von (objektorientiertem) Quellcode 

verbessern. 

Erfahrungs- anstelle von Code-Wiederverwendung. 

Die veränderlichen Aspekte einer Anwendung von dem 

trennen was konstant bleibt. 

“Das einzig konstante in der Softwareentwicklung ist die 

Veränderung.” 









Entwurfsmuster - Die Erfinder 



Design Patterns (1995), Gamma, Helm, Johnson, Vlissides 

(The Gang of Four oder GoF) 

Idee Muster anzuwenden stammt von Professor Christopher 

Alexander, einem Architekten 











Entwurfsmuster - Was sind Entwurfsmuster? 

Definition 

Ein (Entwurfs-)Muster ist eine Lösung für ein Problem in einem 

bestimmten Kontext. 

Der Kontext ist die Situation, in der das Muster angewandt 

wird. (z.B. Sammlung von Objekten) 

Das Problem ist das Ziel, das erreicht werden soll, sowie 

Bedingungen. (z.B. alle Objekte durchgehen) 

Die Lösung ist ein allgemeines Design. (z.B. Kapsle die 

Iteration in einer separaten Klasse) 











Entwurfsmuster - Kategorien von Mustern 1 

Erzeugungsmuster 

Erzeugen Objekte. 

Fabrikmethode 

Singleton 

Strukturmuster 

Erzeugen aus Objekten/Klassen umfangreichere Strukturen. 

Adapter 

Fassade 

Verhaltensmuster 

Lassen Objekte interagieren. 

Beobachter 

Strategie 











Entwurfsmuster - Kategorien von Mustern 2 

Muster gibt es auch für viele andere Bereiche. 

Weitere Arten: 

Anwendungs-Muster (Client-Server, Schichtenmodelle) 

Benutzungsschnittstellen-Muster 

aus dem “echten” Leben: 

Geschäftsprozess-Muster 

Organisations-Muster 









Entwurfsmuster - Musterkataloge 

Gibt den einzelnen Mustern Namen, 

und ordnet sie Kategorien zu 

Beschreibt Muster und ihre 

Beziehungen untereinander 

Löst welches Problem? 

Ein Diagramm beschreibt die 

Beziehungen der beteiligten Klassen. 

Die Konsequenzen der Anwendung 

werden erläutert. (Vor-/Nachteile) 

Beispielcode 

In welchen Programmen wurde das 

Muster schon angewandt? 



Name, Klassifizierung 

Zweck 

Motivation 

Anwendbarkeit 

Struktur 

Teilnehmer 

Interaktionen 

Konsequenzen 

Implementierung 

Beispielcode 

Bekannte Verwendungen 

Verwandte Muster 











Entwurfsmuster - Gemeinsames Vokabular 

Besser: 

“Ich habe eine Broadcast-Klasse geschrieben. Sie merkt sich, 

welche Objekte ihr zuhören, und sagt ihnen Bescheid, wenn es 

neue Daten gibt. Ein Objekt kann sich jederzeit an- und 

wieder abmelden. Die Broadcast-Klasse muss nichts über die 

Zuhörer wissen, diese müssen nur ein bestimmtes Interface 

implementieren.” 

“Ich benutze das Beobachter-Muster.” 

Erleichtert die Kommunikation, wie Fachbegriffe. 









Entwurfsmuster - Beispiel: Singleton 



Stellt sicher, dass es von einer Klasse nur eine Instanz gibt, und 

stellt einen globalen Zugriffspunkt darauf bereit. 











Entwurfsmuster - Schlußbemerkungen 

generelle Lösungen für wiederkehrende Probleme 

Erfahrungswiederverwendung 

nur einsetzen wo sinnvoll 

KISS, einfache Lösungen bevorzugen 

kein Entwurfsmuster verwenden, nur weil es irgendwann mal 

sinnvoll sein könnte (einfach anfangen, bei Bedarf 

Refaktorisieren) 

Anti-Muster: sehen wie gute Lösungen aus, sind es aber nicht 











Kernprozesse - Validierung & Verifikation 

Modultests (Low-Level-Test): 

Test einzelner Module 

Integrationstests (Low-Level-Test): 

Test des Zusammenspiels mehrerer Komponenten 

Systemtests (High-Level-Test): 

Test des Gesamtsystems gegen die Spezifikation / 

Anforderungen 

Akzeptanztests (High-Level-Test): 

Test durch den Kunden 











Entwurfsmuster - Weiterführende Literatur 

Design Patterns, das Original 

Head First Design Patterns, witzig, leicht verständlich 

The Portland Patterns Repository 

http://c2.com/cgi/wiki?WelcomeVisitors 

Hillside Group 

http://hillside.net 









Exkurs - Unterstützungsprozesse 



Qualitätsmanagement: 

z.B.: Software-Ergonomie 

Konfigurationsmanagement: 

Versionsverwaltung 

Release Management 

Application Management (Anwenderbetreuung und 

Weiterentwicklung) 









Exkurs - Unterstützungsprozesse 



Dokumentation: 

Software-Dokumentationswerkzeug 

Systemdokumentation (Weiterentwicklung und 

Fehlerbehebung) 

Betriebsdokumentation (Betreiber / Service) 

Bedienungsanleitung (Anwender) 

Verfahrensdokumentation (Beschreibung rechtlich relevanter 

Softwareprozesse) 









Phasenmodelle - Vorteile 



Integration einfach, da: 

Anforderung möglichst vollständig ermittelt 

Anforderung dokumentiert 

Entwurf auf Basis der Anforderungen entwickelt 

kein umfangreiches Versions- und Konfigurationsmanagement 

erforderlich 









Phasenmodelle - Anwendung 

Anforderungen müssen 

sein. 

beschreibbar 

möglichst stabil 











Phasenmodelle - Nachteile 



Aufwandsabschätzung: 

sehr schwierig (Termin) 

auch Weglassen von Teilfunktionen bewirkt nicht viel 

schwieriger Integrationstest 


Wasserfallmodelle 






























































Wasserfallmodelle - Anwendung 

Anforderungen müssen 

sein. 

beschreibbar 

möglichst stabil 














kontrollierte Iterationen: 

erneute Ausführung bereits abgeschlossener 

Entwicklungsaktivitäten unter bestimmten Umständen 

(Behebung eines Fehlers, ...) 









Wasserfallmodelle - Vorteile 








erforderlich 









Wasserfallmodelle - Nachteile 

















Prototypische Vorgehensmodelle - Anwendung 

Anforderungen unklar 

Teile von Anforderungen unklar 









Prototypische Vorgehensmodelle 



Erstellung von Prototypen zu bestimmten Zeitpunkten 

während der Entwicklung: 

Analyse 

Entwurf 


... 











Prototypische Vorgehensmodelle - Vorteile 





Erfüllung geforderter nicht-funktionaler Anforderungen 

(Entwurfsprototypen) 


erforderlich 

Reduktion des Risikos einer Fehlentwicklung ( Überprüfung 

kritischer Bereiche mit dem Kunden) 

Identifikation von Systemteilen, die unter Zeitdruck 

weggelassen werden können (Prototypen) 











Prototypische Vorgehensmodelle - Nachteile 





Gefahren: 

Erhebung der Anforderungen nicht korrekt 

→ Verlangsamung des Entwicklungsprozesses 

Dokumentation der Anforderungen nicht ordentlich 

→ Verlangsamung des Entwicklungsprozesses 

Verkennung eines ausführbaren Prototyps von Kunden / 

Benutzern als Endsystem 











Iterativ-inkrementelle Verbesserungsmodelle 

Erstellung der Ergebnisse einer Teilmenge aller Anforderungen 

in sequenzieller Ordnung 

Aktivitäten entsprechen im Wesentlichen den Phasen der 

Vorgehensmodelle der Phasen- oder Wasserfallmodelle 

Inkrement: alle Ergebnisse für die Teilmenge der 

Anforderungen 

Teilmenge der Anforderungen wird erweitert und ein weiteres 

Inkrement erstellt 

evolutionäre Modelle: Erweiterung um Risikoanalyse zur 

Auswahl der Anforderungen des nächsten Inkrements 

rekursive Modelle: Durchlauf der Entwicklungsaktivitäten für 

jedes (Teil-)System 











Iterativ-inkrementelle Verbesserungsmodelle 

iterativ: schrittweise 

inkrementell: zunehmend 

evolutionär: sich entwickelnd 

rekursiv: selbstbezüglich 











Iterativ-inkrementelle Verbesserungsmodelle - Anwendung 

Teile der Anforderungen unklar 

Teile der Anforderungen instabil 

Aufteilung der Anforderungen in Teilmengen mit wenig 

Abhängigkeiten untereinander muss möglich sein 











Iterativ-inkrementelle Verbesserungsmodelle - Vorteile 

Auslieferungstermin kann eingehalten werden, ggf.: 

Auslieferung bereits fertig gestellter Inkremente 

Weglassen noch nicht realisierter Anforderungen unter 

Zeitdruck 

→ Anforderungen mit Kunden gemeinsam priorisieren 

einfacher Integrationstest 


Spiralmodell 








Barry W. Boehm (1978) 



Prototypisches und iterativ-inkrementelles Vorgehensmodell 

Software-Entwicklung als Durchlaufen einer Spirale 











Iterativ-inkrementelle Verbesserungsmodelle - Nachteile 

umfangreiches Versions- u. Konfigurationsmanagement 

Integration der verschiedenen Inkremente kann schwierig sein 


Spiralmodell 











Spiralmodell 










pro Zyklus werden vier Quadranten durchlaufen: 

1 Identifikation von Zielen 

Festlegen von Alternativen 

Bestimmung von Einschränkungen 

2 Bewerten von Alternativen 

Aufdecken von Risikoquellen 

Definition von Maßnahmen zur Beherrschung der Risiken 

3 Entwicklung und Abnahme des Software-Systems auf der 

jeweiligen Stufe 

4 Planung der nächsten Stufe des Software-Systems 

Zyklus endet mit Überprüfung des Entwicklungsergebnisses 

Abnahme ist Voraussetzung für nächsten Zyklus 












basiert auf drei verschiedenen Diagramm-Typen: 

1 Objektmodell: 

statische Objektstruktur des SW-Systems 

2 dynamisches Modell: 

zeitliche, verhaltensbezogene Aspekte einzelner Objekte 

3 funktionales Modell: 

Datenverarbeitungs- / Funktionsaspekte 

Werkzeuge: z.B. Software-ThroughPictures, Visio2000 












James Rumbaugh und Kollegen (Anfang der 1990er) 

Phasen- / Wasserfallmodell 


Booch 








Grady Booch (1991) 



Iterativ-inkrementelles Vorgehensmodell (Mikroprozess) und 

Wasserfallmodell (Makroprozess) 

Mikroprozess: tägliche Entwicklungstätigkeit 

Makroprozess: Kontrolle über Entwicklungsprozess 


Booch 











Booch 










Werkzeuge: 

Modellierung der Analyse- und Entwurfsdiagramme: z.B. 

VisualThought, RationalRose 

Werkzeuge für schnelles Umschalten zwischen Editieren, 

Compilieren, Ausführen und Debuggen 

Reverse-Engineering, damit Dokumentation mit aktueller 

Implementierung übereinstimmt: z.B. StP / UML 

Klassenbrowser 

inkrementeller Compiler 


Booch 










objektorientierte Analyse 

Vielzahl verschiedener Diagramme und Dokumente zur 

Beschreibung des Systems: 

Szenarien 

Data-Dictionary 

Objektdiagramme 

Klassendiagramme 

Zustandsdiagramme 

Interaktionsdiagramme 

Moduldiagramme 

Prozessdiagramme 


Booch 










Werkzeuge: 

Debugger mit Kenntnis der Semantik von Klassen und 

Objekten, Belastungstester, Speicheranalyse-Werkzeug 

Konfigurations- und Versionskontrolle 

Wiederverwendung durch Browser mit Navigationsmöglichkeit 

in Klassenbibliotheken 

GUI-Builder 


Objectory 








Ivar Jacobson (1992) 

Iterativ-inkrementelles Vorgehensmodell 



Use-Case-Modell beschreibt gesamte Funktionalität des 

Systems durch Interaktion von Aussenwelt und System 

Phasen: 

Analyse 

Konstruktion 

Testen 


Fusion 










Derek Coleman und Kollegen (Mitte der 1990er) 

Rekursives Vorgehensmodell 


Objectory 










Entwicklung der ersten Version basierend auf geg. 

Anforderungsdokument 

Änderungen an den Anforderungen in der Wartungsphase 

führen zu neuen Versionen des Systems 

Definition von Inkrementen auf dem vorgegebenen 

Anforderungsdokument möglich 

Werkzeuge: z.B. VisualThought, Rational Rose, Rational 

Suite TestStudio 


Fusion 










verschiedene Diagramme zur Beschreibung des SW-Systems: 

hohe Abstraktionsebene: 

Beschreibung der Problemdomäne und des gewünschten 

Verhaltens durch Objekt- und Schnittstellenmodelle 

mittlere Abstraktionsebene: 

Wiedergabe der Signatur aller Klassen und deren statische 

Beziehungen durch Klassenbeschreibungen und 

Vererbungsgraphen 

niedrige Abstraktionsebene: 

Beschreibung der Zusammenarbeit zwischen Klasseninstanzen 

und spezifischer Situationen zur Laufzeit durch Interaktionsund 

Sichtbarkeitsgraphen 

Werkzeuge: z.B. Rational Rose zur Unterstützung von UML 

und Testdokumenten 


Catalysis 










Desmond D’Souza und Alan Wills (1998) 










Rational Unified Process (RUP) 



Ivar Jacobson, James Rumbaugh und Grady Booch (1998) 


Definition eines generischen Prozess-Rahmens 

Spezialisierung für 

1 unterschiedliche Anwendungsgebiete 

2 verschiedene Organisationen 

3 unterschiedliche Kompetenzebenen 

4 verschiedene Projektgrößen 

möglich 

Werkzeuge: z.B. VisualThought, Rational Rose, Rational 

Suite TestStudio, Rational Werkzeug Suite (kompl. Prozess) 


Catalysis 








komponenten-basiert 

UML-basiert 



Typenmodell zur Beschreibung extern sichtbarer Artefakte 

Verfeinerung als 

Entwicklungsschritt 

Verfolgbarkeitsrelation 

rekursive Entwicklungsprozesse zur Beherrschung von 

Komplexität 

Werkzeuge: z.B. Platinum Advantage 


KobrA 










Fraunhofer-Team (2001) 


System als Hierarchie von Komponenten 

Werkzeuge: z.B. Rational Rose 









Extreme Programming (XP) 

Kent Beck (Ende der 1990er) 




Einsatz bei Projekten mit 

extrem kurzer Entwicklungszeit 

instabilen Anforderungen 

agile Softwareentwicklung 

rasche Erstellung eines ausführbaren Systems mit einem 

Minimum an flankierenden Maßnahmen, wie z.B. Modellierung 












Planungsphase (Verständnis / Dokumentation der 

Anforderungen): 

Story Cards: 

vom Kunden erstellt 

Beschreibung der gewünschten Eigenschaften 

wenige Tage Arbeit 

Task Cards: 

vom Entwickler-Team erstellt 

Diskussion zwischen Entwickler und Kunde 

pro Schritt, der zur Implementierung der Story benötigt wird 

Abschätzungen für Story Cards und Task Cards: 

Dauer 

Risiko 












Teamgedanke: 

Guidelines 

gemeinsame Verantwortung für alle Entwicklungsartefakte 

Pair Programming: 

wechselnde Paarzusammenstellungen 

→ Wissensverbreitung 

Driver: Konzentration auf Aufgabendetails 

Navigator: Konzentration auf Gesamtprojekt und Guidelines 

Rollenwechsel 

frühe Einbeziehung des Kunden 

Kunde ist Teil des Teams 

autorisiert Projekt-Ziele und Eigenschaften festzulegen 

Akzeptanztest 

ständige Kommunikation (Entwickler und Kunde) 












iterative Phase (Realisierung des Systems): 

Auswahl der Story Cards durch Kunde 

Implementierung: 

so einfach wie möglich 

keine zusätzlichen Eigenschaften einbauen / vorsehen 



ständige Rücksprache mit anderen Entwickler-Teams und 

Kunde 

Verzögerungen, ... sofort mit Kunde besprechen 

Test 












Vorteile: 

kurze Entwicklungszyklen 

präzise Vorhersagemöglichkeiten 

simple und effiziente Implementierungen 

Nachteile: 

ideale Teamgröße: 12-14 Personen 

→ für Großprojekte nicht geeignet 

disziplinierte Arbeitsweise notwendig 











Exkurs - Unified Modeling Language (UML) 

Diagrammtypen: 

Anwendungsfalldiagramm 

Klassendiagramm 

Verhaltensdiagramm: 

Aktivitätsdiagramm 

Kollaborationsdiagramm 

Sequenzdiagramm 

Zustandsdiagramm 

Implementierungsdiagramm: 

Komponentendiagramm 

Verteilungsdiagramm 












Unified Modeling Language (UML) ist eine Sprache und Notation 

zur 

Spezifikation 

Konstruktion 

Visualisierung 

Dokumentation 

von Modellen für Softwaresysteme. 

Die Unified Modeling Language ist keine Methode. 












Anwendungsfalldiagramm (use case diagram): 

Beziehungen zwischen Akteuren 

und Anwendungsfällen 

Akteur: 

Einheit außerhalb des Systems 

Interaktion mit System 

z.B. Benutzer, Betriebssystem, ... 

Anwendungsfall (use case): 

Aktivitäten eines Systems 

Sicht der Akteure 

wahrnehmbares Ergebnis 

durch Akteur initiiert 

unteilbare Beschreibung 












Klassendiagramm (class diagram): 

Basiselemente: 

Klasse 

Objekt 

Schnittstelle 

Komponente 

... 

Beziehungselemente: 

Vererbung 

Assoziation 

Aggregation 

Komposition 

Abhängigkeitsbeziehung 












Kollaborationsdiagramm (collaboration diagram) / 

Interaktionsdiagramm: 

Interaktionen zwischen Objekten 

begrenzte Situation 

Betonung der Beziehungen 

andere Perspektive als 

Sequenzdiagramm 












Aktivitätsdiagramm (activity diagram) / Ablaufdiagramm: 

beschreibt Ablaufmöglichkeiten eines Systems 

spezielle Form des Zustandsdiagramms 

Aktivität: einzelner Schritt in einem Ablauf 

Nebenläufigkeit 

als Objektflussdiagramm einsetzbar 












Sequenzdiagramm (sequence diagram) / Interaktionsdiagramm: 

Austausch von Nachrichten zwischen 

Objekten 

zeitlich begrenzte Situation 

Betonung des zeitlichen Ablaufs 

andere Perspektive als 

Kollaborationsdiagramm 












Zustandsdiagramm (state diagram) / Zustandsübergangsdiagramm 

(state transition diagram): 

Folge von Zuständen, die ein Objekt einnehmen kann 

Zustandsänderungen 

hypothetische Maschine (endlicher Automat) 












Verteilungsdiagramm (deployment diagram): 

Konfiguration von Knoten (Prozesse, 

Computer) 

→ Zuordnung von Komponenten und 

Objekten zu Knoten 

Kommunikationsbeziehungen an 

Knoten 












Komponentendiagramm (component diagram): 

Beziehungen der Komponenten 

untereinander 

Komponente: 

Software 

eigene Identität 

definierte Schnittstellen 











Exkurs UML - Weiterführende Literatur 

Die UML-Kurzreferenz für die Praxis - Überblick über die 

wichtigsten Diagrammtypen, jeweils mit Definition, 

Beschreibung, Notation und Beispiel 









Zusammenfassung - Einordnung 



Phasen- Wasserfall- Prototyp. Iterativ-inkr. 

Modelle 

OMT X X 

Spiralmodell X X 

Unified Process X X 

XP X X 

Booch X 

Objectory X 

Fusion X 

Catalysis X 

KobrA X 









Zusammenfassung - Vor- / Nachteile 



Vorteile Nachteile 

Phasen- Integration einfach Aufwandsabschätzung schwierig 

modelle Vers.- / Konfig.management einfach Teilfunktionen mitgeplant 

Integrationstest schwierig 

Wasserfall- Integration einfach Aufwandsabschätzung schwierig 

modelle Vers.- / Konfig.management einfach Teilfunktionen mitgeplant 

Integrationstest schwierig 

Prototyp. Integration einfach Aufwandsabschätzung schwierig 

Modelle nicht-funktionale Anforderungen Teilfunktionen mitgeplant 

Vers.- / Konfig.management einfach Integrationstest schwierig 

Fehlentwicklung unwahrscheinlich Gefahr: Anforderungserhebung 

Weglassen von Systemteilen Gefahr: Prototyp als Endsystem 

It.-inkr. Auslieferungstermin einhalten Vers.- / Konfig.man. umfangreich 

Modelle Integrationstest einfach Inkrement-Integration schwierig 









Zusammenfassung - Anwendung 

Anforderungen beschreibbar und stabil: 

Phasenmodelle 


Anforderungen unklar: 

Prototypische Modelle 

Iterativ-inkrementelle Modelle 

Anforderungen instabil und aufteilbar: 

Iterativ-inkrementelle Modelle 




Fazit 










Verwendung eines Vorgehensmodells abhängig von: 

Anforderungen des Projekts 

Umfang des Projekts 

Größe des Entwickler-Teams 

Teamfähigkeit der Entwickler 

Kommunikationsmöglichkeiten mit dem Kunden 

Es gibt kein Vorgehensmodell, das universell einsetzbar ist. 


Fazit 










Wichtig ist die Bearbeitung der Kernprozesse: 

Planung 

Analyse 

Entwurf 

Programmierung 

Validierung & Verifikation 

und der Unterstützungsprozesse: 

Qualitätsmanagement 

Konfigurationsmanagement 

Dokumentation 









Konsistenz und Programmierstil 

Komplexität beherrschbar machen 


Namen 

Ausdrücke und Anweisungen 

Funktionsmakros 

Magische Zahlen 

Kommentare 

Zusammenfassung 

Style Guides 

konsistenter Quelltext einfacher zu verstehen 

Aussehen des Codes auch wichtig 

pedantisch? konsequent, professionell! 









Weiterführende Literatur 



Vorgehensmodelle kompakt - Überblick über die vorgestellten 


Extreme Programming - kurzgehaltene, anschauliche 

Einführung 


Programmierstil 









Namen 




Kommentare 


Style Guides 

Der Zweck eines bestimmten Programmierstils ist, den Code für 

einen selbst und andere leichter lesbar zu machen. 

Einfachheit (Programme kurz und handlich halten) 

Klarheit (verständlich vor allem für den Menschen) 

Allgemeinheit (in unterschiedlichsten Situationen korrekt 

funktionieren) 

Guter Stil ist entscheidend, wenn man gut programmieren will. 


Schlechter Stil 









Namen 




Kommentare 


Style Guides 


Guter Stil 









Namen 




Kommentare 


Style Guides 

Prinzipien eines Programmierstils basieren auf gesundem 

Menschenverstand sowie Programmiererfahrung. 

Code sollte klar und einfach sein: 

geradlinige Logik 

natürliche Ausdrucksweise 

konventioneller Sprachgebrauch (Bewährtes anwenden) 

bedeutungsvolle Namen 

ordentliche Formatierung 

hilfreiche Kommentare 

Raffinierte Tricks und ungebräuchliche Konstruktionen vermeiden! 


Guter Stil 









Namen 




Kommentare 


Style Guides 

Gut geschriebene Programme sind besser als schlecht geschriebene, 

denn: 

leichter lesbar 

verständlicher 

enthalten weniger Fehler 

leichter zu debuggen 

leichter zu modifizieren 

Erfordert Disziplin. 

Compiler haben keine Probleme mit schlecht geschriebenem Code, 

Menschen schon... 


Konsistenz 









Namen 




Kommentare 


Style Guides 

Konsistenz erleichtert anderen Programmierern das Lesen des 

Codes. 

wichtig im Team: gemeinsamer Stil 


Namen 

Ein Name 









Namen 




Kommentare 


Style Guides 

bezeichnet ein bestimmtes Objekt (oder Funktion) 

übermittelt Informationen über seinen Zweck 

sollte informativ, kurz, einprägsam und aussprechbar sein 

je größer der Sichtbarkeitsbereich, desto mehr Informationen 

sollte der Name vermitteln 

Beschreibende Namen für globale Variablen, und kurze für lokale. 

Konsistent sein: verwandten Dingen ähnliche Namen geben. Nicht 

Q, Queue und queue. 


Namen - Variablen 








Klarheit wird oft durch Kürze erreicht. 


Namen 




Kommentare 


Style Guides 

1 for (theElementIndex = 0; 

2 theElementIndex < numberOfElements; 

3 theElementIndex++) 

4 elementArray[theElementIndex] = 

theElementIndex; 

Besser: 

1 for (i = 0; i < nElems; i++) 

2 elem[i] = i; 



Lokale Variablen: 








sollten kurz sein 

i, j für Schleifenvariablen 

p, q für Zeiger (nodep) 

s, t für Strings 


Namen 




Kommentare 


Style Guides 

n: Anzahl, nPoints (numberOfPoints ist übertrieben) 



Globale Variablen: 









Namen 




Kommentare 


Style Guides 

beginnen oft mit Großbuchstaben oder ’ ’ 

haben normalerweise längere (selbsterklärende) Namen 

(PointsOfInterest, RemoteAccessPoints) 

Konstanten: 

oft mit Großbuchstaben (MAX SIZE) 









Namen - Funktionen 


Namen 




Kommentare 


Style Guides 

Aktivität ausdrückende Namen für Funktionen: Verben eventuell 

gefolgt von Substantiv. 

1 now = date.getTime(); 

2 putchar(’\n’); 

Rückgabewerte sollten einfach deutbar sein: 

1 if (checkoctal(c)) 

besser: 

1 if (isoctal(c)) 











Namen 




Kommentare 


Style Guides 

Den klarsten Code schreiben, der die Aufgabe erledigt. 

Quellcode so formatieren, dass er gut lesbar ist. 

Eigentlich trivial, aber wichtig. 









Namen - Benennungskonventionen 


Namen 




Kommentare 


Style Guides 

Schreibweise der Namen ist reine Geschmackssache: 

1 nPending 

2 numPending 

3 num_pending 

Spezielle Regeln weniger wichtig als das konsistente Einhalten eines 

Stils. 










Namen 




Kommentare 


Style Guides 

Ausdrücke und Anweisungen - Einrücken 

Einrücken, um Strukturen zu verdeutlichen: 

1 for(n++;n









Namen 




Kommentare 


Style Guides 

Ausdrücke und Anweisungen - Einrücken 

Konventionellere Form, leichter zu verstehen: 

1 for (n++; n < 100; n++) 

2 field[n] = ’\0’; 

3 *i = ’\0’; 

4 return(’\n’); 










Namen 




Kommentare 


Style Guides 

Ausdrücke und Anweisungen - Klammern 

Klammern setzen um Mehrdeutigkeiten vorzubeugen: 

geben Gruppierungen wieder 

Absicht verdeutlichen, auch wenn nicht nötig 

1 leapYear = y % 4 == 0 && y % 100 != 0 

2 || y % 400 == 0; 

Besser mit Klammern: 

1 leapYear = ((y % 4 == 0) && (y % 100 != 0)) 

2 || (y % 400 == 0); 










Namen 




Kommentare 


Style Guides 

Ausdrücke und Anweisungen - Ausdrücke 

Ausdrücke in natürlicher Form schreiben: 

so wie man sie aussprechen würde 

Negierungen schwer zu verstehen 

1 if (!(n < min) && !(n > max)) 

Besser Vergleiche positiv formulieren: 

1 if ((n >= min) && (n









Namen 




Kommentare 


Style Guides 

Ausdrücke und Anweisungen - Klar ausdrücken 

Immer versuchen klaren Code zu schreiben, statt kürzestmöglichen: 

1 child = (!LC&&!RC)?0:(!LC?RC:LC); 

einfacher zu verstehen: 

1 if (LC == 0 && RC == 0) 

2 child = 0; 

3 else if (LC == 0) 

4 child = RC; 

5 else 

6 child = LC; 










Namen 




Kommentare 


Style Guides 

Ausdrücke und Anweisungen - Seiteneffekte 

Code mit Seiteneffekten vermeiden. 

1 i = 3; 

2 array[i++] = i; 

Welches Array-Element wird auf welchen Wert gesetzt? 

Seiteneffekte mal definiert, mal undefiniert. Wenn unsicher: anders 

schreiben. 

1 i = 3; 

2 array[i] = i; 

3 i++; 










Namen 




Kommentare 


Style Guides 

Ausdrücke und Anweisungen - Klar ausdrücken 

Immer versuchen klaren Code zu schreiben, statt (vermeintlich) 

cleveren: 

1 subkey = 

2 subkey >> (bitoff - ((bitoff >> 3) > (bitoff & 0x7); 

oder: 

1 subkey >>= bitoff & 0x7; 









Konsistenz und Idiome 

Konsistenz führt zu besseren Programmen. 

Nicht: 


Namen 




Kommentare 


Style Guides 

Schleifen mal vorwärts, mal rückwärts durchlaufen 

Strings mal mit strcpy, mal mit Schleifen kopieren 

Gleiche ”Berechnung” immer auf dieselbe Art und Weise 

vornehmen. 










Namen 




Kommentare 


Style Guides 

Konsistenz und Idiome - Konsistenz beim Einrücken und 

Klammern 

Einrückungen offenbaren die Struktur. 

Öffnende Klammer auf gleicher Zeile wie if, for, ...? 

Letztendlicher Stil weniger wichtig als dessen konsequente 

Einhaltung. 

Bei Änderungen an fremdem Code, jeweiligen Stil beibehalten. 









Konsistenz und Idiome - Idiome 


Namen 




Kommentare 


Style Guides 

Eines der bekanntesten Idiome ist die Form einer Schleife. 

Unüblich: 

1 i = 0; 

2 while (i = 0; ) 

2 array[i] = 1.0; 










Namen 




Kommentare 


Style Guides 

Konsistenz und Idiome - Konsistenz beim Einrücken 

1 if (month == FEB) 

2 { 

3 if (year%4 == 0) 

4 if (day > 29) 

5 legal = false; 

6 else 

7 if (day > 28) 

8 legal = false; 

9 } 

Die Einrückungen hier sind irreführend! (else) 

(Tipp: auch einzelne Zeilen immer mit geschweiften Klammern 

umgeben.) 









Konsistenz und Idiome - Idiome 

übliche Form: 

1 for (int i = 0; i < n; i++) 

2 array[i] = 1.0; 

n Elemente besucht 

in aufsteigender Reihenfolge 


Namen 




Kommentare 


Style Guides 

gesamte Kontrolle der Schleife im for-Ausdruck 

++-Operator zum inkrementieren 

Immer bekannte Idiome benutzen. 









Konsistenz und Idiome - Schleifen 


Namen 




Kommentare 


Style Guides 

Standardschleife zum Durchlaufen einer Liste in C: 

1 for (p = list; p != NULL; p = p->next) 

2 ... 

Endlosschleifen: 

1 for (;;) 

2 ... 

3 while (true) 

4 ... 










nicht verwenden 

#define ist reine textuelle Ersetzung 


Namen 




Kommentare 


Style Guides 

ändert lexikalische Struktur eines Programms im Hintergrund 

in C++ inline-Funktionen verwenden 

Ein Parameter, der mehr als einmal in der Definition des Makros 

auftaucht wird auch mehrmals ausgewertet. 










Namen 




Kommentare 


Style Guides 

Konsistenz und Idiome - Mehrfachentscheidungen 

else-Klauseln vertikal übereinander statt auf Höhe des jeweiligen 

ifs. Betont, dass Tests nacheinander ausgeführt werden. 

1 if (Bedingung1) 

2 Anweisung1 

3 else if (Bedingung2) 

4 Anweisung2 

5 ... 

6 else 

7 Defaultanweisung 

Sobald eine Bedingung erfüllt ist, wird entsprechender Code 

ausgeführt und dann nach letztem else-Zweig fortgefahren. 

Vermeidet nach rechts wandernden Code. (Tiefe Schachtelung 

Zeichen für schlechten Code.) 










Ungewollte Mehrfachauswertung: 


Namen 




Kommentare 


Style Guides 

1 #define isupper(c) ((c) >= ’A’ && (c) = ’A’ && 

2 (c = getchar())










Namen 




Kommentare 


Style Guides 

Magische Zahlen sind die Konstanten, Arraygrößen, 

Zeichenpositionen, Umrechnungsfaktoren und andere literale 

numerische Werte, die in einem Programm auftauchen. 

Magischen Zahlen einen Namen geben! 









Magische Zahlen - Besser (1/2) 

1 enum { 


Namen 




Kommentare 


Style Guides 

2 MINROW = 1, // upper row 

3 MINCOL = 1, // left column 

4 MAXROW = 24, // lower row 

5 MAXCOL = 80, // right column 

6 LABELROW = 1, // label position 

7 NLET = 26, // alphabet size 

8 HEIGHT = MAXROW ? 4, // bar height 

9 WIDTH = (MAXCOL ? 1) / NLET // bar width 

10 }; 

11 

12 // set scaling factor 

13 fac = (lim + HEIGHT - 1) / HEIGHT; 

14 if (fac < 1) 

15 fac = 1; 









Magische Zahlen - Negativbeispiel 


Namen 




Kommentare 


Style Guides 

1 fac = lim / 20; // set scaling factor 

2 if (fac < 1) 

3 fac = 1; 

4 

5 // generate histogram 

6 for (i = 0, col = 0; i < 27; i++, j++) { 

7 col += 3; 

8 k = 21 - (let[i] / fac); 

9 star = (let[i] == 0 ) ? ’ ’ : ’*’; 

10 for (j = k; j < 22; j++) 

11 draw (j, col, star); 

12 } 

13 

14 draw(23, 2, ’ ’); // draw x-axis 

15 for (i = ’A’; i









Magische Zahlen als Konstanten definieren. 

In C nicht #define (Makro!) verwenden: 

1 enum { MAXROW = 24 }; 

In C++: 

1 const int MAXROW = 24; 

In Java: 

1 static final int MAXROW = 24; 


Namen 




Kommentare 


Style Guides 


Kommentare 









Namen 




Kommentare 


Style Guides 

Kommentare sollten nicht offensichtliches wiederholen: 

1 // Default behavior 

2 default: 

3 break; 

4 

5 // return SUCCESS 

6 return SUCCESS; 

7 

8 zerocount++; // increment zero-entry-counter 

9 

10 // initialise "total" with "number_received" 

11 node->total = node->number_received; 


Kommentare 









Namen 




Kommentare 


Style Guides 

Kommentare sollen beim Verständnis eines Programms helfen. Sie 

sollten kurz bedeutende Details herausstellen oder einen 

umfassenden Blick auf den Programmablauf geben. 

Kommentare sollten zusätzliche Informationen beinhalten, die nicht 

direkt aus dem Code abgelesen werden können. Oder verstreute 

Informationen an einer Stelle sammeln. 










Namen 




Kommentare 


Style Guides 

Kommentare - Funktionen und globale Daten 

Funktionen und globale Daten sollten kommentiert werden. 

globale Variablen oft in größeren Abständen über Programm 

verstreut: Gedächtnisstütze 

Kommentar vor einer Funktion erspart u.U. ihren Code lesen 

zu müssen 


Kommentare 









Namen 




Kommentare 


Style Guides 

Schlechten Code nicht kommentieren, sondern neu schreiben! 

Wenn mehr Kommentare als Code geschrieben werden, dann 

bedarf der Code wahrscheinlich einer Überarbeitung. 

Nicht dem Code widersprechen: oft wird beim Ändern des 

Codes die Anpassung der Kommentare vergessen. 

Inkonsistenz verwirrt. 

Klarheit schaffen, keine Verwirrung (nicht noch mehr Fragen 

aufwerfen). 









Zusammenfassung 1/2 

Programmierstil 

beschreibende Namen 

Klarheit in Ausdrücken 

geradlinige Kontrollflüsse 

Lesbarkeit von Code und Kommentaren 


Namen 




Kommentare 


Style Guides 

konsistente Einhaltung von Konventionen und Idiomen 


Kommentare 









Namen 




Kommentare 


Style Guides 

Kommentare sollen helfen, Teile eines Programmes zu 

verstehen, die nicht beim bloßen Lesen des Codes erfasst 

werden können. 

Code schreiben, der leicht zu verstehen ist. Dann müssen 

weniger Kommentare geschrieben werden. 

Guter Code benötigt weniger Kommentare als schlechter. 









Zusammenfassung 2/2 

Lohnt der Aufwand? 

gut geschriebener Code 

ist leichter zu lesen und zu verstehen 

weist meist weniger Fehler auf 


Namen 




Kommentare 


Style Guides 

oft kürzer als sorglos zusammengestrickter Code 

Nachlässiger Code ist schlechter Code. 

Guter Stil sollte eine Angewohnheit sein. 


Allgemeines 








Quellcode auf englisch 


Namen 




Kommentare 


Style Guides 

Funktionen sollten möglichst kurz sein (kurz ist smart) 


Style Guides 









Namen 




Kommentare 


Style Guides 










Namen 




Kommentare 


Style Guides 

Konsistenz und Programmierstil - Weiterführende Literatur 

Programmierpraxis, Prinzipien zur effizienten 

Programmierung (Brian W. Kernighan, Rob Pike) 


Motivation 








Spaghetti-Code vermeiden 

Fehlervermeidung 

Code für Kollegen leichter verständlich 


Namen 




Kommentare 


Style Guides 

Fehlersuche wird einfacher, da alter Code besser verständlich 


Inhalt 









Namen 




Kommentare 


Style Guides 

Kommentierung des Quellcodes (evtl. Schlüsselwörter) 

Namensgebung 

Formatierung 

Ausdrücke 

Reihenfolge der Eigenschaften in Klassendeklarationen 

Zugriffsrechte und -methoden von Klassen 


Formatierung 








Einrücken 

verbundene Ausdrücke 

Klammersetzung bei Blöcken 

Kontrollierter Datenfluss: 

leere Blöcke 

Blöcke mit nur einer Zeile 


Namen 




Kommentare 


Style Guides 


Namensgebung 









Namen 




Kommentare 


Style Guides 

einheitliche Benennung (Variablen, Konstanten, ...) 

z.B. ungarische Notation: 

Charles Simonyi 

Kennzeichnung von Variablen und Funktionen durch optionales 

Präfix, Datentypangabe und Identifikator 

Variablenname dient der Identifikation 

Präfix und Datentypangabe meist ein bis zwei Kleinbuchstaben: 

Zeiger Wahrh.wert Zeichen Funktion Wort Long Byte ... 

p f ch fn w l b ... 

pointer flag character function word long byte ... 

Identifikator beginnt mit Großbuchstaben 

Identifikator setzt sich aus Worten zusammen, die mit 

Großbuchstaben beginnen 


Ausdrücke 









Namen 




Kommentare 


Style Guides 

Vermeiden von Shift-Operatoren statt arithmetischen 

Operationen 

Klammern setzen 

Konstanten statt Zahlenliteralen 


Fazit 

Wichtig ist, dass 








1 ein Style Guide existiert 


Namen 




Kommentare 


Style Guides 

2 sich das gesamte Team an den Style Guide hält 

3 der Style Guide nachvollziehbar ist 

4 der Style Guide möglichst viele Aspekte abdeckt 

5 Ausnahmen möglich sind, aber nicht zur Regel werden 









Quellcode-Formatierer 


Namen 




Kommentare 


Style Guides 

Quellcode-Formatierer passen Quellcode an eigene Vorlieben an: 

http://jalopy.sourceforge.net (Java) 

http://perltidy.sourceforge.net (Perl) 

bcpp (http://dickey.his.com/bcpp/bcpp.html) (C++) 

http://www.faqs.org/docs/Linux-HOWTO/C-C++Beautifier- 

HOWTO.html 

Artistic Style (http://astyle.sourceforge.net) (C, C++, C#, 

und Java) 


Beispiele 








Einige ”offizielle” Style Guides: 


Namen 




Kommentare 


Style Guides 

http://java.sun.com/docs/codeconv/html/ 

CodeConvTOC.doc.html 

http://www.perl.com/doc/manual/html/pod/perlstyle.html 

Ein Style Guide Generator für C, C++ und Java: 

http://www.rosvall.ie/CSG/ 


DRY-Prinzip 








DRY-Prinzip 

Gründe für Wiederholungen 


Datenformate 









Die Übel der Wiederholung 

DRY-Prinzip 



Datenformate 

Als Programmierer sammelt, organisiert, pflegt und nutzt man 

Wissen. 

Wissen ist nicht stabil, es verändert sich schnell. 

Anforderungen (des Kunden) können sich ändern 

gewählter Algorithmus funktioniert evtl. nicht 

Gesetze ändern sich 

Diese Instabilitäten führen dazu, dass das Wissen in einem System 

immer wieder neu organisiert und formuliert werden muss. 









Wie entstehen Wiederholungen? 

DRY-Prinzip 



Datenformate 

Erzwungene Wiederholung. Man scheint keine Wahl zu 

haben. Umstände scheinen die Wiederholung zu erfordern. 

Unabsichtliche Wiederholung. Aus Versehen. 

Wiederholung aus Ungeduld. Faulheit. Wiederholen, weil 

es einfacher scheint. 

Wiederholungen durch mehrere Entwickler. Verschiedene 

Entwickler wiederholen dieselbe Information. 


DRY-Prinzip 








DRY-Prinzip 



Datenformate 

Wenn dasselbe Stück Wissen an zwei oder 

mehr Stellen auftaucht, muss bei einer 

Änderung einer dieser Repräsentationen daran 

gedacht werden auch alle anderen Vorkommen 

zu ändern. Sonst sind unschöne Widersprüche 

die Folge. 

Die Frage ist nicht, ob man die anderen Vorkommen vergisst, 

sondern wann. 









DRY-Prinzip 



Datenformate 

Erzwungene Wiederholung - Verschiedene 

Repräsentationen einer Information 

Oft wird dieselbe Information in verschiedenen 

Repräsentationsformen benötigt. 

Client-Server-Anwendungen mit unterschiedlichen 

Programmiersprachen, die gemeinsame Strukturen verwenden 

müssen. 

Eine Klasse, die das Schema einer Datenbank widerspiegelt. 

Erzeugung von Folien, die Quelltext beinhalten, der aber auch 

getestet werden soll. 









DRY-Prinzip 



Datenformate 

Erzwungene Wiederholung - Verschiedene 

Repräsentationen einer Information 

Lösungsansätze: 

Filter oder Quelltext-Generatoren, die auf gemeinsame 

Meta-Daten zurückgreifen 

Quellcode-Dateien, die Strukturen deklarieren, für mehrere 

Sprachen erzeugen 

Klassendeklaration aus Datenbank-Beschreibung erzeugen 

lassen 

Quellcode per include-Befehl einfügen 









DRY-Prinzip 



Datenformate 

Erzwungene Wiederholung - Kommentare 

Besser: 

1 // check whether we have a valid country 

2 if ((country == "Austria") || 

3 (country == "Switzerland") || 

4 (country == "France")) 

5 {} 

Falsche Kommentare sind schlimmer als gar keine. 









DRY-Prinzip 



Datenformate 

Erzwungene Wiederholung - Kommentare 

Konkretes Wissen gehört in den Quelltext. Kommentare sind für 

abstraktere Erklärungen. 

Ansonsten wird Wissen wiederholt, und bei jeder Änderung müssen 

sowohl Quelltext als auch Kommentar angepasst werden. 

1 // valid for Germany and Switzerland 

2 if ((country == "Austria") || 

3 (country == "Switzerland") || 

4 (country == "France")) 

5 {} 









DRY-Prinzip 



Datenformate 

Erzwungene Wiederholung - Dokumentation im Quelltext 

Man schreibt Quelltext, und die Dokumentation dazu. 

Man ändert den Quelltext, und muss die Dokumentation 

ändern. 

Man ändert den Quelltext wieder, ... 

Dokumentation aus Quelltext extrahieren! (Doxygen, eigenes 

Skript) 









DRY-Prinzip 



Datenformate 

Erzwungene Wiederholung - Sprachprobleme 

Bei Java ist Klassendeklaration und -Definition eins. 

In C++ gibt es Header-Dateien (Deklarationen) und die 

eigentlichen Quelltexte (Implementation der Deklarationen). 

1 // stack.h 

2 class IntStack 

3 { 

4 int pop(); 

5 }; 

1 // stack.cpp 

2 int IntStack::pop() 

3 { 

4 } 









Unabsichtliche Wiederholung 

1 class Line { 

2 public: 

3 Point start; 

4 Point end; 

5 double length; 

6 }; 

DRY-Prinzip 



Datenformate 

Wird ’start’ oder ’end’ geändert, so muss auch length neu 

berechnet werden. 

(Nebenbemerkung: Variablen sollten nie public sein. Stattdessen 

getter und setter Methoden verwenden.) 










Fehler im Entwurf: 

1 class Van 

2 { 

3 string model; 

4 string licencePlate; 

5 string driver; 

6 }; 

DRY-Prinzip 



Datenformate 

1 class Tour 

2 { 

3 string from; 

4 string to; 

5 string driver; 

6 }; 

Wenn der Van auf Tour geschickt wird, taucht der Fahrer zwei Mal 

auf. 










Berechnen statt speichern: 

DRY-Prinzip 



Datenformate 


2 public: 

3 Point start; 

4 Point end; 

5 double length() { 

6 return start.distanceTo(end); 

7 } 

8 }; 

Zugriff: 

1 double len = line.length; // bad 

2 double len = line.length(); // good 










DRY-Prinzip 



Datenformate 

Bei aufwändigen Berechnungen Ergebnis cachen. 


2 public: 

3 Point getEnd(); 

4 void setEnd(Point p) { 

5 end = p; 

6 upToDate = false; 

7 } 

8 double length() { 

9 if (!upToDate) { 

10 length = start.distanceTo(end); 

11 upToDate = true; 

12 } 

13 return length; 

14 } 

15 }; 









Wiederholung aus Ungeduld 

DRY-Prinzip 



Datenformate 

Wenn man eine Funktion benötigt, die einer existierenden ähnelt, 

dann ist man oft versucht das Original zu kopieren und leicht zu 

modifizieren. 

Besser Originalfunktion flexibler machen, um für beides verwendet 

werden zu können. 

Oder Originalfunktion aus neuer Funktion heraus aufrufen. 

Abkürzungen dauern länger. 









DRY-Prinzip 



Datenformate 

Unabsichtliche Wiederholung von Code 

Code der mehrmals auftaucht an eine Stelle (z.B. Funktion) 

auslagern: 

1 _cldb->getSig (get_c_string(car(file))); 

2 _cldb->getCoefs(get_c_string(car(file))); 

1 const EST_String 

2 fileName(get_c_string(car(file))); 

3 

4 _cldb->getSig (fileName); 

5 _cldb->getCoefs(fileName); 

reduziert Fehlerquellen, da weniger Code 

kann mehrfache Berechnungen ersparen 









DRY-Prinzip 



Datenformate 

Wiederholungen durch mehrere Entwickler 

Schwer zu entdecken und zu vermeiden. 

Jeder programmiert sich seine eigenen Hilfsfunktionen. Viele sind 

dann mehrfach vorhanden. 

Aktive und häufige Kommunikation wichtig. 

Beispielsweise ein Diskussions-Forum einrichten. 

Hilfsfunktionen an zentralem Ort speichern. 









DRY-Prinzip 



Datenformate 

Wiederholungen durch mehrere Entwickler 

Wiederverwendung einfach machen. 

Z.B. Informationen in einem Projekt-Wiki eintragen. 

Wenn es nicht einfach ist, werden es die Leute nicht tun. 


DRY-Prinzip 








DRY-Prinzip 



Datenformate 

Jedes Stück Wissen muss eine einzige, eindeutige und maßgebliche 

Repräsentation in einem System haben. 

DRY - Don’t Repeat Yourself! 

Eines der wichtigsten ”Werkzeuge” eines (pragmatischen) 

Programmierers. 


Backups 








DRY-Prinzip 



Datenformate 

Backups zählen nicht als redundante Wiederholung von 

Informationen. 

Regelmäßig Backups erzeugen. 









Zusammenfassung - DRY-Prinzip 

DRY-Prinzip 



Datenformate 

Don’t Repeat Yourself 

Wiederholung aus Ungeduld/ Unwissen vermeiden 

verschiedene Repräsentationen von Daten erzeugen lassen 

Wiederverwendung von Code und Daten 

Wiederverwendung einfach machen (autom.) 


Datenformate 








DRY-Prinzip 



Datenformate 

Wissen möglichst in Klartext speichern. 

Klartext besteht aus druckbaren Zeichen, und kann von Menschen 

gelesen und direkt verstanden werden. 

Field42=0x23 

besteht aus druckbaren Zeichen, ist aber nichtssagend. 

Besser, weil verständlich: 

DrawingType=UMLActivityDrawing 


Datenformate 

Vorteile von Klartext: 








portabel (Vorsicht: Zeilenende) 

leicht zu lesen 

DRY-Prinzip 



Datenformate 

für jede Art von Werkzeug zugänglich (nicht nur für das 

Erzeugende) 

Versicherung gegen Veralten 

vereinfacht Tests, da Eingabedaten leicht erzeugt werden 

können 

Beispiel: XML 


Datenformate 








DRY-Prinzip 



Datenformate 

Klartext ist oft abstrakter als binäre Kodierung. 

window.displayFrame=FALSE 

vs. binär: 

00101010 

Problem der meisten Binärformate: 

Kontext für das Verständnis der Daten ist von den Daten isoliert. 

Ohne die Anwendungslogik nichtssagend. 

Mit Klartext kann man einen selbstbeschreibenden Datenstrom 

erreichen. 


Datenformate 








Nachteile von Klartext: 

Dateigröße (aber: zip und co) 

u.U. längere Ladedauer (Parsen) 

Möglichst Klartext speichern. 

DRY-Prinzip 



Datenformate 











Gesteigerte Produktivität 

Vermindertes Risiko 

Größere Projekte 
















Orthogonalität ist ein entscheidendes Konzept, wenn man Systeme 

erstellen will, die einfach 

zu entwerfen 

zu bauen 

zu testen 

und zu erweitern sind 









Was ist Orthogonalität? 






Orthogonalität ist ein Begriff aus der Geometrie. 

2 Geraden sind orthogonal, wenn sie sich 

im rechten Winkel treffen 

als Vektoren betrachtet sind sie 

unabhängig voneinander 

In der Informatik: 

Unabhängigkeit 

Entkopplung 

Zwei oder mehr Dinge sind orthogonal, wenn Veränderungen an 

einem keines der anderen beeinflußt. 









Was ist Orthogonalität? 






In einem gut entworfenen System ist z.B. die Datenbankanbindung 

orthogonal zur Benutzeroberfläche. 

Man kann das eine verändern ohne das andere zu beeinflussen. 















Nicht-orthogonale Systeme sind von Natur aus schwer zu 

verändern. 

Wenn die Teile eines Systems voneinander abhängig sind, ist ein 

lokal begrenzter Eingriff nicht möglich. 

Wechselwirkungen zwischen unabhängigen Dingen beseitigen. 


Isolierte Funktion 













1 float calcFunnyNumber(float x, float offset, int n) 

2 { 

3 float temp = 0.0; 

4 

5 for (int i = 0; i < n; i++) 

6 { 

7 temp += temp * x; 

8 } 

9 

10 return temp + offset; 

11 } 

strong cohesion: erfüllt einen (wohldefinierten) Zweck 

loose coupling: verwendet nur übergebene Parameter und lokale 

Variablen 















Komponenten sollten in sich abgeschlossen sein: 

Unabhängig, und mit einem einzigen, wohldefinierten Zweck 

(loose coupling (lose Kopplung), strong cohesion (hoher 

Zusammenhang)) 

Wenn Komponenten voneinander isoliert sind, kann man eine 

ändern, ohne sich um den Rest kümmern zu müssen. 










Veränderungen sind lokal beschränkt: 






reduziert Zeit für Entwicklung und Testen 

leichter, kleine abgeschlossene Komponenten zu schreiben 

existierender Quelltext muss kaum angepasst werden 

fördert Wiederverwendung: 

wenn Komponenten spezifische, wohldefinierte 

Verantwortlichkeiten haben, können sie auf verschiedenste 

(unvorhergesehene) Art und Weise kombiniert werden (lose 

Kopplung) 










subtile Produktivitätssteigerung: 






Zwei Komponenten mit jeweils unterschiedlichen 

Funktionalitäten (M, N) können MxN neue Dinge tun. Bei 

Nichtorthogonalität gibt es Überschneidungen, und 

dementsprechend weniger Kombinationsmöglichkeiten. 










es wird vermutlich besser getestet: 






einfacher Tests für einzelne Komponenten zu entwerfen und 

laufen zu lassen 

geringere Bindung an einen bestimmten Hersteller: 

Schnittstellen zu Komponenten von Dritten sind auf kleineren 

Teil des Quelltexts beschränkt 















Orthogonales Vorgehen vermindert die inhärenten Risiken jeder 

Software-Entwicklung. 

problematische Quelltextabschnitte werden isoliert: 

gibt es Probleme in einem Modul, ist es weniger 

wahrscheinlich, dass sich die Symptome auf das ganze System 

ausbreiten 

System ist robuster: 

Reparaturen an einer Stelle wirken sich positiv auf viele 

Stellen des Systems aus 


Projektteams 













In effizienten Teams gibt es wenig Überschneidungen, da jeder 

spezielle Verantwortlichkeiten hat. 

Veränderungen erfordern keine Besprechung des ganzen Teams, da 

nicht jeder betroffen ist. 


Entwurf 













Systeme sollten aus einer Menge kooperierender Module 

zusammengesetzt werden. 

Z.B. Unterteilung in Schichten (jede Schicht greift nur auf Schicht 

direkt darunter zu) 


Testen 













Orthogonales System einfacher zu testen. Viele Tests können auf 

der Ebene einzelner Module stattfinden, da Interaktionen zwischen 

Komponenten geordnet und begrenzt sind. 

Gut, da Modultests einfacher zu spezifizieren und durchzuführen 

sind als Integrationstests. 










Quelltext entkoppelt halten: 






schüchternen Code schreiben (Kapselung) 

Globale Daten vermeiden: 

Zugriff auf diese Daten über ganzen Quelltext verteilt 

benötigter Kontext direkt an Module/Funktionen übergeben 

ähnliche Funktionen vermeiden: 

wiederholter Quelltext Symptom für strukturelle Probleme 

z.B. Strategie- oder Schablonenmethode-Muster verwenden 









Zusammenfassung - Orthogonalität 






Untrennbares Wissen nicht über mehrere Systemkomponenten 

verteilen. 

Wechselwirkungen zwischen unabhängigen Dingen beseitigen 

(Module, Klassen, Komponenten, Schichten) 

globale Daten vermeiden 

Gesteigerte Produktivität, da Veränderungen lokal beschränkt 

(lose Kopplung) 

fördert Wiederverwendung, neue Kombinationsmöglichkeiten 

(Unix-Tools) 















Der Pragmatische Programmierer, (Andrew Hunt, David 

Thomas) 











Make 

Build-Prozess 

Nützliche Programme 

Skripte 


Die Anleitung für das Starten eines Ford T war mehr als 2 Seiten 

lang... 

Fehleranfällige Prozedur 

nervig 











Make 

Build-Prozess 


Skripte 


“Die Zivilisation schreitet dadurch fort, dass wir die Anzahl 

wichtiger Tätigkeiten steigern, die wir ohne Nachdenken verrichten 

können.” (Alfred North Whitehead) 










Make 

Build-Prozess 


Skripte 


Beispiele für Automatisierung beim Programmieren 

Build-Prozess 

Freigabe von Programmversionen 

Papierkram für Quelltext-Review 

100 Dateien umbenennen 

Möglichst viel muss automatisch geschehen! 









Konsistenz und Wiederholbarkeit 


Make 

Build-Prozess 


Skripte 


Automatisierung ist wichtig um Konsistenz und 

Wiederholbarkeit in einem Projekt gewährleisten zu können. 

Manuelle Vorgänge überlassen die Konsistenz dem Zufall, 

wodurch die Wiederholbarkeit nicht garantiert ist. 

Anleitungen lassen oft Raum für Interpretationen. (Anlassen 

von Ford T!) 


Projekt kompilieren 









Make 

Build-Prozess 


Skripte 


Kompilieren des Projekts ist eine Routineaufgabe. Sollte 

sein. 

zuverlässig 

und wiederholbar 


Automatik 









Make 

Build-Prozess 


Skripte 


Shell-Skript oder Batch-Datei führt dieselben Anweisungen aus, in 

derselben Reihenfolge und immer wieder. 

Manuelle Vorgänge vermeiden! 


Make 









Make 

Build-Prozess 


Skripte 


Änderung einer Datei führt zur Neukompilierung nur der 

betroffenen Dateien 

zentrale Konfigurationsstelle für alle anfallenden Aufgaben 

(clean, doc, install, test, create) 

anfänglicher Mehraufwand, der sich auszahlt 

nicht nur für Quelltext 









Aufbau von Makefiles 


Make 

Build-Prozess 


Skripte 


Regeln: beschreiben, wie aus einer oder mehreren Quellen ein Ziel 

erzeugt wird. 

1 Ziel: Quelle1 Quelle2 ... QuelleN 

2 Befehl1 

3 Befehl2 

Aufruf von make: 

1 make [-f Makefile] [foobar] 










Falsche Ziele: 

1 clean: 

2 rm -f *.o 


Make 

Build-Prozess 


Skripte 


Bei mehreren Zielen wird per default das erste ausgewählt. Wird 

oft ’all’ genannt, und hat als ”Abhängigkeit” das Hauptziel. 

1 all: foobar 











Make 

Build-Prozess 


Skripte 


1 foobar: foo.c bar.c 

2 gcc foo.c bar.c -o foobar 

Erzeugt foobar komplett neu, auch wenn nur eine c-Datei geändert 

wurde. 

Besser: 

1 foobar: foo.o bar.o 

2 gcc foo.o bar.o -o foobar 

3 

4 foo.o: foo.c 

5 gcc foo.c -c 

6 

7 bar.o: bar.c 

8 gcc bar.c -c 










Implizite Regeln: 

1 .cpp.o: 


Make 

Build-Prozess 


Skripte 


2 $(CXX) $(DBG_FLAGS) -o $@ -c $(CXXFLAGS) $< 

ist eine Regel, wie aus .cpp-Dateien .o-Dateien erstellt werden 

sollen. 

Automatische Variablen: 

$@ repräsentiert den Dateinamen des Ziels, das die 

Ausführung der Regel verursacht hat. 

$< repräsentiert den Namen der ersten Abhängigkeit 









Quelltext generieren 


Make 

Build-Prozess 


Skripte 


Um Wiederholungen zu vermeiden, können Quelltext und andere 

Dateien aus gemeinsamen Quellen abgeleitet werden. 

Der Abhängigkeitsmechanismus von make kann diesen Prozess 

vereinfachen. 

1 .SUFFIXES: .java .class .xml 

2 

3 .xml.java: 

4 convert.pl $< > $@ 

5 

6 .java.class: 

7 $(JAVA) $(JAVAC_FLAGS) $< 

make test.class sucht eine Datei ’test.xml’, erzeugt daraus per 

Perl-Skript eine Java-Datei und kompiliert diese. 


Build-Prozess 









Make 

Build-Prozess 


Skripte 


In vielen Projekten wird diese Art Build-Prozess jede Nacht 

automatisch ausgeführt. 

Dabei werden oft komplette Tests durchgeführt. So sieht man am 

nächsten Morgen, ob die letzten Änderungen Fehler eingeführt 

haben. 


Build-Prozess 









Make 

Build-Prozess 


Skripte 


Build-Prozess beginnt mit leerem Verzeichnis, und baut das 

Projekt von Grund auf. Erstellt alles was am Ende abgeliefert 

werden muss (CD-ROM-Master, selbst entpackendes Archiv). 

1 Auschecken der Quelltexte aus der Versionsverwaltung 

2 Projekt von Grund auf bauen (z.B. per make). Jeder Lauf des 

Build-Prozesses erhält Versionsnummer. 

3 Erstellen einer vollständigen Version, die verteilt werden kann. 

4 Ausführen von Testläufen. 









Webseiten erzeugen 

Der Build-Prozess kann auch: 

Dokumentation erzeugen 

interne Webseiten updaten 


Make 

Build-Prozess 


Skripte 


Alles sollte aus Informationen aus dem Versionsverwaltungssystem 

erzeugt und ohne menschliche Eingriffe veröffentlicht werden. 

Wieder DRY-Prinzip: Informationen existieren nur in einer einzigen 

Form. Web-Seite ist nur eine Sicht darauf. 









Genehmigungsprozeduren 


Make 

Build-Prozess 


Skripte 


In einigen Projekten müssen bestimmte Verwaltungsabläufe befolgt 

werden: 

Reviews von Quelltexten und Entwürfen einplanen und 

durchführen 

Genehmigungen erteilen 

Papierkram kann durch Automatisierung vereinfacht werden. 


cron 









Make 

Build-Prozess 


Skripte 


Führt Aufgaben zu genau festgelegten Zeitpunkten aus. 

1 # MIN HOUR DAY MONTH DAYOFWEEK COMMAND 

2 #----------------------------------------------- 

3 5 0 * * * /projects/Manhattan/bin/nightly 

4 15 3 * * 1-5 /usr/local/bin/backup 

5 0 0 1 * * /home/accounting/expense_reports 

1 crontab crontab.txt 

2 crontab -e 

3 crontab -r 









Genehmigungsprozeduren 

1 // Status: needs_review 


Make 

Build-Prozess 


Skripte 


Ein Skript könnte die Quelltext-Hierarchie nach solchen Dateien 

durchsuchen und: 

eine Liste dieser Dateien auf eine Webseite stellen 

eine email an die betroffenen Personen schicken 


find 








find hilft beim Suchen von Dateien 

1 find . -name "*.tex" 

2 find /usr/local -perm -400 

3 find /etc -type d 

4 find . -type f -empty 


Make 

Build-Prozess 


Skripte 



grep 








grep hilft beim Durchsuchen von Dateien 

1 grep "Subject:" ~/mbox-spam 

2 grep -v DONT_SHOW 

3 grep -l PATTERN * 


Make 

Build-Prozess 


Skripte 



Bash 








Umbenennen von Dateien: 


Make 

Build-Prozess 


Skripte 


1 for i in ‘find . -name "*.tex"‘; do 

2 mv $i ; 

3 done 

Parameter Expansion 

1 ${parameter#word} 

2 ${parameter##word} 

3 ${parameter%word} 

4 ${parameter%%word} 

5 ${parameter/pattern/string} 


Bash 

Schleifen: 









Make 

Build-Prozess 


Skripte 


1 for i in ‘find . -name "*.tex"‘; do 

2 echo $i; 

3 done 


cms.sh 








1 if [ -f ~/mbox-spam ]; then 

2 grep "Subject:" ~/mbox-spam; 

3 fi 


Make 

Build-Prozess 


Skripte 


1 if [ -f ~/mbox-spam ]; then 

2 grep "Subject:" ~/mbox-spam | grep -v SPAM; 

3 fi 


f.sh 

1 #!/bin/bash 

2 









Make 

Build-Prozess 


Skripte 


3 if [ $# -eq 0 ] 

4 then 

5 echo "usage: ${0} < 

FILES_TO_SEARCH>" 

6 echo "e.g.: ${0} printf \"*.cc\"" 

7 exit 1 









sameRightsForGroup.sh 

1 #!/bin/bash 

2 


Make 

Build-Prozess 


Skripte 


3 echo "Giving the group the same rights as the owner 

..." 

4 

5 for i in ‘find . -perm -400‘; do 

6 chmod g+r $i 

7 done 


9 chmod g+w $i 

10 done 


12 chmod g+x $i 

13 done 


f.sh 








1 elif [ $# -eq 1 ] 

2 then 

3 SEARCH_PATTERN=${1} 

4 FILES_TO_SEARCH="*" 

5 else 

6 SEARCH_PATTERN=${1} 

7 FILES_TO_SEARCH=${2} 

8 fi 

9 


Make 

Build-Prozess 


Skripte 


10 find . -name "${FILES_TO_SEARCH}" | xargs grep "${ 

SEARCH_PATTERN}" 


replace.pl 








1 #!/usr/bin/perl -w 

2 


Make 

Build-Prozess 


Skripte 


3 if (!defined($ARGV[0]) && !defined($ARGV[1]) && ! 

defined($ARGV[2])) 

4 { 

5 print("usage: replace.pl < 

fileName>\n\n"); 

6 print(" where is the string to search 

for\n"); 

7 print(" and the string to insert 

instead.\n"); 

8 exit(1); 

9 } 


eplace.pl 








1 $searchString = $ARGV[0]; 

2 $replaceString = $ARGV[1]; 

3 $fileName = $ARGV[2]; 

4 


Make 

Build-Prozess 


Skripte 


5 $tmpFile = $fileName . "." . getpgrp(0) . ".tmp"; 

6 

7 open(IN, "$fileName") 

8 || die "Cannot open $fileName for reading: $!"; 

9 

10 open(OUT, ">$tmpFile") 

11 || die "Cannot open $tmpFile for writing: $!"; 


replace.pl 

1 close(IN); 

2 close(OUT); 

3 








4 unlink($fileName); 

5 rename($tmpFile, $fileName); 


Make 

Build-Prozess 


Skripte 



replace.pl 

1 while () 

2 { 

3 $line = $_; 

4 









Make 

Build-Prozess 


Skripte 


5 if (/$searchString/) 

6 { 

7 $line =~ s/$searchString/$replaceString/g; 

8 } 

9 

10 print(OUT $line); 

11 } 









Leerzeichen am Zeilenende 

1 #!/bin/bash 

2 


Make 

Build-Prozess 


Skripte 


3 for i in ‘find . -name "*.tex" | xargs grep -l ’ \+$ 

’‘; do 

4 echo $i; 

5 replace.pl ’ +$’ ’’ $i; 

6 done 









Wiederholungen vermeiden 


Make 

Build-Prozess 


Skripte 


Wenn man bemerkt, dass man eine Aufgabe wieder und wieder 

(umständlich) erledigt, sollte man sich überlegen, wie man sie 

automatisieren kann. 

befreit Programmierer von Routinearbeiten 


Entropie 








Zerbrochene Fensterscheiben 

Programmieren mit dem Zufall 


Beispiele 


Entropie ist ein Begriff aus der Physik, der das Maß der 

Unordnung in einem System beschreibt. 

Unglücklicherweise besagen die Gesetze der Thermodynamik, dass 

die Entropie im Universum ein Maximum anstrebt. 

Wenn Unordnung in Software zunimmt, sagen Programmierer: 

”Die Software vergammelt.” 











Make 

Build-Prozess 


Skripte 


manuelle Vorgänge vermeiden 

Skriptsprachen (Perl, Python, Tcl, *sh, ...) 

PCs machen stupides gerne und besser als der Mensch 

Quelltext, der Quelltext erzeugt 

was einfach machbar ist, wird eher gemacht 










Manche Projekte sehen so, andere so aus: 




Beispiele 














Beispiele 


Verfall beginnt mit einer zerbrochenen Fensterscheibe. 

und wird immer schlimmer. Man fühlt sich immer unwohler und 

irgendwann besteht kein Interesse mehr an einer ”Renovierung”. 

Deshalb: 

Zerbrochene Fensterscheiben nicht akzeptieren. (Wehret den 

Anfängen) 













Beispiele 


Schlechten Quelltext nicht stehen lassen, sondern sofort reparieren 

sobald er entdeckt wird. 

Sonst kann es zu folgender Einstellung kommen: 

”Der Rest des Quelltexts ist schon Schrott. Ich mache es einfach 

genauso.” 

In einem Projekt mit sauber geschriebenem Code wird man mehr 

Sorgfalt walten lassen. Keiner will der Erste sein, der Schaden 

anrichtet. 













Beispiele 


Ein Versuch in New York begann mit einem intakten Auto und 

endete so: 










Bei Zeitmangel 

Meldung ausgeben 

Quellcode kommentieren 

1 // FIXME: this does not work 

2 // XXX: nonsense 

3 // TODO: make it work 




Beispiele 











Software vergammelt 

Fehler beheben, wenn man darauf stößt 

kein “das verbessere ich später” 




Beispiele 


chaotisch aussehender Code, sieht oft nicht nur so aus 


Zufall beim Testen 











Beispiele 


Es ist einfach anzunehmen, dass X unweigerlich zu Y führt. 

Nicht annehmen, sondern beweisen. 

Nicht mit dem Zufall programmieren/testen. 










1 paint(g); 

2 invalidate(); 

3 validate(); 

4 revalidate(); 

5 repaint(); 

6 paintImmediately(r); 




Beispiele 


Verzweiflung? 

Irgendwie scheint es zu funktionieren. Aber warum? 









Überlegt Programmieren 




Beispiele 


Ziel: Quelltext mit weniger Aufwand produzieren und Fehler so 

früh wie möglich erkennen und beseitigen. 

Sich immer bewusst sein, was man tut. 

Nicht mit verbundenen Augen programmieren. 

Programm verstehen 

Technologie verstehen 

Einem Plan folgen (d.h. vorher überlegen) 









Überlegt Programmieren 




Beispiele 


Nur auf Verlässliche Dinge verlassen. Keine Zufälle oder 

Annahmen. 

Annahmen dokumentieren 

Nicht nur Quelltext testen, sondern auch Annahmen. Nicht 

raten, sondern ausprobieren. 













Beispiele 


“Es funktioniert doch, jetzt bloß nichts anfassen...” (Anonymer 

Programmierer) 

Bedenklich. Höchstwahrscheinlich versteht man das System nicht. 

(Sonst wüsste man, was man wie ändern kann.) 

nie mit dem Zufall programmieren 

immer verstehen was man tut 

nur auf verlässliches verlassen 

zur Not unverständlichen Quelltext ersetzen (refaktorisieren) 










”Never change a running system”? 




Beispiele 


Vielleicht funktioniert es ja gar nicht, sondern sieht nur so aus. 

Zufälliger Grenzfall 

Undokumentiertes Verhalten könnte sich in der nächsten 

Version der Bibliothek ändern. 

Zusätzliche, unnötige Aufrufe machen das Programm 

langsamer. 

Zusätzliche Aufrufe erhöhen das Risiko, zusätzliche Fehler 

einzubauen. 

Nur auf dokumentiertes Verhalten verlassen. 













Beispiele 


Hausbau ist eine übliche Metapher für Software-Entwicklung 

Architekt zeichnet Plan 

Fundament ausgraben, Geschosse bauen, Elektrik, 

Wasserversorgung, Innenausbau 

Mieter ziehen ein, und rufen bei Problemen den Hausmeister 

Software-Entwicklung funktioniert jedoch anders! 










Zutreffender ist Gartenpflege 

nach anfänglichem Plan, und unter 

Beachtung der Umgebungsbedingungen 

werden verschiedene Sachen im Garten 

angepflanzt 

einige gedeihen, andere nicht 

Pflanzen werden umgepflanzt 

Unkraut gejähtet; Pflanzen gedüngt 

Man beobachtet und greift bei Bedarf ein. 




Beispiele 










Wie refaktorisiert man? 




Beispiele 


Refaktorisieren ist eine Tätigkeit, die langsam, überlegt und 

sorgfältig ausgeführt werden muss. 

Nicht gleichzeitig refaktorisieren und neue Funktionalität 

implementieren. 

Test-Code schreiben, und vor und nach der Änderung laufen 

lassen. ( Änderungen können neue Fehler hervorrufen.) 

Bei jedem Schritt nur kleine Änderungen vornehmen. 

Früh und häufig refaktorisieren. 









Refaktorisieren - Definition 




Beispiele 


Quelltext ist nichts statisches. Er muss sich weiterentwickeln. 

Quelltext neu zu schreiben, zu überarbeiten und neu zu entwerfen, 

ist allgemein als Refaktorisieren bekannt. 

Dabei wird normalerweise die Funktionalität nicht verändert. 









Einfaches Erweitern 




Beispiele 


Wenn man ein Programm um ein Feature erweitern möchte und 

dies nicht einfach möglich ist, dann sollte man erst den Code 

ändern, so dass es einfach möglich ist. Erst dann sollte man das 

neue Feature einbauen. 


Vorgehen 

Kleine Schritte: 








Vertrauen in Code wächst 

Weniger Stress 

Werkzeug-unterstütztes Refaktorisieren: 

Smalltalk-Refactoring-Browser 

Eclipse 




Beispiele 










”Schlechte Gerüche” 

Quelltext stinkt wenn 

Code dupliziert wird 

Methoden zu lang sind 




Beispiele 


Klassen zu groß sind (zu viele Variablen) 

ein neues Feature viele Änderungen nötig macht 

Code unnötig generell ist 

(zu viele) Kommentare nötig sind 

... 









Wann Refaktorisieren? 




Beispiele 


Eine Vielzahl von Anzeichen qualifiziert Quelltext für das 

Refaktorisieren: 

Wiederholung. Verletzung des DRY-Prinzips. 

Nicht-orthogonaler Entwurf. 

Veraltetes Wissen. Dinge ändern sich, Anforderungen 

ebenso, eigenes Wissen wächst. 

Performance. Programm zu langsam. 

Früh und häufig refaktorisieren. 


Katalog 











Beispiele 


Wie bei Entwurfsmustern gibt es auch für Refaktorisierungen 

Kataloge von bewährten Code Transformationen. 

Aufbau: 

Name (Vokabular) 


der Situation in der sie benötigt wird 

dessen, was sie tut 

Motivation (wann anwenden und wann nicht) 

Mechanismus (knappe, Schritt für Schritt Anleitung) 

Beispiel 

Oft paarweises Vorkommen, für beide Richtungen. 












Beispiele 


Methoden entwerfen - Methode extrahieren 

Ein Code-Fragment kann gruppiert werden. 

Das Fragment in eine eigene Methode auslagern. Der Name der 

Methode erklärt ihren Zweck. 

1 void printOwing(double amount) { 

2 printBanner(); 

3 

4 // print details 

5 System.out.println("name: " + _name); 

6 System.out.println("amount " + amount); 

7 } 












Beispiele 


Methoden entwerfen - Methode ”inlinen” 

Der Funktionsrumpf ist genauso klar wie ihr Name. 

Den Rumpf der Funktion an allen sie aufrufenden Stellen einsetzen. 

1 int getRating() { 

2 return moreThanFiveLateDeliveries() ? 2 : 1; 

3 } 

4 boolean moreThanFiveLateDeliveries() { 

5 return _numberOfDeliveries > 5; 

6 } 

1 int getRating() { 

2 return (_numberOfDeliveries > 5) ? 2 : 1; 

3 } 












Beispiele 


Methoden entwerfen - Methode extrahieren 

1 void printOwing(double amount) { 

2 printBanner(); 

3 printDetails(amount); 

4 } 

5 

6 printDetails(double amount) { 

7 System.out.println("name: " + _name); 

8 System.out.println("amount " + amount); 

9 } 












Beispiele 


Methoden entwerfen - Temporäre Variable ”inlinen” 

Einer temporären Variable wird nur einmal ein Wert zugewiesen, 

und sie wird selten verwendet. 

Alle Referenzen auf die Variable durch den Ausdruck ersetzen. 

1 double basePrice = anOrder.basePrice(); 

2 

3 return (basePrice > 1000); 

1 return (anOrder.basePrice() > 1000); 












Beispiele 


Methoden entwerfen - Erklärende Variable einführen 

Man hat einen komplizierten Ausdruck. 

Das Ergebnis des Ausdrucks (oder Teile davon) in einer 

temporären Variable speichern. 

1 if ((platform.toUpperCase().indexOf("MAC") > -1) && 

2 (browser.toUpperCase().indexOf("IE") > -1) && 

3 wasInitialized() && resize > 0) { 

4 // do something 

5 } 












Beispiele 


Methoden entwerfen - Temporäre Variable aufteilen 

Man hat eine temporäre Variable, der verschiedene Werte 

zugewiesen werden. 

Separate Variablen für jede Zuweisung einführen. 

1 double temp = 2 * (_height + _width); 

2 System.out.println(temp); 

3 

4 temp = _height * _width; 

5 System.out.println(temp); 












Beispiele 


Methoden entwerfen - Erklärende Variable einführen 

1 final boolean isMacOS = platform.toUpperCase(). 

indexOf("MAC") > -1; 

2 final boolean isIEBrowser = browser.toUpperCase(). 

indexOf("IE") > -1; 

3 final boolean wasResized = resize > 0; 

4 

5 if (isMacOS && isIEBrowser && wasInitialized() && 

wasResized) { 

6 // do something 

7 } 












Beispiele 


Methoden entwerfen - Temporäre Variable aufteilen 

1 final double perimeter = 2 * (_height + _width); 

2 System.out.println(perimeter); 

3 

4 final double area = _height * _width; 

5 System.out.println(area); 












Beispiele 


Methoden entwerfen - Zuweisungen zu Parametern 

entfernen 

Der Code weist einem Parameter Werte zu. 

Temporäre Variable verwenden. 

1 int discount(int inputVal, int quantity, int 

yearToDate) { 

2 if (inputVal > 50) inputVal -= 2; 

1 int discount(int inputVal, int quantity, int 

yearToDate) { 

2 int result = inputVal; 

3 if (inputVal > 50) result -= 2; 









Daten organisieren - Feld kapseln 

1 private int _low, _high; 

2 




Beispiele 


3 boolean includes(int arg) { 

4 return arg >= getLow() && arg = _low && arg











Beispiele 


Daten organisieren - Ersetze magische Zahl durch 

symbolische Konstante 

Man hat eine Zahl mit einer bestimmten Bedeutung. 

Konstante erzeugen, und nach der Bedeutung der Zahl benennen. 

1 double potentialEnergy(double mass, double height) { 

2 return mass * 9.81 * height; 

3 } 

1 double potentialEnergy(double mass, double height) { 

2 return mass * GRAVITATIONAL_CONSTANT * height; 

3 } 

4 static final double GRAVITATIONAL_CONSTANT = 9.81; 












Beispiele 


Konditionalausdrücke vereinfachen - Schachtelungen durch 

”Wächter” ersetzen 

1 double getPayAmount() { 

2 if (_isDead) return deadAmount(); 

3 if (_isSeparated) return separatedAmount(); 

4 if (_isRetired) return retiredAmount(); 

5 

6 return normalPayAmount(); 

7 } 












Beispiele 


Konditionalausdrücke vereinfachen - Schachtelungen durch 

”Wächter” ersetzen 

Der normale Ausführungspfad durch eine Funktion ist nicht klar. 

”Wächter” für die Spezialfälle verwenden. 

1 double getPayAmount() { 

2 double result; 

3 if (_isDead) result = deadAmount(); 

4 else { 

5 if (_isSeparated) result = separatedAmount(); 

6 else { 

7 if (_isRetired) result = retiredAmount(); 

8 else result = normalPayAmount(); 

9 } 

10 } 

11 return result; 

12 } 












Beispiele 


Methodenaufrufe vereinfachen - Methode umbenennen 

Der Name einer Methode macht ihren Zweck nicht klar. 

Den Namen ändern. 

1 getinvcdtlmt() 

1 getInvoiceCreditLimit() 












Beispiele 


Methodenaufrufe vereinfachen - Trenne Abfrager von 

Modifizierer 

Eine Methode gibt einen Wert zurück, und ändert zusätzlich den 

Zustand des Objekts. 

Erzeuge zwei Methoden. Eine für die Abfrage, und eine für die 

Modifikation. 

1 getTotalOutstandingAndSetReadyForSummaries() 

1 getTotalOutstanding() 

2 setReadyForSummaries() 












Beispiele 


Methodenaufrufe vereinfachen - Parameterobjekt einführen 

Eine Gruppe von Parametern passt zusammen. 

Ersetze sie durch ein Objekt. 

1 setDate(int day, int month, int year) 

1 setDate(Date today) 












Beispiele 


Methodenaufrufe vereinfachen - Methode parametrisieren 

Mehrere Methoden machen etwas ähnliches, aber mit 

unterschiedlichen Werten. 

Eine Methode erzeugen, die den Wert als Parameter erhält. 

1 fivePercentRaise() 

2 tenPercentRaise() 

1 raise(percentage) 









Generalisierung - Feld hochziehen 




Beispiele 


Zwei Subklassen haben die gleiche Variable. 

Bewege die Variable in der Klassenhierarchie nach oben. 

1 class Employee { }; 

2 

3 class Salesman extends Employee { 

4 String name; 

5 }; 

6 

7 class Engineer extends Employee { 

8 String name; 

9 }; 









Generalisierung - Feld hochziehen 

1 class Employee { 

2 String name 

3 }; 

4 




Beispiele 


5 class Salesman extends Employee { }; 

6 

7 class Engineer extends Employee { }; 













Beispiele 


Refactoring - Improving the design of existing code, Martin 

Fowler 










Aufräumen von Code 




Beispiele 


überarbeiten und dadurch interne Struktur verbessern 

ändert nichts am nach außen sichtbaren Verhalten 

investierte Zeit lohnt sich, sonst später Chaos 

kleine Änderungen, dann testen 









Weshalb der Nikolaus im Norden lebt 






















































































































Rentierschlittenkufenwachsdosen- 

deckelbeschriftungsfarbenrotanteil 



















Also, dass war dann so, dass 

ich dort jemanden getroffen hatte, 

der meinte, dass ich unbedingt und ganz, 

ganz dringend - es würde wirklich nicht anders 

gehen und es wäre schon wichtig, dass ich das tun würde, weil 

nämlich sonst etwas passieren könnte (oder würde ich einfach nur 

etwas verpassen? Naja, wie auch immer ist ja eigentlich auch egal), also 

was ich sagen wollte, war ... ja, was war das noch gleich, ah ja - auch das liegt 

durchaus im Bereich des möglichen - was tun sollte, das ich jetzt vergessen habe ... 



















Ein Rückblick auf seine Reise zeigte dem Nikolaus auf, wie viel er 

unterwegs gelernt hatte: 

Kombination der Farben Rot und Blau zu 

vermeiden (Türkei) 

gängige Datenformate einzuhalten (Griechenland) 

Rot als Signalfarbe zu verwenden (Rumänien) 

auf gut erkennbare Kontraste zu achten (Ungarn) 

das Gesetz der Nähe ( Österreich) 

einfach und verständlich Hilfe zu leisten (Italien) 










Software-Ergonomie - ausführliche Einführung in die 

Software-Ergonomie mit Hintergrund-Erläuterungen 










das Gesetz der Isolation (Frankreich) 

Undo-Funktionen vorzusehen (Spanien) 

das Gesetz der Gleichheit (Frankreich) 

lange Antwortzeiten zu vermeiden oder überspielen 

(Schweiz) 

nicht mehr als sieben Informationseinheiten 

gleichzeitig zu verwenden (Deutschland) 

komplexe Fragestellungen mit Graphik zu 

verdeutlichen (Dänemark) 

keine starken Helligkeitskontraste zu verwenden 

(Norwegen) 


Teil 2 - Werkzeuge 

Programmiersprachen 

Editoren 



Fehlersuche 


Test 

8 Programmiersprachen 

9 Editoren 

10 Versionskontrolle 

11 Quellcode erzeugen / anpassen 

12 Fehlersuche 

13 Dokumentationserstellung 

14 Test 



Editoren 



Fehlersuche 


Test 


Klassifizierung von Programmiersprachen 




Editoren 



Fehlersuche 


Test 



Klassifizierung nach Generationen - Maschinensprachen 

System von Instruktionen und Daten, die der Prozessor direkt 

ausführen kann 

Binärcode 



Editoren 



Fehlersuche 


Test 

Klassifizierung nach Generationen 

1 Maschinensprachen 

2 Assemblersprachen 

3 Höhere Programmiersprachen 

4 4GL-Sprachen 

5 Very High Level Languages 





Editoren 



Fehlersuche 


Test 



Klassifizierung nach Generationen - Assemblersprachen 

Repräsentation der Maschinensprache einer spezifischen 

Prozessorarchitektur in einer für Menschen lesbaren Form 

Ausnutzung der kompletten Bandbreite des Computers 

direkte Programmierung von Hardwarechips 

in der Regel kleiner und schneller als Programme mit 

ähnlichem Komplexitätsgrad und Hochsprache als Basis 

höhere Fehleranfälligkeit 

extrem großer Programmieraufwand 

Portieren auf andere Hardware nicht möglich 



Editoren 



Fehlersuche 


Test 



Klassifizierung nach Generationen - Höhere 


Third generation language (3GL) 

Einführung von standardisierten Kontrollstrukturen 

genaue Beschreibung, wie ein Problem gelöst werden soll 

Aufgabenstellung schwierig aus Quellcode zu erkennen 



Editoren 



Fehlersuche 


Test 



Klassifizierung nach Generationen - Very High Level 

Languages 

Beschreiben von Sachverhalten und Problemen 

vor allem im Bereich der künstlichen Intelligenz 



Editoren 



Fehlersuche 


Test 



Klassifizierung nach Generationen - 4GL-Sprachen 

Fourth generation language 

anwendungsorientiert 

vorgefertigte Bausteine 

Beschreibung, was der Rechner tun soll 

Programme in der Regel gut lesbar 



Editoren 



Fehlersuche 


Test 

Klassifizierung nach Paradigma 

1 imperativ / prozedural 

2 funktional / applikativ 

3 logisch / prädikativ 

4 objektbasiert 

5 objektorientiert 





Editoren 



Fehlersuche 


Test 



Klassifizierung nach Paradigma - imperativ / prozedural 

Programm als Folge von Befehlen, die der Rechner in einer 

definierten Reihenfolge abarbeitet. 

Funktionen und Prozeduren dienen der Kapselung und 

Wiederverwendung von Funktionalität. 

Beispiele: Ada83, BASIC, C, COBOL, FORTRAN 



Editoren 



Fehlersuche 


Test 



Klassifizierung nach Paradigma - logisch / prädikativ 

Programm besteht aus einer Menge von Fakten und Regeln. 

Beispiel: PROLOG 



Editoren 



Fehlersuche 


Test 



Klassifizierung nach Paradigma - funktional / applikativ 

Berechnung von Funktionen, die Eingabewerte auf Ausgabewerte 

abbilden. 

Beispiel: LISP 



Editoren 



Fehlersuche 


Test 



Klassifizierung nach Paradigma - objektbasiert 

Objekte werden unterstützt, weiterführende Konzepte, wie Klassen 

und deren Beziehungen fehlen. 

Beispiel: JavaScript 



Editoren 



Fehlersuche 


Test 



Klassifizierung nach Paradigma - objektorientiert 

Alle zur Lösung eines Problems notwendigen Informationen 

(Daten, Anweisungen, Regeln) werden als Objekte aufgefasst. 

Beispiel: Ada95, C++, Java, Smalltalk 


C 


Editoren 



Fehlersuche 


Test 



C-Compiler für nahezu jede Prozessorarchitektur vorhanden 

fast alle Kernel der bekannten Betriebssysteme in C 

implementiert 

portabel und sowohl assemblernahe als auch abstrakte 

Programmierung möglich 

niedriger Abstraktionsgrad 

lückenhafte Sprachdefinition (Verhalten z. T. undefiniert) 

keine boolescher Datentyp, kein Datentyp für Zeichenketten 

keine Speicherverwaltung 


C 


Editoren 



Fehlersuche 


Test 



Ken Thompson und Dennis Ritchie, frühe 1970er Jahre 

Weiterentwicklung von B (Bell Laboratories) 

prozedurale Programmiersprache 

Compiler 

gut geeignet für Systemprogrammierung 

Zeigerarithmetik zur effizienten Behandlung von Feldzugriffen, 

Parametern, ... 

Hardwarenahe Programmierung möglich, direkter 

Speicherzugriff und Zeigerarithmetik 


C++ 


Editoren 



Fehlersuche 


Test 

Bjarne Stroustrup (AT&T), ab 1979 



Weiterentwicklung (“Inkrement”) von C 

Multiparadigmen-Sprache (Hybridsprache), unterstützt: 

prozedurale Programmierung 

modulare Programmierung 

strukturierte Programmierung 

Programmierung mit selbstdefinierten Datentypen 

objektorientierte Programmierung 

generische Programmierung 

Compiler 


C++ 


Editoren 



Fehlersuche 


Test 

Erzeugung hocheffizienten Codes möglich 



sowohl maschinennahe als auch hochabstrakte 

Programmierung 

sehr hohe Ausdrucksstärke und Flexibilität 

für große Projekte geeignet 

nicht im Besitz einer Firma; Standardisierung durch die ISO 

historischer Ballast wg. Kompatibilität mit C 

aktuelle C++-Standardbibliothek deckt einige neue 

Erfordernisse noch nicht ausreichend ab (z.B.: Threads, 

TCP/IP, Dateisystem-Verzeichnisse) 


Java 


Editoren 



Fehlersuche 


Test 

aus Smalltalk übernommen: 

Objektbaum, in den alle Objekte 

eingehängt werden und von einem 

einzigen Mutterobjekt abstammen 

automatische Speicherbereinigung 

virtuelle Maschine 

Syntax an C++ angelehnt 

Konstrukte aus C++, die Java nicht 

bietet: 

Mehrfachvererbung 

fehleranfällige Zeigerarithmetik 

Überladen von Operatoren 




Java 


Editoren 



Fehlersuche 


Test 

Patrick Naughton, Mike Sheridan, 

James Gosling, Bill Joy, ... (Sun 

Microsystems), 1991/1992 (Urversion, 

“The Green Project”) 

von den Entwicklern bevorzugte 

Kaffee-Sorte 

objektorientierte Programmiersprache 

Interpreter und Compiler 




Ada 


Editoren 



Fehlersuche 


Test 

Jean Ichbiah (Honeywell Bull), 1970er 

Lady Ada Lovelace (1815-1852) 

imperative / prozedurale 

Programmiersprache 

Ada 95 unterstützt auch 

objektorientierte Programmierung und 

dynamische Polymorphie 

Compiler 

erste standardisierte Hochsprache 




Ada 


Editoren 



Fehlersuche 


Test 

eingebettete und Echtzeit-Systeme 

strenges Typsystem (starke 

Typisierung) 

zahlreiche Prüfungen zur 

Programmlaufzeit 

parallele Verarbeitung 

Ausnahmebehandlung 

generische Systeme 




COBOL 


Editoren 



Fehlersuche 


Test 



1960 als COBOL-60 von CODASYL verabschiedet 

Common Business Oriented Language 

imperative / prozedurale Programmiersprache 

Compiler 

betriebswirtschaftlicher Bereich: 

Handhabung großer Datenmengen 

Ein- und Ausgabe großer Datenmengen 

wortreich, stark an natürliche Sprache angelehnt 

strikte Trennung von Datendeklaration und prozeduralen 

Anweisungen 


FORTRAN 


Editoren 



Fehlersuche 


Test 



John W. Backus, ... (IBM), ab 1954 

FORmula TRANslation 

prozedurale, inzw. auch objektorientierte Programmiersprache 

Compiler 

numerische Berechnungen 

früher Fortran-Stil: Goto-Anweisungen 

seit FORTRAN 77 strukturierte Programmierung 

ab Fortran 90: 

Freigabe des aus der Lochkartenzeit stammenden Zeilenformats 

optionale Parameter 

Identifikation von Prozedurparametern über Namen, nicht nur 

über Position in Parameterliste 


COBOL 


Editoren 



Fehlersuche 


Test 



Gliederung in vier Teile (DIVISION) mit einer festgelegten 

Reihenfolge: 

1 Identification Division: Programmname und Paragraphen für 

Kommentare 

2 Environment Division: Definition von Schnittstellen zum 

Betriebs- und Dateisystem 

3 Data Division: Definition der Programmvariablen und 

Datenstrukturen 

4 Procedure Division: prozedurale Anweisungen 

und in Kapitel (SECTION) und Abschnitte (PARAGRAPH) 

traditionelles Kodierschema bei Cobol entspricht Lochkarte 

mit 80 Spalten 


BASIC 


Editoren 



Fehlersuche 


Test 



John George Kemeny und Thomas Eugene Kurtz (Dartmouth 

College), 1964 

Beginner’s All-purpose Symbolic Instruction Code 

imperative Programmiersprache 

Interpreter 

entwickelt, um Studenten den Einstieg in die Programmierung 

mit Algol und Fortran zu erleichtern 


Perl 


Editoren 



Fehlersuche 


Test 



Larry Wall, 1987 

Zitat aus dem Matthäus-Evangelium 

Hybridsprache 

Interpreter 

Werkzeug zur System- und Netzwerkadministration 

Entwicklung von Webanwendungen 

Bioinformatik 

Kombination von C mit Werkzeugen wie sed, awk, grep und 

sort und Eigenschaften der Bourne Shell 

schnelle Problemlösung und größtmögliche Freiheit für 

Programmierer 

Stärken: Umgang mit Texten und viele frei verfügbare Module 


BASIC 


Editoren 



Fehlersuche 


Test 



Entwurfsprinzipien: 

für Anfänger einfach zu erlernen 

universell einsetzbar 

Erweiterbarkeit der Sprache für Experten 

Interaktivität 

klare Fehlermeldungen 

rasche Antwortzeiten 

Hardwareunabhängigkeit 

Betriebssystemunabhängigkeit 

Plattformunabhängigkeit nicht erreicht 

hunderte inkompatibler Dialekte, deren Gemeinsamkeiten sich 

auf Datenverarbeitung beschränken 


PHP 


Editoren 



Fehlersuche 


Test 

Rasmus Lerdorf, 1995 

Personal Home Page Tools 

Hybridsprache 

Interpreter 



Erstellung von Webseiten oder Webanwendungen 

Open-Source-Software 


Python 


Editoren 



Fehlersuche 


Test 

Guido van Rossum (Centrum voor 

Wiskunde en Informatica, 

Amsterdam), 1990er Jahre 

benannt nach Monty Python 

objektorientierte, aspektorientierte und 

funktionale Programmiersprache 

(Hybridsprache) 

Interpreter 

Übersichtlichkeit und Lesbarkeit des 

Codes (z.B.: Teamarbeit, 

Programmieranfänger) 




Ruby 


Editoren 



Fehlersuche 


Test 

Yukihiro “Matz” Matsumoto, 1993 - 

1995 

Edelstein Rubin 

Hybridsprache, unterstützt: 

objektorientierte Programmierung 

prozedurale Programmierung 

funktionale Programmierung 

Nebenläufigkeit 




Python 


Editoren 



Fehlersuche 


Test 

einfach und übersichtlich 

(Entwurfsziel): 

mächtiger Funktionsumfang in nur 

wenigen Schlüsselwörtern 

grammatische Syntax reduziert und 

auf Übersichtlichkeit optimiert 

Möglichkeit, auch Programme anderer 

Sprachen als Modul einzubetten 

maschinennahe Programmierung 

schnellerer Routinen 

Skriptsprache anderer Programme 

(z.B.: OpenOffice.org, Blender, 

PyMOL und Gimp) 




Ruby 

Interpreter 


Editoren 



Fehlersuche 


Test 

vollständig objektorientiert 

Principle Of Least Surprise 

Duck Typing: “When I see a bird that 

walks like a duck and swims like a 

duck and quacks like a duck, I call 

that bird a duck.” (James Whitcomb 

Riley) 




Lisp 


Editoren 



Fehlersuche 


Test 



Massachusetts Institute of Technology (MIT), 1995 

List Processing 

objektorientierte, funktionale, prozedurale 

Programmiersprache 


ursprünglich FORTRAN-Unterprogramme, für symbolische 

Berechnungen bzgl. des Lambda-Kalküls 

historisch: Programmiersprache der künstlichen Intelligenz 

“programmierbare Programmiersprache”: große Flexibilität 

und weit reichende Einflussmöglichkeiten des Programmierers 

LISP = “Lots of Irritating Superfluous Parentheses” 


Smalltalk 


Editoren 



Fehlersuche 


Test 



Alan Kay, Dan Ingalls, Adele Goldberg (Xerox PARC 

Forschungszentrum), 1970er Jahre 

objektorientierte Programmiersprache 

Interpreter 

entwickelt für Unterrichtszwecke 

Expertensysteme (Anfang und Mitte der 1990er Jahre) 

Dynamische Typisierung 

keine Mehrfachvererbung 

Automatische Speicherbereinigung 

von Lisp und Simula beeinflusst 

Einfluss auf Entwicklung späterer Programmiersprachen (z.B.: 

Java, Ruby) 


PROLOG 


Editoren 



Fehlersuche 


Test 



Alain Colmerauer, Anfang der 1970er Jahre 

Programming in Logic 

logische Programmiersprache 


beruht auf mathematischen Grundlagen der Prädikatenlogik 

Sammlung von Horn-Klauseln 

Datenbasis, die Fakten und Regeln umfasst 

Anwendungsgebiete: 

1980er Jahre: Bau von Expertensystemen 

heute: Computerlinguistik, Künstliche Intelligenz 



Editoren 



Fehlersuche 


Test 

Interpreter vs. Compiler 

Interpreter: 

schnellere Entwicklungszyklen 

einfachere Testbarkeit 

höhere Flexibilität 

Compiler: 

Ausführungsgeschwindigkeit 





Editoren 



Fehlersuche 


Test 




Taschenbuch Programmiersprachen - Überblick mit 

Beispielen, Bibliographie, ... 


Editor 


Editoren 



Fehlersuche 


Test 

Editor 

Editor-Funktionen 

jEdit 

Eclipse 


Werkzeuge sollen zur Verlängerung der Hände werden. 

Text muss mühelos bearbeitbar sein, da er das elementare 

Rohmaterial für’s Programmieren ist 

Konzentration auf einen Editor, und diesen beherrschen 

(Tastaturkürzel) 

Editor für Quelltext, Dokumentation und sonstige Daten 

verwenden 


Handwerkszeug 


Editoren 



Fehlersuche 


Test 

Editor 


jEdit 

Eclipse 


Ein Schreiner bearbeitet das Rohmaterial Holz. 

Ein Programmierer bearbeitet Text. 


Editor 


Editoren 



Fehlersuche 


Test 

Editor 


jEdit 

Eclipse 


Beim Verwenden mehrerer Programme darauf achten, dass 

(möglichst viele) Tastaturkürzel gleich sind 

Tastaturkürzel müssen zum Reflex werden 

idealerweise einen Editor wählen, der auf mehreren 

Plattformen verfügbar ist 




Editoren 



Fehlersuche 


Test 

Editor 


jEdit 

Eclipse 


Elementare Fähigkeiten, die ein Editor mitbringen sollte: 

Konfigurierbarkeit 

Erweiterbarkeit 

Programmierbarkeit 


Erweiterbarkeit 


Editoren 



Fehlersuche 


Test 

Editor 


jEdit 

Eclipse 


Plugins bieten die Möglichkeit, den Editor um neue Funktionen zu 

erweitern. 

Editor sollte nicht veralten, wenn neue Programmiersprache 

oder neues Datenformat erscheint (z.B. Syntax-Highlighting) 

jede mögliche Compiler-Umgebung sollte integriert werden 

können (Aufruf der spezifischen Tools) 


Konfigurierbarkeit 


Editoren 



Fehlersuche 


Test 

Editor 


jEdit 

Eclipse 


Alle Aspekte sollten auf die eigenen Vorlieben hin konfigurierbar 

sein: 

Schriftart 

Farben (Syntax-Highlighting) 

Fenstergrößen 

Tastenbelegungen (alle Bearbeitungsoperationen sollten per 

Tastaturkürzel nutzbar sein) (”unsichtbares” kann mit 

Tastaturkürzeln erledigt werden) 


Programmierbarkeit 


Editoren 



Fehlersuche 


Test 

Editor 


jEdit 

Eclipse 


Editor sollte für komplizierte, mehrstufige Aufgaben 

programmierbar sein. 

Makros 

eingebaute Skriptsprache (z.B. Emacs-Lisp) 


Produktivität 


Editoren 



Fehlersuche 


Test 

Editor 


jEdit 

Eclipse 


Cursor-Bewegungen: 

Tastenkürzel, die den Cursor in Einheiten von Wörtern, Zeilen, 

Blocks oder Funktionen bewegen sind effizienter als wiederholt eine 

Taste zu drücken. 

Neue Datei: 

Editor kann abhängig vom Typ eine Vorlage liefern 

Namen der Klasse oder des Moduls 

Namen und Urheberrechtsangaben 

Gerüst für Deklarationen (z.B. Konstruktor, Destruktor) 



Editoren 



Fehlersuche 


Test 

Editor 


jEdit 

Eclipse 


Programmiersprachen-spezifische Funktionen 

Syntax-Hervorhebung (falsch geschriebene Schlüsselwörter 

fallen so z.B. schnell auf) 

Automatische Vervollständigung 

Automatische Einrückung 

Textvorlagen 

Verbindung mit Hilfesystem 

IDE-artige Merkmale 

z.B. Compiler und Debugger starten 

direkt zu Fehlern springen 


Produktivität 


Editoren 



Fehlersuche 


Test 

Editor 


jEdit 

Eclipse 


Automatische Einrückung: 

Nach drücken von Return (oder schon nach drücken z.B. von ’{’) 

wird neue Zeile richtig eingerückt. 

Zeilen sortieren: 

Emacs: M-x sort-lines 


jEdit 

www.jedit.org (Java) 


Editoren 



Fehlersuche 


Test 

Editor 


jEdit 

Eclipse 



Editier-Modi 


Editoren 



Fehlersuche 


Test 

Editor 


jEdit 

Eclipse 


jEdit bietet verschiedene Modi für viele Datenformate bzw. 

Programmiersprachen. Ein Modus beschreibt: 

Syntax-Highlighting 

Einrückungsstil 

Softe vs. echte Tabs 



Editoren 



Fehlersuche 


Test 

Tastenkombinationen - Navigieren 

Navigieren: 

Gehe zu Zeile: Ctrl-L 

Ctrl-LEFT, -RIGHT, -UP, -DOWN 

Editor 


jEdit 

Eclipse 


gehe zur passenden Klammer: Ctrl-] 

Code-Block auswählen: Ctrl-[ 

vorherige Klammer: Ctrl-E Ctrl-[ 

nächste Klammer: Ctrl-E Ctrl-] 



Editoren 



Fehlersuche 


Test 

Tastenkombinationen 

Menüs öffnen: 

Dateien: 

Editor 


jEdit 

Eclipse 


Alt-UnterstrichenerBuchstabe, dann UnterstrichenerBuchstabe 

öffnen: Ctrl-O (Dateien anwählen, indem Anfangsbuchstaben 

eingegeben werden) 

speichern: Ctrl-S 



Editoren 



Fehlersuche 


Test 

Tastenkombinationen - Editieren 

Editieren: 

Undo: Ctrl-Z 

Kopieren: Ctrl-C 

Ausschneiden: Ctrl-X 

Einfügen: Ctrl-V 

Zeile löschen: Ctrl-D 

Editor 


jEdit 

Eclipse 


Wort hinter Cursor löschen: Ctrl-DEL 

Bis Zeilenende löschen: Ctrl-Shift-DEL 

Wort vor Cursor löschen: Ctrl-BACKSPACE 

Bis Zeilenanfang löschen: Ctrl-Shift-BACKSPACE 



Editoren 



Fehlersuche 


Test 

Tastenkombinationen - Komfort 

Andere: 

Wort komplettieren: Ctrl-B 

Editor 


jEdit 

Eclipse 


Abkürzung expandieren: Ctrl-; (oder Eingabe von Space am 

Ende der Abkürzung) 


Action Bar 


Editoren 



Fehlersuche 


Test 

Action Bar (Ctrl-RETURN): 

Editor 


jEdit 

Eclipse 


die meisten Editor-Features sind so per Tastatur erreichbar 

Wiederholungen: #Wiederholungen Taste/Aktion 

History; auch Menü-Aktionen und Toolbar-Klicks werden 

gespeichert 

mittels TAB wird eine Liste möglicher Aktionen angezeigt 

(sucht nicht nur am Anfand sondern auch nach Sub-Strings); 

RETURN nimmt das erste Element der (unsichtbaren) Liste 

Eigenschaften ändern (buffer.tabSize=4) 



Editoren 



Fehlersuche 


Test 

Tastenkombinationen - Buffer 

Buffer: 

Splitten: 

Vorheriger Buffer: Ctrl-PAGE UP 

Editor 


jEdit 

Eclipse 


Nächster Buffer: Ctrl-PAGE DOWN 

Letzter Buffer: Ctrl-BACK QUOTE 

Buffer-Liste: Alt-BACK QUOTE 

Horizontal: Ctrl-2 

Vertikal: Ctrl-3 

Umschalten zwischen Text Areas: 

Vorherige: Alt-PAGE UP 

Nächste: Alt-PAGE DOWN 



Editoren 



Fehlersuche 


Test 

Suchen und Ersetzen 

Editor 


jEdit 

Eclipse 


inkrementelles Suchen: Alt-COMMA 

alle Vorkommen eines Ausdrucks: Alt-PERIOD 

reguläre Ausdrücke 

ersetzen durch BeanShell-Snippets 


Makros 


Editoren 



Fehlersuche 


Test 

Editor 


jEdit 

Eclipse 


Temporäres Makro aufnehmen: Ctrl-M Ctrl-M 

Temporäres Makro abspielen: Ctrl-M Ctrl-P 

Benanntes Makro aufnehmen: Ctrl-M Ctrl-R 

Aufnahme beenden: Ctrl-M Ctrl-S 

letztes Makro wiederholen: Ctrl-Shift-B 

Makro aufnehmen, speichern und eine Tastenkombination 

zuweisen. 

Makros sind BeanShell-Skripte. 


Zwischenspeicher 


Editoren 



Fehlersuche 


Test 

Editor 


jEdit 

Eclipse 


Nicht nur ein Zwischenspeicher, sondern (fast) beliebig viele: 

als Register bezeichnet 

in Register kopieren: Ctrl-R Ctrl-C key 

in Register ausschneiden: Ctrl-R Ctrl-X key 

aus Register kopieren: Ctrl-R Ctrl-V key 

Register-Inhalte werden zwischen Sitzungen gespeichert 


BeanShell 


Editoren 



Fehlersuche 


Test 

Makro-Programmiersprache 

Java-Syntax 

erlaubt Zugriff auf jEdit-Klassen 

Editor 


jEdit 

Eclipse 


Utilities>BeanShell>Evaluate Selection: interpretiert Auswahl 

als BeanShell-Code und ersetzt Auswahl durch Ergebnis (z.B. 

”(2*3) + 4”) 


Marker 


Editoren 



Fehlersuche 


Test 

Editor 


jEdit 

Eclipse 


Marker markieren Positionen im Quelltext: 

unbenannten Marker einfügen/löschen: Ctrl-E Ctrl-M 

nächster Marker: Ctrl-E Ctrl-COMMA 

vorheriger Marker: Ctrl-E Ctrl-PERIOD 

benannten Marker einfügen: Ctrl-T key 

zu benanntem Marker gehen: Ctrl-Y key 


Folding 


Editoren 



Fehlersuche 


Test 

Folding (Ausblenden von Quelltext): 

Fold zuklappen: Alt-BACKSPACE 

eine Stufe zuklappen: Alt-RETURN 

Editor 


jEdit 

Eclipse 


alle Stufen zuklappen: Alt-Shift-RETURN 

alles zuklappen: Ctrl-E C 

alles expandieren: Ctrl-E X 

Narrowing (Gegenteil von Folding): 

nur aktuellen Fold anzeigen: Ctrl-E N N 

nur aktuelle Auswahl anzeigen: Ctrl-E N S 


Plugins 


Editoren 



Fehlersuche 


Test 

viele Plugins erhältlich: 

Editor 


jEdit 

Eclipse 


Anwendungen (z.B. Taschenrechner) 

Enterprise (z.B. SQL) 

Datei-Management (z.B. FindFile) 

Formatierer und Prüfer (z.B. AStyle Beautifier) 

HTML und XML (z.B. JTidyPlugin) 

Java (z.B. JExplorer) 


Coole Features 


Editoren 



Fehlersuche 


Test 

Editor 


jEdit 

Eclipse 


entpackt und packt mit GZip komprimierte Dateien 

automatisch 

automatisches Speichern, und Crash Recovery 

Backups (speichert mehrere Versionen einer Datei) 

Kann gut mit Zeichenkodierungen umgehen 

Tooltips für Icons zeigen entsprechendes Tastaturkürzel 

Rechteck- und multiple Selektion von Text 


Plugins 


Editoren 



Fehlersuche 


Test 

Editor 


jEdit 

Eclipse 


Sprachunterstützung (z.B. ClassWizard) 

Netzwerk (z.B. FTP) 

Projekt-Management (z.B. JCounter) 

Unterstützung (z.B. ShortcutDisplay) 

Text (z.B. RETest) 

Versionskontrolle (z.B. GruntspudPlugin) 

Visual (z.B. Highlight) 


Eclipse 


Editoren 



Fehlersuche 


Test 

www.eclipse.org (Java) 

Editor 


jEdit 

Eclipse 





Editoren 



Fehlersuche 


Test 

Editor 


jEdit 

Eclipse 


Einen Editor, und den richtig beherrschen 

Konfigurierbar 

Erweiterbar 

Programmierbar (Makros, Skriptsprache) 

Tastaturkürzel lernen (!), sollten zum Reflex werden 

Syntaxhervorhebung, automatische Vervollständigung, autom. 

Einrückung, Textvorlagen, Hilfesystem, Tools starten 

eclipse, jedit, (emacs) 



Editoren 



Fehlersuche 


Test 

Eclipse - Coole Features 

Klassenbrowser 

Auto-Completion 

Fehler werden sofort angezeigt 

Editor 


jEdit 

Eclipse 


Ctrl-LMB auf Funktions- oder Variablenname springt zur 

Definitionsstelle 

neue Variablen und Funktionen werden sofort im 

Klassenbrowser angezeigt 


Maustipps zeigen Javadoc oder Deklaration an 




Editoren 



Fehlersuche 


Test 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 


Motivation 


Editoren 



Fehlersuche 


Test 

Zugriff auf ältere Versionen 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 

Bearbeiten von Dateien durch mehrere Benutzer 

Erstellen von Zweigen 

Protokollierung von Änderungen 


Sandbox 


Editoren 



Fehlersuche 


Test 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 

Definition 

Eine Sandbox dient der Ablage von Arbeitskopien der 

Dateiversionen aus dem Repository auf dem lokalen Rechner. Für 

jedes Repository kann eine beliebige Anzahl Sandboxes angelegt 

werden, z.B. für unterschiedliche Entwicklungsstufen des selben 

Projekts. 


Repository 


Editoren 



Fehlersuche 


Test 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 

Definition 

Das Repository ist ein zentraler Ablageort für alle Dateien eines 

Projektes. Es enthält alle Angaben, die für die Wiederherstellung 

von früheren Versionen einer Projektdatei notwendig sind. 


Aktionen 


Editoren 



Fehlersuche 


Test 

Importieren von Daten 

Hinzufügen von Daten 

Holen von Daten 

Übermitteln von Daten 

Editieren von Dateien 

Löschen von Dateien 

Markieren von Dateien 

Aktualisieren der Daten 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 



Editoren 



Fehlersuche 


Test 

Importieren von Daten 

Anlegen eines (leeren) Repository 

noch keine Sandbox vorhanden 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 

Erstes Hinzufügen lokaler Projektdateien zum Repository 


Holen von Daten 


Editoren 



Fehlersuche 


Test 

Daten im Repository vorhanden 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 

Daten in der Sandbox nicht vorhanden 

Holen von Dateien aus dem Repository in die Sandbox 



Editoren 



Fehlersuche 


Test 

Hinzufügen von Daten 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 

Daten im Repository nicht vorhanden 

Daten in der Sandbox vorhanden 

Hinzufügen neuer Dateien aus der Sandbox zum Repository 



Editoren 



Fehlersuche 


Test 

Übermitteln von Daten 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 

ältere Version der Daten im Repository vorhanden 

bearbeitete Version der Daten in der Sandbox 

Hinzufügen der bearbeiteten Daten aus der Sandbox ins 

Repository 



Editoren 



Fehlersuche 


Test 

Editieren von Dateien 

Datei zur Bearbeitung vorbereiten 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 

Markierung der Datei zur Information für andere Bearbeiter 



Editoren 



Fehlersuche 


Test 

Markieren von Dateien 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 

Markieren von Dateien, Verzeichnissen, Zweigen, ... 

Versionsnummer, ... 



Editoren 



Fehlersuche 


Test 

Löschen von Dateien 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 

Entfernen von Dateien / Verzeichnissen aus dem Repository 



Editoren 



Fehlersuche 


Test 

Aktualisieren der Daten 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 

Aktualisieren der Daten in der Sandbox 

Unterschiede in den Daten des Repository und der Sandbox 

werden dargestellt 

Dateien, die in einer älteren Version in der Sandbox liegen, 

werden durch die neueste Version aus dem Repository ersetzt 



Editoren 



Fehlersuche 


Test 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 

Beispiele für Versionsverwaltungen 

RCS 

SCCS 

VSS 

Rational ClearCase 

CVS 

SVN 


SCCS 


Editoren 



Fehlersuche 


Test 

Source Code Control System 

1972 

Bell Labs 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 


RCS 


Editoren 



Fehlersuche 


Test 

Revision Control System 

1980er 

Walter F. Tichy 

Purdue University 

GNU-Projekt 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 


VSS 


Editoren 



Fehlersuche 


Test 

Visual SourceSafe 

Microsoft 

VisualBasic, C++, C 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 


Rational ClearCase 

1980er Jahre 

IBM 


Editoren 



Fehlersuche 


Test 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 


Aktionen 

import 

add 

checkout 

commit 

edit 

remove 

tag 

unedit 

update 


Editoren 



Fehlersuche 


Test 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 


CVS 


Editoren 



Fehlersuche 


Test 

Concurrent Versions System 

Entwicklung seit 1989 

GNU General Public License 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 

Weiterentwicklung von RCS und SCCS 


WinCVS 


Editoren 



Fehlersuche 


Test 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 


Cervisia (KDE) 


Editoren 



Fehlersuche 


Test 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 


SVN 


Editoren 



Fehlersuche 


Test 

Vorteile gegenüber CVS: 

Versionierung von Verzeichnissen 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 

Umbenennen von Dateien (und Verzeichnissen) beeinflußt 

nicht die Historie der Datei 

Suche nach Unterschieden zwischen Dateien mit Algorithmus, 

der für Text- und Binärdateien funktioniert 


SVN 

Subversion 


Editoren 



Fehlersuche 


Test 

Entwicklung seit 2000 

CollabNet 

Ersatz für CVS 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 

Konversion eines CVS-Repository mit cvs2svn 


Aktionen 

import 

add 

checkout 

commit 

copy 

delete 

update 


Editoren 



Fehlersuche 


Test 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 


SVN 


Editoren 



Fehlersuche 


Test 

Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 



Editoren 



Fehlersuche 


Test 

Software wird komplexer 

Komplexität 

Fachsprachen 

Quelltextgeneratoren 

Dateien parsen 


früher zeichenorientierte Terminals 

heute grafische Benutzungsschnittstellen mit 

kontextsensitiver Hilfe 

Cut and Paste 

Drag and Drop 

Anwendungen selbst werden immer komplexer 

(Mehrschichtarchitektur). Programme sollen dynamisch und 

flexibel sein und mit Anwendungen von Dritten zusammenarbeiten. 

Programmieren wird immer komplexer. 



Editoren 



Fehlersuche 


Test 


Fachbegriffe 

Aktionen 

Beispiele 

CVS 

SVN 

Literatur 

CVS kurz & gut - Überblick über die wichtigsten Befehle 

Versionskontrolle mit Subversion 

Kurzeinführung in CVS - kurze Einführung in die 

allerwichtigsten CVS-Befehle und in Cervisia 


Zauberer 


Editoren 



Fehlersuche 


Test 

Komplexität 

Fachsprachen 





Neue Werkzeuge 


Editoren 



Fehlersuche 


Test 

Komplexität 

Fachsprachen 




Heute benötigt man andere Werkzeuge wie vor 20 Jahren. 

”Assistenten” erzeugen mit wenigen Eingaben automatisch ein 

Quelltextgerüst. (Danach helfen sie einem dann aber nicht mehr...) 

Aber Vorsicht: Wer den erzeugten Programmcode nicht versteht 

programmiert mit dem Zufall. 

Keinen generierten Quelltext verwenden, den man nicht versteht. 

Sonst veliert man bald die Kontrolle. 


Fachsprachen 


Editoren 



Fehlersuche 


Test 

Komplexität 

Fachsprachen 




“Die Grenzen meiner Sprache bedeuten die Grenze meiner Welt.” 

(Ludwig Wittgenstein) 

Programmiersprachen beeinflußen, wie man über Probleme 

nachdenkt 

Nahe am Problem programmieren, d.h. eigene einfache 

Sprache entwickeln 



Editoren 



Fehlersuche 


Test 

Komplexität 

Fachsprachen 




Unterscheidung zwischen fremdem und eigenem Code 

Implementierungen von verwendeten Bibliotheken versteht man oft 

auch nicht. Diese sind aber in sich gekapselt und nur durch 

wohldefinierte Schnittstellen ansprechbar. 

Generierter Quelltext wird jedoch Teil des eigenen Programms. 


Fachsprachen 


Editoren 



Fehlersuche 


Test 

Komplexität 

Fachsprachen 




Datenbeschreibungssprachen: erzeugen Datenstrukturen, die 

von der Anwendung benutzt werden 

sendmail-Konfiguration 

Menüs, Steuerelemente, Dialoge in Windows Ressourcen-Datei 

Imperative Sprachen: werden in ausführbaren Code umgesetzt 

Umsetzung von eigener Sprache in z.B. C++-Code 

Skriptsprachen, die in Anwendung interpretiert werden (z.B. 

Beanshell in jEdit) 


Schablonen 


Editoren 



Fehlersuche 


Test 

Komplexität 

Fachsprachen 




Wenn ein Schreiner dasselbe Stück immer wieder herstellen muss, 

dann macht er sich eine Schablone. 

vereinfacht die Aufgabe 

verringert das Risiko, Fehler zu begehen 

Der Handwerker kann sich auf die Qualität konzentrieren. 



Editoren 



Fehlersuche 


Test 

Passive Quelltextgeneratoren 

Komplexität 

Fachsprachen 




Passive Quelltextgeneratoren sparen Tipparbeit. Sie sind 

parametrisierte Vorlagen, die aus einer Menge von Eingaben eine 

vorgegebene Ausgabe erzeugen. 

Einsatzzwecke: 

Erzeugen neuer Quelltextdateien: z.B. Vorlagen, 

Urheberrechtsangaben, Standardkommentare, 

Code-Grundgerüst 


Quelltextgenerator 


Editoren 



Fehlersuche 


Test 

Komplexität 

Fachsprachen 




Äquivalent kann sich ein Programmierer einen Quelltextgenerator 

schreiben. 

Es gibt 2 Arten von Quelltextgeneratoren: 

Passive: werden einmalig ausgeführt, von da an wird das 

Ergebnis selbständig 

Assistenten 

einige CASE-Werkzeuge 

Aktive: werden jedesmal Mal ausgeführt, wenn das Ergebnis 

benötigt wird. Ergebnis ist ein Wegwerfprodukt, da es 

jederzeit neu hergestellt werden kann. 



Editoren 



Fehlersuche 


Test 

Passive Quelltextgeneratoren 

Komplexität 

Fachsprachen 




Einmalige Konvertierungen zwischen Programmiersprachen: 

z.B. troff nach L ATEX. Konvertierung muss nicht perfekt sein; 

geringe Nacharbeiten können OK sein. 

Erzeugen von Nachschlagetabellen (LUT) und anderen 

Ressourcen, die zur Laufzeit aufwändig zu berechnen sind. 



Editoren 



Fehlersuche 


Test 

Aktive Quelltextgeneratoren 

Komplexität 

Fachsprachen 




Passive Quelltextgeneratoren sind eine Annehmlichkeit, während 

aktive eine Notwendigkeit sind, wenn man dem DRY-Prinzip folgen 

will (ein einziges Stück Wissen in alle notwendigen Formen 

konvertieren). 

Immer wenn man versucht, verschiedene Umgebungen zur 

Zusammenarbeit zu bewegen, sollte man über aktive 

Quelltextgeneratoren nachdenken. 



Editoren 



Fehlersuche 


Test 

Komplexität 

Fachsprachen 




Aktive QTGs - Beispiel Programmiersprachen 

Werden mehrere Programmiersprachen in einer Anwendung 

verwendet, benötigt man für die Kommunikation (Datenstrukturen, 

Nachrichtenformate) gemeinsame Informationen. 

Entweder die Daten für die eine Sprache aus der anderen 

auslesen. 

Oft leichter Informationen in einer einfachen, sprachneutralen 

Darstellung zu formulieren, und Quelltext für beide Sprachen 

generieren. 



Editoren 



Fehlersuche 


Test 

Aktive QTGs - Beispiel DB 

Komplexität 

Fachsprachen 




Entwickeln einer Datenbankanwendung, 2 Umgebungen: DB und 

Programmiersprache. 

Quelltext aus Datenbankschema generieren. Wird das Schema 

geändert erzeugt man einfach den Quelltext neu. Wird eine Spalte 

gelöscht, verschwindet auch das entsprechende Feld in der 

Datenstruktur. 

1 Schema 

2 Tabelle ’Employee’ 

3 Tabelle ’Employer’ 

4 Tabelle ’Benefit’ 

1 struct EmployeeRow 

2 ... 

3 struct EmployerRow 

4 ... 

5 struct BenefitRow 

6 ... 



Editoren 



Fehlersuche 


Test 

Komplexität 

Fachsprachen 




Aktive QTGs - Beispiel Programmiersprachen 

1 # Add a product 

2 # to the ’on-order’ list 

3 M AddProduct 

4 F id int 

5 F name char[30] 

6 F order_code int 

1 /* Add a product */ 

2 /* to the ’on-order’ list 

*/ 

3 typedef struct { 

4 int id; 

5 char name[30]; 

6 int order_code; 

7 } AddProductMsg; 

1 { Add a product } 

2 { to the ’on-order’ list } 

3 AddProductMsg = packed 

record 

4 id: LongInt; 

5 name: array[0..29] of 

char; 

6 order_code: LongInt; 

7 end; 



Editoren 



Fehlersuche 


Test 

Komplexität 

Fachsprachen 




Aktive QTGs - Beispiel UML zu Quellcode 

Erzeugung von Quelltext aus UML-Diagrammen 

z.B. mit Umbrello 



Editoren 



Fehlersuche 


Test 

QTG - Keep it simple 

Komplexität 

Fachsprachen 




QTGs sind im Idealfall sehr einfach gehalten 

Parsen der Steuerungsdatei ist eigentlich das größte Problem 

also Datenformat einfach halten! 

Erzeugung des Quelltexts besteht hauptsächlich aus 

print-Anweisungen 

QTGs können für jede beliebige Ausgabe verwendet werden 

(HTML, L ATEX, ...) 


Intelligente QTGs 


Editoren 



Fehlersuche 


Test 

Komplexität 

Fachsprachen 




Es geht auch ”two-way”: Eclipse passt die Ansicht einer Klasse im 

Klassen-Browser an, wenn der Quelltext geändert wird und 

umgekehrt. Erzeugt aber nur Grundgerüste. 


Parsen 


Editoren 



Fehlersuche 


Test 

Komplexität 

Fachsprachen 




Die Struktur einer Datei zu analysieren besteht aus 2 Aufgaben: 

1 die Datei in einzelne Token zerlegen 

2 die hierarchische Struktur erkennen 

Dafür gibt es die Programme flex (lex) und bison (yacc). Werden 

hauptsächlich beim Compilerbau verwendet. 


(f)lex 


Editoren 



Fehlersuche 


Test 

flex: ein schneller Scanner-Generator 

Komplexität 

Fachsprachen 




zerlegt einen Eingabestrom in einzelne Einheiten 

gesteuert durch reguläre Ausdrücke und dazugehörige 

Programmfragmente 

flex analyse.lex 

erzeugt C[++]-Code, der Dateien entsprechend der regulären 

Ausdrücke segmentiert (deterministischer endlicher Automat) 

gcc lex.yy.c 


beispiel.lex 


Editoren 



Fehlersuche 


Test 

Komplexität 

Fachsprachen 




1 /* tells flex to provide a default main function */ 

2 %option main 

3 

4 /* rules below */ 

5 %% 

6 a | 

7 e | 

8 [iou] printf("\nVowel %s recognized\n", yytext); 



Editoren 



Fehlersuche 


Test 

Struktur einer flex-Datei 

Definitionsteil 

%% 

Regelteil 

%% 

Benutzerdefinierte Routinen 

Komplexität 

Fachsprachen 




Wobei der Regelteil folgendermaßen aussieht: 

r1 a1; 

r2 a2; 

rn an; 

Eine Aktion besteht aus einer oder mehreren C[++]-Anweisungen. 



Editoren 



Fehlersuche 


Test 

Komplexität 

Fachsprachen 




Segmentierung anhand von beispiel.lex 

Die Eingabe 

1 abcdefghijklmnopqrstuvwxyz 

wird in folgende Einheiten zerlegt: 

1 abcd 

2 e 

3 fgh 

4 i 

5 jklmn 

6 o 

7 pqrst 

8 u 

9 vwxyz 


ison (yacc) 


Editoren 



Fehlersuche 


Test 

Komplexität 

Fachsprachen 




yacc: yet another compiler-compiler (Compiler-Generator) 

analysiert die Struktur eines Datenstroms 

gesteuert durch eine LALR(1) kontextfreie Grammatik (BNF) 

und dazugehörigem Code 

bison analyse.y 

erzeugt C[++]-Code, der bei Auftreten einer Struktur, den 

entsprechenden Code ausführt 


Andere Sprachen 


Editoren 



Fehlersuche 


Test 

Komplexität 

Fachsprachen 




flex und bison erzeugen C[++]-Code 

gibt es auch für andere Sprachen (z.B. javacc) 

http://catalog.compilertools.net 



Editoren 



Fehlersuche 


Test 

Struktur einer bison-Datei 

Definitionsteil 

%% 

Regelteil 

%% 

Benutzerdefinierte Routinen 

Komplexität 

Fachsprachen 




Wobei der Regelteil folgendermaßen aussieht: 

linkeSeite : rechteSeite a1; 

linkeSeite : rechteSeite a2; 

linkeSeite : rechteSeite an; 

Eine Aktion besteht aus einer oder mehreren C[++]-Anweisungen. 




Editoren 



Fehlersuche 


Test 

Komplexität 

Fachsprachen 




Assistenten verwenden ist OK, wenn man den erzeugten 

Quelltext versteht 

Format der Steuerungs-Datei einfach halten 

nicht nur Quelltext kann erzeugt werden, sondern natürlich 

jede Art von Daten (HTML, Text, ...) 



Editoren 



Fehlersuche 


Test 


Komplexität 

Fachsprachen 





Thomas) 

Compilers - Principles, Techniques and Tools, (Aho, 

Sethi, Ullman) 


Debuggen 


Editoren 



Fehlersuche 


Test 

Debuggen 

Psychologie der Fehlersuche 

Strategien für die Fehlersuche 

Debugger 



“Es ist eine schmerzhafte Sache, seine eigenen Probleme zu sehen 

und zu wissen, dass nur man selbst und niemand anders sie 

verursacht hat.” (Sophokles) 


Der 1. Bug 


Editoren 



Fehlersuche 


Test 

Debuggen 



Debugger 





Editoren 



Fehlersuche 


Test 


niemand schreibt perfekte Software 

Debuggen 



Debugger 



ca. 50 % der Zeit werden Fehler gesucht 

Fehlersuche einfach als Lösen von Problemen betrachten 

Wer ist schuld? Egal, Problem beheben! 



Editoren 



Fehlersuche 


Test 

Mentalität für die Fehlersuche 

Debuggen 



Debugger 



“Sich selbst kann man am leichtesten täuschen.” (Edward 

Bulwer-Lytton) 

entspannen 

Bequem machen 

Keine Panik! 

ruhig nachdenken, worin die Ursachen liegen könnten 

Wurzel des Problems finden, nicht nur Symptome beseitigen 


Daten visualisieren 


Editoren 



Fehlersuche 


Test 

Debuggen 



Debugger 



bearbeitete Daten anzeigen lassen 

als einfacher Text 

grafisch 

Debugger verwenden, der Daten und deren Zusammenhänge 

visualisieren kann 

Daten als 3D-Landschaft 

als Strukturdiagramm 

Papier und Bleistift 


Wo beginnen? 


Editoren 



Fehlersuche 


Test 

Debuggen 



Debugger 



bevor man beginnt, sicherstellen, dass Quelltext ohne 

Warnungen kompiliert 

genaue Fehlerbeschreibung, relevante Informationen 

zusammentragen 

eventuell Anwender befragen, der Fehler entdeckte 

künstliche Tests testen die Anwendung nicht ausreichend 

sowohl Grenzfälle als auch realistische Eingabemuster testen 

Fehler (mit möglichst wenigen Schritten) reproduzierbar 

machen 


Tracing 


Editoren 



Fehlersuche 


Test 

Debuggen 



Debugger 



Zustand des Programms oder einer Datenstruktur im Laufe 

der Zeit beobachten 

Diagnosemeldungen auf Bildschirm oder in Log-Datei 

reguläres, konsistentes Format verwenden; ermöglicht 

automatische Analyse 


Gummi-Enten 


Editoren 



Fehlersuche 


Test 

Debuggen 



Debugger 



einfache aber nützliche Technik für die Analyse eines 

Problems: es jemand anderem erklären 

das kann eine Gummi-Ente sein :-) 

oft führt das schrittweise Erklären dazu, dass einem die 

Ursache des Problems klar wird 

dadurch werden Dinge explizit ausgesprochen, die man für 

selbstverständlich hält 



Editoren 



Fehlersuche 


Test 

Überraschungsmomente 

Debuggen 



Debugger 



manchmal liegt der Fehler in einer Funktion, von der man 

glaubte, dass sie absolut korrekt funktioniert 

nicht annehmen, dass etwas auf eine bestimmte Art und 

Weise funktioniert, sondern beweisen 

gibt es andere Stellen im Programm, die für diesen Fehler 

anfällig sein könnten? gleich mitbeheben. 

wenn Fehlersuche lange gedauert hat, überlegen, wie man es 

beim nächsten Mal schneller machen kann 


Ausschlussverfahren 


Editoren 



Fehlersuche 


Test 

Debuggen 



Debugger 



meist liegt der Fehler im eigenen Code, und nicht in den 

verwendeten Bibliotheken 

lesen der Dokumentation hilft, wenn man meint, etwas müsste 

auf eine bestimmte Art und Weise funktionieren, es aber nicht 

tut 

binäres Verfahren zur Fehlersuche 



Editoren 



Fehlersuche 


Test 

Tote Programme lügen nicht 

Debuggen 



Debugger 



immer Prüfen, ob Funktionen fehlerfrei beendet wurden 

defensiv Programmieren: Probleme so früh wie möglich 

erkennen 

Programme abstürzen lassen (aber möglichst noch 

Aufräumen), sonst macht man eventuell mit zweifelhaften 

Daten weiter 

Java wirft z.B. Runtime Exceptions 



Editoren 



Fehlersuche 


Test 

Abgesichert Programmieren 

Debuggen 



Debugger 



“Selbstbezichtigung ist auch eine Art Luxus. Wenn wir uns selbst 

die Schuld geben, glauben wir niemand sonst habe das Recht uns 

zu beschuldigen.” (Oscar Wilde) 

”Das kann nie passieren...” Doch! 

Das Unmögliche mit Zusicherungen verhindern. 

C[++]: assert-Makro 

1 void writeString(char* string) { 

2 assert(string != NULL); 

3 ... 


Design by Contract 


Editoren 



Fehlersuche 


Test 

geht noch weiter als Zusicherungen 

Debuggen 



Debugger 



dokumentiert Rechte und Pflichten von Softwaremodulen 

Vorbedingungen: müssen gelten damit eine Funktion 

aufgerufen werden kann 

Nachbedingungen: garantierter Zustand nach Beendigung 

der Funktion 

Klassen-Invarianten: Klasse stellt sicher, dass diese 

Bedingung aus Sicht des Aufrufers immer gilt 

arbeitsscheuen Code schreiben: streng sein mit dem was man 

akzeptiert, und wenig versprechen 

unterstützt von Eiffel, iContract für Java, Nana für C[++] 



Editoren 



Fehlersuche 


Test 

Abgesichert Programmieren 

Debuggen 



Debugger 



Bedingung einer Zusicherung darf keine Seiteneffekte haben 

(also keinen Quelltext, der ausgeführt werden muss) 

Heisen-Bug: Fehlersuche, die das Verhalten des Systems 

beeinflusst 

Zusicherungen möglichst immer eingeschaltet lassen 



Editoren 



Fehlersuche 


Test 

Debuggen 



Debugger 



Design by Contract - Beispiel (iContract) 

1 /** 

2 * @invariant forall Node n in element() | 

3 * n.prev() != null 

4 * implies 

5 * n.value().compareTo(n.prev().value()) > 0 

6 */ 

7 public class dbc_list { 

8 /** 

9 * @pre contains(aNode) == false 

10 * @post contains(aNode) == true 

11 */ 

12 public void insertNode(final Node aNode) { 

13 // ... 


GDB 


Editoren 



Fehlersuche 


Test 

Debuggen 



Debugger 




DDD 


Editoren 



Fehlersuche 


Test 

Debuggen 



Debugger 



graphisches Front-End für zeichenorientierte Debugger (GDB, 

DBX, Ladebug, XDB) 

unterstützt auch Java (jdb), Python (pydb), Perl und Bash 

stellt Datenstrukturen und deren Beziehungen übersichtlich 

dar 


GDB 

GNU Debugger 


Editoren 



Fehlersuche 


Test 

Debuggen 



Debugger 



zeichenorientierter Debugger für C[++] und Modula-2, 

Fortran, Java, Pascal, Assembler und Ada 

Schritt für Schritt durch ein Programm 

Anzeigen von Variablen-Inhalten 

Haltepunkte an beliebigen Stellen, oder wenn bestimmte 

Bedingungen eintreten 

funktioniert sehr gut, ist jedoch mühsam zu bedienen 


DDD 


Editoren 



Fehlersuche 


Test 

Debuggen 



Debugger 




Valgrind 


Editoren 



Fehlersuche 


Test 

Debuggen 



Debugger 



läßt zu untersuchende Programme in einer virtuellen Maschine 

laufen 

findet Speicherlecks 

cachegrind prüft Laufzeit (profiler) 


Strace 


Editoren 



Fehlersuche 


Test 

Zeigt geöffnete Dateien und Systemaufrufe. 

Anzahl und Dauer von Systemaufrufen 

1 strace -c ls -l 

Dateizugriffe 

1 strace -e trace=file ls -l 

Netzwerkzugriffe 

1 strace -e trace=network firefox 

Debuggen 



Debugger 




Flawfinder 


Editoren 



Fehlersuche 


Test 

Debuggen 



Debugger 



analysiert Quellcode statisch (eingebaute DB von C/C++ 

Funktionen mit bekannten Problemen, einfaches 

Patternmatching) 

findet häufige Fehler 

ähnliche Tools: splint, RATS (Rough Auditing Tool for 

Security) 




Editoren 



Fehlersuche 


Test 

Debuggen 



Debugger 



50 % der Zeit Fehler suchen, Keine Panik! 

Fehler binär suchen 

Compilerwarnungen beachten 

gdb, ddd als Frontend 

Programme kennenlernen 

Tracing (Logging) 

Gummi-Ente 



Editoren 



Fehlersuche 


Test 


Debuggen 



Debugger 




Thomas) 


Dokumentation 


Editoren 



Fehlersuche 


Test 

Dokumentation 

Dokumentationswerkzeuge 


Dokumentieren sollte als integraler Bestandteil der 

Software-Entwicklung angesehen werden 

Dokumentieren wird einfacher wenn 

man die Arbeit nicht mehrfach macht 

die Dokumentation in Reichweite aufbewahrt wird 

Donald Knuth: ”Literate Programming” (Schreiben von 

Computerprogrammen in einer Form, so dass sie vor allem für 

Menschen lesbar sind) 

Javadoc, etc. 


Dokumentation 


Editoren 



Fehlersuche 


Test 

Dokumentation 



“Die blasseste Tinte ist besser als das schlechteste Gedächtnis.” 

(Chinesisches Sprichwort) 


Dokumentation 


Editoren 



Fehlersuche 


Test 

Dokumentation 



Quelltext und Dokumentation sind 2 Sichten auf dasselbe 

Modell 

Dokumentation ist ein Spiegel des Quelltextes. Bei 

Unstimmigkeiten zählt der Quelltext 

Deutsch (Englisch) wie eine Programmiersprache behandeln. (D.h. 

alle pragmatischen Prinzipien genauso auf Dokumentation 

anwenden wie auf Quelltext.) 

Dokumentation einbauen anstatt sie dranzuschrauben. 



Editoren 



Fehlersuche 


Test 

Arten der Dokumentation 

Dokumentation 



Es gibt 2 Arten der Dokumentation: 

interne 

Quelltextkommentare 

Entwurfs- und Testdokumente 

Pflichtenheft 

externe 

alles was ausgeliefert oder für die Außenwelt veröffentlicht wird 

(z.B. Benutzerhandbücher) 



Editoren 



Fehlersuche 


Test 

Kommentare im Quelltext 

Kommentiert werden sollten: 

das Modul 

Datentypen 

Dokumentation 



Klassen 

Funktionen 

beschreibt, wie die Funktion aufgerufen wird, und was dabei 

beachtet werden muss 



Editoren 



Fehlersuche 


Test 


Dokumentation 



Aus Kommentaren und Deklarationen im Quelltext kann 

Dokumentation erzeugt werden. Quelltext benötigt Kommentare, 

zu viele sind aber genauso schlecht wie zu wenige. 

Kommentare sollen erklären wieso etwas getan wird (Zweck und 

Ziel, Grund für Kompromisse, Alternativen). Wie es getan wird 

steht schon im Quelltext (und sollte deshalb nicht kommentiert 

werden). 



Editoren 



Fehlersuche 


Test 


Dokumentation 



Was nicht in Quelltextkommentaren stehen sollte: 

eine Liste der exportierten Funktionen der Datei 

Änderungshistorie (dafür sind Versionskontrollsysteme da) 

Liste von Dateien, die verwendet werden 

Name der Datei 

Es gibt externe Programm, die Quelltext analysieren, und diese 

Informationen ermitteln können. 



Editoren 



Fehlersuche 


Test 

Ausführbare Dokumente 

Dokumentation 



SQL-Anweisungen und Datenstruktur aus 

Datenbank-Spezifikation erzeugen 

bei Vorlage in Klartext z.B. Perl verwenden 

bei Vorlage in proprietärem Format: 

Makros schreiben 

oder als Klartext exportieren 

bei Änderung der Spezifikation können andere ”Ansichten” 

auf das ”Modell” einfach automatisch erzeugt werden 



Editoren 



Fehlersuche 


Test 

Drucken oder Weben 

Dokumentation 



Dokumentation auf Papier veraltet sobald sie gedruckt ist 

Dokumentation möglichst (zusätzlich) in einer Form erstellen, 

die im Netz mit Hyperlinks veröffentlicht werden kann 

ist leichter aktuell zu halten 

oft muss Dokumentation in verschiedenen Formaten erstellt 

werden (Handbuch, Webseite) 

kein Cut and Paste! 

alles automatisch aus einer Quelle erstellen 

oder Textbearbeitungsprogramm verwenden, das in die 

benötigten Formate exportieren kann 


Technische Autoren 


Editoren 



Fehlersuche 


Test 

Dokumentation 



externe Dokumentation wie Benutzerhandbücher und 

Werbematerial werden oft von professionellen technischen 

Autoren geschrieben 

diese sollten auch Zugriff auf automatisch generierte 

Dokumentation haben 


Markup-Sprachen 


Editoren 



Fehlersuche 


Test 

Dokumentation 



für (große) Dokumentationsprojekte Markup-Sprachen 

verwenden 

DocBook (SGML-basiert) 

kann in viele verschiedene Formate umgewandelt werden 

(TeX, PS, HTML) 



Editoren 



Fehlersuche 


Test 


Dokumentation 



Dokumentation im Quellcode (DRY) 

javadoc, doxygen, DOC++ 

Quellcode browsen (auch ohne zusätzliche Kommentare) 

Visualisierung von Vererbungsdiagrammen und 

Abhängigkeitsgraphen 


Doxygen 


Editoren 



Fehlersuche 


Test 

Dokumentation 




Doxygen 


Editoren 



Fehlersuche 


Test 

Dokumentation 



unterstützte Programmiersprachen: C[++], Java, Python, ... 

Ausgabeformate: HTML, LaTeX, PostScript, PDF, Man page, 

... 




Editoren 



Fehlersuche 


Test 

Dokumentation 



Dokumentation und Quellcode sind (sollten sein) zwei Sichten 

auf dasselbe Modell 

Dokumentation im Quellcode (DRY) 

javadoc, doxygen 

erzeugte API-Doku kann zum Quellcodebrowsen verwendet 

werden 



Editoren 



Fehlersuche 


Test 


Dokumentation 




Thomas) 


Motivation 


Editoren 



Fehlersuche 


Test 

Motivation 

Testarten 

Testbare Eigenschaften 

Testablauf 

Regressionstest 

Black-Box-Test 

Glass-Box-Test 


Code and Fix: Codierung oder Korrektur im Wechsel mit 

Ad-hoc-Tests (unwirtschaftlich, aber weit verbreitet) 

Tests gehören zu den Kernprozessen in einem 

Entwicklungsprozess 

Zusammenspiel mehrerer Komponenten 

Nacharbeiten (nach Auslieferung) vermeiden: 

Kunde soll funktionierende Software erhalten 

Kunde soll vollständige Software erhalten (entsprechend 

Spezifikation) 

Fehler sind nicht immer offensichtlich 


Test 


Editoren 



Fehlersuche 


Test 

Motivation 

Testarten 


Testablauf 






Testarten 


Editoren 



Fehlersuche 


Test 

Motivation 

Testarten 


Testablauf 





Was wird getestet? 

Modultest (Low-Level) 

Integrationstest (Low-Level) 

Systemtest (High-Level) 

Akzeptanztest (High-Level) 

→ vgl. Kernprozesse eines Entwicklungsprozesses 

Wie wird getestet? 





Modultest 

Unit Test 


Editoren 



Fehlersuche 


Test 

Komponententest 

Motivation 

Testarten 


Testablauf 





Überprüfung der Korrektheit eines Software-Moduls 

automatisiert (Testprogramm) 

Vorstufe zu Integrationstest 

Voraussetzung für Refaktorisieren: 

Modultest nach jeder Änderung 


Systemtest 


Editoren 



Fehlersuche 


Test 

Motivation 

Testarten 


Testablauf 





Test des Gesamtsystems gegen die Spezifikation 

Funktionaler Systemtest: 

Überprüfung auf Korrektheit und Vollständigkeit 

Nicht funktionaler Systemtest: 

Überprüfung auf Sicherheit, Benutzbarkeit, Zuverlässigkeit, ... 


Integrationstest 


Editoren 



Fehlersuche 


Test 

Motivation 

Testarten 


Testablauf 





Test des Zusammenspiels abhängiger Komponenten 

vorheriger Test der einzelnen Komponenten 

Überprüfung der einzelnen Komponenten nach der 

Zusammenführung 

Überprüfung des Datenaustausches über gemeinsame 

Schnittstelle(n) 

Bottom-Up-Methode: 

Integrationstest für abgegrenztes Subsystem 

Subsystem wird als Komponente betrachtet 


Akzeptanztest 


Editoren 



Fehlersuche 


Test 

Test durch Kunde/Anwender 

Motivation 

Testarten 


Testablauf 





Überprüfung der Anforderungen aus dem Pflichtenheft 



Editoren 



Fehlersuche 


Test 


Funktionalität 

Installation 

Wiederinbetriebnahme 

Verfügbarkeit 

Motivation 

Testarten 


Testablauf 






Installation 


Editoren 



Fehlersuche 


Test 

Installation möglich? 

Inbetriebnahme möglich? 

Dokumentation vollständig? 

Motivation 

Testarten 


Testablauf 






Funktionalität 


Editoren 



Fehlersuche 


Test 

Spezifikation erfüllt? 

Motivation 

Testarten 


Testablauf 







Editoren 



Fehlersuche 


Test 

Wiederinbetriebnahme 

Motivation 

Testarten 


Testablauf 





Neustart nach Unterbrechung möglich? 

Dokumentation vollständig? 


Verfügbarkeit 


Editoren 



Fehlersuche 


Test 

Motivation 

Testarten 


Testablauf 





Systemlauf über geforderte Zeitspanne 

Störung? 


Vorbereitung 


Editoren 



Fehlersuche 


Test 

Testplan erstellen: 

Abgleich mit Spezifikation 

Wiederverwendung 

Erweiterung 

Motivation 

Testarten 


Testablauf 






Vorbereitung 


Editoren 



Fehlersuche 


Test 

Testfälle bestimmen: 

Anfangszustand 

Werte der Eingabedaten 

Bedienungen 

erwartete Ausgaben 

Motivation 

Testarten 


Testablauf 






Vorbereitung 


Editoren 



Fehlersuche 


Test 

Motivation 

Testarten 


Testablauf 





Der Test sollte nach Möglichkeit nicht vom Entwickler selbst 

ausgeführt werden. 

Ein Test durch den Entwickler ist aber immer noch besser als gar 

kein Test. 


Regeln 


Editoren 



Fehlersuche 


Test 

kein vorzeitiger Abbruch 

Motivation 

Testarten 


Testablauf 





keine spezielle Testvariante des Programms 

kein Wechseln zwischen Test und Debugging 


Auswertung 


Editoren 



Fehlersuche 


Test 

Motivation 

Testarten 


Testablauf 





Prüfung, ob Programm genau das tut, was es soll und nichts 

anderes 

Testbericht: 

administrative Angaben (Modulbezeichnung, Datum, ...) 

Schlußbewertung 

Verweise auf den Test betreffende Dokumente 

festgestellte Abweichungen (⇒ Problemmeldung) 

Grundlage für Planung und Kontrolle der Fehlerbehebung 


Abbruchkriterien 


Editoren 



Fehlersuche 


Test 

nach festgelegter Maximaldauer 

nach bestimmtem Aufwand 

Motivation 

Testarten 


Testablauf 





nach festgelegter Laufzeit ohne Fehler 

Ausführung aller spezifizierten Testfälle liefert spezifizierte 

Ergebnisse 

durchschnittliche Testkosten pro entdecktem Fehler 

übersteigen festgelegten Wert 

festgelegte Anzahl Fehler entdeckt 




Editoren 



Fehlersuche 


Test 

Änderung von Software: 

Bugfix 

Erweiterung 

Motivation 

Testarten 


Testablauf 





Überprüfung auf Nebenwirkungen durch Modifikation bereits 

getesteter Software 

Wiederholung aller Testfälle 

Übereinstimmung der Testresultate mit denen der Vorversion 

(abgesehen von gewollten Unterschieden) 

automatisierte Ausführung möglich 


Funktionstest 


Editoren 



Fehlersuche 


Test 

Abgleich mit Spezifikation 

Motivation 

Testarten 


Testablauf 





Testdatenauswahl entsprechend der gewünschten 

Funktionalität des Programms 



Editoren 



Fehlersuche 


Test 

Eingabeüberdeckung 

Motivation 

Testarten 


Testablauf 





Bearbeitung aller unterschiedlichen Eingabekombinationen 

Eingabekombinationen aus Spezifikation auflisten 

Testfall für jede Eingabemöglichkeit beschreiben 



Editoren 



Fehlersuche 


Test 

Funktionsüberdeckung 

Motivation 

Testarten 


Testablauf 





Überprüfung aller Funktionen des Programms 

Funktionen aus Spezifikation auflisten 

Testfall für jede Funktion beschreiben 



Editoren 



Fehlersuche 


Test 

Ausgabeüberdeckung 

Motivation 

Testarten 


Testablauf 





Erzeugen sämtlicher möglicher Ausgabeformen 

Ausgabeformen aus Spezifikation auflisten 

Testfall/Testfälle für jede Ausgabeform beschreiben 



Editoren 



Fehlersuche 


Test 

Beispiel - Testgegenstand 

Motivation 

Testarten 


Testablauf 







Editoren 



Fehlersuche 


Test 

Beispiel - Funktionsüberdeckung 

Motivation 

Testarten 


Testablauf 





Nr. Beschreibung Eingabe Ausgabe Kommentar 

F01 Transportmittel vollpacken und Gepäck wird ok 

(R01) losschicken transportiert 

F02 handhabbar von A nach B bewegt sich durchgef. 

(R02) führen von A nach B (störrisch) 

F03 kommt mit un- über unebenes bewegt sich ok 

ebenem Ge- Gelände führen über unebenes 

lände klar (R03) Gelände 

... ... ... ... ... 

Fnn umweltfreundl. Brennstoff umweltvertr. ok 

(Rnn) Abfallprodukt 



Editoren 



Fehlersuche 


Test 

Beispiel - Anforderungen 

Motivation 

Testarten 


Testablauf 





Nr. Beschreibung 

R01 als Transportmittel nutzbar 

R02 leicht handhabbar 

R03 kommt mit unebenem Gelände zurecht 

... ... 

Rnn umweltfreundlich 



Editoren 



Fehlersuche 


Test 

Beispiel - Eingabeüberdeckung 

Motivation 

Testarten 


Testablauf 





Nr. Eingabe geforderte Reaktion Kommentar 

E01 Kommando “Los” Vorwärtsbewegung durchgefallen 

(funktioniert oft) 

E02 Kommando “links” Bewegung nach durchgefallen 

links (unzuverlässig) 

E03 Kommando “rechts” Bewegung nach durchgefallen 

rechts (unzuverlässig) 

E04 Kommando Stillstand durchgefallen 

“stehenbleiben” (unzuverlässig) 

... ... ... ... 

Enn Manueller Anschub Vorwärtsbewegung ok (widerwillig) 



Editoren 



Fehlersuche 


Test 

Beispiel - Ausgabeüberdeckung 

Motivation 

Testarten 


Testablauf 





Nr. geforderte Ausgabe benötigte Eingabe Kommentar 

A01 Vorwärtsbewegung Kommando “Los”, ok 

ggf. manueller Anschub 

A02 Stillstand Kommando “stehen- ok 

bleiben”, ggf. Festhalten 

A03 voll Beladen Festhalten und Beladen ok 

... ... ... ... 

Ann Fortbewegung in Kommando “rechts”, ok 

korrekte Richtung “links” oder manueller (widerwillig) 

Anschub 



Editoren 



Fehlersuche 


Test 

Anweisungsüberdeckung 

Motivation 

Testarten 


Testablauf 





Überprüfung möglichst vieler Anweisungen 

Idealfall: 

Überprüfung aller Anweisungen 

Überdeckung wird als Verhältnis angegeben: 

x % der Anweisungen wurden im Test ausgeführt 


Strukturtest 


Editoren 



Fehlersuche 


Test 

Überprüfung der Abläufe 

Motivation 

Testarten 


Testablauf 





Testdatenauswahl unter Einfluß der inneren Struktur des 

Programms 



Editoren 



Fehlersuche 


Test 

Motivation 

Testarten 


Testablauf 





Zweig- / Entscheidungsüberdeckung 

Überprüfung möglichst vieler Verzweigungsmöglichkeiten 

Idealfall: 

Überprüfung aller Verzweigungsmöglichkeiten 


x % der Verzweigungsmöglichkeiten wurden im Test ausgeführt 


Termüberdeckung 


Editoren 



Fehlersuche 


Test 

Motivation 

Testarten 


Testablauf 





Ausführen möglichst vieler logischer Terme 

Idealfall: Ausführen aller logischen Terme 


x % der logischen Terme wurden im Test wirksam 


Pfadüberdeckung 


Editoren 



Fehlersuche 


Test 

Motivation 

Testarten 


Testablauf 





Ausführen möglichst vieler Pfade durch das Programm 

Idealfall: Ausführen aller möglichen Pfade 


x % der möglichen Pfade wurden im Test durchlaufen 



Editoren 



Fehlersuche 


Test 

Behandlung von Schleifen 

Umgehung der Schleife 

eine Iteration 

zwei Iterationen 

typische Anzahl Iterationen 

maximale Anzahl Iterationen 

Motivation 

Testarten 


Testablauf 







Editoren 



Fehlersuche 


Test 

Programmeinheitenüberdeckung 

Motivation 

Testarten 


Testablauf 





Überdeckungskriterium für Programmkomponenten 

jede Komponente wird mindestens einmal aufgerufen 


Aufrufüberdeckung 


Editoren 



Fehlersuche 


Test 

Motivation 

Testarten 


Testablauf 






jeder aufrufbare Teil der Einheiten eines Programms wird 

wenigstens einmal aufgerufen 




Editoren 



Fehlersuche 


Test 

Motivation 

Testarten 


Testablauf 





Modultest zur Überprüfung von Programmkomponenten 

Integrationstest zur Überprüfung des Zusammenspiels 

mehrerer Komponenten 

Systemtest zur Überprüfung des Gesamtsystems 

Akzeptanztest durch den Kunden 

Black-Box-Test zur Überprüfung der Funktionalität 

Glass-Box-Test zur Überprüfung der Struktur 

Black- und Glass-Box-Test ergänzen einander 

Testen ist wichtig! 



Editoren 



Fehlersuche 


Test 

Programmpfadüberdeckung 

Motivation 

Testarten 


Testablauf 






alle möglichen Ausführungssequenzen von Programmeinheiten 

werden mindestens einmal durchlaufen 



Editoren 



Fehlersuche 


Test 


Motivation 

Testarten 


Testablauf 





Quelle: Skript zur Vorlesung “Software-Engineering” (Stand: 

Mai 1997) 

Prof. Dr. rer. nat. Jochen Ludewig 

http://www.iste.uni-stuttgart.de/se/se.html

Effizientes Programmieren - Methoden und Werkzeuge ...

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?