Praktische Softwaretechnologie Vorlesung 8

Transkript

1 Praktische Softwaretechnologie Vorlesung 8 Martin Giese Johann Radon Institute for Computational and Applied Mathematics Österr. Akademie der Wissenschaften Linz PSWT Dezember 2006 p.1/32

2 Die Software-Krise Ende der 1960er wurde deutlich, daß gute Software schwer zu erstellen und zu erhalten ist: Projekte werden teurer als erwartet Projekte dauern länger als erwartet Die produzierte Software ist fehlerhaft Funktionalität entspricht nicht den Kundenanforderungen Software ist schwer zu warten Entwicklung des Software-Engineering als Ingenieurwissenschaft Systematisierung von Prozessen zur Software-Konstruktion PSWT Dezember 2006 p.2/32

3 Cost-of-change Kurve Die Kosten einer Änderung hängen exponentiell von der Zeit ab PSWT Dezember 2006 p.3/32

4 Konsequenz der exponentiellen Kurve Jeder Aufwand am Anfang, durch den das Risiko einer Änderung später gemindert wird ist gerechtfertigt. PSWT Dezember 2006 p.4/32

5 Wasserfall-Modell Zunächst vollständige Analyse Dann sorgfältiges Design u.s.w. Wasserfall-Modell Jede Phase beendet und abgenommen bevor die nächste beginnen kann. Minimierung von Änderungen nach Fertigstellung von Dokumenten PSWT Dezember 2006 p.5/32

6 Probleme des Wasserfall-Modells Anforderungen des Kunden ändern sich Mißverständnisse werden aufgeklärt Lücken in der Spezifikation tauchen auf Implementierung ist zu langsam/braucht zu viel Ressourcen... Schwächen in frühen Phasen werden erst später erkennbar Implementierter Algorithmus in der Praxis zu langsam Entwurf erlaubt keine effiziente Implementierung... PSWT Dezember 2006 p.6/32

7 Iteratives Modell Jede Iteration bildet einen eigenen Wasserfall Analyse und Design für jede Iteration neu. Reaktion auf geänderte Anforderungen möglich. Typischer Vertreter: Der Rational Unified Process (RUP) PSWT Dezember 2006 p.7/32

8 Der IBM Rational Unified Process Verbreiteter Software-Engineering Prozeß. Besteht aus Richtlinien für alle Aktivitäten der SW-Entwicklung. Iterative Entwicklung Systematische Erfassung & Organisation von Anforderungen Zerlegung des Systems in Komponenten Verwendung von UML Dauernde Qualitätskontrolle Systematisch kontrollierte Änderungen an SW/Dokumenten PSWT Dezember 2006 p.8/32

9 Probleme des iterativen Modells Iterative Entwicklung mit Prozessen wie RUP immer noch träge: Iterationen relativ lang. Analysefehler beim Design schwer zu beheben Designfehler bei der Implementierung schwer zu beheben Prozesse wie RUP umfangreich und aufwendig zu implementieren PSWT Dezember 2006 p.9/32

10 Neue Technologien Exponentielle Cost-of-Change-Kurve hat seit 1970 die Entwicklung vieler neuer Technologien und Werkzeuge angeregt: Modularität, Geheimnisprinzip Objektorientierung Entwurfsmuster relationale und OO Datenbanken Parser CASE-Tools u.v.m. PSWT Dezember 2006 p.10/32

11 Agile Softwareentwicklung Neuer Trend für SW-Entwicklungsprozesse seit 1990ern Zielorientert (insbes. Code wichtiger als Diagramme) Schlank, unbürokratisch Flexibel bzgl. geänderter Anforderungen Wenig Bürokratie: Sinnvoll für kleine Projekte, wenige Entwickler an einem Ort Große Projekte agiler Ansatz auf Teilen denkbar Bekanntester agiler Prozeß: Extreme Programming (XP) PSWT Dezember 2006 p.11/32

