4.A Programmierung. Bausteine der Programmierung: Problemformulierungen Algorithmen Implementierungen Testen Dokumentieren

Transkript

1 ISS: EDV-Grundlagen 1. Einleitung und Geschichte der EDV 2. Daten und Codierung 3. Rechnerarchitektur 4. Programmierung und Softwareentwicklung 5. Betriebssyteme 6. Internet und Internet-Dienste

2 4.A Programmierung Programmieren, oder besser, Computer Programmieren, ist der Prozess, Instruktionen für einen Computer zu schreiben, die den Computer veranlassen, eine vorbestimmte Aufgabe zu erledigen. Bausteine der Programmierung: Problemformulierungen Algorithmen Implementierungen Testen Dokumentieren Ergebnis ist Software: lauffähige Programme oder verwendbare Bibliotheken.

3 4.B Software Engineering Software Engineering beschreibt eine systematische Vorgehensweise für Entwicklung von Software Betrieb von Software Pflege von Software Sterben von Software Begleitet also die gesamte Lebenszeit einer Software (software life-cycle). Es existieren verschiedene Systematiken für einzelne Bausteine. Systematiken sind notwendig/sinnvoll für Arbeiten im Team: Jeder weiß, wer was wie macht. Einhalten von Systematiken gehört zum Qualitätsmanagment, kurz QM.

4 4.C Algorithmen Ganz grob ist ein Algorithmus ein Lösungsverfahren für eine Klasse von Problemen. Vergleichbar einem Rezept, Prozess, Methode, Technik, Prozedur, Routine. Beispiele für Problemklassen und ihre Algorithmusidee: Bestimmen des größten gemeinsamen Teilers: Euklidischer Algorithmus Lösung einer quadratischen Gleichung: p-q-formel Lösung eines linearen Gleichungssystems: Gauss-Algorithmus Sortieren von Patientendaten: Sortieren durch Auswahl Öffnen einer Tür: trainierter Reflex?

5 1) The Art of Computer Programming I, pp. 4 4.C Algorithmen Formale Definition (nach Knuth 1) ): Ein Algorithmus ist ein endlicher Satz von Anweisungen zur Lösung einer gegebenen Klasse von Aufgaben. Zusätzlich muss ein Algorithmus die folgenden fünf Kriterien erfüllen: 1. Endlichkeit (finiteness): Ein Algorithmus terminiert in allen Fällen nach einer endlichen Anzahl von Schritten. 2. Bestimmtheit (definitness): Jede Anweisung eines Algorithmus ist klar, unzweideutig und durchführbar. 3. Eingabe (input): Ein Algorithmus hat Null oder mehr Eingaben: Objekte, die zu Beginn oder zur Laufzeit extern eingegeben werden. 4. Ausgabe (output): Ein Algorithmus hat eine oder mehr Ausgaben: Objekte, die in einer spezifischen Relation zur Eingabe stehen. 5. Effizienz (effectiveness): Jede Anweisung eines Algorithmus muss so grundlegend sein, dass sie im Prinzip von jedermann mit Papier und Bleistift in endlicher Zeit ausgeführt werden kann.

6 4.C Algorithmen Zwischen Algorithmus und Programm wird in der Informatik unterschieden. Ein Programm muss beispielsweise nicht endlich sein. Etwa wartet eine vergessene grafische Oberfläche endlos auf Benutzereingaben, wenn das Betriebssystem des Computers nicht abstürzt. Darüber hinaus muss das Programm so formuliert sein, dass es auf einem Rechner lauffähig ist. Ein Algorithmus kann auf verschiedene Weisen formuliert werden: in natürlicher Sprache, in Pseudo Code, in grafischer Darstellung (Struktogramm, Flußdiagramm),....

7 4.D Programmiersprachen Programmiersprachen: Zu klären ist: Wie rede ich mit meinem Computer? Wie bringe ich ihm bei, dass zu tuen, was ich von ihm will? Wie setze ich konkret einen Lösungsalgorithmus auf dem Rechner um? Wir brauchen eine Programmiersprache. Diese fallen in drei Kategorien: 1. Maschinensprache, 2. Assembler und 3. Höher Programmiersprache.

