3. Versionsmanagement. Typischer Weg der Software-Entwicklung

Transkript

1 3. Versionsmanagement Typischer Weg der Software-Entwicklung Inkrementelle Entwicklungsschritte Varianten der Versionskontrolle Repository Typischer Arbeitszyklus Auflösung von Konflikten Literatur: [CFP07] B. Collins-Sussman, B. W. Fitzpatrick, C. M. Pilato, Version Control with Subversion, [als PDF von Subversion-Webseite frei verfügbar, Aufgabenteil auswählen Programmstück kodieren Programmstück testen läuft nicht fertig fertig kleiner Fehler Fehler unklar kleine Überarbeitung Umstrukturierung Korrekturversuch Einbau/Nutzung von Debuginformationen kleine Lösungsvariante große Lösungsvariante Software-Versionen Software entwickelt sich inkrementell, bei Versuchen muss der Weg zurück möglich sein Versionsbaum Paket 1 V 1 V 2 V 3 V 4 V 5 Paket 2 V 1 V 2 V 3 V 4 V 5 V 6 Paket 3 V 1 V 2 V 3 V 4 V 5 Inkrement 1 V 6 V 7 Inkrement 2 Verwaltung von Software Die gemeinsame Entwicklung von Software hat u. a. folgende Aufgaben zu lösen: wie kann ein Entwickler seine eigene Softwareentwicklung koordinieren wie bekommen andere Entwickler mit, was der aktuelle Entwicklungsstand ist wie wird aus den einzelnen Dateien effizient das lauffähige System kompiliert Die ersten beiden Fragen beantwortet ein Versionskontrollsystem die letzte Frage fordert die Erweiterung zum Softwarekonfigurationsmanagementsystem (-> Ant) 50 51

2 Versionskontrolle: konservative Variante Dateien werden zentral im Repository verwaltet Entwickler checkt zu ändernde Software aus Entwickler erhält damit lokale Kopie zur Bearbeitung Während der Entwickler an der Software arbeitet, kann niemand anderes diese Software bearbeiten (erhält die Situation klärenden Hinweis) Entwickler checkt lokale Kopie (mit Änderungsverweis) wieder ein; jeder kann diese Kopie zur erneuten Bearbeitung auschecken Vorteil: garantiert nur ein Bearbeiter Nachteile: keine gleichzeitige Arbeit an unterschiedlichen Programmstellen, wartende Entwickler, vergessenes Einchecken Realisierung von Repository sehr unterschiedlich lösbar (Datenbanksystem, Aufsatz auf Filesystem) Hinweis: Generell sollte das Einchecken mit einer Prüfung verbunden sein 52 Versionskontrolle: progressive/chaotische Variante Dateien werden zentral im Repository verwaltet Entwickler checkt zu ändernde Software aus Entwickler erhält damit lokale Kopie zur Bearbeitung andere Entwickler können gleichen Programmcode auschecken erst beim Einchecken wird geprüft, ob seit dem Auschecken zwischenzeitliche neue Version eingecheckt wurde, wenn ja, passiert Versionsabgleich, Konflikt muss gelöst werden Vorteil: massive parallele Arbeit wird möglich, kein Ausbremsen anderer Entwickler Nachteil: Chaos bei häufig veränderten Ressourcen Lösung: für selten genutzte Dateien progressiver, für sehr kritische oder häufig genutzte Dateien konservativer Ansatz bisher Open Source: progressiv, kommerziell: konservativ 53 Übungsaufgabe Ein klassisches Problem der Versionierung ist der Fall, dass ein Entwickler X alleine bearbeitet, ein anderer Entwickler Y alleine bearbeitet und beide (ohne Probleme) ihre Änderungen einchecken. Das alte Programm lief ohne Probleme, die neue Variante läuft nicht, da gegenseitige Abhängigkeiten nicht berücksichtigt worden. Schreiben Sie ein einfaches lauffähige Programm mit den Klassen A und B. Überlegen Sie sich Änderungen von A nach A und von B nach B, so dass A mit B und A mit B ohne Probleme laufen, A mit B zusammen aber nicht läuft. Versionsmanagementsysteme Subversion (SVN) ( Git ( Concurrent Versions System (CVS) ( Mercurial ( Bazaar ( Microsoft Visual Source Safe ( Clearcase ( 142.ibm.com/software/products/de/de/clearcase) Perforce (

3 Repository anlegen Architektur von Subversion [CFP07] Hinweis: Sie werden bei der Arbeit mit Subversion typischerweise nur sehr wenige Befehle benötigen, hier werden weitere Befehle vorgestellt, die das Üben auf dem eigenen Rechner ermöglichen. Dabei immer das lesenswerte freie Buch [CFP07] beachten Hinweis: Anlegen passiert durch zentralen Administrator (FH- Regelung im Praktikum) G:\> svnadmin create /svnrepos hier wird u. a. eine Datenbank angelegt, diesen Ordner nie von Hand bearbeiten svnadmin ist Administrationswerkzeug und wird von einfachen Nutzern nie genutzt Repository in Ordnerstruktur organisiert, diese Ordner werden vom Nutzer selbst angelegt Man beachte, dass immer / genutzt werden muss Einspielen der Daten Es werden lokale Daten in das Repository eingespielt Zentrale Versionsmanagementaufgabe: Sinnvolle Dateistruktur für das Projekt anzulegen Typischerweise werden generierbare Dateien (*.class) nicht unter Versionskontrolle genommen, evtl. sinnvoll, fertige Releases vollständig einzuchecken (mit Executable), dieses aber nicht veränderbar Daten vor dem Einspielen in eine sinnvolle Repository-Struktur bringen G:\>svn import g:/antspiel/src file:///g:/svnrepos/mvc/source -m:"ausgangsdaten" file steht für lokales Verzeichnis, hier normalerweise URL file://localhost/svnrepos file:///g:/svnrepos oder "file:///g /svnrepos" Hinweis: import Befehl wird nur einmal für Daten genutzt, danach zum Ändern immer die folgenden Befehle nutzen 58 Auschecken der Daten Ansatz: Daten werden immer aus Repository in lokalen Ordner kopiert G:\arbeit>svn checkout file:///g:/svnrepos/mvc/source quelle A quelle/de A quelle/de/kleuker A quelle/de/kleuker/xview.java A quelle/de/kleuker/xmodel.java A quelle/de/kleuker/xcontroller.java A quelle/de/kleuker/xstarter.java A quelle/de/kleuker/xmodellistener.java Ausgecheckt, Revision 1. G:\arbeit>dir quelle :28 <DIR> :28 <DIR> :28 <DIR>.svn :28 <DIR> de.svn ist zentrales Verwaltungsverzeichnis zum Erkennen von Änderungen (verwaltet u. a. den Stand beim Auschecken) Danach ist lokale Bearbeitung der Dateien möglich 59

4 Einchecken der Daten ausgecheckte Dateien beliebig veränderbar löschen, kopieren und verschieben, an Subversion melden Mit commit können ganze Verzeichnisse eingecheckt werden, man kann aber auch Dateien angeben (nur Neues wird kopiert), z. B. (ohne m mit Kommentar oder f File nicht ausführbar) G:\arbeit\quelle\de\kleuker>svn commit XView.java -m"groesse angepasst" Sende XView.java übertrage Daten. Revision 2 übertragen. G:\arbeit\quelle\de\kleuker>svn commit -m"groesse 450" Sende kleuker/xview.java übertrage Daten. Revision 3 übertragen. Bei Problemen wird das Einchecken nicht durchgeführt Einchecken ist atomar (ganz oder gar nicht) Datenunterschiede erkennen diff-befehl zeigt zeilenweise Unterschiede (bei eigener Arbeit, aber auch zwischen zwei Dateien), hier XStarter.java bearbeitet G:\arbeit\quelle\de\kleuker>svn diff XStarter.java Index: XStarter.java ================================================== --- XStarter.java (Revision 8) +++ XStarter.java -3,9 public class XStarter { public static void main(string[] args) { - XModel x= new XModel(); - new XView(x); - new XController(x); + XModel xmodel= new XModel(); + new XView(xmodel); + new XController(xmodel); Konfliktbearbeitung (1/5) Annahme: wir bearbeiten XStarter.java, diese Datei wurde nach uns von anderem Entwickler zwischenzeitlich eingecheckt G:\arbeit\quelle\de\kleuker>svn commit XStarter.java -m"variablennamen angepasst" Sende XStarter.java svn: übertragen fehlgeschlagen (Details folgen): svn: Out of date: '/MVC/source/de/kleuker/XStarter.java' in transaction '6' Lösungsansatz: Zunächst eigene Dateien aktualisieren G:\arbeit\quelle\de\kleuker>svn update G XStarter.java Aktualisiert zu Revision 5. U: selbst nicht bearbeitet, aber neue Version im Repository G: lokal und im Repository bearbeitet, von Subversion gelöst (merge) [???!!!] C: selbst bearbeitet und im Repository bearbeitet, Subversion hat keinen Lösungsvorschlag 62 Konfliktbearbeitung (2/5) merge muss kontrolliert werden (Änderungen an unterschiedlichen Stellen) hier Ergebnis (überlegen Sie, was anderer Implementierer gemacht hat): public class XStarter { public static void main(string[] args) { XModel xmodel= new XModel(); new XView(xmodel); new XController(xmodel); new XView(x); // zweiter View new XController(x); // zweiter Controller 63

5 Konfliktbearbeitung (3/5) Bei erkanntem Konflikt auf Datei XStarter.java werden bei update folgende Dateien angelegt G:\arbeit\quelle\de\kleuker>svn update C XStarter.java Aktualisiert zu Revision 11. G:\arbeit\quelle\de\kleuker>dir XStarter.* : XStarter.java : XStarter.java.mine : XStarter.java.r : XStarter.java.r11.java.mine: unsere aktuelle Variante (falls.java verändert).r<alt>: Version beim Auschecken.r<neu>: aktuelle Version aus dem Repository.java: unsere Datei mit Konfliktmarkierungen (wenn Subversion Überarbeitung für möglich hält) Nutzer muss dann von Hand die wünschenswerte Lösung komponieren (diff ist hilfreich) 64 Konfliktbearbeitung (4/5) Beispiel für Konfliktbeschreibung in Datei package de.kleuker; public class XStarter { public static void main(string[] args) { XModel xmodel= new XModel(); <<<<<<<.mine new XView(xmodel); new XController(xmodel); new XView(xmodel); new XController(xmodel); ======= XView[] views= {new XView(xmodel), new XView(xmodel); new XController(xmodel); for(int i=0;i<2;i++) views[i].setlocation(0+i*500,0); >>>>>>>.r11 65 Konfliktbearbeitung (5/5) Nutzer überarbeitet Konflikt eine Variante: eigene Änderungen zurückziehen (lokale Dateien automatisch gelöscht) svn revert XStarter.java Konfliktlösung muss Subversion mitgeteilt werden (lokale Dateien automatisch gelöscht) svn resolved XStarter.java ohne Meldung der Lösung kann keine commit erfolgreich sein (theoretisch neues Problem möglich, falls zwischenzeitlich erneut neue Version eingespielt) Generell gilt, dass häufig auftretende Konflikte auf eine mangelnde Projektorganisation oder Kommunikation hindeuten 66 History-Informationen svn log r4 Administrator :59: (Sun, 11 Feb 2007) 1 line ArrayStrukur r3 Administrator :12: (Sat, 10 Feb 2007) 1 line Variablennamen angepasst r2 Administrator :50: (Sat, 10 Feb 2007) 1 line zwei Models und Views r1 Administrator :40: (Sat, 10 Feb 2007) 1 line Ausgangsdaten Möglichkeit, bestimmte Releases anzusehen: svn log r 4:3 Möglichkeit History einer Datei anzusehen (nur Releases mit Änderung angezeigt) : svn log XModel.java 67

6 Arbeit mit alten Versionen man kann aktuellen Stand mit Revisionen vergleichen svn diff r3 XStarter.java man kann zwei Revisionen vergleichen svn diff r2:3 XStarter.java man kann sich alten Stand ansehen (evtl. umlenken) svn cat r2 XStarter.java svn cat r2 XStarter.java > analysedatei Inhalt des Repository ansehen (-v verbose häufiger nutzbar) G:\arbeit\quelle\de\kleuker>svn list -v file:///g:/svnrepos/mvc/source/de/kleuker 1 Administ 1566 Feb 10 17:16 XController.java 1 Administ 1186 Feb 10 17:16 XModel.java 1 Administ 90 Feb 10 17:16 XModelListener.java 11 Administ 313 Feb 11 09:59 XStarter.java 4 Administ 1223 Feb 10 17:40 XView.java Auschecken einer alten Revisionsnummer (richtigen Ort beachten, danach normal mit commit und update bearbeitbar) svn checkout file:///g:/svnrepos/mvc/source/de -r3 68 Versionsnummern Versionsnummern einzelner Dateien werden bei commit hochgezählt Subversion nutzt Versionsnummern für vollständige Bäume, bedeutet, dass Revisionsnummer für alle Dateien (auch nicht geänderte) hochgezählt wird (anders in anderen Versionsmanagementwerkzeugen) mit Abfrage der History feststellbar, ob Datei überhaupt in der Version geändert wurde Statusabfrage zeigt aktuelle Versionsnummer und in welcher Version letzte Änderung (formal alle in Version 19) G:\arbeit\quelle\de\kleuker>svn status -v Administrator Administrator XView.java Administrator doku Administrator doku/comment.txt 11 1 Administrator XModel.java 11 1 Administrator XController.java Administrator XStarter.java 11 1 Administrator XModelListener.java 69 Status abfragen Vor commit oder update immer sinnvoll, den aktuellen Arbeitsstatus abzufragen, gibt Informationen welche Änderungen durchgeführt wurden A C D M R?! ~ I X Soll hinzugefügt werden (add) Steht in einem Konflikt, muss vor commit gelöst werden Soll gelöscht werden (delete) Inhalt wurde verändert (modify) Soll ersetzt werden (gleicher Name, neuer Inhalt, replace) Befindet sich nicht unter Versionskontrolle (kein Problem) Unter Versionskontrolle, fehlt aber (irrtümlich gelöscht) Typ in Repository und Arbeitsbereich passt nicht Nicht unter Versionskontrolle, Ignorieren vereinbart Nicht versioniert, aber als extern gekennzeichnet 70 Arbeiten an der Dateistruktur Werden Dateistrukturen geändert, so muss dies Subversion mitgeteilt werden, da Dateien sonst nicht unter Versionsverwaltung (Änderungen erst nach commit) Hinzufügen einer Datei oder eines Verzeichnisses (Verzeichnis automatisch rekursiv absteigend, ausschalten mit --nonrecursive), Daten müssen vorher existieren svn add neuedatei Löschen einer Datei oder eines Verzeichnisses svn delete wegdamit Kopieren einer Datei /eines Verzeichnisses (kein *) svn copy quelldatei zieldatei Verschieben einer Datei/ eines Vezeichnisses (kein *) svn move quelldatei neuerquelldateiname Verzeichnis anlegen svn mkdir verzeichnis (einige Befehle direkt auf Repository anwendbar) 71

7 Locking Setzen eines Locks (aktuell nur für Dateien möglich!) svn lock XStarter.java -m "Namen anpassen"»xstarter.java«gesperrt durch»administrator«. [anderer Nutzer] svn lock XStarter.java svn: warnung: Pfad»/MVC/source/src/de/kleuker/XStarter.java«ist bereits durch Benutzer»Administrator«im Dateisystem»g:/svnrepos/db«gesperrt Aufheben eines Locks, entweder mit commit (für alle Dateien eines angegebenen Verzeichnisses) oder svn unlock XStarter.java Erkennen eines Locks (z. B.) svn -v status --show-updates K 3 3 Administrator XStarter.java Neben dem Administrator kann jeder auch ein Lock löschen oder sogar stehlen (schlechter Projektstil) svn lock XStarter.java --force -m "Namen anpassen" evtl. aufräumen: svn cleanup (z. B. Problem, wenn ein Nutzer mehrmals gleiche Dateien auscheckt) 72 Nutzung von Properties Dateien und Verzeichnisse können Properties (Eigenschaften) als Paare Eigenschaftsname und Wert zugeordnet werden Properties stehen unter Versionskontrolle Es gibt Systemproperties (eigene dürfen deshalb nicht mit svn: beginnen Setzen (und ändern) von Properties svn propset lizenz 'free' XModel.java Lesen von Properties svn propget lizenz XModel.java svn proplist -v XModel.java Löschen von Properties svn propdel lizenz XModel.java 73 Dateien ignorieren Generierte Dateien werden typischerweise nicht unter Versionskontrolle genommen, diese und Hilfsdateien wie ~*, können aus der Verwaltung ausgeschlossen werden es gibt zentrale Möglichkeit für Repository (haben wir nicht) Einstellung über Properties für Verzeichnisse (nicht absteigend gesetzt) svn propset svn:ignore -F ignore.txt kleuker ignore.txt ist Datei mit folgendem Inhalt: (Zeilenumbrüche beachten) Wenn doch alles gezeigt werden soll svn status --no-ignore? ignore.txt I bla.class I x.jar *.class *.jar Verzweigungen In großen Projekten möchte man häufig auf einem stabilen Stand eigene Experimente machen Typisch ist die Möglichkeit, Branches (Verzweigungen) ab einer bestimmten Version anzulegen (nicht Subversion) Subversion-Ansatz: Arbeitsversion als Kopie in Subversion erstellen (diese später synchronisieren und löschen) Direktes Kopieren auf Repository ist möglich svn copy file:///svnrepos/mvc/source file:///g:/svnrepos/mvc/branch -m"lokaler Branch" svn list -v file:///svnrepos/mvc 23 Administ Feb 11 15:09 branch/ 22 Administ Feb 11 15:06 source/ 74 75

8 Zusammenfassung: Typische Arbeitsschritte Am Anfang auschecken (einmal) oder aktualisieren checkout update evtl. Dateien erzeugen, löschen, verschieben add delete copy remove Änderungen analysieren status diff revert Änderungen durchführen commit Konflikte lösen update resolved Man beachte: Lokale Arbeitskopien können einfach gelöscht werden, dann neue Version auschecken 76 Weitere Konfigurationsmanagementaufgaben generell: Verwaltung aller Projektergebnisse, neben Quellcodes Dokumentation Arbeitsplatzstruktur (Dateistruktur des Projekts) Sicherung der benutzen Arbeitsumgebung, z. B. Kopie des verwendeten Betriebssystems Kopie des verwendeten Compilers Kopie der verwendeten Software- Entwicklungsumgebung eventuell alles mit Versionsnummer (z. B. bei Compilerwechsel) Erstellung von Sicherungskopien (wenn Server abbrennt, müssen fast aktuelle Arbeitsergebnisse erhalten bleiben; gibt Internetlösungen) muss jederzeit in der Lage sein, jedes Release in kurzer Zeit wieder herzustellen 77 Subversion und Eclipse = Subversive Subversionverbindung in Eclipse Subversion gut in Eclipse integriert Ansatz: Eclipseprojekt erstellen und dann in den Projektbaum in Subversion (nicht oberste Ebene) einbauen Generell dann Subversion-Nutzung bei Programmierung nur aus Eclipse heraus Shell, z. B. für Befehl svn status, zum Schauen ist erlaubt 78 79

9 Windows-Explorer+Subversion=TortoiseSVN 80 Übung (1/2) [Angaben für UNIX anpassen] 1. Neben dem eigentlichen Projekt-Repository, das Sie nur nutzen können, haben Sie die Möglichkeit, eigene Repositories anzulegen. Legen Sie zum Üben ein Repository unter z:/svnrepos an und spielen Sie ein Java-Projekt, genauer die *.java-dateien, ein. 2. Gehen Sie in ein anderes Verzeichnis, z. B. z:/tmp/svn1 und checken Sie das Projekt aus, probieren Sie die Befehle status, diff, commit und revert mehrfach mit kleinen Dateiänderungen aus. 3. Öffnen Sie eine zweite DOS-Box (cmd), gehen Sie in ein zweites Verzeichnis, z. B. /tmp/svn2 und checken Sie das Projekt aus. Ändern Sie in beiden DOS-Boxen eine Datei und versuchen Sie sie einzuchecken, nutzen Sie die Befehle status, update und resolved. Erzeugen Sie einmal eine Situation, in der Subversion die Dateien automatisch merged und eine Situation, in der Sie den Konflikt von Hand lösen müssen. 81 Übung (2/2) 4. Experimentieren Sie mit den Befehlen add, delete, copy. 5. Stellen Sie in einem Verzeichnis sicher, dass Dateien mit der Endung tmp nicht von Subversion verwaltet werden und prüfen Sie den Erfolg. 6. Setzen Sie und verändern Sie Eigenschaften (Properties) einer Datei. Was passiert, wenn zwei Nutzer unterschiedliche Änderungen machen? 7. Erzeugen Sie in Eclipse ein neues Java-Projekt und spielen Sie (nicht-versionierte) Dateien ein. Stellen Sie das Projekt unter Versionskontrolle und wiederholen Sie die Befehle ab Aufgabe 2 erneut (Sie müssen allerdings nicht erneut auschecken.) 8. Ergänzen Sie in Ihrem Repository ein neues Projekt von Eclipse aus. Ändern Sie eine Datei in Eclipse und außerhalb von Eclipse, checken Sie in Eclipse ein. 9. [Windows: Beschäftigen Sie sich mit den Nutzungsmöglichkeiten von TortoiseSVN] Logging Grundidee Aufbau des Loggings in Java Konfiguration des Loggings systematisches Logging Hinweis: Hier Logging-Klassen aus java.util.logging vorgestellt, gibt Alternativen (log4j, und abstrahierende Frameworks für unterschiedlicher Logger 83

10 Was ist Loggen? Logging erzeugt Nachrichten, die informieren, was im Programm passiert zunächst vergleichbar mit System.out.println() Nachrichten können auf Konsolen oder in Dateien ausgegeben, über Schnittstellen übertragen werden Logging kann in der Entwicklung das Debuggen unterstützen Logging kann beim Kunden Statusnachrichten und Probleme sammeln (Ziel: sinnvoller Fehlerbericht) Grundsätzlicher Ansatz Programm Logger Filter Handler Filter Formatter Ausgabe Software generiert Logging-Nachricht mit Level Logger entscheidet mit Filter ob weiter bearbeitet bei Bearbeitung an angeschlossene n Handler Handler entscheidet mit Filter ob weiter bearbeitet bei Bearbeitung wird Nachricht mit Formatter formatiert und in zugehöriger Ausgabeform ausgegeben (Logger hierarchisch organisiert) Logging-Level Level sind einfache Aufzählung und haben zunächst keine konkrete Bedeutung Level.SEVERE Level.WARNING Level.INFO Level.CONFIG Level.FINE Level.FINER Level.FINEST Nutzer kann Leveln Bedeutung zuordnen Nutzung: LOG.log(Level.INFO, "Hallo") alternativ LOG.info("Hallo") 86 Minibeispiel (1/4) - einfache Logging-Nutzung package myutil; import java.io.fileinputstream; import java.io.filenotfoundexception; import java.io.ioexception; import java.util.logging.filehandler; import java.util.logging.filter; import java.util.logging.handler; import java.util.logging.logmanager; import java.util.logging.logrecord; import java.util.logging.logger; public class Global { public static Logger LOG; public static void init(){ LOG = Logger.getLogger("MyLogs"); 87

11 Minibeispiel (2/4) - einfache Logging-Nutzung package geo; import java.util.logging.level; import myutil.global; public class Punkt { private int x; private int y; public Punkt(){ Global.LOG.log(Level.FINEST,"fein fein"); Global.LOG.log(Level.SEVERE,"servieren"); System.out.println("Ruf mich auf"); 88 Minibeispiel (3/4) - einfache Logging-Nutzung package main; import java.util.logging.level; import geo.punkt; import myutil.global; public class Main { public static void spielerei1(){ Global.init(); Punkt p = new Punkt(); System.out.println(Global.LOG.getLevel()); Global.LOG.setLevel(Level.FINEST); p = new Punkt(); public static void main(string[] args) { spielerei1(); 89 Minibeispiel (4/4) - einfache Logging-Nutzung Default-Einstellung (1/2) mit getlogger(<name>) wird eindeutiger Logger über Namen identifiziert; bei Erstnutzung erzeugt Filter im Default-Logger lässt nur Nachrichten ab Level INFO durch Handler bereitet Nachricht zur Konsolen-Ausgabe (System.err) vor Default-Einstellungen stehen in JRE- Unterverzeichnis lib/logging.properties Änderbar über einmaligen LogManager LogManager.getLogManager().readConfiguration(new FileInputStream("mylog.properties")); 90 91

12 Default-Einstellung (2/2) - Ausschnitt # Default global logging level..level= INFO # default file output is in user's home directory. java.util.logging.filehandler.pattern = %h/java%u.log java.util.logging.filehandler.limit = java.util.logging.filehandler.count = 1 java.util.logging.filehandler.formatter = java.util.logging.xmlformatter # Limit the message that are printed on the console # to INFO and above. java.util.logging.consolehandler.level = INFO java.util.logging.consolehandler.formatter = java.util.logging.simpleformatter 92 Beispiel mit eigener Konfigurationsdatei (1/2) #Kopie der Standarddatei, einzige Änderung java.util.logging.consolehandler.level = FINEST In Global.java ergänzt: public static void lokalekonfig(){ try { LogManager.getLogManager().readConfiguration( new FileInputStream("mylog.properties")); catch (SecurityException e) { catch (FileNotFoundException e) { catch (IOException e) { 93 Beispiel mit eigener Konfigurationsdatei (2/2) public static void spielerei2(){ Global.lokaleKonfig(); Global.init(); Punkt p = new Punkt(); System.out.println(Global.LOG.getLevel()); Global.LOG.setLevel(Level.FINEST); p = new Punkt(); 94 Änderung des Default-Verhaltens im Programm standardmäßig Übergabe von Nachrichten an oberen Logger Einstellungsmöglichkeit in Konfigurationsdatei Einstellungsmöglichkeit im Programm, in Global.java public static void keindefaultlogger(){ LOG.setUseParentHandlers(false); // in Main.java public static void spielerei3(){ Global.init(); Global.keinDefaultLogger(); Punkt p = new Punkt(); Global.LOG.setLevel(Level.FINEST); p = new Punkt(); 95

13 Erstellung eigener Filter (1/2) In Global.java public static void machfilter(){ Filter f = new public boolean isloggable(logrecord lr) { System.out.println("Filter: " + lr.getmessage()); return true; ; LOG.setFilter(f); Filter ist Interface Erstellung eigener Filter (2/2) public static void spielerei4(){ Global.init(); Global.keinDefaultLogger(); Global.machFilter(); Punkt p = new Punkt(); Global.LOG.setLevel(Level.FINEST); p = new Punkt(); Klasse LogRecord get- und set-methoden 98 Erstellung eigener Handler (1/2) public static void machhandler(){ Handler h= new public void close() throws SecurityException public void flush() public void publish(logrecord lr) { System.err.println("Handler: "+lr.getmessage() +" "+lr.getsourceclassname()); ; LOG.addHandler(h); 99

14 Erstellung eigener Handler (2/2) public static void spielerei5(){ Global.init(); Global.keinDefaultLogger(); Global.machFilter(); Global.machHandler(); Punkt p = new Punkt(); Global.LOG.setLevel(Level.FINEST); p = new Punkt(); 100 Nutzung vorhandener Handler (1/4) public static void nutzehandler(){ try { LOG.addHandler(new FileHandler("log.xml")); FileHandler fh= new FileHandler( "log.txt",true); fh.setformatter(new SimpleFormatter()); LOG.addHandler(fh); catch (SecurityException e) { catch (IOException e) { übergebener String ist Pattern: "%t" the system temporary directory "%h" the value of the "user.home" system property "%g" the generation number to distinguish rotated logs "%u" a unique number to resolve conflicts "%%" translates to a single percent sign "%" 101 Nutzung vorhandener Handler (2/4) public static void spielerei6(){ Global.init(); Global.keinDefaultLogger(); Global.nutzeHandler(); Punkt p = new Punkt(); Global.LOG.setLevel(Level.FINEST); p = new Punkt(); Nutzung vorhandener Handler (3/4) aus log.xml <?xml version="1.0" encoding="windows-1252" standalone="no"?> <!DOCTYPE log SYSTEM "logger.dtd"> <log> <record> <date> t12:54:37</date> <millis> </millis> <sequence>0</sequence> <logger>mylogs</logger> <level>severe</level> <class>geo.punkt</class> <method><init></method> <thread>10</thread> <message>servieren</message> </record>

15 Nutzung vorhandener Handler (4/4) log.txt Typischer Konstruktor von FileHandler (javadoc) nach zwei Programmdurchläufen :54:37 geo.punkt <init> SCHWERWIEGEND: servieren :54:37 geo.punkt <init> AM FEINSTEN: fein fein :54:37 geo.punkt <init> SCHWERWIEGEND: servieren :02:57 geo.punkt <init> SCHWERWIEGEND: servieren :02:57 geo.punkt <init> AM FEINSTEN: fein fein :02:57 geo.punkt <init> SCHWERWIEGEND: servieren Wann Loggen Grundsätzlich unterscheiden: Entwicklung und Auslieferung Einfacher zentraler Umschalter in einer Konfigurationsdatei (nicht im Code) Kunde möchte keine unverständlichen Details sehen (Start von Web-Server und DB-Servern häufig mit viel Laberei verbunden) Nutzer sollte Logging-Level einfach konfigurieren wichtig, nicht alles speichern Was ggfls. sinnvoll loggen Kritische Ereignisse, z. B. Belegung oder Verbrauch von Ressourcen Zusammenfassende Ergebnisse langer Transaktionen, wie das Einspielen von Datensätzen Kommunikationen, die über Grenzen des entwickelten Systems herausgehen Bereiche, die bei letzten Updates kritisch waren, Bereiche, die bei verschiedenen Kunden zu unterschiedlichen Problemen führen Generell: nicht jedes Mal neue Datei anfangen z. B. zwei Dateien, die zyklisch geschrieben werden und garantierten Speicherplatz behalten

16 5. Vorgehensmodelle 5.1 Phasen der Software-Entwicklung 5.2 Wasserfallmodell 5.3 Prototypische Entwicklung 5.4 Iterative Entwicklung 5.5 Iterativ-inkrementelle Entwicklung 5.6 Allgemeines V-Modell 5.7 Das V-Modell der Bundesrepublik Deutschland 5.8 Rational Unified Process 5.9 Agile Vorgehensmodelle 5.10 Scrum 5.11 Extreme Programming Herausforderungen der SW-Entwicklung 5.1 Software-Systeme sind heutzutage verteilte Anwendungen Anschluss an existierende Software (z.b. SAP, MS Office, bestehende Unternehmenssoftware...) Integration neuer Komponenten in existierende Systeme Erweiterung existierender Systeme eigene Komponenten neues System??? Legacy Systeme Systeme an anderen Standorten?? Systeme anderer Anbieter Die Phasen der SW- Entwicklung Anforderungsanalyse Grobdesign Feindesign Implementierung Test und Integration Erhebung und Festlegung des WAS mit Rahmenbedingungen Klärung der Funktionalität und der Systemarchitektur durch erste Modelle Detaillierte Ausarbeitung der Komponenten, der Schnittstellen, Datenstrukturen, des WIE Ausprogrammierung der Programmiervorgaben in der Zielsprache Zusammenbau der Komponenten, Nachweis, dass Anforderungen erfüllt werden, Auslieferung Wasserfallmodell 5.2 Anforderungsanalyse Grobdesign Feindesign Implementierung Test und Integration Merkmale: Phasen werden von oben nach unten durchlaufen Vorteile: - Plan auch für Nichtexperten verständlich - einfache Meilensteinplanung - lange Zeit am häufigsten eingesetzt Nachteile: - Anforderungen müssen 100%-ig sein - späte Entwicklungsrisiken werden spät erkannt - Qualität des Design passt sich Zeitplan an Optimierung: es ist möglich, in die vorherige Phase zu springen

17 Prototypische Entwicklung 5.3 Grobdesign Feindesign Anforderungsanalyse Implementierung Test und Integration Prototyp Anforderungsanalyse Grobdesign Feindesign Implementierung Test und Integration Merkmale: - potenzielle Probleme frühzeitig identifiziert, - Lösungsmöglichkeiten im Prototypen gefunden, daraus Vorgaben abgeleitet Vorteile: - frühzeitige Risikominimierung - schnelles erstes Projektergebnis Nachteile: - Anforderungen müssen fast 100%-tig sein - Prototyp (illegal) in die Entwicklung übernommen - Kunde erwartet schnell Endergebnis Optimierung: es ist möglich, in die vorherige Phase zu springen 112 Iterative Entwicklung 5.4 Anforderungsanalyse Grobdesign Feindesign Implementierung Test und Integration Merkmale: - Erweiterung der Prototypidee; SW wird in Iterationen entwickelt - In jeder Iteration wird System weiter verfeinert - In ersten Iterationen Schwerpunkt auf Analyse und Machbarkeit; später auf Realisierung große Vorteile: - dynamische Reaktion auf Risiken - Teilergebnisse mit Kunden diskutierbar Nachteile im Detail: - schwierige Projektplanung - schwierige Vertragssituation - Kunde erwartet zu schnell Endergebnis - Kunde sieht Anforderungen als beliebig änderbar 113 Iterativ Inkrementelle Entwicklung (State of the Art) 5.5 Anforderungsanalyse Grobdesign Feindesign Implementierung Test und Integration Bsp.: vier Inkremente Merkmal: - Projekt in kleine Teilschritte zerlegt - pro Schritt neue Funktionalität (Inkrement) + Überarbeitung existierender Ergebnisse (Iteration) - n+1-ter Schritt kann Probleme des n- ten Schritts lösen Vorteile: - siehe iterativ - flexible Reaktion auf neue funktionale Anforderungen Nachteile: - siehe iterativ (etwas verstärkt) Optimierung/Anpassung: Anforderungsanalyse am Anfang intensiver durchführen 114 Fertigstellung mit Iterationen Anforderungsanalyse Grobdesign Feindesign Implementierung Test und Integration Iterationen % Fertigstellungsgrad 100% 115

18 Bekanntheit von Vorgehensmodellen W asserfallm odell V-M odell S piralm odell Inkrem entelle E ntw icklung E volutionäres P rototyping Extrem e Program m ing R U P (R ational U nified Process) keines dieser M odelle genutzte M odelle bekannte M odelle Quelle: Softwareentwicklung läuft nicht auf Zuruf, Computer Zeitung Nr. 46/ Struktur komplexer Vorgehensmodelle 5.6 Aktuelle Vorgehensmodelle, wie V-Modell XT des Bundes (Rational) Unified Process OEP (Object Engineering Process) enthalten Aktivitäten (was soll gemacht werden), Rollen (wer ist wie an Aktivität beteiligt) und Produkte (was wird benötigt; bzw. ist Ergebnis) es gibt Vorschläge für typische Anwendungsszenarien, wie Aktivitäten zu verknüpfen sind Rahmenwerke, am Anfang eines Projekts muss (werkzeuggestützt) bestimmen, welche Aktivitäten, Rollen, Produkte und Reihenfolgen von Aktivitäten für das individuelle Projekt relevant sind (tailoring, d. h. zurecht schneidern, benötigt viel Erfahrung) 117 allgemeines V-Modell manuelle Prüfung manuelle Prüfung manuelle Prüfung Konstruktion Funktionaler Systementwurf Technischer Systementwurf Anforderungsdefinition Komponenten- Spezifikation manuelle Prüfung Anmerkung: wird iterativ / inkrementell zum W-Modell Validierung Validierung Validierung Validierung Programmierung Komponententest Integrationstest Systemtest Abnahmetest Integration 118 V-Modell des Bundes 5.7 Regelung der Softwarebearbeitung (im Bereich der Bundeswehr, des Bundes und der Länder) einheitliche und (vertraglich) verbindliche Vorgabe von Aktivitäten und Produkten (Ergebnissen), Historie: V-Modell 92 (Wasserfall im Mittelpunkt), Überarbeitung V-Modell 97 (Anpassung an inkrementelle Ideen (W-Modell); Forderung nach zu früher Festlegung von Anforderungen) aktuell: V-Modell XT (extreme Tailoring), neuer Erstellung mit Fokus auf Verhältnis von Auftragnehmer und Auftraggeber (starker akademischer Einfluss bei Entwicklung) 119

19 Struktur des V-Modell XT für V-Modell XT-Informationen: Copyright Reserved Bundesrepublik Deutschland Produktorientierung im V-Modell XT Eine Projektdurchführungsstrategie definiert die Reihenfolge der im Projekt zu erreichenden Projektfortschrittsstufen; nutzt Entscheidungspunkte (go, no go) Produkte stehen im Mittelpunkt, sie sind DIE Projektergebnisse Projektdurchführungsstrategien und Entscheidungspunkte geben die Reihenfolge der Produktfertigstellung und somit die grundlegende Struktur des Projektverlaufs vor Die detaillierte Projektplanung und -steuerung wird auf der Basis der Bearbeitung und Fertigstellung von Produkten durchgeführt Für jedes Produkt ist eindeutig eine Rolle verantwortlich und im Projekt dann eine der Rolle zugeordnete Person Die Produktqualität ist überprüfbar durch definierte Anforderungen an das Produkt und explizite Beschreibungen der Abhängigkeiten zu anderen Produkten 121 Entscheidungspunkte des V-Modells XT Beispiel: Projektdurchführungsplan relevant für alle V-Modell-Projekte Organisationsspezifisches V-Modell Schnittstelle Auftraggeber / Auftragnehmer Systementwicklung Projekt genehmigt Projekt definiert Anforderungen festgelegt Projekt ausgeschrieben Angebot abgegeben Vorgehensmodell analysiert Verbesserung Vorgehensmodell konzipiert Verbesserung Vorgehensmodell realisiert Geamtprojekt aufgeteilt Projekt beauftragt System spezifiziert System entworfen Feinentwurf abgeschlossen Gesamtfortschritt überprüft Projektfortschritt überprüft Iteration geplant Abnahme erfolgt Lieferung durchgeführt System integriert Systemelemente realisiert Projekt abgeschlossen (Systementwicklungsprojekt eines Auftraggebers (AG))

20 Beispielaktivität: Anforderungen festlegen Rational Unified Process (RUP) 5.8 Disziplinen Konzeption Entwurf Phasen Konstruktion Inbetriebnahme Geschäftsprozessmodell Anforderungsanalyse Design Implementierung Test Installation Konfigurations- und Änderungsmanagement Projektmanagement Projektumfeld Start nach IBM/Rational: Rational Unified Process Entwurf Iteration 1 Entwurf Iteration 2 Konstruktion Iteration 1 Konstruktion Iteration 2 Iterationen Konstruktion Iteration n Inbetrieb Iteration 1 Inbetrieb Iteration Phasen des RUP inception (Konzeption): Ermittlung zentraler Anforderungen, Projektumfang definieren, erste Entwurfs- und Implementierungsansätze, Identifikation der Projektrisiken und Aufwände elaboration (Ausarbeitung): stabile, möglichst vollständige Anforderungen, Entwurfsspezifikation, detaillierter Projektplan mit aktivem Risikomanagement construction (Konstruktion): Implementierung, Integration, auslieferbare Version transition (Inbetriebnahme): Beta-Test, Endabnahme, Inbetriebnahme, Endlieferung Struktur des RUP strukturiert durch Disziplin Software Engineering Process Arbeitsablauf verfeinert durch beschrieben in bearbeitet Rolle Hilfsmittel verantwortlich für Hilfsmittel Checkliste beschrieben durch Eingabe Aktivität Produkt (Artifact) Ergebnis Werkzeuganleitung Strukturbeschreibung (Template) erstellt mit Hilfe von Arbeitsablaufdetails Hilfsmittel Bericht

21 Kritik an klassischen Vorgehensmodellen 5.9 Es müssen viele Dokumente erzeugt und gepflegt werden Eigene Wissenschaft Modelle wie V-Modelle und RUP zu verstehen und zurecht zu schneidern Prozessbeschreibungen hemmen Kreativität Anpassung an neue Randbedingungen, z. B. neue Technologien (Web-Services) in Prozessen und benutzten Werkzeugen ist extrem aufwändig alternativer Ansatz: Menschen machen Projekte erfolgreich, traue den Menschen => agile Prozesse (vorherige Name: leichtgewichtige Prozesse) Arten von agilen Prozessen (1/2) generell: Methoden lernen von einander; es gibt nicht die eine agile Methode Variante 1: Beschreibung auf Metaprozessebene Grundregeln zur Projektorganisation Vorgehensweisen in Projekten werden vom Team festgelegt Beispiele: Scrum (u. a. Ken Schwaber, Jeff Sutherland) [s. Folien] Crystal Methodenfamilie (Alistair Cockburn) Arten von agilen Prozessen (2/2) Variante 2: Konkrete Prozessbeschreibungen Für verschiedene Phasen der Software- Entwicklung werden konkrete Verfahren vorgeschlagen Abhängigkeiten der Verfahren werden dokumentiert ( wer A macht muss auch B machen ); Möglichkeiten zur individuellen Optimierung Beispiele: extreme Programming (XP) (u. a. Kent Beck, Ward Cunningham) [s. Folien] Dynamic Systems Development Method (Konsortium) 130 Agiles Manifest (Februar 2001) We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas 131

22 Scrum (1/2) 5.10 ( Scrum : Gedränge beim Rugby) Scrum Teams mit maximal 7 Personen mit unterschiedlichen Fähigkeiten, einem Leiter (Scrum Master) Bei größeren Teams: mehrere Teilteams durch Scrum Master koordiniert Zentrales Steuerungselement: Scrum meetings; jeden Tag 15 Minuten: was habe ich seit letztem Meeting gemacht? was werde ich bis zum nächsten Meeting machen? was hat meine Arbeit behindert? Scrum Master ist Koordinator; beseitigt Behinderungen; kommuniziert im Unternehmen Arbeitsablauf im Team wird vom Team selbst geregelt Scrum (2/2) Projektplanung: Eng mit dem Kunden werden Hauptaufgaben identifiziert (Stack mit product backlog) Hauptaufgaben können auch Test von Technologien und die Entwicklung von Prototypen sein Scrum Team schätzt Aufwände; wählt mit Kunden aus product backlog wichtigste nächste Aufgaben für nächste Iteration (heißt sprint) aus Jeder sprint dauert ca. 30 Tage; hat sprint backlog mit priorisierten Aufgaben; sorgt für nicht unterbrochene Arbeitsphase des Teams (Scrum Master kann abbrechen) Nach jedem sprint Analyse mit dem Kunden, was wurde erreicht; wie kann Projekt verbessert werden [zurück Planung] siehe auch: Scrum - Überblick... Product backlog Aufgabe 1 Aufgabe 2... Planung für sprint sprint backlog Teilaufgabe 1 Teilaufgabe 2 Status- Review Scrum-Meeting Arbeitstag sprint 30 Arbeitstage Ideen des Extreme Programming (XP) (1/3) 5.11 Planning User stories are written Release planning creates the schedule Make frequent small releases The Project Velocity is measured The project is divided into iterations Iteration planning starts each iteration Move people around A stand-up meeting starts each day Fix XP when it breaks Designing Simplicity Choose a system metaphor Use CRC cards for design sessions Create spike solutions to reduce risk No functionality is added early Refactor whenever and wherever possible

23 Ideen des Extreme Programming (XP) (2/3) Coding The customer is always available Code must be written to agreed standards Code the unit test first All production code is pair programmed Only one pair integrates code at a time Integrate often Use collective code ownership Leave optimization till last No overtime Testing All code must have unit tests All code must pass all unit tests before it can be released When a bug is found tests are created Acceptance tests are run often and the score is published 136 Ideen des Extreme Programming (XP) (3/3) User Stories Releaseplan Anforderungen Systemidee unklare Annahmen Release- Planung Miniprototyp (Spike) neue User-Story geänderte Randbedingung Kundenzustimmung abgesicherte Annahmen Testfälle Iteration Fehler aktuelle Version nächste Iteration Akzeptanz -tests kleine Releases Quelle der XP-Folien : Varianten: z. B. in der Nutzung von Dokumentation (keine minimal) Architekturansatz 137 Versuch einer Beurteilung von agilen Methoden agile Methoden haben viele Innovationen in verstaubte SW- Entwicklungsprozesse gebracht (etwas Neues; viel neu arrangiertes) Einsetzbarkeit hängt stark von technischen und menschlichen Fähigkeiten des Teams ab große Erfolge möglich, wenn Dream-Team gefunden Aufpassen bei Beratungs-Hype ( XP ist die Zukunft ) Hamburger Berater: Wir haben agile Methoden erfolgreich in Versicherung X eingeführt und manifestiert Projektleiter bei X: Haben neue Ideen zur Optimierung unseres existierenden Prozesses genutzt; konkret übrig geblieben sind Stand-Up-Meetings Agiles Manifest interessant für alle SW-Entwicklungsprozesse Ideen auf andere Ansätze übertragbar Überblick mit Kommentaren in Artikeln von J. Coldewey Generell: Vorgehensmodell muss zum Projekt und den Menschen passen 138