12 Information zu Extreme Programming Buch: KENT BECK, Extreme Programming Explained: Embrace Change. Addison Wesley 1999 Webseiten: PSWT Dezember 2006 p.12/32

13 Eigenschaften Typisch für XP sind: Programmieren als zentrale Tätigkeit inkrementelles Vorgehen in allen Bereichen frühes Feedback durch kurze Zyklen Vertrauen in Code durch automatisches Testen Enge Zusammenarbeit zwischen Programmieren PSWT Dezember 2006 p.13/32

14 ? Cost-of-change mit XP These: Durch konsequente Anwendung von moderner Technologie und XP Praktiken kann die Kurve entschärft werden. PSWT Dezember 2006 p.14/32

15 Konsequenz der flachen Kurve Jeder Aufwand am Anfang für eine spätere Änderung, die möglicherweise nicht nötig sein wird, ist riskant. PSWT Dezember 2006 p.15/32

16 XP Werte Grundlegende Werte müssen bei der SW-Entwicklung beachtet werden: Kommunikation Einfachheit Feedback Mut Respekt PSWT Dezember 2006 p.16/32

17 XP Prinzipien Schnelles Feedback Inkrementelle Änderungen Von Einfachheit ausgehen Änderungen begrüßen Qualitätsarbeit Lernen lehren Auf Gewinn spielen Offene, ehrliche Kommunikation Angenommene Verantwortung Wenig Marschgepäck Kleine Anfangsinvestition Konkrete Experimente Mit den Instinkten arbeiten Lokale Anpassung Ehrliche Messungen PSWT Dezember 2006 p.17/32

18 XP Praktiken Das Planungsspiel Kleine Releases Metapher Einfaches Design Testen Refaktorisierung Paar-Programmierung Kollektiver Codebesitz Ständige Integration 40-Stunden Woche Kunde vor Ort Codierrichtlinien PSWT Dezember 2006 p.18/32

19 Das Planungsspiel Planung im Dialog von Management und Entwicklern Management ist zuständig für Umfang von Releases Prioritäten Deadlines Entwickler sind zuständig für Aufwandsabschätzungen Konsequenzen von Management-Entscheidungen Organisation von Arbeit und Team Zeiteinteilung im Kleinen PSWT Dezember 2006 p.19/32

20 Kleine Releases,Metapher Kleine Releases: Releases so klein wie möglich Alle 1 bis 2 Monate Jeweils nur die wichtigsten Features Metapher: Gemeinsames Vokabular für Grobsicht Soll Architektur größtenteils ersetzen PSWT Dezember 2006 p.20/32

21 Einfaches Design Software sollte jederzeit so entworfen werden, daß sie Alle Tests besteht Keine duplizierte Funktionalität enthält Jeden wichtigen Inhalt vermittelt So wenig Klassen und Methoden wie möglich umfaßt Flache Cost-of-Change Kurve: Design, das nur für künftige Erweiterungen gebraucht wird, sollte erst dann hinzugefügt werden, wenn es gebraucht wird. PSWT Dezember 2006 p.21/32

22 Testen Jedes Programmstück besitzt automatische Unit-Tests. Die Unit-Tests laufen jederzeit zu 100%. Tests werden vor der Implementierung geschrieben. Stärkt Vertrauen der Entwickler in ihre Arbeit. Der Kunde schreibt Funktionstests. Stärken Vertrauen des Kunden. Erstellung von Unit-Tests wird durch Test-Frameworks erleichtert, z.b. JUnit für Java. PSWT Dezember 2006 p.22/32

23 Refaktorisierung [MARTIN FOWLER, Refactoring Improving the Design of Existing Code. Addison-Wesley, 1999] Designänderung vor Einbau neuer Features Kleine, inkrementelle Änderungen Dazwischen compilieren und testen Ursprünglich manuelle Vorgehensweise Teilweise schon Automatisierung durch Werkzeuge: Eclipse, NetBeans u.a. PSWT Dezember 2006 p.23/32