8 4.D Programmiersprachen Maschinensprache: Einzige Sprache, die direkt vom Computer verstanden wird. Definiert durch das Hardware Design des Rechners: maschinenabhängig. Unverständlich für den Menschen: Strom von 0en und 1en. Kaum bis gar nicht für den Menschen programmierbar. Führte zu den Assemblern. Anfang von hello.exe hexadezimal: f 464c a2c c c f f f b b a0 96b a b c d d d e f c2f c2f 2d64 696c 756e

9 4.D Programmiersprachen Assembler: Englisch ähnliche Abkürzungen, die elementare Operationen des Rechners darstellen. Ebenfalls maschinenabhängig. Spricht Prozessor, Register und RAM direkt an. Werden in die Maschinensprache übersetzt. Übersetzung geht schnell. Deutlich lesbarer als Maschinencode. Aber immer noch viele Instruktionen für einfache Aufgaben. Aufgabe: total = LDA 5 STA num1 LDA 4 ADD num1 STA total Einsatz für System-Software und Speziallösungen z.b. Signalprozessoren und Grafikchips. Führt zu höheren Programmiersprachen.

10 4.D Programmiersprachen Höhere Programmiersprachen: Einzelne Anweisungen führen komplexe Aufgaben aus. Maschinenunabhängig. Compiler Sprachen: Werden nach Maschinensprache übersetzt: Compiler. Übersetzung benötigt relativ viel Zeit. Schnelle Laufzeit der Programme. Interpreter Sprachen: Lassen Programme ohne Compilierung laufen. Rapid Development. Deutlich langsamere Laufzeiten der Programme. Für beide gilt: Anweisungen sind lesbar für den Menschen. Klingen nach alltäglichen Englisch. Enthalten übliche mathematische Notationen.

11 4.D Programmiersprachen Es gibt viele Hundert verschiedene höhere Programmiersprachen: Ada, Algol, APL, awk, Basic, C, C++, Cobol, Delphi, Eiel, Euphoria, Forth, Fortran, (HTML), Icon, Java, Javascript, Lisp, Logo, Mathematica, Matlab, Miranda, Modula-2, Oberon, Pascal, Perl, PL/1, Prolog, Python, Rexx, SAS, Scheme, sed, Simula, Smalltalk, Snobol, SQL, Visual Basic, Visual C++, (XML), The Language Guide: Computer Languages History: C Dennis Ritchie (Bell Laboratories) 1971 C++ Bjarne Stroustrup (Bell Laboratories) Juli 1983 Fortran John Backus (IBM) Nov Java James Gosling (Sun Labs) Mai 1995 Mathematica Stephen Wolfram (Wolfram Research) 1988 Pascal Nikolaus Wirth (ETH) 1970 Python Guido Van Rossum (Stichting) 1991 Ruby Yukihiro Matsumoto, Feb. 1993

12 4.D Programmiersprachen Was jede höhere Programmiersprache unterstützt sind Input: Lesen von Werten in das Programm Output: Schreiben von Werten aus dem Programm Mathematik: Rechenoperationen auf Zahlen Bedingungen: Bedingte Ausführung von Anweisungen Wiederholungen: Wiederholte Ausführung von Anweisungen Und das genügt auch, um all das zu programmieren, was gebraucht wird. Was meist noch dazukommt sind Funktionen oder Unterprogramme, Bibliotheken für das modulare Programmieren.

13 4.D Programmiersprachen,Hello world Traditionell beginnt jedes Lernen einer Programmiersprache mit einem Programm, dass Hello World! auf dem Monitor ausgibt. Wir schauen uns das an in C++, Java und Python. Wer noch mehr Beispiele sehen möchte: Hello, World Page! Page!:

14 4.D Programmiersprachen,Hello world in C++:./src/hello.cpp // "Hello world!" in C++ #include <iostream> int main(void) { std::cout << "Hello world!" << std::endl; return 1; } Dann compilieren (erzeugt hello.o): C:\> g++ -c hello.cpp Dann linken (erzeugt hello.exe): C:\> g++ -o hello.exe hello.o Starten mit C:\> hello

