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/ ]


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


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


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)


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


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


Ü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.


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/ )


Arc

hite

ktur

von

Sub

vers

ion

[CF

P07

]


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


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


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


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)


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);

}}


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



• 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

}

}



• 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)



• 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

}}



• 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


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


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


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


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


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)


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)


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


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


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/


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


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


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


Subversionverbindung in Eclipse


Windows-Explorer+Subversion=TortoiseSVN


Ü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.


Ü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]


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


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)


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


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")


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");

}



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");

}

}



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();

}}




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"));


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


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) {

}

}


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();

}


Ä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();}


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


Erstellung eigener Filter (2/2)

public static void spielerei4(){

Global.init();

Global.keinDefaultLogger();Global.machFilter();



p = new Punkt();

}


Klasse LogRecord

• get- und set-Methoden


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);

}


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();

}


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 "%"


Nutzung vorhandener Handler (2/4)

public static void spielerei6(){

Global.init();

Global.keinDefaultLogger();

Global.nutzeHandler();



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>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>...


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>


08.10.2010 13:02:57 geo.Punkt <init>


08.10.2010 13:02:57 geo.Punkt <init>

AM FEINSTEN: fein fein

08.10.2010 13:02:57 geo.Punkt <init>



Typischer Konstruktor von FileHandler (javadoc)


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


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


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


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


Wasserfallmodell

Anforderungsanalyse

Grobdesign

Feindesign

Implementierung


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


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


Anforderungs-analyse

Grobdesign

Feindesign

Implemen-tierung


Prototyp

5.3


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


5.4


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


Bsp.: vier Inkremente

5.5


Fertigstellung mit Iterationen

0% 100%Fertigstellungsgrad

Anforderungsanalyse

Grobdesign

Feindesign

Implementierung


1. 2. 3. 4.Iterationen


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


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


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


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


Struktur des V-Modell XT

für V-Modell XT-Informationen:Copyright Reserved © Bundesrepublik Deutschland 2004.

http://www.v-modell-xt.de


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


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


Beispiel: Projektdurchführungsplan

(Systementwicklungsprojekt eines Auftraggebers (AG))


Beispielaktivität: Anforderungen festlegen


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


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

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


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


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)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


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


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


Scrum - Überblick

Scrum-Meeting

Arbeitstag

Status-Review sprint

30 Arbeitstage

Planungfür sprint

...

Aufgabe 2

Aufgabe 1

Productbacklog

...

Teilaufgabe 2

Teilaufgabe 1

sprintbacklog


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



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



• 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


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

3. Versionsmanagement Typischer Weg der...

Documents

Transcript of 3. Versionsmanagement Typischer Weg der...