Anhang A: Die Familie der C-Sprachen Anhang B: Grundlagen der C++ und der Java-Programmierung. Vorgehensmodelle der Software-Entwicklung

Transkript

1 Einführung in die Software-Entwicklung 7 Software-Entwicklung im Team 1. Von der Idee zur Software 2. Funktionen und Datenstrukturen 3. Organisation des Quellcodes 4. Werte- und Referenzsemantik 5. Entwurf von Algorithmen 6. Fehlersuche und behandlung 7. Software-Entwicklung im Team 8. Abstrakte Datentypen: Einheit von Daten und Funktionalität 9. Vielgestaltigkeit (Polymorphie) 10. Entwurfsprinzipien für Software Anhang A: Die Familie der C-Sprachen Anhang B: Grundlagen der C++ und der Java-Programmierung 7.1 Management von Software-Projekten 7.2 Agile Software-Entwicklung 7.3 Design, Testen und Dokumentation unter XP 7.4 Agile Software-Entwicklung in großen Projekten? 7.5 Projektmanagement-Hilfsmittel 7.6.Vorgehensmodelle für größere Projekte 7.7 Zusammenfassung Im Lehrbuch und Kompendium nicht behandelt. Folien mit gelben Punkten am oberen rechten Rand sind weniger wichtiger für das Verständnis der nachfolgenden Kapitel. V 3.11; Prof. Helmke 3 V 3.11; Prof. Helmke 4 Wasserfallmodell Vorgehensmodelle der Software-Entwicklung Ein Vorgehensmodell zur Software-Entwicklung (auch als Software- Lebenszyklus bezeichnet) ist ein ausgefeilter Plan mit zeitlichen und sachlichen Vorgaben. Es legt die Reihenfolge einzelner Schritte mit ihrem jeweiligen Ergebnissen fest und regelt detailliert, wer wann was in einem Projekt zu tun hat. Das Vorgehensmodell gestaltet die Software-Entwicklung übersichtlicher und erleichtert die Beherrschung der Komplexität. V 3.11; Prof. Helmke 5 V 3.11; Prof. Helmke 6

2 Vorgehensmodelle der Software-Entwicklung (2) Wasserfallmodell (2) Ein Vorgehensmodell (der Plan) unterteilt den Entwicklungsprozess in überschaubare, zeitlich und inhaltlich begrenzte Aktivitäten, deren Ergebnisse einzelne Teilprodukte sind. Die Aktivitäten werden zu Phasen (z.b. Analyse, Design, Implementierung, Fehlersuche, Test) zusammengefasst und diese werden dann -- evtl. mit geringen Modifikationen -- einmal (z. B. Wasserfallmodell) oder mehrmals durchlaufen (z. B. Spiralmodell). Wir werden sehen, dass es das optimale Vorgehensmodell nicht geben kann. Es hängt in jedem Fall von der zu lösenden Aufgabe (vom Projekt), aber auch von beteiligten Personen (vom Team) ab. In der Regel verhält es sich aber so, dass je statischer und eindimensionaler die Betrachtungsweise ist, desto weniger hat sie mit der Praxis der Programmierung zu tun. Eines der ältesten Modelle ist das sog. Wasserfallmodell, das eine starre Abfolge der einzelnen Phasen annimmt. Dabei gehen die Phasenergebnisse immer als bindende Vorgaben in die nächst tiefere Phase ein. Jede Phase hat wohldefinierte Start- und Endpunkte mit eindeutig definierten Ergebnissen. Zu den wichtigsten Dokumenten zählen dabei das Lastenheft sowie das Pflichtenheft als Ergebnisse der Analysephase. In der betrieblichen Praxis gibt es viele Varianten des reinen Modells. V 3.11; Prof. Helmke 7 V 3.11; Prof. Helmke 8 Wasserfallmodell (3) 7 Software-Entwicklung im Team Die Anwendung des Wasserfallmodells setzt voraus, dass sich die Anforderungen in der Planungsphase relativ präzise beschreiben lassen. Erweiterungen des einfachen Modells erlauben deshalb ein schrittweises Vorgehen. Der Kunde (Nutzer) weiß zu Beginn und auch am Ende der Analysephase noch gar nicht genau, was ihm wirklich helfen könnte. Erst wenn er ein lauffähiges System vorliegen hat und damit herumspielen kann, kann er seine Anforderungen mehr und mehr konkretisieren. Wenn dann allerdings bereits drei Jahre Entwicklungszeit verstrichen sind, haben sowohl Kunde als auch die Entwickler ein Problem. 7.1 Management von Software-Projekten 7.2 Agile Software-Entwicklung 7.3 Design, Testen und Dokumentation unter XP 7.4 Agile Software-Entwicklung in großen Projekten? 7.5 Projektmanagement-Hilfsmittel 7.6.Vorgehensmodelle für größere Projekte 7.7 Zusammenfassung Im Lehrbuch und Kompendium nicht behandelt. Genau hier versuchen die im Folgenden vorgestellten agilen Methoden anzusetzen. V 3.11; Prof. Helmke 9 V 3.11; Prof. Helmke 11

