Software Engineering 1 WS 2012/2013 - TU Braunschweig · 2012-12-04 · Prof. Dr. Ina Schaefer Institut für Softwaretechnik und Fahrzeuginformatik Technische Universität Braunschweig

Prof. Dr. Ina Schaefer

Institut für Softwaretechnik und Fahrzeuginformatik

Technische Universität Braunschweig

(mit Folien von Prof. B. Rumpe und Dr. Chr. Kästner)

Implementierung

Software Engineering 1

WS 2012/2013

Prof. Dr. Ina Schaefer Software Engineering 1 Seite 2

Implementierungsphase


Definition: Implementierung

Definition: Implementierung ist die Menge aller Programmier-Aktivitäten.

Die Implementierung geht von einer gegebenen System-Architektur und detaillierten Spezifikation der Funktionalität aus.

Ihre Ergebnisse sind:

• Quellprogramm, einschließlich integrierter Dokumentation

• Lauffähiges System

• Testplanung und Testdokumentation

Die Implementierungs-Aktivitäten sind daher stark mit den Test-Aktivitäten verzahnt, um die Qualität des Systems sicher zu stellen.

Varianten der „Implementierung“:

• Legacy-System ist zu erweitern oder anzupassen.

• Rapid Prototyping/Extreme Programming: auf Design und Detailspezifikation wird u.U. verzichtet.


Übersicht

Auswahl der Programmiersprache

Codierungsstandards

• Formatierung

• Bezeichnerwahl

• Kommentare

• Stilrichtlinien

Entwicklungsumgebungen

Zusammenarbeit und Versionsverwaltung


Prozedurale Programmiersprachen

Beispiele: Modula-2, Pascal, C, Fortran, …

Ideen zum Modul-Konzept teilweise vorhanden

Komfortable Definition von Datenstrukturen im Speicher

Seiteneffekte (durch Pointer, Pointerarithmetik, …)

Trennung von Datenstruktur und Funktionen macht Wartbarkeit

schwieriger.

Fazit:

• Für kleinere und mittlere Systeme geeignet.

• Prozedurale Programmierung ist in der objektorientierten

Programmierung subsumiert und wird deshalb kaum mehr in

Reinform verwendet.


Objektorientierte Programmierung

Beispiel: Java (C++, Oberon, Modula-3, Smalltalk, C#, ...)

Die Merkmale der OO:

• Objekte (Klassen) zur Kapselung von Daten und Funktionen

• Objekte dynamisch erzeugen: Objektidentität

• Vererbung (in ihren verschiedenen Ausprägungen)

OO Sprachen subsumieren prozedurale Programmierung

Es erfordert aber eine wesentlich andere Vorgehensweise, um Vorteile der OO zu nutzen:

• Vererbung als Mechanismus zur Anpassung und Verbesserung der Wiederverwendung

• „Gutes Design“, um Wartbarkeit und Erweiterbarkeit zu stützen

• Codingstandards für Lesbarkeit

Fazit: OO ist heute das Mittel der Wahl für große Projekte, effizienter geht es aber oft mit Spezialsprachen (domain-specific languages).


Funktionale Programmiersprachen

Beispiele: Gofer, Haskell, ML

Meist Seiteneffektfrei und dadurch leicht verstehbar

Sehr mächtiges Typsystem (bei den Beispielen)

Patternmatching auf Argumenten

Effiziente Definition von Datenstrukturen und Funktionen

• data Tree = Leaf(Int) | Node(Tree,Int,Tree)

Funktionen höherer Ordnung (Funktionen über Funktionen)

• twice f x = f(f(x))

Kompakte Formulierung

Fazit:

• Effektive Programmierung, aber langsamere Ausführungszeiten

durch Interpreterierung.

• Schwierigkeiten mit interaktiven Systemen (z.B. GUI)


Spezialsprachen

Logikprogramme: Prolog

• Logische Aussagen in Hornklauselform als Programm

Visuelle Programmierung

• a) Komposition des Programms aus Bausteinen

• b) Modellierung z.B. mit ausführbaren Statecharts

Parallele Programmiersprachen

• für massiv verteilte Systeme

Skriptsprachen

• Beispiel: Python

• Meist kein festes Typsystem

• effektive Module zur Textbearbeitung (z.B. reguläre Ausdrücke)

• Neu: immer bessere Integration mit anderen Sprachen (z.B.

Python + Java)