15 4.D Programmiersprachen Und nochmal,hello world in Java:./src/hello.java // "Hello world!" in Java class hello { public hello() { } public static void main(string[] args args) { System.out.println("Hello world!"); } } Dann compilieren (erzeugt hello.class): C:\> javac hello.java Starten mit C:\> java hello

16 4.D Programmiersprachen Zuletzt,Hello world in Python:./src/hello.py # "Hello world!" in Python print "Hello world!" Starten mit C:\> python hello.py Und alle drei Programme erzeugen die Ausgabe Hello world!

17 4.B Softwareentwicklung Statistische Angaben aus der Praxis - Nur 5 % aller SW-Projekte werden termingerecht fertig (Wallmüller 90, S. 2) % des Entwicklungsaufwandes (oder oft mehr) für Fehlersuche und Fehlerbehebung aufgewendet (Wallmüller 90, S. 3). - Von 8 großen Softwareprojekten werden durchschnittlich 2 abgebrochen (Spektrum der Wissenschaft). - 3 / 4 aller komplexen SW-Projekte funktionieren am Ende nicht wie gedacht bzw. werden nicht eingesetzt (SdW).

18 Softwareentwicklung

19 Konsequenzen Nach Erhalt einer SW-Entwicklungsaufgabe: - nicht sofort drauflos programmieren - zunächst gründlich die Aufgabe durchdenken, Unklarheiten beim Kunden nachfragen Programmierung macht bei der SW-Entwicklung nur einen kleineren Anteil aus. Genauso wichtig sind Fähigkeiten wie exakte Problemdefinition finden, systematische Fehlersuche u. a. Bereits bei der Programmierung muss an die Zeit nach der Auslieferung der SW gedacht werden (Wartung): lesbare, gut strukturierte, gut kommentierte Programme SW-Entwicklung bedeutet immer Teamarbeit

20 Konsequenzen Softwaresysteme gehören zu den komplexesten Gebilden, die je von Menschenhand geschaffen wurden. Strukturen und Abläufe in großen Systemen sind im einzelnen oft nicht mehr überschaubar. Man kann sie weder im vorhinein, beim Entwurf, noch im nachhinein, beim Testen, im Betrieb und in der Wartung vollständig verstehen. (Denert, Software-Engineering, S. 4) Das entscheidende Charakteristikum der industriell einsetzbaren Software ist, daß es für den einzelnen Entwickler sehr schwierig, wenn nicht gar unmöglich ist, alle Feinheiten des Designs zu verstehen. Einfach ausgedrückt, überschreitet die Komplexität solcher Systeme die Kapazität der menschlichen Intelligenz. (Booch, Objektorientierte Analyse und Design, S.18)

21 Software = Programme, Daten, Dokumentation Eigenschaften von Software: (vgl. Balzert, S. 26 f., Denert) - kein Verschleiß (keine Abnutzung beim Einsatz) - leicht kopierbar ( auch Fehler) -altert *) (SW wird ständig angepaßt) - lange in Benutzung **) - schwer zu vermessen (Metriken: Qualität, Quantität) - äußerst komplex (in der Praxis) *) nach 10 Jahren Einsatzzeit existiert oft keine Originalzeile mehr (Faustregel, nach Pagel, Six S. 35) **) durchschnittlich Jahre, (Wallmüller 90, S. 3) bis zu 30 Jahren (Hausi Müller)

22 Softwaregröße Klassifikation der Softwaregröße: klein: bis 2000 Zeilen Quelltext mittel: groß: sehr groß: > 1 Mio. Durchschnittliche Größe verwalteter Software unter den 100 größten USA-Firmen: 35 Mio Zeilen Quellcode. z. B.USA, DoD: 1,4 Mia. Quelltextzeilen (verteilt über 1700 Datenzentren) Betriebskosten für diese Systeme: 9 Mia. Dollar / Jahr.

23 Qualitätskriterien für SW-Produkte (nach Pagel/Six, Pomberger, Meyer, Marciniak) Korrektheit, Robustheit (z. B. bei Fehlbedienung), Effizienz, Benutzerfreundlichkeit, Dokumentation (Beschreibung der Programme), Modifizierbarkeit Lesbarkeit (Verständlichkeit, Kommentare, sinnvolle Bezeichnerwahl, Formatierung...), Wiederverwendbarkeit, Modularität (zerlegt in Module / Komponenten), Portabilität (übertragbar auf anderen Rechner) Integrität (Schutz gegen unberechtigten Zugriff)