3 Clicker- Abstimmung Clicker- Abstimmung Kennen Sie XP (extreme Programming)? Kennen Sie agile Software-Entwicklung? 1. Noch nie von gehört 2. Grobe Vorstellung 3. Kenne ich. 1. Noch nie von gehört 2. Grobe Vorstellung 3. Kenne ich. 1_ 2_ 3_ 1. Noch nie von gehört 2. Grobe Vorstellung 3. Kenne ich. 1_ 2_ 3_ V 3.11; Prof. Helmke 12 V 3.11; Prof. Helmke 13 Literatur zur Agilen Software-Entwicklung --- Kent Beck: Extreme Programming, Addison Wesley --- K. Beck, M. Fowler: Extreme Programming planen, Addison Wesley, Jutta Eckstein: Agile Softwareentwicklung im Großen -- Ein Eintauchen in die Untiefen erfolgreicher Projekte, dpunkt.verlag, 2004 XP -- Geschichte Extreme Programming (XP) wurde Ende der 90er Jahre von Kent Beck erfolgreich innerhalb eines Projektes bei Chrysler eingesetzt. Es beruht auf allgemein in der Software-Entwickler-Gemeinde akzeptierten Prinzipien. Allerdings werden sie in XP nicht nur ein bisschen eingesetzt, sondern alle Regler werden voll aufgedreht, daher der Name extreme Programming : --- Martin Lippert, Stefan Roock, Henning Wolf: Software entwickeln mit extreme Programming -- Erfahrungen aus der Praxis, dpunkt.verlag, Jeffries, Anderson, Hendrickson: Extreme Programming installed, Addison Wesley,2001 V 3.11; Prof. Helmke 14 V 3.11; Prof. Helmke 15

4 Akzeptierte Prinzipien werden extrem genutzt Akzeptierte Prinzipien werden extrem genutzt (2) Von Code-Reviews ist bekannt, dass sie ein sehr positives Kosten-Nutzen- Verhältnis aufweisen. Warum also nicht durch paarweises programmieren, ständig Reviews durchführen? Wenn Testen zur Qualitätsverbesserung der Software beiträgt, warum soll dann nicht jeder Entwickler (durch Unit-Tests) und der Kunde (durch Akzeptanztests) ständig testen? Ein gutes Design der Software ist wichtig. Deshalb sollte jeder Entwickler durch Refactoring täglich zur Designverbesserung beitragen. Da einfache Systeme besser zu warten sind, sollte immer das einfachste Design gewählt werden, dass die gegenwärtigen Anforderungen erfüllt. Da Integration und Integrationstest wichtig sind, wird mehrmals am Tag integriert und getestet. Schnelle Iterationen sind anzustreben. Deshalb sollte eine Iteration sehr, sehr kurz sein -- Stunden oder Tage, nicht Wochen oder gar Monate. V 3.11; Prof. Helmke 16 V 3.11; Prof. Helmke 17 Werte von XP 7 Software-Entwicklung im Team XP basiert auf vier einfachen Werten: Einfachheit (engl. simplicity), Kommunikation (engl. communication), Rückkopplung (engl. feedback) und Mut (engl. courage). 7.1 Management von Software-Projekten 7.2 Agile Software-Entwicklung Die Basistechniken von XP 7.3 Design, Testen und Dokumentation unter XP 7.4 Agile Software-Entwicklung in großen Projekten? 7.5 Projektmanagement-Hilfsmittel 7.6.Vorgehensmodelle für größere Projekte 7.7 Zusammenfassung Feedback anzunehmen und zu geben, erfordert Mut. Festgetrampelte Pfad abzutrampeln erfordert keinen Mut (Tools, die von allen benutzt werden). V 3.11; Prof. Helmke 18 V 3.11; Prof. Helmke 21

