WS12/13 -- Basisinformationstechnologie I | 09: Programmiersprachen

Transcript

1. Universität zu Köln. Historisch-Kulturwissenschaftliche Informationsverarbeitung Jan G. Wieners // jan.wieners@uni-koeln.de Basisinformationstechnologie I Wintersemester 2012/13 12. Dezember 2012 – Programmiersprachen I
2. Phasen der Programmentwicklung  Analyse  Spezifikation  Entwurf  Algorithmus  Pseudocode  Implementation  (Dokumentation)  (Testphase)  (Refactoring) Programmiersprachen  Compiler / Interpreter Themenüberblick „Programmiersprachen I“
3. Phasen der Programmentwicklung
4. Neulich in den Sommerferien…
14. Analyse
15. Analyse des gestellten Problems  ToDo: Eine Möglichkeit entwickeln, trotz Dunkelheit einen Weg aus dem Labyrinth zu finden Spezifikation: Problembeschreibung – im Gegensatz zum Algorithmus, der die Lösung des Problems angibt Beachten:  Problemkomplex exakt und vollständig beschreiben  Ein- und Ausgabewerte berücksichtigen (Parameter)  Randbedingungen bzw. Spezialfälle berücksichtigen Programmentwicklung: Analyse
16. Descartes (1596-1650) -- „Regeln zur Leitung des Geistes" (1628):  Hohe Relevanz der Analysephase  Aufteilung in Teil- und Unterprobleme  Hierarchischer Erkenntnisprozess  Analyse der Analyse i.e. Sicherung der Analyse Programmentwicklung: Analyse Vgl.: http://www.netzmafia.de/skripten/ad/ad2.html
17. Spezifikation: Problembeschreibung – im Gegensatz zum Algorithmus, der die Lösung des Problems angibt Algorithmus: Anleitung oder Vorschrift, wie sich ein Problem lösen lässt Arbeitsdefinition Algorithmus: Eindeutige Beschreibung eines endlichen Verfahrens zur Lösung einer bestimmten Klasse von Problemen Algorithmus im Labyrinthbeispiel: Verfahren, um aus dem dunklen Labyrinth zu gelangen Programmentwicklung: Algorithmus
18. Entwurf
19. Welche Annahmen, Verfahren, Entwürfe liegen der folgenden Lösung zu Grunde? Programmentwicklung: Entwurfsphase I
20. Entwurf I: Wir entkommen den Fängen des Minotaurus, wenn wir: 1. Vorsichtig (es ist ja dunkel) der Nase nach gehen, bis wir auf eine Wand treffen 2. Wir mit der linken Hand an der Wand entlang gehen Programmentwicklung: Entwurfsphase I
21. Problem! Treffen wir auf eine Säule, so funktioniert unsere Lösung nicht mehr, viel schlimmer noch: Wir drehen uns endlos im Kreis Programmentwicklung: Entwurfsphase II
22. Wir verlangen (zumeist) von Algorithmen, dass sie terminieren, d.h. dass sie in endlicher Zeit (und möglichst schnell  Performance) ihre Arbeit erledigt haben Algorithmen: Terminierung
23. Performance A: Performance
24. Performance B: Gibt es einen schnelleren Weg, um aus dem Labyrinth zu gelangen? Ja! Performance
25. Zurück zum Problem Treffen wir auf eine Säule, so funktioniert unsere Lösung nicht mehr - wir drehen uns endlos im Kreis Programmentwicklung: Entwurfsphase II
26. Berücksichtigung von Sonderfällen: Der Algorithmus muss Säulen verarbeiten können Programmentwicklung: Entwurfsphase II
27. Neuer Versuch: Wir folgen der Nase nach bis zur Wand, folgen anschließend der Wand so lange, bis wir wieder in die alte Richtung schauen; dann erneut geradeaus Programmentwicklung: Entwurfsphase II
28. Problem: Die neue Lösung ist partikulär, funktioniert nicht für die erste Problemstellung Programmentwicklung: Entwurfsphase II
29. Grundfrage Algorithmus:  Existiert ein Algorithmus, der für jedes denkbare Labyrinth, aus dem es einen Ausgang gibt, einen Weg ins Freie findet?  Pledge-Algorithmus: Zusätzlich zur Gangrichtung berücksichtigen wir die Drehungen, die an den Ecken ausgeführt werden Programmentwicklung: Entwurfsphase III
30. Pledge-Algorithmus:  Prämisse: Wir gehen davon aus, dass alle Ecken rechtwinklig sind  Somit kommen nur Rechtsdrehungen und Linksdrehungen um jeweils 90 Grad vor  Wir verwalten unterwegs einen Umdrehungszähler, der:  bei jeder Linksdrehung um eins erhöht und  bei jeder Rechtsdrehung um eins verringert wird (auch bei der ersten Rechtsdrehung, die nach dem Auftreffen auf eine Wand ausgeführt wird).  Zu Beginn wird dieser Umdrehungszähler auf null gesetzt  Anschließend werden die beiden Anweisungen  geradeaus, bis Wand erreicht  Folge der Wand, bis Umdrehungszähler = 0 solange wiederholt, bis wir ins Freie gelangen Programmentwicklung: Entwurfsphase III
31. Pseudocode Pledge-Algorithmus:  Setze Umdrehungszähler auf 0;  Repeat  Repeat  Gehe geradeaus;  Until Wand erreicht;  Drehe nach rechts;  Repeat  Folge dem Hindernis;  Until Umdrehungszähler=0;  Until ins Helle gelangt;  Entwurf ist unabhängig von Programmiersprache! Programmentwicklung: Entwurfsphase III Vgl.: Vöcking, Berhold et. al.:Taschenbuch der Algorithmen. Springer. 2008. S. 75-81.
33. Phasen der Programmentwicklung  Analyse  Spezifikation  Entwurf  Algorithmus  Pseudocode  Implementation  (Dokumentation)  (Testphase)  (Refactoring)  Programmiersprachen  Compiler / Interpreter Zwischenstand
34. Implementation Programmerstellung und Programmiersprachen
35. Programmiersprachen [Quelle: http://www.spiegel.de/fotostrecke/fotostrecke-62645.html] Programmiersprache: Eine zum Formulieren von Programmen geschaffene künstliche / formale Sprache Warum braucht man so etwas? Darum:
36. C++ C
37. Strukturierte Computerorganisation Problemorientierte Sprache Assemblersprache Betriebssystemmaschine Befehlssatzarchitektur (ISA) Mikroarchitektur Digitale Logik Ebene 5 Ebene 4 Ebene 3 Ebene 2 Ebene 1 Ebene 0
38. Maschinennahe Programmiersprache: Assembler Beispiel: „Hello World“ : DATA SEGMENT ;- Beginn des Datensegments Meldung db "Hello World" ;- Die Zeichenkette "Hello World" db "$" ;- Endzeichen der Zeichenkette DATA ENDS ;- Ende des Datensegment CODE SEGMENT ;- Beginn des Codesegements ASSUME CS:CODE,DS:DATA ;- Dem Assembler die Segmente mitteilen Anfang: ;- Label für den Anfang des Programms mov ax, DATA ;- das Daten... mov ds, ax ; ...segment festlegen mov dx, offset Meldung ;- den Text in das auf DS bezogene Datenregister laden mov ah, 09h ;- Die Unterfunktion 9 des Betriebssysteminterrupts 21h auswählen int 21h ;- den Betriebssysteminterrupt 21h (hier erfolgt Ausgabe des Texts) aufrufen mov ax, 4C00h ;- Die Unterfunktion 4Ch (Programmbeendigung) des Betriebssysteminterrupts 21h festlegen int 21h ;- diesen Befehl wiederum ausführen CODE ENDS ;- Ende des Codesegments END Anfang ;- dem Assembler das Ende des Labels Anfang mitteilen Programmiersprachen: Klassifizierung Vgl.: http://de.wikipedia.org/wiki/Assemblersprache
39. Anweisungen, die wir dem Computer geben, werden als Text formuliert, z.B.: In Python: print "Hello World!„ In JavaScript: document.write( “Hello World!“ ); In C++: […] cout << „Hello World“; […] Programmiersprachen
40. Programmtext ist formuliert nach festen Regeln: Beispiel C++: cout << “Hello World“; Die Regeln (Grammatik) der Programmiersprache C++ schreiben vor, dass der Ausdruck cout << “Hello World“ mit einem Semikolon abgeschlossen werden muss Programmiersprachen
41. Wer prüft zu welchem Zeitpunkt die Grammatik? Programmierung häufig mittels Programmierumgebungen (IDE, integrated develompent environment), die Werkzeuge beinhalten:  Editor  Compiler  Debugger (Fehlersuche) Beispiele: Microsoft Visual Studio, Qt Creator, Eclipse Compiler  Computerprogramm, das ein in einer Hochsprache (C++, etc.) formuliertes Programm, das sog. Quellprogramm in ein Zielprogramm, z.B.:  Bytecode (Sammlung von Befehlen für eine virtuelle Maschine) oder  Maschinencode (Instruktionen, die der entsprechende Prozessor (Hardware) direkt umsetzen kann) übersetzt „kompilieren“: Verb, Anwendung eines Compilers auf ein Quellprogramm Programmiersprachen
42. Compiler  kompletter Programmtext wird in eine Folge von Maschinenbefehlen übersetzt, bevor die erste Programmanweisung ausgeführt wird. [C++] Interpreter  übersetzt immer nur eine einzige Programmanweisung in ein kleines Unterprogramm aus Maschinenbefehlen und führt dieses sofort aus. Anschließend wird mit der nächsten Anweisung genauso verfahren. [JavaScript, Python] Interpreter Pro: Einfacher zu konstruieren als Compiler Interpreter Contra: Ein Befehl, der mehrfach ausgeführt wird, muss jedes mal erneut übersetzt werden Compiler vs. Interpreter
43. Programmierparadigmen
44.  Dynamische Typisierung  Paradigmen: Prozedurale, funktionale und objektorientierte (klassenlose) Programmierung
45. Variablen: Behälter / Speicherstelle; Typisierung  Typ der Variable In JavaScript: // Deklaration var eineVariable, eineWeitereVariable; // Initialisierung eineVariable = 23; eineWeitereVariable = “Hello World!“;  Dynamische Typisierung In C++: int eineVariable = 23; char eineWeitereVariable[]="Hello World";  Statische Typisierung Typisierung
46. Paradigmen:  funktional  imperativ  objektorientiert  prozedural  etc.
47. Funktionale Programmierung: Programme bestehen aus Funktionen. JavaScript: var randomize = function( lowerBound, upperBound ) { if( lowerBound > upperBound ) { return( -1 ); } if( lowerBound === upperBound ) { return( lowerBound ); } return lowerBound + parseInt( Math.random() * ( upperBound-lowerBound+1 ), 10); } Programmierparadigmen
48. Prozedurale Programmierung: Aufteilung von Programmen in Teilprogramme bzw. –Aufgaben: Prozeduren [C, Pascal] Objektorientierte Programmierung [C++, Java]  Zentrales Konzept: Objekt  Objekt  Verfügt über einen bestimmten Zustand  Reagiert mit einem definierten Verhalten auf Anforderungen / seine Umgebung  Besitzt eine Identität, die es von anderen Objekten unterscheidet  Kann mit anderen Objekten verbunden sein Programmierparadigmen
49. C++:  Ermöglicht maschinennahe Programmierung (Stichw. „Zeiger“), als auch abstrakte Programmierung (i.e. Objektorientierung)  Kompilierung über g++ Compiler, Microsoft Visual C++ Compiler, etc. Objektorientierte Programmiersprachen: C++
50. Java  Besonderheit: Java-Programme werden in Bytecode übersetzt, anschließend in einer Java-Laufzeitumgebung ausgeführt  Virtuelle Maschine (VM)  Vorteil: Plattformunabhängigkeit: Java-Programme laufen zumeist ohne weitere Anpassungen auf unterschiedlichen Computer- und Betriebssystemen, für die eine Java-VM existiert Objektorientierte Programmiersprachen: Java
51. Tradierung von (Entwurfs- und Implementations)wissen Gamm, Helm, Johnson, Vlissides [1994]  The Gang of Four U.a.: • Factory Pattern • Singleton Pattern • Observer Pattern
52. Endspurt der Implementation…
53. Überprüfung, ob das entwickelte Programm die Problemstellung korrekt und vollständig löst Dazu: Ausführung des Programmes mit verschiedenen Eingabewerten und Startzuständen, um möglichst jede Situation abzubilden Automatisierte Tests  “Writing automated tests is accepted to produce higher quality code at lower cost. More tests == less time spent debugging” (vgl.: Francesco Carucci (Crytek): http://www.slideshare.net/fcarucci/aaa-automated-testing) Testphase
54. “Write the simplest code that could possibly make the test pass Refactor the code to eliminate all possible duplications and code smells” (vgl.: Francesco Carucci (Crytek): http://www.slideshare.net/fcarucci/aaa-automated-testing) Test-driven development
55. Refactoring (Refaktorisierung / Umgestaltung): Manuelle oder automatisierte Programmverbesserung (u.a. Performance, CodeQualität) unter Beibehaltung des Programmverhaltens Refactoring
56. …notwendig: Dokumentation
57. /
58. Aufgabe 1: Skizzieren Sie bitte kurz die Analyse- und die Entwurfsphase bei der Programmentwicklung. Aufgabe 2: Was bezeichnet eine Spezifikation, was ein Algorithmus? Aufgabe 3: Erläutern Sie bitte den Unterschied zwischen einem Compiler und einem Interpreter. Aufgabe 4: Worin unterscheidet sich die dynamische von der statischen Typisierung? Welche Vor- und Nachteile haben beide Konzepte? Aufgabe 5: Unterscheiden Sie bitte das funktionale Programmierparadigma vom objektorientierten. Hausaufgaben