Nach oben.3.1. Installation des Lizenz - Key
3.2. Erstellen eines neuen Projektes
3.3. Erstellen eines Klassendiagramms (Class Diagram)
3.4. Erstellen eines Zustandsdiagramms (Statechart)
3.5. Aktivitätsdiagramme (Activitydiagram)
3.6. Anwendungsfalldiagramm (Use Case)
3.7. Sequenzdiagramm (Sequence diagram)
4.2. Ein neues Java - Projekt erstellen
Die Entwicklung objektorientierter Programmiersprachen hat vor ca. 30 Jahren begonnen. Zu dieser Zeit erschienen auch erste Publikationen über objektorientierte Programmiersprachen, die ersten Bücher über objektorientierte Analyse- und Designmethoden erschienen erst Anfang der 90er Jahre. Am beliebtesten waren dabei die Methoden, die Anfang der 90 Jahre, von Grady Booch und James Rumbaugh publiziert wurden. Booch und Rumbaugh begannen 1995 ihre Methoden zusammenzufassen. Daraus ergab sich die gemeinsame Notation Unified Method (UM). Da die Unified Method (UM) jedoch keine Methodik beschrieb, sondern nur die grafische Darstellung und Semantik der Modellierung vereinheitlichte, wurde es in Unified Moddeling Language (UML) umbenannt.
Abb. 1: Historische Entwicklung objektorientierter Programmiersprachen
Die von Ivar Jacobson entwickelten Use Cases (dt. Anwendungsfälle) wurden kurze Zeit später aufgenommen. Die hohe Popularität der einzelnen Methoden von Booch, Rumbaugh und Jacobson, die jetzt zusammengefasst vorlagen, trugen dazu bei, dass die UML zu einem Quasistandard wurde. In der Literatur sind Booch, Rumbaugh und Jacobson ab diesem Zeitpunkt als "Amigos" bekannt. 1997 wurde die UML in der Version 1.1 der Object Management Group (OMG) zur Standardisierung eingereicht. In den nachfolgenden Versionen 1.2, 1.3 und 1.4 wurden jeweils einige Korrekturen vorgenommen. Aktuell ist die Version 2.0 geplant.
Abb. 2: Historische Entwicklung objektorientierter Methoden der UML
Die UML dient zwar hauptsächlich einer einheitlichen Notation und Semantik und der Definition eines Metamodells, dennoch ist sie sehr vielfältig und integriert auch interessante Ideen, Konzepte und Methoden anderer Autoren wie z.B. die State Charts (dt. Zustandsdiagramme) von Harel. Die Definition einer Entwicklungsmethode gehört nicht direkt zur UML und wurde erst Anfang 1999 mit dem so genannten Unified Process (UP) veröffentlicht. Eine spezielle Version des UP ist der Rational Unified Process (RUP), der von der Fa. Rational speziell für ihre Werkzeuge (z.B. Rose) entwickelt wurde.
Als Konkurrenz zur UML gibt es die Open Moddeling Language (OML) des OPEN- Konsortiums, dass über 30 bekannte Unterstützer hat.
Abb. 3: Together Logo
Nach der Installation von Together 6.0.1 muß die Datei license.tg in das Verzeichnis bin des Together - Ordners kopiert werden. Die Datei kann aus unserem internen Bereich der Softwareprojektseite heruntergeladen werden (http://www.informatik.uni-oldenburg.de/sp02/sp02g10/Together/). Die Datei license.tg enthält die offiziellen Lizenzinformationen der Universität Oldenburg und wird Informatikstudenten der Universität Oldenburg kostenlos zur Verfügung gestellt. Die Lizenz ist bis zum 15.07.2003 gültig, danach wird ein neuer Lizenz - Key benötigt. Es wurde mir versichert, daß wir den neuen Lizenz - Key rechzeitig vor Ablauf des jetzigen Lizenz - Keys erhalten werden.
Nachdem Together gestartet ist, öffnet man das Menü "File" und klickt auf den Punkt "New...". Es öffnet sich folgendes Fenster:
Abb. 4: Object Gallery
Durch Klicken auf "Next" öffnet sich folgendes Fenster:
Abb. 5: New Project
Unter "Project name:" trägt man den Namen des neu zu erstellenden Projektes ein, in diesem Beispiel "Bank". Mit dem Dateiordnersymbol öffnet sich der "Select Root Directory" - Dialog, mit dem man die Position des neuen Projektes bestimmen kann. Das Feld "Initial diagram:" ändert man auf "None". Als nächstes klickt man auf "Finish" und es öffnet sich das Hauptfenster in dem das Projekt "Bank" erstellt wurde.
Abb. 6: Together Hauptansicht
Um ein neues Klassendiagramm einzufügen, öffnet man das Menü "File" und klickt auf den Punkt "New...". Es öffnet sich folgendes Fenster:
Abb. 7: Object Gallery
Dort wählt man aus der Kategorie "General" das Template "Diagram" aus und klick auf "Next". Es öffnet sich folgendes Fenster:
Abb. 8: New Diagram
In diesem Fenster kann man jetzt eine Reihe von Diagrammen auswählen. Wir wählen jetzt das Class - Diagramm aus und geben unter "Diagram name:" eine treffende Bezeichnung an und klicken auf "Finish". Im Explorer - Fenster wird jetzt das Klassendiagramm aufgeführt und im Designer - Fenster ist die Registerkarte mit dem Klassendiagramm im Vordergrund. Durch klicken auf die Schaltfläche "Class" kann eine neue Klasse an die gewünschte Position im Klassendiagramms hinzugefügt werden.
Abb. 9: Hinzufügen einer Klasse
Als erstes sollte der Klassenname wie gewünscht geändert werden. In unserem Beispiel wurde er "Konto" genannt. Nachdem der Name wie gewünscht eingestellt ist, wird im Editor - Fenster eine Datei "Konto.java" erstellt, in der das Klassengerüst schon vorgefertigt ist. Jetzt kann man bequem alle weiteren Variablen und Prozeduren einfach im Editor - Fenster eintragen und sie werden automatisch in das UML - Klassendiagramm übernommen.
Abb. 10: Die erste Klasse
Durch Hinzufügen der Klassen GiroKonto, FestgeldKonto, SparKonto und Kunde mit den folgenten Quelltexten:
public class GiroKonto extends Konto {
}
public class FestgeldKonto extends Konto {
double Zinsen;
date Startdatum;
int Laufzeit;
public void aufloesen(){}
}
public class SparKonto extends Konto {
double Zinsen;
zinsenAendern(){}
}
public class Kunde {
int KundenNr;
String Name;
String Vorname;
Konto[] Konten;
public void Kunde(){}
}
ergibt sich folgendes Klassendiagramm:
Abb. 11: Das Klassendiagramm
Die Klassen GiroKonto, FestgeldKonto und SparKonto sind von der
Klasse Konto abgeleitet, was durch diesen
Ableitungspleil dargestellt wird. Der blaue Pfeil
,
der von der Klasse Kunde zu der Klasse Konto zeigt, ist eine Assoziation. Es
gibt verschiedene Arten von Assoziationen:
| UML - Notation | Bedeutung | Beschreibung |
 |
1:1 | Ist die einfachste aller Assoziationen und bedeutet, daß zu einem Objekt genau nur ein anderes existiert und umgekehrt. Wenn kein spezielles Verhältnis angegeben ist, ist der Standardwert 1 gemeint. |
|
|
1:0..* | Zu einem Objekt können 0 bis unendlich viele andere Objekte der speziellen Klasse gehören. |
 |
1:1..* | Zu einem Objekt muß mindestens 1 bis unendlich viele andere Objekte der speziellen Klasse gehören. |
 |
1..*:1..* | Zu mindestens einem bis unendlich vielen Objekten gehörten mindestens ein bis unendlich viele Objekte. |
 |
3:4 | Die Verhältnisse können auch expliziter angegeben werden. Zum Beispiel: Zu genau 3 Objekten gehören genau 4 andere Objekte. |
Des weiteren lassen sich diese Verhältnisse beliebig anpassen,
wie z.B. 1..4:2..* (zu ein bis vier Objekten gehören mindestens 2 bis unendlich
viele Objekte usw.). Es gibt aber noch zwei speziellere Arten von Assoziationen
als die oben beschriebenen. Zum einen ist da die Aggregation, die sich durch
"ist Teil von" bzw. "besteht aus" (Ganzes & Teile, whole & part) beschreiben
lässt. In der UML - Notation wird die Aggregation als ein Peil dargestellt, an
dessen Ursprung sich eine offene Raute befindet, wie z.B.
. Zum anderen ist da die Komposition, die eine "starke" Aggregation
ist und somit gilt die dynamische Semantik des Ganzen gilt auch für seine Teile.
Konkret bedeutet das z.B.: Wird das Ganze gelöscht, werden automatisch auch seine
Teile gelöscht (they live and they die with it). In der UML - Notation wird die
Komposition als ein Peil dargestellt, an dessen Ursprung sich eine geschlossene
Raute befindet, wie z.B.
. In unserem Beispiel (Abb.11) würde diese
Komposition also die verwendete Assoziation verschärfen, da es keine Konten
geben darf, ohne dass es dazu einen Kunden gibt.
Wie sind Statecharts definiert?
Ein Statechart besteht aus Zuständen und Zustandsübergängen (Transitionen).
Ein Zustand ist eine Zeitspanne, in der ein Objekt auf ein Ereignis wartet.
Ein Ereignis tritt immer zu einem Zeitpunkt auf und besitzt keine Dauer.
Statecharts werden verwendet, um das dynamische Verhalten der Objekte einer Klasse zu beschreiben.
Im Anfangszustand
wird das Objekt erzeugt. Zustände sind
Rechtecke mit runden Kanten
. Die Zustandsnamen sind optional, Zustände ohne
Namen heißen anonyme Zustände und sind alle voneinander verschieden. Transitionen verbinden die einzelnen Zustände und können durch verschiedene
Ereignisse ausgelöst werden, z.B.:
eine Botschaft - Aufruf einer Methode
einer Bedingung, die wahr wird, z.B. when (Kontostand < 0)
ein Signal - Mausklick des Users
eine verstrichene Zeitspanne, z.B. after ( 10 sec.)
Mit Statecharts können auch bedingte Anweisungen (if,...)
dargestellt werden. Im Endzustand
hört das Objekt auf zu existieren.
Um ein Statechart in das Together Projekt einzufügen, wählt man das Menü "File" und klickt dann auf "New...". Daraufhin öffnet sich die "Object Gallery" (vgl. Abb. 7), dort wählt man aus der Kategorie "General" das Template "Diagram" aus und klick auf "Next". Es öffnet sich folgendes Fenster:
Abb. 12: Neues Zustandsdiagramm erstellen
In diesem Fenster wählt man "Statechart" aus, gibt unter "Diagram name:" den gewünschten Namen ein und klickt auf "Finish".
Das nachfolgende Beispiel (Abb. 13) beschreibt die Zustände, die ein Konto zum Beilspiel annehmen kann. Vom Startzustand aus wird das Konto eröffnet und ist somit aktiv. Auf diesem aktiven Konto können Buchungen durchgeführt werden. Dieses Konto bietet die Möglichkeit, daß es eingefroren werden kann und somit passiv wird. Natürlich muß man das das Konto auch wieder reaktivieren können, damit es wieder in den aktiven Zustand übergehen kann. Die letzte Möglichkeit ist das Konto zu schließen, womit der Endzustand erreicht wird.
Abb. 13: Das Zustandsdiagramm eines Kontos
Die Bezeichnung zu einer Transition gibt man ein, indem man mit der rechten Maustaste auf die "Transition" klickt und im Kontextmenü "Properties..." klickt und dann im "Inspector" unter "event name" die Bezeichnung eingibt.
Abb. 14: Der Inpector
Aktivitätsdiagramme sind eine Erweiterung der Statecharts. Mit Aktivitätsdiagrammen kann man parallele Aktivitäten und deren Synchronisation darstellen. Eine weitere Anwendungsmöglichkeit ist die Spezifikation von Arbeitsabläufen (workflow), da es in Aktivitätsdiagrammen Verzweigungen wie in Kontrollflussdiagrammen gibt.
Um ein Aktivitätsdiagramm in das Together - Projekt einzufügen, wählt man das Menü "File" und klickt dann auf "New...". Daraufhin öffnet sich die "Object Gallery" (vgl. Abb. 7), dort wählt man aus der Kategorie "General" das Template "Diagram" aus und klick auf "Next". Es öffnet sich folgendes Fenster:
Abb. 15: Neues Aktivitätsdiagramm erstellen
In diesem Fenster wählt man "Activity" aus, gibt unter "Diagram name:" den gewünschten Namen ein und klickt auf "Finish".
Wenn zum Beispiel ein Kredit genehmigt werden soll, müssen zuerst alle Daten erfasst werden. Als nächstes werden zeitgleich die Kundenhistorie sowie Schufa - Einträge überprüft. Wenn alle Überprüfungen ausgewertet wurden, kann entweder das OK für den Kredit gegeben werden, oder es wird ein Bausparvertrag empfohlen.
Abb. 16: Kredit gewähren
In dem Diagramm (Abb. 16) läßt sich sehr schön die Parallelität der beiden Aktivitäten (Überprüfung Schufa / Kundenhistorie) erkennen, die jeweils durch einen schwarzen Balken aufgespaltet und zusammengeführt werden (fork and join). Die Bedingung der Fallunterscheidungen wird jeweils in einer eckigen Klammer neben der Transition notiert.
Wenn ein Akteur in den Dialog mit einem System mehrere zusammengehörende Transaktionen durchführt, dann können diese in einem Anwendungsfall zusammengefasst werden. Ein Akteur ist in den meisten Fällen der User, es kann aber auch ein anders System sein. In keinem Fall ist der Akteur das System, das entwickelt wird. Anwendungsfälle werden meistens formal mit einer festgelegten Schablone spezifiziert. Beispiel:
| Überschrift: | Beschreibung: | Beispiel: |
| Anwendungsfall: | Name des Anwendungsfalls. | Geld abheben. |
| Ziel: | Zielsetzung bei erfolgreicher Ausführung des Anwendungsfalls. | Dem Kunden wurde die gewünschte Menge Geld ausgehändigt. |
| Vorbedingung: | erwarteter Zustand bevor der Anwendungsfall beginnt. | Der Kunde hat ein Konto. |
| Nachbedingung Erfolg: | -/- | Der Kunde hat die gewünschte Menge Geld ausgehändigt bekommen. |
| Nachbedingung Fehlschlag: | -/- | Der Kunde hat die gewünschte Menge Geld nicht ausgehändigt bekommen. |
| Beteiligte Akteure: | -/- | Kunde, Bankfachangestellter |
| Auslösendes Ereignis: | -/- | Kunde möchte Geld abheben. |
| Beschreibung: | Hier wird der Standardfall beschrieben. | 1.) Kontostand prüfen. 2.) Betrag abbuchen. 3.) Geld auszahlen. |
| Erweiterungen: | Erweiterungen des Funktionsumfangs. | 1a.) Dispo - Kredit prüfen. |
| Alternativen: | Alternative Ausführungen. | 3a.) Betrag überweisen. |
Um ein Anwendungsfalldiagramm in das Together - Projekt einzufügen, wählt man der Menü "File" und klickt dann auf "New...". Daraufhin öffnet sich die "Object Gallery" (vgl. Abb. 7), dort wählt man aus der Kategorie "General" das Template "Diagram" aus und klick auf "Next". Es öffnet sich folgendes Fenster:
Abb. 17: Neues Anwendungsfalldiagramm
In diesem Fenster wählt man "Use Case" aus, gibt unter "Diagram name:" den gewünschten Namen ein und klickt auf "Finish".
Wenn man jetzt die obige Tabelle in das Anwendungsfalldiagramm einfügt, entstehen folgende Abbildungen:
Abb. 18 & 19: Anwendungsfalldiagramm mit Inspector
Die Akteure, Kunde und Bankfachangestellter, werden jeweils als "Strichmännchen" dargestellt. Das komplette Banksystem wird von dem grauen, rechteckigen Kasten umfasst, in dem momentan nur der eine Anwendungsfall "Geld abheben" betrachtet wird. Dieser Anwendungsfall wird auch im Inspector angezeigt, in dem alle Einträge aus der Tabelle oben eingetragen werden können.
Auch Anwendungsfälle können untereinander in Beziehung stehen. Zum einen gibt es die Möglichkeit, daß ein Anwendungsfall einen anderen benutzt <<includes>> ( entspricht <<uses>> aus UML 1.1) oder dass ein Anwendungsfall einen anderen Erweitert. In der UML 1.1 zeigte übrigens der Pfeil auf die Klasse, die eine andere erweitert, jetzt ist es genau umgekehrt.
Abb. 20: Anwendungsfall erweitern
Die recht groben Anwendungsfalldiagramme lassen sich durch Sequenzdiagramme noch genauer spezifizieren, indem die einzelnen Anwendungsschritte, Vor- bzw. Nachbedingung und jede Erweiterung bzw. Alternative einzeln dargestellt werden können. Sequenzdiagramme werden zweidimensional dargestellt, das heißt auf der Vertikalen wird die Zeit dargestellt und auf der Horizontalen werden die Objekte abgetragen. Objekte werden durch das jeweilige Objektsymbol und der dazu gehörigen Lebenslinie dargestellt.
Um ein Sequenzdiagramm in das Together - Projekt einzufügen, wählt man der Menü "File" und klickt dann auf "New...". Daraufhin öffnet sich die "Object Gallery" (vgl. Abb. 7), dort wählt man aus der Kategorie "General" das Template "Diagram" aus und klick auf "Next". Es öffnet sich folgendes Fenster:
Abb. 21: Neues Sequenzdiagramm
Wenn man das Beispiel aus dem Anwendungsfall in ein Sequenzdiagramm umsetzt, erhält man folgende Abbildungen:
Abb. 22 & 23: Sequenzdiagramm mit Inspector
Die Akteure, Kunde und Bankfachangestellter, sind uns schon aus den Anwendungsfällen bekannt. Im Sequenzdiagramm kann man sehr eindeutig sehen, welcher Akteur mit welchem Objekt arbeitet und welche Schritte durchzuführen sind. Die Aktion 1.1. liefert ein Ergebnis an den Bankfachangestellten zurück, was durch die gestrichelte Linie verdeutlicht wird. Damit die gestrichelte Linie im Diagramm angezeigt wird, wählt man im "Inspector" die CheckBox "return arrow" aus. Es besteht auch die Möglichkeit, dass einzelne Anwendungsschritte nur ausgeführt werden, wenn eine bestimmte Bedingung zutrifft, die unter "condition" im "Inspector" eingetragen werden kann. Im Diagramm stehen die Bedingungen zu den Anwendungsschritten in eckigen Klammern [Bedingung]Operation.
Des weiteren gibt es noch das Komponentendiagramm (component diagram), das die Abhängigkeiten und Organisation von einzelnen ausführbaren Softwaremodulen darstellt, die wohldefinierte Schnittstellen haben. Dieser Diagrammtyp hat für unser Projekt keine Bedeutung.
Das Kollaborationsdiagramm (collabration diagram) ähnelt dem Sequenzdiagramm, da es die Interaktionen einzelner ausgewählter Objekte bezogen auf einen bestimmten Kontext anzeigt. Das Verteilungsdiagramm (deployment diagramm) zeigt die Konfiguration der zur Laufzeit vorhandenen Prozesse und Objekte an. Beide Diagrammtypen lassen sich mit Together analog zu den anderen Diagrammen erstellen, allerdings werde ich hier nicht näher auf diese Diagrammtypen eingehen.
Abb. 24: The Eclipse Project
Das Eclipse Projekt ist ein Open Source Projekt von www.eclipse.org, das vom Project Management Committee (PMC) und den Projektleitern verwaltet wird. Somit dürfen wir dieses Programm kostenlos nutzen. Zur Zeit ist Eclipse für folgende Betriebssysteme verfügbar:
Microsoft® Windows® 98SE, ME, NT, 2000, XP
Linux auf Intel x86 - Motif, GTK 2.0
RedHat Linux 7.2 x86
SuSE Linux 7.3 x86
Sun Solaris 8 SPARC - Motif
HP-UX 11i hp9000 - Motif
IBM(r)® AIX 5.1 auf PowerPC - Motif
Nachdem man die aktuelle Eclipse Version von der offiziellen Seite http://download.eclipse.org/downloads/drops/S-M3-200211151436/index.php heruntergeladen hat, entpackt man das Zip - Verzeichnis direkt in dem Zielordner, da keine weitere Installation notwendig ist. Eclipse läßt sich direkt aus dem Zielordner starten.
Die Windows® Version von Eclipse läßt sich durch ein Doppelklick auf eclipse.exe starten. Danach öffnet sich folgendes Fenster:
Abb. 25: Das Eclipse Hauptfenster
Wenn man ein neues Java - Projekt in Eclipse erstellen möchte, klickt man auf das Menü auf "File", dann auf "New" und "Projekt..."
Abb. 26: Neues Projekt - Schritt 1
In dem Fenster "New Project" muss man "Java Projekt" auswählen und kann dann auf "Next" klicken.
Abb. 27: Neues Projekt - Schritt 2
Unter "Project name:" gibt man den Namen des neuen Projektes an. Wenn man nicht möchte, daß das neue Projekt in dem Standardverzeichnis von Eclipse gespeichert wird, sollte man das Häkchen aus der CheckBox von "Use default" nehmen und einen eigenen Dateipfad angeben. Sobald man auf "Finish" klickt, wird das Projekt erstellt.
Abb. 28: Das Neue Projekt
Im "Package Explorer" existiert jetzt das HalloWelt - Projekt. Im nächsten Schritt fügt man ein Package hinzu, indem man mit der rechten Maustaste auf das neue Projekt klickt und dann den Menüpunkt "New" auswählt und auf "Package" klickt.
Abb. 29: Ein neues Packet
Versucht man als neuen Paketnamen "TextUI" einzugeben, wird man von Eclipse dezent darauf hingewiesen, dass, wenn man der Konvention entsprechen möchte, der erste Buchstabe eines Paketes kleingeschrieben wird. Also gibt man natürlich "textUI" ein.
Als nächstes wollen wir dem Paket eine neue Java - Klasse hinzufügen. Dazu klickt man mit der rechten Maustaste auf das neu erstellte Paket und wählt im Kontextmenü "New" und "Class" aus.
Abb. 30: Eine neue Klasse
In diesem Fenster kann man bestimmte Standardeinstellungen vornehmen. Man kann zum Beispiel auswählen, ob es in der Klasse eine public static void main(Sting[] args){} - Methode geben soll oder ob die Konstruktoren der Oberklasse übernommen werden sollen. Durch ein Klick auf "Finish" wird die Klasse erstellt:
package textUI;
/**
* @author Thorsten
*
*/
public class Start {
public static void main(String[] args) {
}
}
Auch bei der Programmierung wird man von Together unterstützt. Wenn man z.B. "System.out.p" eingegeben hat bekommt man eine Liste mit Methoden, die mit p anfangen und an dieser Stelle verwendet werden können. Durch drücken der Enter - Taste werden diese Methoden übernommen.
Abb. 31: Methoden Vervollständigung
Ein weiters Beispiel für hilfreiche Autoverfollständigung ist, dass durch die Eingabe eines "@" in dem Bereich des Javadoc eine Liste mit möglichen Parametern angezeigt wird.
Abb. 32: Eingabehilfe
Auch wenn man eine falsche Wertzuweisung macht, wie "int wert =
1.3" und somit einer Integer Variabe einen Floatwert zuweisen will, wird man von Eclipse darauf hingewiesen, indem neben der entsprechenden Zeile ein
Glühbirnensymbol
aufleuchtet und die entsprechende Stelle rot unterkringelt ist.. Klickt man nun
auf dieses Symbol werden einem verschiedene Lösungsmöglichkeiten angeboten. Man
kann die Lösungsmöglichkeiten mit der Maus auswählen und es erscheint eine
Vorschau auf den Quelltext nach der Änderung. Durch drücken der Entertaste wird
der Vorschlag übernommen.
Abb. 33: Methodenkorrektur
Um ein geschriebenes Programm auszuführen, wählt man die entsprechende Java - Datei im "Package Explorer" aus und klickt im Menü neben das laufende Männchen auf den Pfeil. In dem Menü, das sich jetzt öffnet, wählt man "Run As" und dann "2 Java Application" aus.
Abb. 34: Ein Programm starten
Bevor das Programm gestartet wird, fordert Eclipse zum Speichern auf. Bestätigt man mit "OK" wird in dem "Console" - Fenster "Hallo Welt!" ausgegeben.
Abb. 35: Ausgabe des Programms
Als "Refactoring actions" bezeichnet man die Umschreibeung eines vorhandenen Quellcodes.
Innerhalb eines Javaquellcodes
Innerhalb verschiedener zusammenhängender Javaquelldateien
Durch Refactoring wird die Programmsemantik nicht geändert.
Es wird also nicht geändert, was das Programm tut,
sondern nur wie es getan wird.
Mit Hilfe von Refactoring steigt die Quelltextqualität, da es leichter wird, schlechten Quellcode umzuschreiben.
Wenn man den folgenden Quellcode betrachtet, stellt man einige Optimierungsmöglichkeiten fest.
public class Start {
public static void main(String[] args) {
System.out.println("Hallo Welt!");
double wert = 1.3;
System.out.println(wert);
wert = 12 + 2;
System.out.println(wert);
}
}
Die 12 und die 2 könnte man jeweils in einer lokalen Variable speichern. Um aus einer konstanten Zahl eine Variable zu machen bietet Eclipse eine sehr einfache Möglichkeit. Man markiert die entsprechende Zahl und klickt mit der rechten Maustaste auf die Zahl. Unter dem Menüpunkt "Refactor" wählt man "Extract Local Variable..." aus. Es öffnet sich das "Refactoring" - Fenster. In diesem Fenster gibt man unter "Variable name:" den Namen an, den die Variable bekommen soll und bestätigt mit "Next"
Abb. 36: Refactoring einer lokalen Variable
In dem Fenster (Abb. 36) kann man die Änderungen des Quelltextes im Vorher - Nachher Vergleich sehen. Mit der 2 verfährt man analog. Der neue Quelltext sieht dann so aus:
public class Start {
public static void main(String[] args) {
System.out.println("Hallo Welt!");
double wert = 1.3;
System.out.println(wert);
int ersterSummand = 12;
int zweiterSummand = 2;
wert = ersterSummand + zweiterSummand;
System.out.println(wert);
}
}
Die Berechnung "wert = ersterSummand + zweiterSummand;" läßt sich sehr einfach in eine eigenständige Methode umwandeln, indem man die Zeile markiert und mit der rechten Maustaste unter dem Menüpunkt "Refactor", "Extract Method..." auswählt.
Abb. 37: Refactoring einer Methode - Schritt 1
Nach Eingabe des Methodennamens und Bestätigung mit "Next"
Abb. 38: Refactoring einer Methode - Schritt 2
In dem Fenster (Abb. 38) kann man die Änderungen des Quelltextes im Vorher - Nachher - Vergleich sehen. Der neue Quelltext sieht dann so aus:
public class Start {
public static void main(String[] args) {
System.out.println("Hallo Welt!");
double wert = 1.3;
System.out.println(wert);
int ersterSummand = 12;
int zweiterSummand = 2;
wert = addieren(ersterSummand,
zweiterSummand);
System.out.println(wert);
}
public static double addieren(int ersterSummand, int
zweiterSummand) {
double wert;
wert = ersterSummand + zweiterSummand;
return wert;
}
}
Aus der 1.3 der Zeile "double wert = 1.3;" läßt sich eine Konstante erstellen, indem man die 1.3 markiert und mit der rechten Maustaste unter dem Menüpunkt "Refactor", "Extract Constant..." auswählt. Der neue Quelltext sieht dann so aus:
...
private static final double STARTWERT = 1.3;
public static void main(String[] args) {
System.out.println("Hallo Welt!");
double wert = STARTWERT;
...
Wenn man im Nachhinein feststellt, daß eine der Umformungen sich als negativ erweist, kann man sie mit der entsprechenden Gegenoperation "Inline ..." die Umformung wieder Rückgängig machen.
Abb. 3: TogetherSoft - Logo
Abb. 4 - 23: Selbsterstellte Together Screenshots
Abb. 24 - 38: Selbsterstellte Eclipse Screenshots
Bernd Oestereich: Objektorientierte Softwareentwicklung: Analyse und Design mit der UML; 5. Auflage; Verlag R.Oldenbourg, München 2001
B. Oestereich / P. Hruschka / N. Josuttis / H. Kocher / H. Krasemann / M. Reinhold: Erfolgreich mit Objektorientierung; 2.Auflage; Verlag R.Oldenbourg, München 2001
W. Hasselbring: Software Engineering: Vorlesungsfolien; http://se.informatik.uni-oldenburg.de/, Software Engineering Sommer Semester 2002
Erstellt von Thorsten Vogt, Januar 2003