24 Modularisierung Eine bekannte Technik zur Beherrschung von Komplexität ist der antike Grundsatz: Devide et Impera (Teile und herrsche). Nur durch eine Einteilung in Einzelteile (Module) können mehrere Personen an einem Gesamtsystem arbeiten. Ein Modul verbirgt wichtige Entwurfsentscheidung und bietet nur seine dokumentierte Funktionalität und den Aufruf der Funktionalität (Signatur) an.

25 Kriterien für Module

26 Kriterien für Module

27 Strukturierte Analyse und Design

28 Modelle der Softwareentwicklung Prozedurale / modulare Programme lassen sich mit der SA/SD (Strukturierte Analyse/ strukturiertes Design) beschreiben. Objektorientierte Programme benötigen anderen Ansatz UML (Unified Modelling Language)

29 Klassisches Wasserfallmodell, auch Stufenmodell

30 Phasen der Softwareentwicklung Analyse und Definition Analyse des Problems + Definition der Anforderungen an das SW-Produkt Gegenstand: Außenverhalten des SW-Systems Auftraggeber Auftragnehmer Produktdefinition (Systemspezifikation, Anforderungsdefinition, Pflichtenheft) Entwurf (Design) Struktur, Aufbau, Komponenten der SW und ihre Beziehungen festlegen Software-Architektur Implementation Software-Architektur ausgefüllt : Programmierung der Komponenten Programm Test Test der Komponenten, Test ihrer Integration (Systemtest) Testprotokolle

31 Vorgehensmodelle: Überblick - Klassisches Phasenmodell (Wasserfallmodell) - Iteriertes Phasenmodell (Lebenszyklus) - Spiralmodell - Prototyping (evolutionäre Softwareentwicklung) - Transformationelle Softwareentwicklung - Systemzusammensetzung aus nachnutzbaren Komponenten

32 Iteriertes Phasenmodell Bewertung des iterierten Phasenmodells 1. Rückschritte sind nur zwischen den benachbarten Phasen möglich 2. Frühes Festschreiben der Anforderungen erschwert nachträgliche Änderungen; Fehler in der Anforderungsanalyse werden erst spät erkannt 3. Einführung Systems erfolgt erst sehr spät und erfolgt auf einen Schlag (Big Bang) Verbesserung durch Rapid Prototyping mit a) Throw-away Prototypes b) Evolutionären Prototypen

33 V-Modell (Life-Cycle) Betont die Wichtigkeit von Tests Quality Assurance Was nicht wirklich verbessert wird: Sequenzialität Feedback Risk Management (während der Entwicklung)

34 V-Modell-XT

35 Spiralmodell

36 Bewertung Spiralmodell - Big Bang-Effekt kann verhindert werden - enge Rückkopplung mit Anwender ermöglicht bessere Umsetzung der Anforderungen - im Gegensatz zum Wasserfallmodell sehr gute Möglichkeiten zum Rücksprung (Iterationen sind fest eingeplant) - ABER: der Projektverlauf ist schwer überprüfbar; die Schwierigkeit liegt im Abschätzen der noch benötigten Iterationen Besondere Problematik: - größerer organisatorischer Aufwand bei der Planung der evolutionären Schritte, d.h. in welche Iteration wird welche Funktionalität realisiert - Ausrichten der Architektur auf den evolutionären Bau - Durch Anpassung an die Änderungen der Anforderungen kann die ursprüngliche Architektur verloren gehen - Ein Projektende kann durch das Anpassen an neue Anforderungen nach hinten verschoben werden; ein dezidiertes Ende muß definiert werden

37 extreme Programming Projektzyklus: Planning Game On-Site Customer Acceptance Test Short Increments Entwicklungszyklus: Simple Design Pair Programming Unit Test Refactoring Unterstützende Praktiken Metaphor Collective Ownership Continuous Integration 40-hour week Programming Standards