Software Engineering 1 WS 2012/2013 - TU Braunschweig · 2012-12-04 · Prof. Dr. Ina Schaefer...
Transcript of Software Engineering 1 WS 2012/2013 - TU Braunschweig · 2012-12-04 · Prof. Dr. Ina Schaefer...
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 3
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.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 4
Übersicht
Auswahl der Programmiersprache
Codierungsstandards
• Formatierung
• Bezeichnerwahl
• Kommentare
• Stilrichtlinien
Entwicklungsumgebungen
Zusammenarbeit und Versionsverwaltung
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 5
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.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 6
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).
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 7
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)
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 8
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, ...
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 9
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, ...
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 10
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)
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 11
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, ...
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 12
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)
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 13
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 14
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/
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 15
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); }}}
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 16
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); } } }
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 17
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!
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 18
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!)
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 19
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.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 20
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 21
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(); …
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 22
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 23
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 24
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()
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 25
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 26
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);
}
}
}
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 27
Ä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")
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 28
Ä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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 29
Ä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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 30
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!)
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 31
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.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 32
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 33
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."
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 34
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 35
Ü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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 36
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); }
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 37
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!
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 38
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").
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 39
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.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 40
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“.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 41
Entwicklungsumgebungen
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 42
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 43
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 44
Änderungskonflikte
aus „Version Control with Subversion“
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 46
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.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 51
Beispiel
System kann nicht automatisch die Reihenfolge entscheiden
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 52
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 53
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 54
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 55
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 56
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 57
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).
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 58
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