Weitere Spezialsprachen: HTML, JSP, XML, SQL, PHP, ...


Weitere Auswahlkriterien

Welche technische Umgebung ist gegeben?

• Legacy-System? Gibt es eine Vorgabe des Unternehmens?

Human Factor: Welche Kenntnisse/Vorlieben besitzen die

Programmierer?

Welche Bibliotheksfunktionen werden benötigt?

Wie gut ist die Werkzeugunterstützung?

• Compiler, Debugger, IDE, ...


Beobachtungen

Fehlende Spracheigenschaften können durch standardisierte

Klassenbibliotheken abgedeckt werden:

• I/O wurde in C als erstes durch Bibliotheksfunktionen

standardisiert.

• Threads/Nebenläufigkeit wird in Java über Bibliothek realisiert.

• Kommunikation, Datenspeicherung wird nicht über

Sprachprimitive, sondern über Bibliotheksfunktionen angeboten

(Middleware)

• Security (z.B. Java Sandbox oder Verschlüsselungsbibliotheken)

• Komponentenkonzepte via Bibliothek (EJBs)


Beobachtungen (2)

Die Kooperationsfähigkeiten der Sprachen erlauben die Anwendung

der jeweils besten Sprache:

• Corba, .NET, Embedded SQL (z.B. in Java)

• Java Server Pages (JSP) = Java + HTML

• Modul-Import über API‘s (Python in Java)

• Generatoren wie Lex und Yacc: Scanner/Parser in C

Werkzeuge für das Management der Implementierung und Wartung

erlauben wesentlich flexiblere Entwicklungsprozesse:

• Dokumentation, Testen, Versionsverwaltung, Evolution,

Generierung, Installation, ...


Programmierstil

Qualität von Programmcode:

• Funktionalität

• Verständlichkeit, Wartbarkeit

• Effizienz

• Eleganz

Im Ablauf identische Programme können in der Verständlichkeit

erheblich differieren.

• Programmierkonventionen, z.B.:

• Verwendete Konstrukte

• Reihenfolgen

• Klammerung

• Bezeichnerwahl

• Layout

• Einrückung

"Style Guide": Standard-Konventionen (z.B. für Projekt, Firma)


Literate Programming

“…the time is ripe for significantly better documentation of

programs,and that we can best achieve this by considering

programs to be works of literature. Hence, my title: „Literate

Programming‟.

“Let us change our traditional attitude to the construction of

programs: Instead of imagining that our main task is to instruct a

computer what to do, let us concentrate rather on explaining to

human beings what we want a computer to do.” (Knuth 1984)

Donald Knuth (1938)

emeritierter Professor für Informatik, Stanford University

und Entwickler des Textsatzsystems TeX


Obfuscated code #!/usr/bin/perl -w

use strict;

$_='ev