5 Änderungskosten während der Software-Entwicklungsphasen Die Basistechniken von XP Konkret wird extreme Programming erst durch die 12 Basistechniken, die die Werte und Prinzipien unterstützen. Die Wirksamkeit der Basistechniken und damit von XP insgesamt beruht auf der Annahme einer flachen Aufwandskurve, d.h. der Aufwand zur Realisierung einer Anforderung ist (weitgehend) unabhängig vom Zeitpunkt der Umsetzung. Damit entfällt der Zwang, bereits alle Anforderungen bei Beginnder Implementierungsphase zu kennen. Im Gegensatz dazu gehen traditionelle Entwicklungsansätze von einer steilen (exponentiellen) Aufwandskurve aus, d.h. je später eine Anforderung nach dem Projektstart erstellt wird, desto größer wird dann deren Realisierungsaufwand angenommen. Somit wäre eine vollständige Erhebung aller Anforderungen zu Projektbeginn vor Beginn der Implementierungsphase anzustreben. V 3.11; Prof. Helmke 22 V 3.11; Prof. Helmke 23 Die 12 Basistechniken des XP 1. Kunde vor Ort 2. Planungsspiel 3. Metapher (bildliche Vorstellungen davon, wie ein System funktioniert und welche grundsätzlichen Annahmen gemacht werden). 4. Kurze Releasezyklen 5. Testen (Komponententests) 6. Einfaches Design 7. Refactoring 8. Programmieren in Paaren 9. Gemeinsame Verantwortlichkeit 10. Fortlaufende Integration 11. (Programmierstandards) Stunden-Woche; keine Überstunden Komponententests Eine Funktion existiert solange nicht, bis sie durch einen automatisierten Test abgeprüft wird. Einsatz von CppUnit Teilweise Ersatz durch Reviews Erfordert sehr viel Disziplin insbesondere die Erstellung der Tests vor der Implementierung Aber: Der Aufwand lohnt sich! V 3.11; Prof. Helmke 24 V 3.11; Prof. Helmke 25

6 KOMPONENTENTESTS mit CppUnit Programmieren in Paaren Richtung_grad degrees = 100.2; asserttest(tovaliddegree1_360(degrees) == 100); degrees = 372.2; asserttest(tovaliddegree1_360(degrees) == 12); int i_degrees = 0; asserttest(tovaliddegree1_360(i_degrees) == 360); degrees = 0.25; asserttest(tovaliddegree0_359(degrees) == 0); degrees = ; asserttest(tovaliddegree0_359(degrees) == 0); Keine Zeile Code wird geschrieben, ohne dass zwei Paar Augen auf den Bildschirm gerichtet sind. Partner wechseln sich an der Tastatur ab, Programmierpartner rotieren Höhere Codequalität Größere Produktivität (mehr Spaß!) Bessere Wissensverbreitung V 3.11; Prof. Helmke 26 V 3.11; Prof. Helmke 27 Programmieren in Paaren (2) Clicker- Abstimmung Keine Zeile Code wird geschrieben, ohne dass zwei Paar Augen auf den Bildschirm gerichtet sind. Schwer realisierbar, aufgrund von unterschiedlichen Arbeitszeitmodellen (Teilzeitkräfte, mehrere Arbeitgeber, Frühaufsteher, Langschläfer), Unterschiedlichen Aufgabentypen (Software-Erstellung, Konzepten, Veröffentlichungen, Managementunterstützung) Aber wenn verwendet, dann durchweg positive Erfahrungen (Austausch von Wissen, Vermeidung von Tunnelblick) Wenn man nicht weiter kommt, auf jeden Fall einen zweiten hinzuziehen. Ihre Meinung zu Programmieren in Paaren? 1. Chef wird das ablehnen, weil das Verschwendung von Personal ist (Warum 2 einsetzen, wo es auch einer könnte). 2. Chef wird sich überzeugen lassen, denn in der Summe wird es die Software-Entwicklung beschleunigen (preiswerter). 3. Keine Meinung 1. Chef lehnt ab 2. Chef sieht Vorteile 3. Keine Meinung 1_ 2_ 3_ V 3.11; Prof. Helmke 28 V 3.11; Prof. Helmke 29