24 Paar-Programmierung Aller Code wird von zwei Personen an einer Maschine geschrieben Einer tippt, der andere achtet auf Fehler, behält den Überblick, usw. Die Partner unterhalten sich dabei Bei Bedarf werden die Rollen gewechselt Die Konstellation von Paaren wechselt oft Jeden Teil des Systems kennen 2 Leute Mehr Anreiz, Prinzipien einzuhalten Schnelle Verbreitung von Wissen Ersetzt formellere Code-Review Techniken PSWT Dezember 2006 p.24/32

25 Kollektiver Codebesitz, Ständige Integration Kollektiver Codebesitz Wer eine Möglichkeit sieht, bestehenden Code zu verbessern, tut es! Jeder ist verantwortlich für das ganze System Paar-Programmierung und Tests mindern Risiko Ständige Integration Neuer Code wird nach wenigen Stunden integriert Danach müssen alle Test durchlaufen Am einfachsten an einem Integrationsrechner PSWT Dezember 2006 p.25/32

26 40-Stunden Woche, Kunde vor Ort 40-Stunden Woche Niemand arbeitet mehr als 40 Stunden pro Woche Eine Woche Überstunden sind vertretbar. Wenn eine zweite Woche Überstunden nötig ist, gibt es ein Problem, das nicht durch Überstunden zu lösen ist. Kunde vor Ort Ein echter Kunde gehört zum Team schnelles Feedback Codierrichtlinien Jeder darf jeden Code ändern Strenge Codierrichtlinien nötig PSWT Dezember 2006 p.26/32

27 Abhängigkeiten PSWT Dezember 2006 p.27/32

28 Zusammenfassung XP XP ist in erster Linie ein Cocktail aus Praktiken, beruhend auf den Grundwerten: Offene, direkte Kommunikation zwischen allen Beteiligten Einfachheit und Durchschaubarkeit von Strukturen Direktes Feedback zu allen Handlungen Mut zur Änderung PSWT Dezember 2006 p.28/32

29 Aufgabe 23 Installiere die Eclipse IDE. Download von: Unter Other downloads for gibt es eine Windows Version des Eclipse SDE (eclipse-sdk win32.zip) Nach dem Starten sieht man den Welcome Screen (auch aus Help Menü, Eintrag Welcome erreichbar) Gehe zu den Tutorials. Arbeite Create a Hello World application durch. PSWT Dezember 2006 p.29/32

30 Aufgabe 23 (forts.) Beachte einige Features einer modernen IDE: Vervollständigungsvorschläge für Identifier Dokumentations-Popups bei Maus über Identifiern Fehleranzeige im Rand, direkt nach Abspeichern Baumdarstellung Packages/Klassen/Methoden Kompilieren und starten per Mausklick PSWT Dezember 2006 p.30/32

31 Aufgabe 24 Installiere das Subclipse Plugin für Eclipse. (Subversion Einbindung für Eclipse) Installationsanleitung: Dokumentation in der Eclipse-Hilfe: Help Menü, Eintrag Help Contents Dann in Subclipse - Subversion Eclipse Plugin schauen. Das in Aufg. 23 geschriebene HelloWorld in das Repository einchecken. Zu der Luxusversion aus Aufgabe 3 erweitern, und die Verbesserung einchecken. PSWT Dezember 2006 p.31/32

32 Aufgabe 24 (forts.) Beachte einige Features der Subversion-Einbindung: Im Kontext-Menü des Package Explorer Compare With stellt Änderungen übersichtlich dar Andere SVN Operationen in Team : Update, Commit,... In der SVN Repositiry Exploring Perspektive: Im Repository blättern History anzeigen Checkout... PSWT Dezember 2006 p.32/32

33 Aufgabe 25 Informiere Dich über die Eclipse-Anbindung zu Deinem Vortragsthema ANTLR Unterstützung als Plug-in Eingebaute JUnit Unterstützung Eingebaute Ant Unterstützung Visual Editor zum Bauen von Swing Oberflächen PSWT Dezember 2006 p.33/32