3. Versionsmanagement Typischer Weg der...
Transcript of 3. Versionsmanagement Typischer Weg der...
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 48
3. Versionsmanagement
• 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, http://svnbook.red-bean.com/ ]
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 49
Typischer Weg der Software-Entwicklung
Programmstück kodieren
Aufgabenteil auswählen
Programmstück testen
Korrektur-versuch
Einbau/Nutzung von Debuginformationen
kleine Lösungsvariante
große Lösungsvarianteläuft
nicht fertigfertig
kleiner Fehler
Fehlerunklar
kleine Überar-beitung
Umstruk-turierung
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 50
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 3V 4
V 5V 6
V 7
Inkrement 1
Inkrement 2
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 51
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)
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 52
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 n iemand
anderes diese Software bearbeiten (erhält die Situatio n 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 unterschiedl ichen
Programmstellen, wartende Entwickler, vergessenes Einchecken
• Realisierung von Repository sehr unterschiedlich lösba r (Datenbanksystem, Aufsatz auf Filesystem)
• Hinweis: Generell sollte das Einchecken mit einer Prüf ung verbunden sein
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 53
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 Ausche cken
zwischenzeitliche neue Version eingecheckt wurde, wen n ja, passiert Versionsabgleich, Konflikt muss gelöst werde n
• 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 s ehr kritische oder häufig genutzte Dateien konservativer An satz
• bisher Open Source: progressiv, kommerziell: konservativ
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 54
Ü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ängigkeite n 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.
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 55
Versionsmanagementsysteme
• Subversion (SVN) ( http://subversion.tigris.org/ ) • Git (http://git-scm.com/ )• Concurrent Versions System (CVS)
(http://www.nongnu.org/cvs/ )• Mercurial ( http://mercurial.selenic.com/ )• Bazaar (http://bazaar.canonical.com/ )
• Microsoft Visual Source Safe (http://msdn.microsoft.com/en-us/vstudio/aa718670.aspx)
• Clearcase ( http://www-142.ibm.com/software/products/de/de/clearcase)
• Perforce ( http://www.perforce.com/ )
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 56
Arc
hite
ktur
von
Sub
vers
ion
[CF
P07
]
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 57
Repository anlegen
• Hinweis: Sie werden bei der Arbeit mit Subversion typischerweise nur sehr wenige Befehle benötigen, hie r werden weitere Befehle vorgestellt, die das Üben auf dem eig enen Rechner ermöglichen. Dabei immer das lesenswerte freie B uch [CFP07] beachten
• Hinweis: Anlegen passiert durch zentralen Administra tor (FH-Regelung im Praktikum)
• G:\> svnadmin create /svnrepos
• hier wird u. a. eine Datenbank angelegt, diesen Ordner n ie von Hand bearbeiten
• svnadmin ist Administrationswerkzeug und wird von einfachen Nutzern nie genutzt
• Repository in Ordnerstruktur organisiert, diese Ordner werd en vom Nutzer selbst angelegt
• Man beachte, dass immer / genutzt werden muss
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 58
Einspielen der Daten
• Es werden lokale Daten in das Repository eingespielt• Zentrale Versionsmanagementaufgabe: Sinnvolle Datei struktur
für das Projekt anzulegen• Typischerweise werden generierbare Dateien (*.class) ni cht
unter Versionskontrolle genommen, evtl. sinnvoll, fer tige Releases vollständig einzuchecken (mit Executable), dieses aber nicht veränderbar
• Daten vor dem Einspielen in eine sinnvolle Repositor y-Strukturbringen
• G:\>svn import g:/antspiel/srcfile:///g:/svnrepos/MVC/source -m:"Ausgangsdaten"
• file steht für lokales Verzeichnis, hier normalerweise URL– http://svn.example.com:9834/repos
– file://localhost/svnrepos
– file:///g:/svnrepos oder "file:///g|/svnrepos"
• Hinweis: import Befehl wird nur einmal für Daten genut zt, danach zum Ändern immer die folgenden Befehle nutzen
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 59
Auschecken der Daten• Ansatz: Daten werden immer aus Repository in lokalen Ordner
kopiertG:\arbeit>svn checkout
file:///g:/svnrepos/MVC/source quelleA quelle/deA quelle/de/kleukerA quelle/de/kleuker/XView.javaA quelle/de/kleuker/XModel.javaA quelle/de/kleuker/XController.javaA quelle/de/kleuker/XStarter.javaA quelle/de/kleuker/XModelListener.javaAusgecheckt, Revision 1.G:\arbeit>dir quelle10.02.2007 17:28 <DIR> .10.02.2007 17:28 <DIR> ..10.02.2007 17:28 <DIR> .svn10.02.2007 17:28 <DIR> de
• .svn ist zentrales Verwaltungsverzeichnis zum Erkennen von Änderungen (verwaltet u. a. den Stand beim Auschecke n)
• Danach ist lokale Bearbeitung der Dateien möglich
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 60
Einchecken der Daten
• ausgecheckte Dateien beliebig veränderbar• löschen, kopieren und verschieben, an Subversion melde n• Mit commit können ganze Verzeichnisse eingecheckt werden,
man kann aber auch Dateien angeben (nur Neues wird ko piert), z. B. (ohne –mmit 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)
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 61
Datenunterschiede erkennen
• diff-Befehl zeigt zeilenweise Unterschiede (bei eigen er Arbeit, aber auch zwischen zwei Dateien), hier XStarter.java be arbeitetG:\arbeit\quelle\de\kleuker>svn diff XStarter.javaIndex: XStarter.java==================================================--- XStarter.java (Revision 8)+++ XStarter.java (Arbeitskopie)@@ -3,9 +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);
}}
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 62
Konfliktbearbeitung (1/5)
• Annahme: wir bearbeiten XStarter.java, diese Datei wurd e nach uns von anderem Entwickler zwischenzeitlich eingechec ktG:\arbeit\quelle\de\kleuker>svn commit
XStarter.java -m"Variablennamen angepasst"Sende XStarter.javasvn: übertragen fehlgeschlagen (Details folgen):svn: Out of date:
'/MVC/source/de/kleuker/XStarter.java' in transaction '6'
• Lösungsansatz: Zunächst eigene Dateien aktualisierenG:\arbeit\quelle\de\kleuker>svn updateG XStarter.javaAktualisiert zu Revision 5.
• U: selbst nicht bearbeitet, aber neue Version im Reposi tory• G: lokal und im Repository bearbeitet, von Subversion gelöst
(merGe) [???!!!]• C: selbst bearbeitet und im Repository bearbeitet, Sub version
hat keinen Lösungsvorschlag
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 63
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
}
}
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 64
Konfliktbearbeitung (3/5)
• Bei erkanntem Konflikt auf Datei XStarter.java werden b ei update folgende Dateien angelegtG:\arbeit\quelle\de\kleuker>svn updateC XStarter.javaAktualisiert zu Revision 11.G:\arbeit\quelle\de\kleuker>dir XStarter.*11.02.2007 10:01 504 XStarter.java11.02.2007 10:01 306 XStarter.java.mine11.02.2007 10:01 296 XStarter.java.r1011.02.2007 10:01 313 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)
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 65
Konfliktbearbeitung (4/5)
• Beispiel für Konfliktbeschreibung in Dateipackage de.kleuker;public class XStarter {
public static void main(String[] args) {XModel xmodel= new XModel();
<<<<<<< .minenew 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
}}
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 66
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 commiterfolgreich sein (theoretisch neues Problem möglich , falls zwischenzeitlich erneut neue Version eingespielt)
• Generell gilt, dass häufig auftretende Konflikte au f eine mangelnde Projektorganisation oder Kommunikation hindeuten
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 67
History-Informationen
• svn log-------------------------------------------------r4 | Administrator | 2007-02-11 09:59:52 +0100 (Sun, 11 Feb 2007) | 1 lineArrayStrukur-------------------------------------------------r3 | Administrator | 2007-02-10 19:12:26 +0100 (Sat, 10 Feb 2007) | 1 lineVariablennamen angepasst-------------------------------------------------r2 | Administrator | 2007-02-10 17:50:30 +0100 (Sat, 10 Feb 2007) | 1 linezwei Models und Views-------------------------------------------------r1 | Administrator | 2007-02-10 17:40:28 +0100 (Sat, 10 Feb 2007) | 1 lineAusgangsdaten-------------------------------------------------
• Möglichkeit, bestimmte Releases anzusehen: svn log –r 4:3
• Möglichkeit History einer Datei anzusehen (nur Release s mit Änderung angezeigt) : svn log XModel.java
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 68
Arbeit mit alten Versionen
• man kann aktuellen Stand mit Revisionen vergleichensvn diff –r3 XStarter.java
• man kann zwei Revisionen vergleichensvn 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 nut zbar)
G:\arbeit\quelle\de\kleuker>svn list -v file:///g:/svnrepos/MVC/source/de/kleuker
1 Administ 1566 Feb 10 17:16 XController.java1 Administ 1186 Feb 10 17:16 XModel.java1 Administ 90 Feb 10 17:16 XModelListener.java
11 Administ 313 Feb 11 09:59 XStarter.java4 Administ 1223 Feb 10 17:40 XView.java
• Auschecken einer alten Revisionsnummer (richtigen Ort beachten, danach normal mit commit und update bearbeit bar)
svn checkout file:///g:/svnrepos/MVC/source/de -r3
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 69
Versionsnummern
• Versionsnummern einzelner Dateien werden bei commithochgezä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 wel cher Version letzte Änderung (formal alle in Version 19)G:\arbeit\quelle\de\kleuker>svn status -v11 11 Administrator .11 4 Administrator XView.java19 19 Administrator doku19 19 Administrator doku/comment.txt11 1 Administrator XModel.java11 1 Administrator XController.java11 11 Administrator XStarter.java11 1 Administrator XModelListener.java
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 70
Status abfragen
• Vor commit oder update immer sinnvoll, den aktuellen Arbeitsstatus abzufragen, gibt Informationen welche Änderungen durchgeführt wurden
Nicht versioniert, aber als extern gekennzeichnetX
Nicht unter Versionskontrolle, Ignorieren vereinbartI
Typ in Repository und Arbeitsbereich passt nicht~
Unter Versionskontrolle, fehlt aber (irrtümlich gelöscht )!
Befindet sich nicht unter Versionskontrolle (kein Prob lem)?
Soll ersetzt werden (gleicher Name, neuer Inhalt, replac e)R
Inhalt wurde verändert (modify)M
Soll gelöscht werden (delete)D
Steht in einem Konflikt, muss vor commit gelöst werdenC
Soll hinzugefügt werden (add)A
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 71
Arbeiten an der Dateistruktur
• Werden Dateistrukturen geändert, so muss dies Subversio n mitgeteilt werden, da Dateien sonst nicht unter Versionsverwaltung (Änderungen erst nach commit)
• Hinzufügen einer Datei oder eines Verzeichnisses (Verz eichnis automatisch rekursiv absteigend, ausschalten mit --non-recursive ), Daten müssen vorher existieren
svn add neueDatei
• Löschen einer Datei oder eines Verzeichnissessvn delete wegDamit
• Kopieren einer Datei /eines Verzeichnisses (kein *)svn copy quelldatei zieldatei
• Verschieben einer Datei/ eines Vezeichnisses (kein *)svn move quelldatei neuerQuelldateiname
• Verzeichnis anlegensvn mkdir verzeichnis
• (einige Befehle direkt auf Repository anwendbar)
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 72
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.javasvn: 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) odersvn 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ösch en
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)
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 73
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 Propertiessvn propget lizenz XModel.java
svn proplist -v XModel.java
• Löschen von Propertiessvn propdel lizenz XModel.java
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 74
Dateien ignorieren
• Generierte Dateien werden typischerweise nicht unter Versionskontrolle genommen, diese und „Hilfsdateien“ w ie ~*, können aus der Verwaltung ausgeschlossen werden
• es gibt zentrale Möglichkeit für Repository (haben wi r nicht)• Einstellung über Properties für Verzeichnisse (nicht ab steigend
gesetzt) svn propset svn:ignore -F ignore.txt kleuker
• ignore.txt ist Datei mit folgendem Inhalt: (Zeilenumbrüche beachten)
• Wenn doch alles gezeigt werden sollsvn status --no-ignore
? ignore.txt
I bla.class
I x.jar
*.class*.jar
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 75
Verzweigungen
• In großen Projekten möchte man häufig auf einem stab ilen Stand eigene Experimente machen
• Typisch ist die Möglichkeit, Branches (Verzweigungen) ab einer bestimmten Version anzulegen (nicht Subversion)
• Subversion-Ansatz: Arbeitsversion als Kopie in Subversi on erstellen (diese später synchronisieren und löschen)
• Direktes Kopieren auf Repository ist möglichsvn copy file:///svnrepos/MVC/sourcefile:///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/
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 76
Zusammenfassung: Typische Arbeitsschritte
• Am Anfang auschecken (einmal) oder aktualisierencheckout update
• evtl. Dateien erzeugen, löschen, verschiebenadd delete copy remove
• Änderungen analysierenstatus diff revert
• Änderungen durchführencommit
• Konflikte lösenupdate resolved
• Man beachte: Lokale Arbeitskopien können einfach gelöscht werden, dann neue Version auschecken
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 77
Weitere Konfigurationsmanagementaufgaben
• generell: Verwaltung aller Projektergebnisse, neben Que llcodes– 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 bleibe n; gibt Internetlösungen)
• muss jederzeit in der Lage sein, jedes Release in ku rzer Zeit wieder herzustellen
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 78
Subversion und Eclipse = Subversive
• 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
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 79
Subversionverbindung in Eclipse
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 80
Windows-Explorer+Subversion=TortoiseSVN
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 81
Ü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 Re positoriesanzulegen. Legen Sie zum Üben ein Repository unter z:/svnrepos an und spielen Sie ein Java-Projekt, genau er die *.java-Dateien, ein.
2. Gehen Sie in ein anderes Verzeichnis, z. B. z:/tmp/s vn1 und checken Sie das Projekt aus, probieren Sie die Befehl e status, diff, commit und revert mehrfach mit kleinen Dateiänderun gen 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 Date i und versuchen Sie sie einzuchecken, nutzen Sie die Befeh le status, update und resolved. Erzeugen Sie einmal eine Situation, in der Subversion die Dateien automatisch mergedund eine Situation, in der Sie den Konflikt von Hand lösen müssen.
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 82
Übung (2/2)
4. Experimentieren Sie mit den Befehlen add, delete, c opy.5. Stellen Sie in einem Verzeichnis sicher, dass Date ien mit der
Endung tmp nicht von Subversion verwaltet werden und prüfen Sie den Erfolg.
6. Setzen Sie und verändern Sie Eigenschaften (Propert ies) einer Datei. Was passiert, wenn zwei Nutzer unterschiedlich e Ä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 Befehl e 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]
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 83
4. Logging
• Grundidee• Aufbau des Loggings in Java• Konfiguration des Loggings• systematisches Logging
• Hinweis: Hier Logging-Klassen aus java.util.loggingvorgestellt, gibt Alternativen (log4j, http://logging.apache.org/log4j/ ) und abstrahierende Frameworks für unterschiedlicher Logger
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 84
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 Debuggenunterstützen
• Logging kann beim Kunden Statusnachrichten und Probleme sammeln (Ziel: sinnvoller Fehlerbericht)
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 85
Grundsätzlicher Ansatz
• 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)
Logger Handler
Filter Filter Formatter
Programm Ausgabe
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 86
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")
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 87
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");
}
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 88
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");
}
}
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 89
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();
}}
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 90
Minibeispiel (4/4) - einfache Logging-Nutzung
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 91
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 LogManagerLogManager.getLogManager()
.readConfiguration(new
FileInputStream("mylog.properties"));
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 92
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.logjava.util.logging.FileHandler.limit = 50000
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
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 93
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) {
}
}
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 94
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();
}
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 95
Ä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();}
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 96
Erstellung eigener Filter (1/2)
• In Global.javapublic static void machFilter(){
Filter f = new Filter(){
@Override
public boolean isLoggable(LogRecord lr) {
System.out.println("Filter: "
+ lr.getMessage());
return true;
}
};
LOG.setFilter(f);
}
• Filter ist Interface
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 97
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();
}
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 98
Klasse LogRecord
• get- und set-Methoden
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 99
Erstellung eigener Handler (1/2)
public static void machHandler(){Handler h= new Handler(){
@Overridepublic void close() throws SecurityException { }
@Overridepublic void flush() {}
@Overridepublic void publish(LogRecord lr) {
System.err.println("Handler: "+lr.getMessage()+" "+lr.getSourceClassName());
} };LOG.addHandler(h);
}
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 100
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();
}
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 101
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 "%"
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 102
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();
}
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 103
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>2010-10-08T12:54:37</date><millis>1286535277125</millis><sequence>0</sequence><logger>MyLogs</logger><level>SEVERE</level><class>geo.Punkt</class><method><init></method><thread>10</thread><message>servieren</message>
</record>...
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 104
Nutzung vorhandener Handler (4/4) – log.txt
• nach zwei Programmdurchläufen08.10.2010 12:54:37 geo.Punkt <init>
SCHWERWIEGEND: servieren
08.10.2010 12:54:37 geo.Punkt <init>
AM FEINSTEN: fein fein
08.10.2010 12:54:37 geo.Punkt <init>
SCHWERWIEGEND: servieren
08.10.2010 13:02:57 geo.Punkt <init>
SCHWERWIEGEND: servieren
08.10.2010 13:02:57 geo.Punkt <init>
AM FEINSTEN: fein fein
08.10.2010 13:02:57 geo.Punkt <init>
SCHWERWIEGEND: servieren
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 105
Typischer Konstruktor von FileHandler (javadoc)
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 106
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
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 107
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
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 108
5. Vorgehensmodelle
5.1 Phasen der Software-Entwicklung5.2 Wasserfallmodell5.3 Prototypische Entwicklung5.4 Iterative Entwicklung5.5 Iterativ-inkrementelle Entwicklung5.6 Allgemeines V-Modell5.7 Das V-Modell der Bundesrepublik Deutschland5.8 Rational Unified Process5.9 Agile Vorgehensmodelle5.10 Scrum5.11 Extreme Programming
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 109
Herausforderungen der SW-Entwicklung
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
Systeme an anderen Standorten
Legacy SystemeSysteme
anderer Anbieter
eigene Komponenten
neues System ?????? ??
??
5.1
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 110
Die Phasen der SW- Entwicklung
• 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
Anforderungsanalyse
Grobdesign
Feindesign
Implementierung
Test und Integration
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 111
Wasserfallmodell
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
5.2
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 112
Prototypische Entwicklung
Merkmale:- potenzielle Probleme frühzeitig
identifiziert,- Lösungsmöglichkeiten im Prototypen
gefunden, daraus Vorgaben abgeleitetVorteile:- frühzeitige Risikominimierung- schnelles erstes ProjektergebnisNachteile:- Anforderungen müssen fast 100%-tig
sein- Prototyp (illegal) in die Entwicklung
übernommen- Kunde erwartet schnell EndergebnisOptimierung:es ist möglich, in die vorherige Phase
zu springen
Anforderungsanalyse
Grobdesign
Feindesign
Implementierung
Test und Integration
Anforderungs-analyse
Grobdesign
Feindesign
Implemen-tierung
Test und Integration
Prototyp
5.3
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 113
Iterative Entwicklung
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 Realisierunggroße Vorteile:- dynamische Reaktion auf Risiken- Teilergebnisse mit Kunden diskutierbarNachteile im Detail:- schwierige Projektplanung- schwierige Vertragssituation- Kunde erwartet zu schnell Endergebnis- Kunde sieht Anforderungen als beliebig
änderbar
Anforderungsanalyse
Grobdesign
Feindesign
Implementierung
Test und Integration
5.4
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 114
Iterativ Inkrementelle Entwicklung (State of the Art )
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
AnforderungenNachteile:- siehe „iterativ“ (etwas verstärkt)
Optimierung/Anpassung:Anforderungsanalyse am Anfang
intensiver durchführen
Anforderungsanalyse
Grobdesign
Feindesign
Implementierung
Test und Integration
Bsp.: vier Inkremente
5.5
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 115
Fertigstellung mit Iterationen
0% 100%Fertigstellungsgrad
Anforderungsanalyse
Grobdesign
Feindesign
Implementierung
Test und Integration
1. 2. 3. 4.Iterationen
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 116
Bekanntheit von Vorgehensmodellen
W asserfallm odell
V -M odell
Spira lm odell
Inkrem entelle Entw icklung
Evolutionäres Prototyping
Extrem e Program m ing
R UP (Rational Unified Process)
keines dieser M odellegenutzte M odellebekannte M odelle
4171
2463
1952
2645
1741
439
1532
2011
Quelle: Softwareentwicklung läuft nicht auf Zuruf, Computer Zeitung Nr. 46/05
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 117
Struktur komplexer Vorgehensmodelle
• Aktuelle Vorgehensmodelle, wieV-Modell XT des Bundes(Rational) Unified ProcessOEP (Object Engineering Process)
enthalten Aktivitäten (was soll gemacht werden), Ro llen (wer ist wie an Aktivität beteiligt) und Produkte (was wird be nötigt; bzw. ist Ergebnis)
• es gibt Vorschläge für typische Anwendungsszenarien, w ie Aktivitäten zu verknüpfen sind
• Rahmenwerke, am Anfang eines Projekts muss (werkzeuggestützt) bestimmen, welche Aktivitäten, R ollen, Produkte und Reihenfolgen von Aktivitäten für das ind ividuelle Projekt relevant sind (tailoring, d. h. „zurecht schne idern“, benötigt viel Erfahrung)
5.6
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 118
Validierung
Validierung
Validierung
allgemeines V-Modell
Anmerkung: wird iterativ / inkrementellzum W-Modell
Anforderungs-definition
FunktionalerSystementwurf
TechnischerSystementwurf
Komponenten-Spezifikation
Programmierung
Komponenten-test
Integrations-test
System-test
Abnahme-test
manuellePrüfung
manuellePrüfung
manuellePrüfung
manuellePrüfung
Konstruktion Integration
Validierung
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 119
V-Modell des Bundes
• 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), Üb erarbeitung V-Modell 97 (Anpassung an inkrementelle Ideen (W-Mod ell); Forderung nach zu früher Festlegung von Anforderungen)
• aktuell: V-Modell XT (eXtreme Tailoring), neuer Erstel lung mit Fokus auf Verhältnis von Auftragnehmer und Auftraggeber (starker akademischer Einfluss bei Entwicklung)
5.7
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 120
Struktur des V-Modell XT
für V-Modell XT-Informationen:Copyright Reserved © Bundesrepublik Deutschland 2004.
http://www.v-modell-xt.de
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 121
Produktorientierung im V-Modell XT
• Eine Projektdurchführungsstrategie definiert die Reihen folge der im Projekt zu erreichenden Projektfortschrittsstufen; nutzt Entscheidungspunkte (go, no go)
• Produkte stehen im Mittelpunkt, sie sind DIE Projekte rgebnisse• Projektdurchführungsstrategien und Entscheidungspunkte
geben die Reihenfolge der Produktfertigstellung und so mit die grundlegende Struktur des Projektverlaufs vor
• Die detaillierte Projektplanung und -steuerung wird a uf der Basis der Bearbeitung und Fertigstellung von Produkten durchgeführt
• Für jedes Produkt ist eindeutig eine Rolle verantwort lich und im Projekt dann eine der Rolle zugeordnete Person
• Die Produktqualität ist überprüfbar durch definierte Anforderungen an das Produkt und explizite Beschreibun gen der Abhängigkeiten zu anderen Produkten
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 122
Entscheidungspunkte des V-Modells XT
relevant für alle V-Modell-Projekte
Organisationsspezifisches V-Modell
Schnittstelle Auftraggeber / Auftragnehmer
Systementwicklung
Vorgehensmodell
analysiert
Verbesserung
Vorgehensmodell
konzipiert
Verbesserung
Vorgehensmodell
realisiert
Projekt
genehmigt
Projekt
definiert
Anforderungen
festgelegt
Projekt
ausgeschrieben
Angebot
abgegeben
Projekt
beauftragt
System spezifiziert
System entworfen
Feinentwurf abgeschlossen Systemelemente realisiert
System integriert
Lieferung durchgeführt
Abnahme
erfolgt
Projekt
abgeschlossenIteration
geplant
Projektfortschritt überprüft
Gesamtfortschritt überprüftGeamtprojekt
aufgeteilt
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 123
Beispiel: Projektdurchführungsplan
(Systementwicklungsprojekt eines Auftraggebers (AG))
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 124
Beispielaktivität: Anforderungen festlegen
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 125
KonstruktionDisziplinen
Geschäftsprozess-modell
Anforderungs-analyse
Design
Test
Installation
Konfigurations- undÄnderungsmanagement
Projekt-management
Projekt-umfeld
Phasen
Entwurf Inbetriebnahme
Start
Konzeption
Entwurf
Iteration 1
Entwurf
Iteration 2
Konstruktion
Iteration 1
Konstruktion
Iteration 2
Konstruktion
Iteration n
Inbetrieb
Iteration 1
Inbetrieb
Iteration 2
Iterationen
Implementierung
Rational Unified Process (RUP)
nach IBM/Rational:Rational Unified Process
5.8
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 126
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
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 127
Struktur des RUP
SoftwareEngineering
Process
Disziplin Arbeitsablauf
Arbeitsablauf-details
strukturiertdurch Werkzeug-
anleitung
BerichtStruktur-beschreibung
(Template)
Checkliste
Produkt(Artifact)
Aktivität
Rollebeschrieben
in
verfeinertdurch
EingabeErgebnis
erstellt mit Hilfevon
Hilfs-mittel
Hilfs-mittel
Hilfs-mittel
bearbeitet
verantwort-lich für
beschrieben durch
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 128
Kritik an klassischen Vorgehensmodellen
• 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: leichtgewicht ige Prozesse)
5.9
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 129
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)
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 130
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)Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 131
Agiles Manifest (Februar 2001)
We are uncovering better ways of developingsoftware 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 Thomaswww.agileAlliance.org
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 132
Scrum (1/2)
• („Scrum“: Gedränge beim Rugby)• Scrum Teams mit maximal 7 Personen mit unterschiedlic hen
Fähigkeiten, einem Leiter (Scrum Master)• Bei größeren Teams: mehrere Teilteams durch Scrum Master
koordiniert• Zentrales Steuerungselement: Scrum meetings; jeden Ta g 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
5.10
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 133
Scrum (2/2)
• Projektplanung: Eng mit dem Kunden werden Hauptaufga ben 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 pro duct backlog wichtigste nächste Aufgaben für nächste Itera tion (heißt sprint) aus
• Jeder sprint dauert ca. 30 Tage; hat sprint backlog mi t 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 Pla nung]
• siehe auch: www.controlchaos.com
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 134
Scrum - Überblick
Scrum-Meeting
Arbeitstag
Status-Review sprint
30 Arbeitstage
Planungfür sprint
...
Aufgabe 2
Aufgabe 1
Productbacklog
...
Teilaufgabe 2
Teilaufgabe 1
sprintbacklog
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 135
Ideen des Extreme Programming (XP) (1/3)
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
5.11
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 136
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
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 137
Ideen des Extreme Programming (XP) (3/3)
• Quelle der XP-Folien : www.extremeprogramming.org• Varianten: z. B. in der Nutzung von Dokumentation (ke ine –
minimal)
Release-Planung
UserStories
Architektur-ansatz Miniprototyp
(Spike)
Iteration Akzeptanz-tests
kleineReleases
Kunden-zustimmung
nächsteIteration
aktuelleVersion
Fehler
Testfälle
unklareAnnahmen
abgesicherteAnnahmen
Release-plan
neue User-Storygeänderte
RandbedingungAnfor-
derungen
System-idee
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 138
Versuch einer Beurteilung von agilen Methoden
• agile Methoden haben viele Innovationen in verstaubt e SW-Entwicklungsprozesse gebracht (etwas Neues; viel neu arrangiertes)
• Einsetzbarkeit hängt stark von technischen und mensc hlichen 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 erfolgrei ch in
Versicherung X eingeführt und manifestiertProjektleiter bei X: Haben neue Ideen zur Optimierung un seres
existierenden Prozesses genutzt; konkret übrig gebliebe n sind Stand-Up-Meetings
• Agiles Manifest interessant für alle SW-Entwicklungsp rozesse• Ideen auf andere Ansätze übertragbar• Überblick mit Kommentaren in Artikeln von J. Coldewey
http://www.coldewey.com/publikationen/Kolumne.html
Generell: Vorgehensmodell muss zum Projekt und den Menschen passen