7 Einfaches Design Einfaches Design (2) Heute nicht etwas für übermorgen entwickeln, sondern höchstens für Morgen (Kein Design auf Vorrat). Einfache Designs widersprechen dem, was Informatiker und Entwickler über Jahre hinweg gelernt haben und auch heute noch vorherrschend ist: Allgemeine Lösungen finden, vorausschauend entwickeln, Anforderungen und Änderungen an Anforderungen antizipieren. Make it as simple as possible, but not simpler (A. Einstein). Es sollte somit das einfachste implementiert werden, das gerade noch funktioniert. Nur die Methoden einer Klasse implementieren, die man wirklich jetzt braucht (Nur InsertList, wenn man EraseList nicht braucht). Erst verwenden, dann erst wieder verwenden. Make it run, make it right, make it fast. (und zwar in dieser Reihenfolge). V 3.11; Prof. Helmke 30 V 3.11; Prof. Helmke 31 Einfaches Design (3) Es wird aber nun nicht einfach "drauflos programmiert". Gutes Design besitzt weiterhin einen hohen Stellenwert. Es wird aber kein großes all umfassendes Design zu Beginn des SW- Entwicklungsprozesses erstellt und dann jegliches Design für beendet erklärt. Design auf Vorrat wird beim Refactoring nur stiefmütterlich behandelt. Er wird im System auch schlecht getestet, weil es per Definition zurzeit nicht gebraucht wird. Auch in der Lagerhaltung der Warenwirtschaft versucht man Waren möglichst kurz zu lagern (just-in-time). Wenn man zuerst die Testklasse und dann erst die eigentliche zu testende Klasse implementiert, wird einfaches Design schon fast erzwungen. Clicker- Abstimmung Könnten Sie in zwei Sätzen erklären, was mit Software-Refactoring gemeint ist. 1. Ja 2. Schon mal gehört, aber genau könnte ich es nicht erklären 3. Noch nie gehört 1. Ja 2. Schon mal gehört 3. Nein 1_ 2_ 3_ V 3.11; Prof. Helmke 32 V 3.11; Prof. Helmke 33

8 Die Bibel zum Refactoring Refactoring --- Martin Fowler: Refactoring -- Improving the Design of Existing Code, Addison Wesley, 2002 Verbessern des Designs von Code, nachdem er geschrieben wurde, ohne dessen Verhalten zu ändern Man muss die Hemmung überwinden, dass man Arbeitskraft zur Verfügung stellt, die erst einmal nichts Produktives (keine neue Funktionalität) schafft. Man muss sich hier zu seinem Glück zwingen (Iterationen mit überwiegend Refactoring-Arbeiten) Ohne automatisch ablaufende Tests ist es ein aussichtsloses Unterfangen. Bevor man beginnt, immer sicherstellen, dass es für die betreffenden Stellen auch wirklich Tests gibt. Unterstützung durch Refactoring Tools auch für C++ sehr wünschenswert. V 3.11; Prof. Helmke 34 V 3.11; Prof. Helmke 35 Refactoring (2) Listen to the code Code, der schlecht riecht: Lange Funktionen Duplizierte Logik switch-ketten, verschachtelte if-then-else Konstanten direkt im Code. Gemeinsame Verantwortung Alle erstellten Quelltexte und Dokumente gehören nicht einem einzelnen, sondern dem gesamten Team. Jeder im Projekt darf zu jeder Zeit alle Quelltexte und Dokumente ändern. Unterschiedliche Qualifikationen können ein Problem sein (nicht jeder ist Software-Entwickler), Wunsch der eigenen Veröffentlichung kann ein Problem sein Der Truck-Factor ist erheblich gesunken, wo dieses konsequent anwendet wird. Integration von Teilzeitkräften und von Mitarbeitern, die in mehreren Projekten gleichzeitig arbeiten, erheblich vereinfacht. Die Mitglieder müssen nicht auf die Fertigstellung durch andere warten, sondern können es selbst übernehmen. Versionsverwaltungssystem sehr hilfreich (CVS, subversion) V 3.11; Prof. Helmke 36 V 3.11; Prof. Helmke 37