al("seek\040D

ATA,0, 0;");foreach(1..2)

{<DATA>;}my @camel1hump;my$camel;

my$Camel ;while( <DATA>){$_=sprintf("%-6

9s",$_);my@dromedary 1=split(//);if(defined($

_=<DATA>)){@camel1hum p=split(//);}while(@dromeda

ry1){my$camel1hump=0 ;my$CAMEL=3;if(defined($_=shif

t(@dromedary1 ))&&/\S/){$camel1hump+=1<<$CAMEL;}

$CAMEL--;if(d efined($_=shift(@dromedary1))&&/\S/){

$camel1hump+=1 <<$CAMEL;}$CAMEL--;if(defined($_=shift(

@camel1hump))&&/\S/){$camel1hump+=1<<$CAMEL;}$CAMEL--;if(

defined($_=shift(@camel1hump))&&/\S/){$camel1hump+=1<<$CAME

L;;}$camel.=(split(//,"\040..m`{/J\047\134}L^7FX"))[$camel1h

ump];}$camel.="\n";}@camel1hump=split(/\n/,$camel);foreach(@

camel1hump){chomp;$Camel=$_;tr/LJF7\173\175`\047/\061\062\063

45678/;tr/12345678/JL7F\175\173\047`/;$_=reverse;print"$_\040

$Camel\n";}foreach(@camel1hump){chomp;$Camel=$_;y/LJF7\173\17

5`\047/12345678/;tr/12345678/JL7F\175\173\047`/;$_=reverse;p

rint"\040$_$Camel\n";}#japh-Erudil';;s;\s*;;g;;eval; eval

("seek\040DATA,0,0;");undef$/;$_=<DATA>;s$\s*$$g;( );;s

;^.*_;;;map{eval"print\"$_\"";}/.{4}/g; __DATA__ \124

\1 50\145\040\165\163\145\040\157\1 46\040\1 41\0

40\143\141 \155\145\1 54\040\1 51\155\ 141

\147\145\0 40\151\156 \040\141 \163\16 3\

157\143\ 151\141\16 4\151\1 57\156

\040\167 \151\164\1 50\040\ 120\1

45\162\ 154\040\15 1\163\ 040\14

1\040\1 64\162\1 41\144 \145\

155\14 1\162\ 153\04 0\157

\146\ 040\11 7\047\ 122\1

45\15 1\154\1 54\171 \040

\046\ 012\101\16 3\16

3\15 7\143\15 1\14

1\16 4\145\163 \054

\040 \111\156\14 3\056

\040\ 125\163\145\14 4\040\

167\1 51\164\1 50\0 40\160\

145\162 \155\151

\163\163 \151\1

57\156\056

International Obfuscated Code Contest

http://www.ioccc.org/


Was tut dieses Java-Programm?

Künstlich verschlechtertes (!) Beispiel aus:Horstmann/Cornell, Core Java Vol. I, Prentice-Hall 1997

public class Z {public static void main(String[] args) {double x = Console.readDouble("X:"); double z =

Console.readDouble("Z:") / 100; int l = Console.readInt("L:"); double y; for (y = z - 0.01; y <= z + 0.01; y += 0.00125) {double p = x * y/12/(1 - (Math.pow(1/(1 + y/12),l*12))); System.out.println(100*y+" : "+p); }}}


Formatierungs-Richtlinien

public class Z { public static void main(String[] args) { double x; double z; int l; x = Console.readDouble("X:"); z = Console.readDouble("Z:") / 100; l = Console.readInt("L:"); double y; for (y = z - 0.01; y <= z + 0.01; y += 0.00125){ double p = x * y /12 / (1 - (Math.pow(1/(1 + y / 12), l * 12))); System.out.println(100*y+" : "+p); } } }


Hinweise zur Formatierung

Einheitliche Formatierung verwenden !

• Werkzeuge ("pretty printer", "beautifier")

Gemäß Schachtelungstiefe einrücken

• Genau festgelegte Anzahl von Leerzeichen (keine Tabulatoren)

• Formatierungsprobleme bei zu tiefer Schachtelung deuten oft

auf Strukturprobleme des Codes hin!

Leerzeilen verwenden (einheitlich)

• z.B. vor und nach Methoden

• Aber: Zusammenhängender Code soll auf einem normalen

Bildschirm darstellbar bleiben!


Hinweise zur Formatierung (2)

Leerzeichen verwenden (einheitlich):

• z.B. Operatoren und Operanden durch ein Leerzeichen trennen

• z.B. keine Leerzeichen vor Methodenparametern, nach Casts

Einheitliche Dateistruktur verwenden

• z.B.: Je Klasse eine .java-Datei, je Package ein Verzeichnis

• "package"-Statement immer als erste Zeile (noch vor "import")

• Zuerst die Methoden, dann die Attribute

(oder umgekehrt, aber einheitlich!)


Einrückung

JavaSoft-Konvention zu Einrückungstiefe:

• 4 Zeichen normale Einrückung

• 8 Zeichen Einrückung zu Sonderzwecken

Wichtig:

• Schreiben aus der Sicht des Lesers!

• denn Code wird wesentlich(!) öfter gelesen als geschrieben.

• Und: Leseaufwand bei schlechtem Code ist immens.


Beispiele zur Einrückung

JavaSoft-Konvention für lange Methodenköpfe:

void methode (int x, Object y, String z, Xyz v,

float p); //konventionell

private static synchronized void etwasLang

(int x; Object y, String z, Xyz v,

float p) {

// Acht Zeichen Einrückung hier besser

x = ... // Methodenrumpf nur vier eingerückt


Beispiele zur Einrückung (2)

JavaSoft-Konvention für die Fallunterscheidung:

// nicht gut erfassbar

if ((bedingung1 && bedingung2 && bedingung3)

|| bedingung4) {

codeFürKomplexeBedingung(); …

// besser

if ((bedingung1 && bedingung2 && bedingung3)

|| bedingung4) {

codeFürKomplexeBedingung(); …


Beispiele zu Klammern und Separatoren

Relativ schlecht wartbarer Code (Java):

if (bedingung)

methode();

Besser wartbarer Code:

if (bedingung) {

methode();

}

Relativ schlecht wartbarer Code (Pascal):

if xyz then

begin

statement1;

statement2

end;

Besser wartbarer Code:

• Strichpunkt nach statement2


Wahl von Bezeichnern

Einheitliche Namenskonvention verwenden!

Bezeichner sollen:

• natürlicher Sprache entnommen (bevorzugt Englisch)

• Ausnahmen: Schleifenvariablen, manche Größen in Formeln

• aussagekräftig

• leicht zu merken

• nicht zu lang, wenn häufig verwendet

• Kurze Bezeichner nur bei sehr kleinem Scope

(Schleifenvariablen)

Beispiele: wofür ist welcher Bezeichner gut?

• x1, x2, i, j, k

• customername, CustomerName, customerName, cust_name

• kontoOeffnen, oeffneKonto, kontoOeffnung, kontoGeoeffnet

• CONSTANT

discuss


Beispiele für Namenskonventionen

Klasse:

• Substantiv, erster Buchstabe groß, Rest klein

• Ganze Worte, Zusammensetzung durch Großschreibung

• Bsp: Account, StandardTemplate

Methode:

• Verb, Imperativ (Aufforderung), erster Buchstabe klein

• Lesen und Schreiben von Attributen mit get/set-Präfix im Namen

• Bsp: checkAvailability(), doMaintenance(), getDate()

• Abfragen/Queries (bool-Ergebnis, keine Änderungen): isLarge(), hasFather()


Beispiele für Namenskonventionen (2)

Konstanten:

• Nur Großbuchstaben, Worte mit "_" zusammengesetzt

• Standardpräfixe: "MIN_", "MAX_", "DEFAULT_", …

• Bsp.: NORTH, BLUE, MIN_WIDTH, MAX_WIDTH,

DEFAULT_SIZE,

Attribute

• Mit führendem Underscore

• Bsp: _availability, _date


Lesbarkeit durch Bezeichnerwahl

public class Zinstabelle {

public static void main(String[] args) {

double betrag; //zu verzinsender Betrag

double zinssatzJahr; //jaehrlicher Zins als Faktor

int laufzeit; //Laufzeit in Jahren

betrag = Console.readDouble("Betrag:");

zinssatzJahr = Console.readDouble("Zinssatz:") / 100;

laufzeit = Console.readInt("Laufzeit:");

double y;

for (y = zinssatzJahr - 0.01;

y <= zinssatzJahr + 0.01; y += 0.00125){

double zinssatzMonat = y/12;

double zahlung = betrag * zinssatzMonat /

(1 - (Math.pow(1/(1 + zinssatzMonat),

laufzeit * 12)));

System.out.println(100*y+" : "+zahlung);

}

}

}


Änderungsfreundlicher Code

Wahl von Variablen, Konstanten und Typen orientiert an der

fachlichen Aufgabe, nicht an der Implementierung:

• Gutes Beispiel (C):

typedef char name [nameLength]

typedef char firstName [firstNameLength]

• Schlechtes Beispiel (C):

typedef char string10 [10]

Symbolische Konstante statt literale Werte verwenden, wenn

spätere Änderung denkbar (also immer).

Algorithmen, Formeln, Standardkonzepte in Methoden/Prozeduren

kapseln.

An den Leser denken:

• Zusammenhängende Einheit möglichst etwa Größe eines

typischen Editorfensters (40-60 Zeilen, 70 Zeichen breit)

• Text probehalber vorlesen ("Telefon-Test")


Änderungsfreundlicher Code (2)

Strukturierte Programmierung

• Kein "goto" verwenden (soweit noch vorhanden)

• "switch" nur mit "break"-Anweisung nach jedem Fall

• "break" nur innnerhalb "switch"-Anweisungen verwenden

• "continue" nicht verwenden

• "return" nur zur Rückgabe des Werts, nicht als Rücksprung in

der Mitte der Methode

„Goto considered harmful“ (E.W. Dijkstra)

• beschreibt die Probleme der Spaghettiprogrammierung


Änderungsfreundlicher Code (3)

Übersichtliche Ausdrücke:

• Möglichst seiteneffektfreie Ausdrücke

• Schlechtes Bsp.: y += 12*x++;

• Inkremementierung/Dekrementierung besser in separaten

Anweisungen

• ++x; y += 12*x

• Fallunterscheidungsoperator (ternäres "? : ") sparsam einsetzen

Sichtbarkeitsprüfungen des Compilers ausnutzen:

• Attribute möglichst lokal und immer "private" deklarieren

• Wiederverwendung "äußerer" Namen (Verschattung) vermeiden


Stilistisch verbessertes Programm

public class Zinstabelle {

private static double zinsFormel (double betrag, double zinssatzMonat, double laufzeit) { double faktor = 1-Math.pow(1/(1+zinssatzMonat), 12*laufzeit) return betrag * zinssatzMonat / faktor; }

static final double BEREICH = 0.01; static final double SCHRITT = 0.00125;

public static void main(String[] args) { double betrag; //zu verzinsender Betrag double zinssatzJahr; //jaehrlicher Zins als Faktor int laufzeit; //Laufzeit in Jahren // Werte einlesen betrag = Console.readDouble("Betrag:"); zinssatzJahr = Console.readDouble("Zinssatz:") / 100; laufzeit = Console.readInt("Laufzeit:"); // Ergebnisse ausgeben double y; for (y = zinssatzJahr - BEREICH; y <= zinssatzJahr + BEREICH; y += SCHRITT){ System.out.println(100*y+" : "+zinsFormel(betrag,y/12,laufzeit)); } } }

(Übrigens: es ist noch einiges verbesserungsfähig!)


Kommentare

Prinzip der integrierten Dokumentation:

• Kommentare im Code sind leichter zu warten

• Kommentare sollten parallel zum Code entstehen

• "Nach-Dokumentation" funktioniert in der Praxis nie!

• Werkzeuge zur Generierung von Dokumentation (z.B. javadoc)

Idealzustand:

• Kommentare zu Klassen und Methoden stellen eine kompakte Spezifikation des Codes dar

Kommentare sollen nicht:

• den Code unlesbar machen

• z.B. durch Verzerrung des Layouts

• redundante Information zum Code enthalten

• Schlechter Kommentar: i++; // i wird hochgezaehlt

Lesbarer kommentarfreier Code ist besser kommentierter, aber unlesbarer Code.


Typischer Einsatz von Kommentaren

"Vorspann" von Paketen, Klassen, Methoden etc.

• Zweck, Parameter, Ergebnisse, Exceptions

• Vorbedingungen, Abhängigkeiten (z.B. Plattform), Seiteneffekte

• Version, Änderungsgeschichte, Status

Formale Annahmen (assertions):

• Vorbedingungen, Nachbedingungen

• Allgemeingültige Annahmen (Invarianten)

Lese-Erleichterung

• Zusammenfassung komplexer Codepassagen

• Überschriften zur Codegliederung

Erklärung von einzelnen Besonderheiten des Codes

• z.B. schwer verständliche Schritte, Seiteneffekte

Arbeitsnotizen

• Einschränkungen, bekannte Probleme

• Offene Stellen (“!!!“,“TODO“), Anregungen, Platzhalter


Hinweise zum Verfassen von Kommentaren

Phrasen statt Sätze: kein Problem!

• Kürze und Übersicht zählt hier mehr als literarischer Anspruch.

Deskriptiv (3. Person), nicht preskriptiv (2. Person)

• Bsp: "Setzt die Kontonummer." statt: "Setze die Kontonummer."

Unnötigen Rahmentext vermeiden:

• Bsp.: "Setzt die Kontonummer." statt:

"Diese Methode setzt die Kontonummer"

Verwendung von "this" bzw. "diese/r/s"

• Bsp: "Ermittelt die Version dieser Komponente." statt:

"Ermittelt die Version der Komponente."


Dokumentationswerkzeuge

JavaDoc

• Software-Dokumentationswerkzeug, das aus Java-Quelltexten

automatisch HTML-Dokumentationsdateien erstellt.

• wie Java von Sun Microsystems entwickelt

• seit Version 2 Bestandteil des Java Development Kits (JDK).

• Dokumentation kann durch spezielle Kommentare im Quelltext

angereichert werden

• Verwendung von Tags um Interfaces, Klassen, Methoden und

Felder näher zu beschreiben

Ähnlich: Doxygen


Übersicht wichtiger JavaDoc Tags

@author name – Autorenname

@version version – Versionsnummer

@since jdk-version – seit wann existent

@see reference - Link auf ein anderes Element der Dokumentation

@param name description - Parameterbeschreibung einer Methode

@return description - Beschreibung des Returnwerts einer Methode


Professionell kommentierter Code

/* * @(#)Observer.java 1.14 98/06/29 * Copyright 1994-1998 by Sun Microsystems, Inc., ... */ package java.util; /** * A class can implement the <code>Observer</code> interface when it * wants to be informed of changes in observable objects. * * @author Chris Warth * @version 1.14, 06/29/98 * @see java.util.Observable * @since JDK1.0 */ public interface Observer { /** * This method is called whenever the observed object is changed. An * application calls an <tt>Observable</tt> object's * <code>notifyObservers</code> method to have all the object's * observers notified of the change. * * @param o the observable object. * @param arg an argument passed to the * <code>notifyObservers</code> method. */ void update(Observable o, Object arg); }


Elements of Programming Style

• Write clearly - don't be too clever.

• Don't sacrifice clarity for efficiency.

• Each module should do one thing well.

• Make sure every module hides something.

• Use the good features of a language, avoid the bad ones.

• Use the "telephone test" for readability.

• Don't stop with your first draft.

• Don't patch bad code - rewrite it.

• Don't comment bad code - rewrite it.

• Make it right before you make it faster.

• Make it clear before you make it faster.

• Keep it right when you make it faster.

• Let your compiler do the simple optimizations.

• Measure your program before making "efficiency" changes.

Auszüge aus: Kernighan/Plauger, The Elements of Programming Style, McGraw-Hill 1978 (!)

• Viele dieser Stilelemente wurden z.B. in Extreme Programming adoptiert!


Elements of Java Style

Auszüge aus: Vermeulen et al.,

The Elements of Java Style, Cambridge University Press 2000

Bezeichnerwahl:

• Join the vowel generation. ("appendSignature" statt "appdSgtr")

• Capitalize only the first letter in acronyms. ("loadXmlDocument")

• Pluralize the names of classes that group static services or

constants.

• Follow the JavaBeans conventions for property access

("get"/"set").


Elements of Java Style (2)

Programmierung:

• Follow the "Open/Closed" principle: Software entities should be

open for extension, but closed for modification.

• Use assertions to test pre- and postconditions of a method.

• Exceptions:

• Unchecked (runtime) exceptions for serious unexpected errors.

• Checked exceptions for errors that may appear in normal program

execution.


Zusammenfassung - Stilfragen der Codierung

Es gibt (leider) keinen allgemein anerkannten einheitlichen

Codingstandard.

Wichtig ist daher zunächst die Projekt-/Firmen-interne Einigung auf

einen Standard!

Wesentliche Kriterien:

• Aussagekräftige und kompakte Kommentierung

• Namenswahl

• Einrückung

• Größe von Codeblöcken (Methoden)

• Größe von Modulen (Klassen)

Java bietet im Internet zugängliche Standards (die weitgehend

kompatibel sind)

Codingstandards verhindern auch „Hacker-Code“.



Anwendungsprogramm zur Entwicklung von Software, mit in der

Regel folgenden Komponenten:

Texteditor

Compiler bzw. Interpreter

Linker

Debugger

Quelltextformatierungsfunktion

Kann auch enthalten:

Versionsverwaltung

Projektmanagement

UML-Modellierung

IDE =integrated development environment


Eclipse

„Eclipse is a kind of universal tool platform - an open extensible IDE

for anything and nothing in particular.“

Anpassung an die verschiedenen Einsatzzwecke durch Plugins

von IBM seit November 2001 als OpenSource-Projekt freigeben.

Für verschiedenste Plattformen verfügbar

Für den eigenen Download am besten die aktuelle Version des

Eclipse SDK wählen auf http://www.eclipse.org/

Aktuell: Eclipse Juno 4.2


Technische Zusammenarbeit

Wo liegen Dateien?

• Geänderte Dateien per Email zuschicken

• Manuelles Synchronisieren bei Projekttreffen

• Alle Dateien auf gemeinsamen Netzlaufwerk

Wer darf was?

• Pro Datei ist ein Entwickler verantwortlich, nur er darf ändern

• Jeder darf alles ändern


Änderungskonflikte

aus „Version Control with Subversion“


Konfliktvermeidung durch Sperren


Probleme beim Sperren

Technische Probleme:

• Technische Sperren vs. Ankündigung auf Mailingliste

• Vergessen zu entsperren typisch

Unnötige Sequentialisierung der Arbeit:

• Gleichzeitige Änderungen an unterschiedlichen Stellen nicht

möglich

Falsches Gefühl von Sicherheit:

• Zwei Nutzer arbeiten getrennt auf den Dokumenten A und B.

Was passiert, wenn A von B abhängig ist? A und B passen nicht

mehr zusammen. Die Nutzer müssen dieses Problem

diskutieren.


Konfliktlösung durch Mischen (Teil 1)


Konfliktlösung durch Mischen (Teil 2)


Beispiel


Beispiel


Beispiel

System kann nicht automatisch die Reihenfolge entscheiden


Eigenschaften des Mischens

Ein Dokument liegt in zwei Versionen vor.

• Überlappende Änderungen: Konflikt

Mischen nicht immer automatisierbar

• Werkzeug (diff) zeigt Unterschiede an

• Ein Nutzer integriert beide Versionen manuell (ggf. in

Absprache)

In der Praxis: die meisten Änderungen sind konfliktfrei


Versionsverwaltung

Gründe für die Versionsverwaltung von Software

Parallele Bearbeitung von Software durch mehrere Personen

Protokollierung durchgeführter Änderungen

Rücknahme von Änderungen möglich

Datensicherung des Quelltextes


Versionsverwaltungssysteme

Systeme für Sperren und Mischen verfügbar

Lokale Versionsverwaltung

• Lokale Archivierung (meist einzelner) Dateien

• Beispielsysteme: SCCS und RCS

Zentrale Versionsverwaltung

• Revisionen liegen auf zentralem Server

• Clients erfragen Updates, senden Änderungen

• Beispielsysteme: CVS, SVN, Perforce, Visual SourceSafe

Verteilte Systeme

• Verteilte Repositories (mit allen bekannten Revisionen) die

synchronisiert werden können

• Beispielsysteme: Git, Mercurial, ClearCase


Subversion

SVN als Ablösung von CVS mit Erweiterungen

z.B. Löschen von Verzeichnissen, Dateiumbenennung

SVN ist für viele Plattformen als Server und Client verfügbar

SVN ist Open Source http://subversion.tigris.org/

Plugin in Eclipse: http://subclipse.tigris.org/

SVN-Zugriff aus Windows Explorer: http://tortoisesvn.tigris.org


Typischer Arbeitszyklus

Einmalig: Projekt lokal anlegen

• svn checkout

Arbeitskopie auf den neuesten

Stand bringen:

• svn update

Änderungen an der Ordner-

struktur durchführen:

• svn add

• svn delete

• svn copy

• svn move

Änderungen prüfen:

• svn status

• svn diff

Änderungen zurücknehmen

(optional):

• svn revert

Konflikte auflösen:

• svn update

• svn resolved

Änderungen in das Repository

einlesen:

• svn commit


SVN: Regeln für die Nutzung

Vor jeder Arbeitsphase ein Update machen.

Vor jedem Commit ein Update machen, um den aktuellen Projektstand

zu erhalten und ggf. Konflikte zu beheben.

Nur lauffähigen (kompilierbaren) Code commiten.

Commits müssen gut kommentiert werden.

Nur Quellcode und Dokumente ablegen.

Keine systemspezifischen oder generierten Daten ablegen (z.B.

Klassenpfade oder .class-Dateien).


Auswahl: SVN Befehle

svn checkout --username student https://...

• Authentifizierung und initiales Überspielen der Version vom SVN-

Server in eine lokale Kopie

svn status (svn info)

• Zeigt alle Unterschiede zur letzten Version

svn update

• Überspielen der aktuellen Version vom SVN-Server in die lokale

Kopie

svn commit –m “aussagekräftige Nachricht an Teamkollegen“

• Überspielen der lokalen Änderungen auf den SVN-Server

svn add Dateiname

• Hinzufügen von Dateien und Verzeichnissen, die bisher nicht

versionsverwaltet sind

svn rm Dateiname

• Markierung von Dateien und Verzeichnissen als gelöscht

svn help


Zusammenfassung - Implementierung

Auswahl der Programmiersprache

Codierungsstandards

• Formatierung

• Bezeichnerwahl

• Kommentare

• Stilrichtlinien


Zusammenarbeit und Versionsverwaltung

Documents

Software Engineering 1 WS 2012/2013 - TU Braunschweig · 2012-12-04 · Prof. Dr. Ina Schaefer Institut für Softwaretechnik und Fahrzeuginformatik Technische Universität Braunschweig