9 Gemeinsame Verantwortung (2) Wer einen Fehler entdeckt, sollte ihn nach Möglichkeit auch gleich beheben. Die Suche nach dem Urheber ist aufwändig und vor allem unnötig. Programmierstandard zwingend erforderlich Clicker- Abstimmung Finden Sie es gut, wenn jeder Ihre Code ändern darf oder würden Sie persönlich es doch lieber bevorzugen, wenn nur Sie Ihren Code (im Normalfall) ändern dürfen? 1. Jeder darf jeden Code ändern. 2. Nur ich darf meinen Code ändern. 3. Keine Meinung 1_ 2_ 3_ Gemeinsame Verantwortung bedeutet nicht "nicht vorhandene Verantwortlichkeit" (No Ownership). V 3.11; Prof. Helmke 38 V 3.11; Prof. Helmke 39 Fortlaufende Integration Spätestens am Abend die Arbeit des Tages in das Gesamtsystem integrieren Gefährlich, wenn man abends schnell nach Hause will. Aufteilung einer Erweiterung in kleine Erweiterungen sehr hilfreich. Man behält die Übersicht. Unterschiedliche Erweiterungen laufen nicht auseinander. Branchingkonzept der Versionsverwaltung bisher kaum verwendet. PROGRAMMIEREPISODE 1. Wir überlegen uns eine Funktion 2. Wir beschreiben die Funktion (zur Dokumentation) in natürlicher Sprache, (was man nicht beschreiben kann, kann man auch nicht bauen). 3. Wir schreiben einen Test dafür 4. Wir refaktorisieren den Code in Form 5. Wir implementieren die Funktion 6. Wir lassen die Test Suite laufen 7. Wir refaktorisieren unseren Code 8. Wir sind fertig, wenn alle Tests erfüllt sind 9. Wir integrieren den Code in das Versionsverwaltungssystem V 3.11; Prof. Helmke 40 V 3.11; Prof. Helmke 42

10 " 5 A 9? D A A J= F D A H A L H HJ 2 = K C I I F EA - E B=? D A I, A I EC 4 A B=? J HE C 2 H C H= EA HA E 2 = = HA 6 A I JA K H A 4 A A = I A O A Die 10 XP-Gebote 1. Fragen sind willkommen! 2. Wechsle deinen Partner oft! 3. Halte unsere Code-Konventionen ein! 4. Tue das einfachste, das funktionieren wird! 5. Sei nicht egoistisch der Code gehört dem Team! 6. Ohne Partner kein Coding! 7. Code ohne Test wird gelöscht! 8. Sei mutig refaktorisiere gnadenlos! 9. Helfe anderen, wie auch dir geholfen wird! 10. Befolge Regeln nicht blind auch diese nicht! 2 H C H= EA HI = H@ I. HJ = K A 1 JA C H= JE / A A E I = A 8 A H= JM HJK C V 3.11; Prof. Helmke 44 aus: Computer Zeitung Nr. 44/ , S.22 bzw Holger Mügge et al., Uni Bonn V 3.11; Prof. Helmke 45