JinBean - Java GUI Builder - intermitto.net

JinBean - Java GUI Builder

Analyse und Entwurf

An der Fachhochschule Dortmundim Fachbereich Informatik

erstellte Projektarbeitim Studiengang Allgemeine Informatik

von

Jens Becker, geboren am 4. Mai 1977Matrikelnummer 7040267

Betreuer: Prof. Dr. Michael Stark

Dortmund, 23. Mai 2005

JinBean - Java GUI Builder

Markenrechtlicher Hinweis

Die in dieser Arbeit wiedergegebenen Gebrauchsnamen, Handelsnamen, Waren-zeichen usw. können auch ohne besondere Kennzeichnung geschützte Markensein und als solche den gesetzlichen Bestimmungen unterliegen.

Sämtliche in dieser Arbeit abgedruckten Bildschirmabzüge unterliegen dem Ur-heberrecht des jeweiligen Herstellers.

Copyright 2004-2005 Jens Becker

http://jinbean.intermitto.net/

Letzte Änderung: 18. Juli 2005

Inhaltsverzeichnis

1. Einleitung 11.1. Werkzeuge zur Anwendungserstellung. . . . . . . . . . . . . . . 11.2. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Untersuchtes Szenario. . . . . . . . . . . . . . . . . . . . . . . 31.4. Gliederung der Projektarbeit. . . . . . . . . . . . . . . . . . . . 31.5. Grundbegriffe. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Untersuchung vorhandener Werkzeuge 72.1. JBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1. Erlernbarkeit. . . . . . . . . . . . . . . . . . . . . . . . 82.1.2. Benutzeroberfläche. . . . . . . . . . . . . . . . . . . . . 102.1.3. Ablauf und Beispiel . . . . . . . . . . . . . . . . . . . . 142.1.4. Design grafischer Benutzeroberflächen. . . . . . . . . . 162.1.5. Erzeugter Code und Dateiformat. . . . . . . . . . . . . . 182.1.6. Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

2.2. Eclipse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .212.2.1. Ablauf und Beispiel . . . . . . . . . . . . . . . . . . . . 232.2.2. Design grafischer Benutzeroberflächen. . . . . . . . . . 242.2.3. Erzeugter Code und Dateiformat. . . . . . . . . . . . . . 262.2.4. Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

2.3. Visaj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .282.3.1. Ablauf und Beispiel . . . . . . . . . . . . . . . . . . . . 292.3.2. Erzeugter Code. . . . . . . . . . . . . . . . . . . . . . . 382.3.3. Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

2.4. Visual Studio .NET. . . . . . . . . . . . . . . . . . . . . . . . . 412.4.1. Design grafischer Benutzeroberflächen. . . . . . . . . . 412.4.2. Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

2.5. NetBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .442.5.1. Design grafischer Benutzeroberflächen. . . . . . . . . . 442.5.2. Erzeugter Code. . . . . . . . . . . . . . . . . . . . . . . 46

I

Inhaltsverzeichnis

2.5.3. Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . .462.6. Bean Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . .48

2.6.1. Benutzeroberfläche. . . . . . . . . . . . . . . . . . . . . 482.6.2. Design grafischer Benutzeroberflächen. . . . . . . . . . 482.6.3. Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . .502.6.4. Bemerkung. . . . . . . . . . . . . . . . . . . . . . . . . 50

3. Folgerung 533.1. Erfüllung der Anforderungen. . . . . . . . . . . . . . . . . . . . 533.2. Konkrete Folgerungen. . . . . . . . . . . . . . . . . . . . . . . 54

3.2.1. Positionierung von Komponenten. . . . . . . . . . . . . 543.2.2. Palette. . . . . . . . . . . . . . . . . . . . . . . . . . . .553.2.3. Simplizität und einheitliche Oberfläche. . . . . . . . . . 563.2.4. Probleme mit Editoren und Persistenz. . . . . . . . . . . 56

4. Zielsetzung 574.1. Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .574.2. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . .58

4.2.1. Prototyp / Projektarbeit. . . . . . . . . . . . . . . . . . . 584.2.2. Diplomarbeit - Musskriterien. . . . . . . . . . . . . . . . 594.2.3. Diplomarbeit - Kannkriterien. . . . . . . . . . . . . . . . 60

4.3. Abgrenzung. . . . . . . . . . . . . . . . . . . . . . . . . . . . .604.4. Zielgruppe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .604.5. Betriebsbedingungen und Umgebung. . . . . . . . . . . . . . . . 61

5. Prototyperstellung 635.1. Objektorientierte Analyse - Geschäftsprozesse. . . . . . . . . . . 64

5.1.1. Erstellen einer grafischen Bean. . . . . . . . . . . . . . . 645.1.2. Verwalten der Paletten. . . . . . . . . . . . . . . . . . . 655.1.3. Verwaltung von Templates. . . . . . . . . . . . . . . . . 65

5.2. Objektorientierte Analyse - Statisches Modell. . . . . . . . . . . 665.3. Objektorientierte Analyse - Dynamisches Modell. . . . . . . . . 68

5.3.1. Zustandsautomat. . . . . . . . . . . . . . . . . . . . . . 685.3.2. Interaktionsdiagramme. . . . . . . . . . . . . . . . . . . 68

5.4. Objektorientiertes Design - Statisches Modell. . . . . . . . . . . 725.4.1. AWT und Swing . . . . . . . . . . . . . . . . . . . . . . 725.4.2. Fachkonzept durch Wrapper. . . . . . . . . . . . . . . . 755.4.3. Vergleich OOA und Swing. . . . . . . . . . . . . . . . . 765.4.4. Kopieren von Komponenten. . . . . . . . . . . . . . . . 775.4.5. Trennung von Fachkonzept und GUI. . . . . . . . . . . . 78

II

Inhaltsverzeichnis

5.4.6. Klassendiagramm. . . . . . . . . . . . . . . . . . . . . . 785.4.7. Entwurf und Implementierung des Eigenschaftsfensters. . 815.4.8. Projekt und Entwurfsfenster. . . . . . . . . . . . . . . . 82

5.5. Objektorientiertes Design - Dynamisches Modell. . . . . . . . . 85

6. Prototypbeschreibung 876.1. Projektfenster. . . . . . . . . . . . . . . . . . . . . . . . . . . .886.2. Projektfenster - Technischer Ablauf. . . . . . . . . . . . . . . . 896.3. Eigenschaftsfenster. . . . . . . . . . . . . . . . . . . . . . . . . 916.4. Eigenschaftsfenster - Technischer Ablauf. . . . . . . . . . . . . 926.5. Palettenfenster. . . . . . . . . . . . . . . . . . . . . . . . . . . .936.6. Palettenfenster - Technischer Ablauf. . . . . . . . . . . . . . . . 93

7. Ausblick 957.1. Betrachtung des Prototyps. . . . . . . . . . . . . . . . . . . . . 957.2. Theoretische Inhalte der Diplomarbeit. . . . . . . . . . . . . . . 96

A. Sun Software License 97

B. Verwendete Literatur 99B.1. Bücher. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99

B.1.1. Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . .99B.1.2. Softwaretechnik . . . . . . . . . . . . . . . . . . . . . . 99

B.2. Webseiten von Sun Microsystems. . . . . . . . . . . . . . . . .100B.2.1. Konventionen. . . . . . . . . . . . . . . . . . . . . . . .100B.2.2. Java API . . . . . . . . . . . . . . . . . . . . . . . . . .100B.2.3. Java Beans. . . . . . . . . . . . . . . . . . . . . . . . .100B.2.4. Ressourcen. . . . . . . . . . . . . . . . . . . . . . . . .101

Tabellenverzeichnis 103

Abbildungsverzeichnis 105

Literaturverzeichnis 107

Index 109

III

Inhaltsverzeichnis

IV

1. Einleitung

1.1. Werkzeuge zur Anwendungserstellung

Der Java GUI BuilderJinBeanist aus der Notwendigkeit entstanden, Studien-Motivation und Ziel

anfängern der Informatik eine einfach und intuitiv zu bedienende Entwicklungs-umgebung zur Erstellung grafischer Benutzeroberflächen in der Sprache Java zubieten.

Gewünscht ist eine Software, mit der Nutzer grafische Benutzeroberflächen untereiner grafischen Benutzeroberfläche entwickeln können. Die grafischen Kompo-nenten sollen nicht im Quelltext entwickelt, sondern in einemEntwurfsfensterergonomisch mit der Maus erstellt und manipuliert werden.

Die Software soll dem Anwender ermöglichen, ein Fenster zu erstellen und die-sem Fenster Komponenten hinzuzufügen, diese Komponenten zu kopieren, aus-zuschneiden oder wieder zu entfernen. Position, Größe und andere Eigenschaf-ten der Komponenten sollen grafisch manipulierbar sein. Das Fenster samt seinerKomponenten soll sowohl zur weiteren Bearbeitung gespeichert als auch in Java-Quellcode umgewandelt werden können.

Das Gros der kommerziell und nicht kommerziell erhältlichen Lösungen für JavaIDEs

sind sogenannte Integrierte Entwicklungsumgebungen (IDE1).

Diese umfangreichen Entwicklungsumgebungen basieren auf einem Quelltext-Editor, derSyntax Highlighting, automatische Codevervollständigung und oft zu-sätzliche Funktionen unterstützt. So werden Syntaxfehler meist hervorgehoben,einige Programme bieten Funktionen wieCode Foldingoder kontextbezogeneHilfe.

Allgemein sind IDEs aus der professionellen Software-Entwicklung nicht mehrZielgruppe von IDEs

wegzudenken. Bei größeren Projekten sind Abhängigkeiten, Versionierung, Do-kumentationserstellung, Deploymentfunktionen und zahlreiche weitere nötige Ar-beitsschritte wesentlich komfortabler über eine IDE zu verwalten, als alle Schritte

1englischIntegrated Development Environment, kurz IDE

1

1. Einleitung

manuell auszuführen.

Oft werden zusätzliche Bibliotheken mitgeliefert, die als Ergänzung zum Java-SDK dienen können. Schließlich sind einige IDEs sogar über die API2 des IDEerweiterbar. Es gibt freie und käufliche Erweiterungen, abgesehen davon kannman sein IDE selbst erweitern.

1.2. Anforderungen

Der gewünschteEntwurfsmodusist bei vielen IDEs bereits enthalten, für anderegibt es Plug-Ins zu diesem Zweck. Im folgenden Kapitel2 wird daher überprüft,in wie weit vorhandene IDEs den Bedürfnissen von unerfahrenen Anwendernentsprechen.

Technische Untersuchungskriterien sind dabei vor allemAnforderungen

O1 eine einheitliche Oberfläche;Oberfläche

O2 gute Erreichbarkeit derPaletteder verfügbaren Komponenten und weitererFenster; Position und Größe der Fenster sollten manipulierbar sein;

O3 eine einfache Bedienung, so dass Nutzer Schritt für Schritt Anleitungen er-halten, wie ihr Ziel erreicht wird3;

O4 das schnelle Erreichen des Ziels; Vorlagen und Wizards können hilfreichsein;

E1 eine geringe Komplexität der Oberfläche und des Entwurfsmodus; gewünsch-Entwurf

te Funktionen müssen gut erreichbar und schnell auffindbar sein;

E2 eine hohe Benutzbarkeit des Entwurfsfensters; Komponenten müssen mitder Maus positioniert und manipuliert werden können;

E3 absolute Positionierung von Komponenten, da Anfänger noch keine Erfah-rung mitLayout Managernbesitzen;

E4 die Ausrichtung mehrerer Komponenten an einer virtuellen Linie4;

2englischApplication Programming Interface, kurzAPI3Wünschenswert ist eine permanente Anleitung des Nutzers. Dies kann über die Oberfläche oder über dieHilfefunktion der Anwendung erreicht werden.

4Pixelgenaues Arbeiten hat den Nachteil, dass eine bündige Platzierung von Komponenten schwierig ist.Daher muss trotz absoluter Positionierung sichergestellt sein, dass Nutzer Komponenten horizontal undvertikal bündig ausrichten können.

2

1.3. Untersuchtes Szenario

M1 eine geringe Ladezeit und eine hohe Geschwindigkeit während des Ent-Weiteres

wurfs;

M2 die Erzeugung von gut lesbaren und kommentierten Quellcodes;

M3 die Wiederverwendbarkeit und Portierbarkeit der erstellten Komponenten.

Die oben genannten Funktionen typischer Entwicklungsumgebungen sind für An-Anfänger

fänger unerheblich. Sie werden nicht benötigt und machen eine Entwicklungs-umgebung nur langsamer und komplexer. Sie werden daher nicht betrachtet. Er-forderlich ist eine spezialisierte, schlanke und schnelle Software zur Erstellunggrafischer Benutzeroberflächen.

Zu beachten ist vor allem, dass die genannten Faktoren im Lehrbetrieb an Hoch-Lehrbetrieb

schulen viel stärker negativ ins Gewicht fallen können als bei einem Einsatz inprivatem Umfeld. Eine hohe Komplexität erfordert Einarbeitung und Erklärungseitens der Lehrpersonen; Probleme und Nachfragen halten den Lehrbetrieb auf.Hohe Ladezeiten werden vor allem dann zu einem Hindernis, wenn die IDE voneinem Server über das Netzwerk geladen wird, auf den alle Studenten gleichzeitigzugreifen.

Zusätzlich muss darauf geachtet werden, dass die Hochschule keine zusätzli-Kosten

chen Mittel für die Software aufwenden kann. Kostenpflichtige Softwareversio-nen werden auf Stärken und Schwächen untersucht, kommen aber für den Einsatzim Lehrbetrieb nicht in Frage.

1.3. Untersuchtes Szenario

Zur Überprüfung des Entwurfsmodus der verschiedenen Lösungen wird ein einfa-ches Fenster erstellt. Dieses Fenster soll zwei Schaltflächen enthalten, die vertikalbündig ausgerichtet sein sollen.

Die Manipulation der Eigenschaften der Komponenten wird getestet. Schließlichwird überprüft, ob ein unerfahrener Anwender problemlos mit der Anwendungarbeiten kann, und ob die oben angegebenen Anforderungen eingehalten werden.

1.4. Gliederung der Projektarbeit

Im folgenden Kap.2 wird untersucht, in wie weit vorhandene Lösungen den An-Konkurrenz

3

1. Einleitung

forderungen entsprechen. Die IDEsJBuilder, EclipseundNetBeanswerden be-wertet, ebenso der schlankereBean Builder. Mit Visaj wird eine Software unter-sucht, die keine komplette Entwicklungsumgebung bietet, sondern speziell daseinfache Erstellen grafischer Oberflächen erlauben soll.

Außer den oben genannten Anforderungen werden Stärken und Schwächen dereinzelnen Lösungen betrachtet. Daher wird auchVisual Studiountersucht, ob-wohl es keine Java-Entwicklungsumgebung ist, da es weit verbreitet ist und einenkomfortablen Entwurfsmodus bietet.

In Kapitel 3 werden die Ergebnisse der Untersuchung zusammengefasst. Es wirdFolgerung

sich zeigen, dass eine Eigenentwicklung nötig ist. Für diese werden konkretereAnforderungen gefolgert, dazu werden auch gefundene Stärken und Schwächender betrachteten Lösungen berücksichtigt.

Kapitel 4 entspricht einem Pflichtenheft und geht auf die Unterschiede zwischenZielsetzung

Projekt- und Diplomarbeit ein. Es werden Kriterien für den Prototypen und dieSoftware aufgestellt.

Im darauf folgenden Kapitel5 wird die objektorientierte Analyse und der EntwurfPrototyperstellung

des Prototypen betrachtet. Im Zuge des Entwurfs werden auch Teile der Imple-mentierung erläutert, wenn es zum Verständnis des Entwurfs beiträgt.

Schließlich wird in Kapitel6 der Prototyp dargestellt. Die Oberfläche der Softwa-Prototypbeschreibung

re und die Zusammenhänge bei Arbeitsschritten werden genau beschrieben. Füralle Teile der Oberfläche werden die Abläufe sowohl aus Sicht des Benutzers alsauch technisch erläutert.

Das letzte Kapitel7 gibt einen kurzen Ausblick auf die dieser Projektarbeit fol-Ausblick

gende Diplomarbeit.

1.5. Grundbegriffe

Eine JavaBean Component, oder kurzBean, ist eine Java-Klasse, die derJava-Bean

Beans Component Architecture[Ham97] genügt. Die Klasse muss also gewisseRegeln einhalten, wodurch die Wiederverwendbarkeit und Plattformunabhängig-keit garantiert wird. Wenn im Text vonKomponentengesprochen wird, sind gra-fische Beans gemeint.

Die Paletteist der Bereich der Oberfläche, aus dem man Komponenten zum Hin-Palette

zufügen in das Entwurfsfenster auswählen kann. In Kapitel2 werden teilweise

4

1.5. Grundbegriffe

andere Begriffe benutzt, wenn die untersuchte Software eine eigene Bezeichnungbenutzt (beispielsweiseToolboxbeiVisual Studio).

DasEntwurfsfenster(oder derDesigner) ist der Bereich der Software, in der dasEntwurf

zu erstellende Fenster mit der Maus manipuliert werden kann. Dort werden Kom-ponenten hinzugefügt und manipuliert.

DasEigenschaftsfenster(oder derProperty Sheet) ist eine tabellarische Übersicht Eigenschaften

über die Eigenschaften (Properties) einer Bean. Die Werte der Eigenschaften kön-nen durchEditorenangesehen und geändert werden.

5

1. Einleitung

6

2. Untersuchung vorhandenerWerkzeuge

Zuerst wird die vorhandene Software zur Erzeugung grafischer Benutzeroberflä-Motivation

chen betrachtet. Das Hauptaugenmerk liegt dabei auf

• der Suche nach einer Software, welche eine Neuentwicklung obsolet ma-chen könnte,

• die Überprüfung vorhandener Lösungen auf die in Abschnitt1.2genanntenAnforderungen und

• der Untersuchung der Lösungen auf besondere Stärken und Schwächen.

Bei einigen Lösungen werden nicht nur die GUI-Erstellung, sondern zusätzlichbesondere Aspekte wie die Online-Hilfe und Architektur betrachtet. JBuilder undVisaj werden sehr ausführlich betrachtet, andere Lösungen zielgerichteter. Wo esangebracht ist, wurde ein vollständiges Beispiel entwickelt, um den Ablauf zurErzeugung von grafischen Oberflächen zu betrachten.

7

2. Untersuchung vorhandener Werkzeuge

2.1. JBuilder

Der JBuilder von Borland1 ist eine reine Java-Lösung, d.h. geschrieben in und fürJava. Es ist eine typische IDE mit vielen Funktionen. Sie wird sehr umfassenduntersucht. Neben der Erstellung grafischer Oberflächen wird auch der generierteCode, die Hilfe und die Oberfläche der IDE selbst ausführlich betrachtet.

Die untersuchte VersionJBuilder Xgibt es in den drei LizenzenEnterprise, De-Lizenz,

Verfügbarkeit veloperundFoundation. Seit Ende 2004 steht der neue JBuilder 2005 bereit, derdas neue J2SE 5.0 und J2EE 1.4 unterstützt. Die Foundation-Version ist kosten-los, mit ihr erstellte Software darf auch kommerziell vertrieben werden. Sie stehtebenso wie die kommerziellen Versionen für Windows, Linux, Solaris und Mac-OS zum Download bereit. Die Dateien sind je nach Version 50 bis 700 MiB groß.

Es handelt sich um eine sehr umfangreiche IDE mit vielen Features. Automati-Aufbau

sche Codevervollständigung und zahlreiche Wizards erleichtern die Entwicklung.Es können mehrere Projekte parallel bearbeitet werden. Insgesamt bietet dieseumfangreiche IDE wesentlich mehr Funktionen, als für Anfänger im Lehrbetriebgewünscht.

JBuilder bringt sehr viele fremde Bibliotheken mit, die verwaltet und eingebun-den werden können (Ant, Cactus, Castor, JDOM und drei Dutzend weitere). VonBorland selbst stammende Bibliotheken sind ebenfalls in der Liste der verfügba-ren Bibliotheken (dbSwing). Auch können an dieser Stelle eigene Bibliothekendefiniert und eingebunden werden. Man kann eine Bibliothek entweder für dasaktuelle Projekt oder allgemein definieren. Es lassen sich sowohl JAR-Dateienals auch Verzeichnisse mit class-Dateien einbinden.

2.1.1. Erlernbarkeit

Die Hilfe ist sehr umfangreich. Die Haupt-Anleitungen gibt es auch als PDF-Anleitungen

Dokument. Leider ist alles so übermäßig detailliert, dass große Teile unnötig sind.Lernen ist damit fast unmöglich, weil das Lesen der Anleitungen Wochen in An-spruch nähme. Mit knapperen Anleitungen wäre der Einstieg schneller und sinn-voller.Entwickler, die solch eine mächtige IDE nutzen, sind üblicherweise keine An-fänger. Als Referenz sind die Anleitungen aber untauglich. Gezielte Suche von

1http://www.borland.com/jbuilder/

8

http://www.borland.com/jbuilder/

2.1. JBuilder

Informationen fällt schwer, die Anleitungen sind mehr zum sequentiellen Lesengedacht. Selbst eine Einführung in Java ist in der Anleitung.

Viele fortgeschrittene Themen sind nicht in den Anleitungen enthalten. Währendauf tausenden von Seiten die einfachsten Sachverhalte ausführlichst erklärt wer-den, findet man zu interessanteren Problemen (damit sind nicht einmal komplexeProbleme gemeint, sondern profane Probleme fortgeschrittener Anfänger) kaumInformationen.

Die Gebrauchstauglichkeit ist nicht schlecht, aber doch verbesserungswürdig.Ergonomie

Wird eine bestimmte Einstellung gesucht, benötigt man meist relativ viel Zeit, umdas richtige Menü zu finden. Beispielweise ist es sehr schwierig herauszufinden,wie JBuilder denCLASSPATHdefiniert, mit dem die erstellte Software innerhalbJBuilders gestartet wird. Ansehen kann man sich denCLASSPATHin den Projekt-Einstellungen, dort ist er aber nicht änderbar. Dies geht nur über Umwege: inden Projekt-Eigenschaften kann man einstellen und nachsehen, welche Biblio-theken die Software benötigt. Diese und natürlich deren Abhängigkeiten werdenautomatisch in denCLASSPATHgeschrieben. UnterTools- Configure Libraries...kann man einstellen und nachsehen, welche Abhängigkeiten bestehen. Außerdemwerden alle mit einem normalen Java-SDK mitgelieferten Bibliotheken in denCLASSPATHeingefügt, was nicht verändert werden kann, beispielsweise

<JAVA-PATH>/demo/jfc/Java2D/Java2Demo.jar

Obwohl alle Einstellungen, die in Dialogen vorgenommen werden können, in derHilfe erklärt sind, ist trotzdem oft nicht eindeutig, was gemeint ist.

Seine Stärken offenbart JBuilder bei komplexen Projekten. So ist es im Projekt-Stärken

fenster, das in einer Baumstruktur aufgebaut ist, nicht nur möglich, Quelltext-Dateien zu öffnen, auch andere Arten von Dateien sind hier aufgeführt. Mankann gezielt Dateien in das Projekt einfügen und editieren (beispielsweise Bil-der, HTML- und XML-Dateien). Außerdem kann man für Dateitypen, aber auchfür einzelne Dateien, angeben, ob sie beim Kompilieren vom Quell- in das Ziel-verzeichnis kopiert werden sollen (so können für die Software benötigte Iconskopiert werden, während für Ant benötigte XML-Dateien nicht kopiert werdensollten). Diese Baumansicht kann zur Verdeutlichung der Beziehungen zwischenKomponenten für die gewünschte Software nützlich sein.

Auch ist die Möglichkeit, zu verschiedenen Zeitpunkten des Build-Vorgangs ver-schiedene Ant-Dateien auszuführen, komfortabel. Syntax-Highlighting für einigeNicht-Java-Dateien wird unterstützt. Die JavaDoc-Generierung kann, wie vieleandere Features, an die eigenen Wünsche angepasst werden. Für die gewünschte

9


Software sind diese Funktionen allerdings unnötig.

Vorlagen und Wizards erleichtern die Erstellung grafischer Komponenten. WirdWizards

beispielsweise ein neues Projekt erstellt, werden nacheinander Wizards für dieProjekteigenschaften, für die Starter-Klasse2 und die Frame-Klasse3 gestartet.Beim Wizard der Frame-Klasse können gleich einige die GUI beeinflussende Ein-stellungen gemacht werden (Abb.2.1).

Abbildung 2.1.:JBuilder - Frame class wizard

JBuilder bietet viele Funktionen und Einstellungsmöglichkeiten, ist aber dement-Fazit

sprechend sehr komplex. Die Anleitungen sollten komplett überarbeitet werden.Wizards unterstützen bei der Erstellung von Projekten oder Klassen.

2.1.2. Benutzeroberfläche

Die GUI ist, wie in Abb.2.2gezeigt, recht übersichtlich. Es gibt folgende Berei-che:

Das Projektfenster erlaubt das Hinzufügen und Entfernen von Paketen, Java- undProjekt

Nicht-Java-Dateien. Problematisch sind manchmal Aktualisierung und Bedienung4,

2Die Klasse, welche die main-Methode enthält.3Die Haupt-Oberflächen-Klasse, die JFrame erweitert.4Wird beispielsweise der Quellcode einer Klasse dahingehend geändert, dass sich die Klasse in einem ande-ren Paket befinden soll, bleibt sie im Projektfenster im alten Paket. Man muss sie dort manuell verschieben.

10

2.1. JBuilder

Abbildung 2.2.:JBuilder - GUI mit den FensternProjekt undStrukturund demEditor-Teil auf der rechten Seite

11


insgesamt ist das Projektfenster aber bedienbar. Für Nicht-Java-Dateien lassensich hier Einstellungen je nach Dateityp vornehmen (wie oben bereits erwähntz.B. ob die Datei beim Build-Vorgang kopiert werden soll). Es gibt eigene Kno-ten für Doclets, die Erstellung vonNative Executables, Ant-Dateien etc., wobeiauch hier spezielle Einstellungen vorgenommen werden können.

Dieses Fenster bietet als zweites Register noch einen Explorer-ähnlichenFileBrowser, der ähnlich einem Dateimanager die benutzten Dateien anzeigt. Dieserbietet keine besonderen Funktionen.

Das Strukturfenster gibt Auskunft über Attribute, Operationen undNested Clas-Struktur

ses(Innere Klassen) einer Klasse. Die Icons geben leicht verständlich Auskunftüber den Typ eines Eintrags und gegebenenfalls vorhandene Modifikatoren.

Hervorzuheben sind einige spezielle Funktionen des Strukturfensters:

• Es werden JavaDoc-Konflikte angezeigt.Beispiel: ein@param-Eintrag in der Beschreibung einer Operation fehlt.

• Es wird getrennt angezeigt, welche Klassen importiert werden und ob sichdiese innerhalb der entwickelten Software befinden oder nicht.

• Alle im JavaDoc-Stil gekennzeichneten unfertigen Stellen im Quellcodewerden angezeigt.Beispiel: / ** @todo Listener hinzufügen * / im Quelltext führt zumEintragListener hinzufügenin der Liste.

Bei Auswahl eines Eintrags mit der Maus springt der Codeeditor zur entspre-chenden Stelle im Quelltext. Natürlich gibt es weitere Funktionen wie Sortier-reihenfolgen und Filter. So können Operationen beispielsweise nach Sichtbarkeitgefiltert werden.

Das Nachrichtenfenster befindet sich im Programmfenster ganz unten. Es zeigtMessages

Nachrichten während des Build-Vorgangs, während der Ausführung (entsprichtdann praktisch der Kommandozeile) und während des Designs an. Hier werdenbeispielsweise auch Suchergebnisse angezeigt.

Das Editorfenster nimmt den großen Teil des Programmfensters ein. Es verfügtEditor

oben und unten über Registerreiter. Oben sind die Dateinamen der geöffneten Da-teien aufgeführt, und ob die Dateien nach dem letzten Speichern verändert wur-den. Unterhalb des Editorfensters zeigt sich die Funktionsvielfalt des JBuilders.Hier gibt es bei Java-Quelltexten gleich mehrere Registerreiter, die dem Entwick-ler diverse Möglichkeiten geben, die geöffnete Datei zu untersuchen oder zu än-dern. Je nach geöffneter Datei sind die folgenden RegisterreiterSource, Design,

12

2.1. JBuilder

Bean, UML, DocundHistoryverfügbar.

Der Quelltexteditor bietet alle gängigen Features wie Syntax-Highlighting undSource

Vervollständigung von Attribut- und Operationsnamen. Ein Drücken der Tabulator-Taste richtet die aktuelle(n) Zeile(n) nach einem automatischen Codelayout aus,das man in den Optionen festlegen kann. Verschiedene Abschnitte einer Datei(Klassen, Importe, Operationen etc.) können zu- und aufgeklappt werden, um dieDatei übersichtlicher zu machen. Leider sind beim nächsten Start wieder alle Ab-schnitte aufgeklappt.

Der RegisterreiterDesignführt zum im nächsten Abschnitt beschriebenen GUI-Design

Designer.

Auf dem RegisterBeankönnen Bean-Eigenschaften angezeigt und teilweise ein-Bean

gestellt werden. Beispielsweise kann angegeben werden, ob die Klasse Serialisie-rung unterstützt. Auf weiteren Registerreitern lassen sich

• allePropertiesanzeigen und derenGetterundSetter(de)aktivieren,

• BeanInfo-Klassen erzeugen und Icons festlegen,

• Eventsfestlegen oder erstellen, die gefeuert oder auf die gehört werden soll,

• Property Editorsfestlegen und erstellen.

Auf dem RegisterUML wird eine Art Klassendiagramm der Klasse mit ihrenUML

Abhängigkeiten angezeigt. Einträge können umbenannt werden. Ein Doppelklickauf einen Eintrag führt zur entsprechenden Stelle im Quelltext. Wie in Abb.2.3ersichtlich, werden alle eingehenden und ausgehenden Verbindungen angezeigt5.Das Diagramm kann in einige Grafikformate exportiert werden. Das Erstellen vonneuen Klassen o.ä. ist nicht möglich6. Diese komplexe Funktionalität ist für diegewünschte Software unnötig, vor allem, wenn eine Baumansicht umgesetzt wird(s.o.).

Auf dem RegisterDoc kann man sich in einem einfachen Browserfenster eineDoc

Vorschau der von dieser Klasse generierten JavaDoc-Dateien anzeigen lassen.

Mit Hilfe des RegistersHistory werden die Backups älterer Dateiversionen ver-History

waltet. In einem Unterfenster kann man sich den Quelltext einer ausgewählten

5Das Diagramm zeigt übrigens eine Klasse der in späteren Kapiteln besprochenen Software, für dessenEntwicklung JBuilder benutzt wurde. Die UML-Fähigkeiten sind allerdings zu beschränkt, als dass sie fürdiese Projektarbeit weiter benutzt wurden.

6Ebenfalls von Borland gibt es das ProduktTogether, das gut mit dem JBuilder zusammenarbeitet und einekomfortablere Arbeit mit UML-Diagrammen erlaubt.

13


Abbildung 2.3.:JBuilder - Reiter UML

älteren Dateiversion ansehen. Man muss recht umständlich in einem kleinen Fens-ter scrollen, um eine gesuchte Stelle im Quelltext zu finden. Vergleichsfunktionengibt es leider nicht.

2.1.3. Ablauf und Beispiel

Wenn ein neues Projekt oder eine neue Klasse erstellt werden soll, kann dieObjectObject Gallery

Gallery benötigte Dateien und Code erstellen. Abb.2.4 zeigt einige oft benutzteObjekte der Object Gallery.

Abbildung 2.4.:JBuilder - Object Gallery

14

2.1. JBuilder

Vor Erstellung der ersten Klasse wird ein neues Projekt aus dem BereichPro-ject gewählt, da JBuilder nur dann Projektdateien erstellt, die das Arbeiten mitzusammengehörigen Dateien erleichtert. Abb.2.5zeigt beispielhaft Schritt 2 desProjekt-Wizards.

Abbildung 2.5.:JBuilder - Project Wizard Schritt 2

Beim zweiten Aufruf der Object Gallery wird die VorlageApplicationgewählt,deren Wizard Starterklasse, Fensterklasse und deren Code erstellt. Der Applica-tion Wizard erstellt in Schritt 1 eine Starterklasse, Abb.2.6 zeigt den zweitenSchritt des Application Wizard, in dem eine Fensterklasse erstellt wird. Es gibteinige Optionen, die zur automatischen Generierung von Code für bestimmte Tei-le des Fensters führen (beispielsweise eineJMenuBar ).

Nach Ausführen von Projekt- und Anwendungs-Wizard zeigt der JBuilder dieim letzten Abschnitt beschriebenen Projekt-, Struktur- und ein Codefenster an,in dem die Fensterklasse angezeigt wird. Wie in Abschnitt2.1.5erläutert ist dasCodelayout des von den Wizards generierten Codes mangelhaft. Abb.2.2 aufSeite11zeigt den (manuell überarbeiteten) generierten Code der Fensterklasse.

Die Auswahl an Vorlagen und Wizards ist für umfangreiche Projekte hilfreich.Bewertung

Für die einfache und schnelle Erstellung eines Fensters sind jedoch zu viele Schrit-te und Aufrufe nötig, außerdem ist die Auswahl für Anfänger zu groß.

15


Abbildung 2.6.:JBuilder - Application Wizard Schritt 2

2.1.4. Design grafischer Benutzeroberflächen

Nach Auswahl des RegisterreitersDesign(unterhalb des Editor-Fensters) zeigtdas Strukturfenster eine Baumansicht der Komponenten. Das Entwurfsfensterzeigt das Fenster, verfügbare Komponenten und die Eigenschaften des Fensters.Nach Klick auf eine Komponente kann man den Bereich im Fenster aufziehen, inden die Komponente eingefügt werden soll. Da standardmäßig jedoch einBorder-

Layout für das Fenster ausgewählt ist und Komponenten abhängig vom Lay-out eingefügt werden, erscheint die Komponente nicht im gewählten Bereich.Abb. 2.7 (Seite17) zeigt das Fenster nach Einfügen eines erstenJButton , dervon JBuilder inBorderLayout.NORTH eingefügt wurde. Außerdem wurde nachBorderLayout.CENTER ein JPanel eingefügt, dessen Layout aufnull gesetztwurde. Darin wurde ein weitererJButton eingefügt.

Das spätere Ausschneiden, Kopieren und Einfügen von vorhandenen Komponen-Bearbeitung

ten funktioniert nicht immer wie gewünscht. Wie später in5.4 erläutert, lassensich Swing-Komponenten anderen Swing-Komponenten hinzufügen. Dies funk-tioniert beim JBuilder aber auch dann nicht zuverlässig, wenn eine Komponentein den oben eingefügtenJPanel hinzugefügt werden soll. Änderungen am Quell-code können Fehler im Designfenster hervorrufen. Wenn das Kopieren und Ein-fügen im Designfenster nicht funktioniert, dann funktioniert es auch im Struk-turfenster nicht. Einmal zur Codeansicht und wieder zurück gewechselt, entdecktman die hinzugefügten Komponenten im Strukturfenster außerhalb des content-

16

2.1. JBuilder

Abbildung 2.7.:JBuilder - Programmfenster mit Designer

17


Pane.

Wird eine Komponente kopiert und per Menü wieder eingefügt, liegt die Kopiegenau über dem Original7 und ist daher im Designfenster nicht zu erkennen.

Die dynamische Erstellung grafischer Komponenten überfordert den Designer.Arrays

Erstellt man im Quellcode beispielsweise ein Array vonJButtons , werden die-se im Designer nicht richtig angezeigt und sind nicht oder nur unzureichend zubearbeiten.

JBuilder nutzt die voreingestellten Layouts für Komponenten, was für AnfängerBewertung

ungeeignet ist. Selbst nach Setzen des Layouts aufnull ist ein ergonomischesArbeiten nicht möglich, da Komponenten nicht bündig ausgerichtet werden kön-nen. Für das vorgesehene Szenario müssen die beiden gewünschten Schaltflächenmanuell ausgerichtet werden, indem Position und Größe imProperty Editorein-gegeben werden.

2.1.5. Erzeugter Code und Dateiformat

Der erzeugte Code ist lesbar und brauchbar. In GUI-Klassen ruft der KonstruktorGUI

die OperationjbInit() auf, in der alle die GUI betreffenden Operationen aufge-rufen werden. LayoutManager werden nicht anonym erzeugt. Abb.2.8zeigt dengesamten Code des oben erstellten Fensters, hier sieht man auch, dass erzeugterCode sich nicht immer an das Codelayout hält.

Im Frame werden für jeden nur erdenklichenActionEvent JBuilder-spezifischeEvents

ActionAdapter-Klassen eingefügt. Bei Dialogen ist dagegen derActionListe-

ner implementiert; der Sinn dieses Unterschieds wird nicht klar. Gerade bei ei-nem Frame ist es übertrieben, für jeden Event einen Adapter bereitzustellen. Dieautomatische Erstellung von Listener-Methoden bzw. Adaptern bei der späterenÄnderung im Designer lässt zu wünschen übrig. Besser wäre, beim Entwicklernachzufragen, wie verfahren werden soll.

Unergonomisch ist allerdings die Codegenerierung durch die Wizards, da JBuil-der sich dort nicht an die Vorgaben hält, die in den Optionen eingestellt werdenkönnen. Der Code hält sich weder an dieCode Conventions for the Java Pro-gramming Language[Hom99], noch an das selbst eingestellte Codelayout. DerWizard beim Erstellen eines neuen Projekts erstellt anderen Code als spätere Wi-zards oder der Design-Modus. Auch werden keine JavaDoc-Kommentare gene-riert. Der anfangs erzeugte Code ist also erst einmal sehr überarbeitungswürdig.

7Dies gilt beim Null-Layout und bei anderen Layouts in verschiedenen Situationen.

18

2.1. JBuilder

Abbildung 2.8.:JBuilder - Erzeugter Code

19


Beans werden wie normale Java-Dateien behandelt und können als solche nurDateiformat

als Java-Dateien gespeichert werden. JBuilder hat natürlich als vollständige IDEauch Möglichkeiten, einzelne Klassen oder das gesamte Projekt zu kompilierenund zu debuggen.

2.1.6. Fazit

JBuilder ist sehr mächtig, weshalb er auch für die Entwicklung der Software be-nutzt wurde. Für professionelle Entwickler ist JBuilder gut geeignet, für Anfän-ger ist er viel zu komplex. Die Lade- und Deployment-Geschwindigkeit ist mit-telmäßig bis langsam, die Arbeitsgeschwindigkeit aber in Ordnung. Der erzeugteQuellcode ist überarbeitungswürdig. Es können nur Java-Dateien erzeugt werden,die aber von anderen Applikationen geöffnet werden können.

Die Oberfläche wirkt voll, aber benutzbar. Die Werkzeugfenster sind relativ gutOberfläche

erreichbar, die verschiedenen Registerreiter am Hauptfenster sind für Anfängerungeeignet, nach kurzer Einarbeitungszeit aber akzeptabel. Die Wizards sind hilf-reich, aber zu komplex. Der von ihnen erzeugte Code ist unzureichend. Die Aus-wahl an verfügbaren Klassen und Typen in derObject Galleryist für Anfängerverwirrend groß. Die Hilfe ist nicht konkret genug.

Der Entwurfsmodus besitzt viele Schwächen, Kopieren und Einfügen zeigen jeEntwurf

nachLayoutManager fehlerhaftes Verhalten. Es werden die voreingestellten Lay-outs für Komponenten genutzt, nach Setzen des Layouts aufnull können Kom-ponenten nur bündig ausgerichtet werden, indem Position und Größe manuell imProperty Editoreingegeben werden.

20

2.2. Eclipse

2.2. Eclipse

Das ursprünglich von IBM entwickelte Eclipse ist Open Source. Einige Teile undZusatzfeatures, wie das Language Pack zur Internationalisierung der IDE, wer-den weiterhin von IBM zur Verfügung gestellt. Neben der Erstellung grafischerOberflächen werden auch Herkunft und besondere Funktionen erläutert. Für denEntwurfsmodus wurde ein Plug-In installiert, dessen Oberfläche und generierterCode betrachtet wird.

eclipse.org ist die Quelle für wesentlich mehr als nur eine IDE. Es gibt folgendeHerkunft

Projekte:

• DasEclipse Projectentwickelt die IDE und stellt eine Sammlung von Bi-bliotheken zur Anwendungsentwicklung zur Verfügung.

• DasEclipse Tools Projecthilft Entwicklern von Tools für die Eclipse Plat-form.

• DasEclipse Technology Projectkümmert sich u.a. um Forschung und umdie Erstellung von Dokumentation und Lernhilfen.

• DasEclipse Web Tools Platform Projectstellt eine Platform für J2EE-Appli-kationen zur Verfügung.

• DasEclipse Test and Performance Tools Platform Projectstellt eine Samm-lung von Bibliotheken für Tools zur Verfügung, mit der Test und Perfor-mance Tools erstellt werden können.

• DasBusiness Intelligence and Reporting Tools (BIRT) Projectstellt Toolsund Frameworks bereit, mit denen eigene Applikationen mit Reporting-Fähigkeiten ausgestattet werden können.

Das Eclipse Project stellt dasEclipse SDKzur Verfügung, welches wiederrum ausPlatform (Integration von Ant, CVS, etc.; Hilfesystem; Editor; SWT8), JDT9 undPDE10 besteht. Im Weiteren wird nur auf das Eclipse Platform SDK eingegangen.

Eclipse ist unter Entwicklern relativ beliebt. Das IDE ist nicht so mächtig wieeinige kommerzielle Konkurrenten, aber erweiterbar und Open Source. Durchden Einsatz der zahlreich vorhandenen Plug-Ins lässt sich Eclipse zu einer sehrmächtigen IDE ausbauen.

8DasStandard Widgets Toolkitist ein grafisches Toolkit, welches für eigene Applikationen genutzt werdenkann.

9Java development tools, das sind IDE und Debug Tools10Plug-in development environment

21


Vom Eclipse Project entwickelte Software steht unter derCommon Public Licen-Lizenz

se11. Von Drittanbietern in die Platform eingebrachte Teile stehen unter verschie-denen Lizenzen.

Im Gegensatz zu beispielsweise JBuilder gibt es keine verschiedenen VersionenVerfügbarkeit

mit unterschiedlichem Funktionsumfang. Für Version 3 gibt es drei verschiede-ne Builds: für Motif unter Linux (x86), Solaris (SPARC), AIX (PPC), HP-UX(HP9000), für Windows 98/Me/2000/XP und für Linux (x86/GTK 2).

Eclipse ist eine umfangreiche IDE mit großem Funktionsumfang. Es ist ohne Er-Funktionen

weiterungen bei weitem nicht so mächtig wie Borlands JBuilder, bietet aber docheinige Funktionen wie das Erstellen vonGetternundSetternfür die Eigenschaf-ten einer Bean. Hilfreich ist die Möglichkeit, bei einem Fehler direkt unter eini-gen Lösungsvorschlägen suchen zu können. Beispielsweise führt ein Klick aufeinenimport -Fehler zu den MöglichkeitenBibliothek zum CLASSPATH hinzufü-genundBibliothek in das Anwendungs-Verzeichnis kopieren, falls Eclipse erkannthat, dass es das zu importierende Paket gibt, es aber momentan von der Anwen-dung nicht erreichbar ist. Damit dies möglich ist, muss Eclipse natürlich wissen,dass es das Paket überhaupt gibt. Dazu muss es importiert werden, was uns zumThema Import und Plug-Ins führt. Das Paketorg.eclipse.swt beispielsweisekann durch Einbinden eines Plug-Ins installiert werden. Die Plug-Ins werden inXML-Dateien definiert, die eigentliche Bibliothek befindet sich üblicherweise ineiner JAR-Datei. Im SDK sind zahlreiche Plug-Ins mitgeliefert.

Wenn im Editor eine Klasse importiert werden soll, zeigt Eclipse nicht nur verfüg-bare Unterpakete und Klassen, sondern, wie Abb.2.9zeigt, auch Beschreibungender Klassen.

Abbildung 2.9.:Eclipse - Import

Das hier erwähnteStandard Widgets Toolkitbietet einige GUI-Komponenten und11http://www.eclipse.org/legal/

22

http://www.eclipse.org/legal/

2.2. Eclipse

-Tools, die das Erstellen grafischer Benutzeroberflächen erleichtern sollen.


Es gibt zwar einenProject Wizardund einenClass Wizard, aber keinenApplicati-on oderFrame Wizardwie beim JBuilder. Eine Entsprechung derObject Galleryist also nicht vorhanden.

Der Project Wizard wirkt aufgeräumt. Einbezogene Pakete werden angezeigt, wieProject Wizard

in Abb. 2.10zu sehen.

Abbildung 2.10.:Eclipse - Project Wizard

Der Wizard zum Erstellen einer neuen Klasse wirkt ebenfalls aufgeräumt undNeue Klasse

bietet einige Hilfen; diese sind jedoch teilweise nicht so benutzbar wie es wün-schenswert wäre. Abb.2.11zeigt den Wizard in der Ausgangsstellung. Für dasfolgende Beispiel wurde einemain -Methode hinzugefügt,javax.swing.JFrame

als Superklasse gewählt.

Die main-Methode bleibt leer, der Wizard erstellt nur den nötigsten Programm-

23


Abbildung 2.11.:Eclipse - Class Wizard

rumpf. Ein unnötiger kommentierter Hinweis auf mögliche Einstellungen zumCodelayout erscheint doppelt im Quelltext. Viele Möglichkeiten kommerziellerKonkurrenten fehlen, dafür ist der Codeeditor gut gelungen, beispielsweise deroben erwähnten Unterstützung wegen.

Die Wizards wirken aufgeräumt und hilfreich. Das Ergebnis desClass WizardBewertung

ist sehr spärlich, die Benutzung des Wizard erspart nicht viel Zeit. Zur schnellenEntwicklung eines Fensters ist kein Wizard vorhanden.


Ein Entwurfsmodus ist im Standardpaket nicht enthalten. Es gibt aber zahlreicheWindowBuilder

Plug-Ins für Eclipse, von denen eines einen Entwurfsmodus hinzufügt. Betrachtetwird der kommerzielleWindowBuilder12 in der Free Version, da eine der An-forderungen war, dass für den Lehrbetrieb keine zusätzlichen Mittel ausgegeben

12http://www.windowbuilderpro.com/

24

http://www.windowbuilderpro.com/

2.2. Eclipse

werden sollen.

Die freie Version kann nurJFrame s erzeugen, was für unsere Belange ausrei-chend ist. Auch für die freie Version ist leider eine Registrierung notwendig, beider viele Informationen übertragen werden. Das Plug-In benutzt leider nicht denEclipse Install and Update Manager, weshalb der WindowBuilder manuell instal-liert werden muss, was zu Problemen führen kann, auf welche auf der Webseitedes Herstellers aber eingegangen wird.

Das Plug-In installiert einen zusätzlichen Quelltexteditor, der einen zweiten Re-gisterreiter für den Designer besitzt. Zunächst fällt negativ auf, dass eine hoheAuflösung notwendig ist, um mit dem Designer arbeiten zu können, wie in Abb.2.12zu erkennen.

Abbildung 2.12.:Eclipse - WindowBuilder bei niedriger Auflösung

Die Handhabung ist recht umständlich, allerdings bietet der WindowBuilder ei-Einfügen von

Komponentennige Annehmlichkeiten, die bei anderen Lösungen fehlen. So werden, abhängigvom für einen Container gewähltenLayoutManager , Hilfestellungen zum Einfü-gen von Komponenten gegeben. Abb.2.13zeigt das Hinzufügen zumcontent-

Pane, der einBorderLayout besitzt. Der obere Bereich ist farblich anders mar-kiert, da er bereits durch einenJButton belegt ist, der mittlere Bereich ist grau,da die Komponente hier eingefügt würde.

Abb. 2.14zeigt das Einfügen einer Komponente in ein NullLayout. Die genaueEinfügeposition ist durch Koordinaten und farblich gekennzeichnet. Außerdem

25


Abbildung 2.13.:WindowBuilder - Hinzufügen einer Komponente in dencontentPane

mit BorderLayout

wird ein Raster angezeigt, das die Ausrichtung erleichtert. Leider kann nicht au-tomatisch am Raster ausgerichtet werden, aber die in der Abb. zu sehende Markie-rung und das Raster werden wieder angezeigt, wenn eine Komponente mit Drag& Drop verschoben wird.

Abbildung 2.14.:WindowBuilder - Hinzufügen einer Komponente in einen JPanel mitNullLayout

Das Ausrichten einer zweiten Schaltfläche fällt also nicht viel leichter als bei denBewertung

bisher betrachteten Lösungen, da zwar ein Raster angezeigt, dieses aber nicht zurAusrichtung genutzt wird.

2.2.3. Erzeugter Code und Dateiformat

Beim erzeugten Code fällt auf, dass weder Events verarbeitet, noch dieJava CodeConventions[Hom99] eingehalten werden. Außerdem werden alle Komponentenals final deklariert, was nicht üblich ist.

Abb. 2.15zeigt einen Auschnitt aus dem erzeugten Code.

26

2.2. Eclipse

Abbildung 2.15.:WindowBuilder - Erzeugter Code

2.2.4. Fazit

Eclipse ist frei verfügbar und wird nicht installiert, sondern kann als Java-Anwen-dung direkt ausgeführt werden. Die Webseite ist unübersichtlich. Die Auswahl,welche Datei heruntergeladen werden muss, ist schwierig. Die Ladezeit ist hoch,die Wahl der Arbeitsumgebung beim Start ist für Anfänger ungeeignet; die Ar-beitsgeschwindigkeit ist akzeptabel. Der erzeugte Code ist absolut mangelhaft,durch andere Applikationen aber verarbeitbar.

Die Oberfläche wirkt ohne WindowBuilder voll, aber aufgeräumt. Mit Window-Oberfläche

Builder ist der Bedarf an Platz inakzeptabel, die Oberfläche wirkt nicht mehr ein-heitlich. Es werden hohe Anforderungen an die Auflösung des Monitors gestellt.Es sind nur wenige Wizards vorhanden, diese erzeugen nur wenig Code, der aberbrauchbar ist.

WindowBuilder ist kompliziert in der Bedienung, die Hilfen beim Einfügen undEntwurf

Manipulieren von Komponenten sind aber angenehm. Die Registrierung ist stö-rend. Raster und Größenvorschau sind hilfreich, eine Ausrichtung wird aber nichtgeboten. Der von WindowBuilder erzeugte Code ist mangelhaft.

27


2.3. Visaj

Visaj ist ein Produkt der FirmaImperial Software Technology(IST)13, dem nacheigenen Angaben„world leader in software engineering tools used to constructgraphical user interfaces for application software running on high-performanceworkstations“. Zielmarkt sind also nicht Privatkunden und Kleinunternehmer, diekleine PC-Anwendungen entwickeln, sondern Firmenkunden. Beste Referenz istLockhead Martin14.

Visaj setzt tiefgehende Kenntnisse in Java voraus, was den Gebrauch in Lehr-veranstaltungen für Studienanfänger verbietet. Des interessanten Konzepts we-gen wird die Erschaffung einer Bean ausführlich anhand des Tutorials aufgezeigt,statt das in Kap.1 angegebene Szenario durchzuführen. Abschließend wird dergenerierte Code geprüft.

IST wurde 1982 von Abgängern desImperial College of Science, Technology andUrsprung

Medicinein London15 gegründet.„Today the company is emerging as a leader insoftware engineering for the Intranet and Internet“. Weiter:„A strategic alliancebetween IST and Sun Microsystems, Inc., enables Sun to integrate IST solutionsinto its product offerings and provides IST with in-depth knowledge of the Javacore technology and direction“16.

Das Konzept von Visaj ist einzigartig, denn es beinhaltet keinen GUI-Designer,Konzept

wie man es von anderen Produkten gewohnt ist. Stattdessen arbeitet man die meis-te Zeit im Class Editor, der eine hierarchische Übersicht über alle verwendetenKlassen bietet. Im Class Editor kann man recht schnell GUI-Prototypen erstel-len, vorausgesetzt man kennt sich so weit mit Java aus, dass man weiß, welcheKomponente in welchem Container platziert werden sollte.

Weiterhin gibt es einenEvent Editor, einenResource Bundle Editorzur Interna-tionalisierung, einenDiamond JavaBeans Layout Editorinklusive absoluter Po-sitionierung und einenAdvanced Image Editor.

Die Preise um 1000 US-Dollar machen gleich deutlich, dass offensichtlich nurLizenz

Firmen die Zielgruppe bilden.

13http://www.ist.co.uk/14http://www.pacist.com/CUSTOMER/STORIES/lockheed_Story.html15http://www.imperial.ac.uk/16http://www.ist.co.uk/visaj/

28

http://www.ist.co.uk/

http://www.pacist.com/CUSTOMER/STORIES/lockheed_Story.html

http://www.imperial.ac.uk/

http://www.ist.co.uk/visaj/

2.3. Visaj


Der mitgelieferte User Guide (PDF) beinhaltet gleich zu Anfang ein Tutorial.Dieses ist didaktisch schlecht aufgebaut: Es wird weder ein Gesamtüberblick ge-geben, noch ist die Reihenfolge überall sinnvoll. Halbwegs positiv ist, dass eineVorschau auf das erzeugte Fenster sofort erstellt und fortlaufend aktualisiert wird.

Als erstes wird die Dateidemos.jar über das MenüPaletteeingefügt; dadurch Building the

Hierarchystehen in der Palette desClass Editors zwei weitere Komponenten zur Verfü-gung, die aber erst später benötigt werden. Danach wird einJFrame und darineineJMenuBar hinzugefügt, woraufhin der Sinn des in Abb.2.16gezeigtenClassEditors deutlicher wird.

Abbildung 2.16.:Visaj Tutorial - Class Editor

Der JFrame ist jetzt offensichtlich Container derJMenuBar , die wiederrum einContainer und daher markiert ist. Nachdem derJMenuBar ein JMenu hinzu-gefügt wurde, zeigt sich eine interessante Eigenschaft von Visaj: DemJMenu

werden zweiJMenuItem s hinzugefügt, wobei dasJMenu markiert bleibt, da dieJMenuItem s keine Container sind, siehe Abb.2.17.

Abbildung 2.17.:Visaj Tutorial - Container

Wenn eine Komponente durch einen Klick in die Palette hinzugefügt wird, dannbekommt sie immer die gerade markierte Komponente alsContainer . In der Pa-lette sind nur diejenigen Komponenten anklickbar, welche die gerade markierteKomponente alsContainer besitzen können.

29


Die nächsten Schritte des Tutorials beschreiben das Einfügen einerJToolBar mitdreiJButton s und einemJEditorPane mit Scrollbars. Dabei ist dieJScrollPane

markiert, da der als letztes hinzugefügteJEditorPane kein Container ist. Nacheinigen weiteren JFC-Komponenten wird schließlich noch eine unsichtbareBeaneingefügt, welche in derdemos.jar enthalten war und daher in der Palette ganzunten zu finden ist. Damit ist der erste Teil des Tutorials beendet.

In Abb.2.18sind derClass Editorund die dazugehörige Vorschau, wie der erstell-te JFrame aussehen wird, dargestellt. Schließlich wird der Zwischenstand nochunter dem Namentutorial.vcl gespeichert.

Abbildung 2.18.:Visaj Tutorial - Schlussbild Building the Hierarchy

Nach einem Doppelklick aufJMenu1 wird dessen in Abb.2.19gezeigterPropertySetting Properties

Sheetgeöffnet.

Die PropertiesdesJMenu1 sind in Gruppen sortiert, innerhalb einer Gruppe al-phabetisch. Die Gruppen entsprechen der aufsteigenden Vererbungsstruktur. Inder unteren Hälfte desProperty Sheets können die Eigenschaften verändert wer-den. Die Größe desProperty Sheets ist änderbar.

Aus der Gruppejavax.swing.AbstractButton wird nun die Eigenschafttext

gewählt. Im unteren Teil des in Abb.2.20 gezeigtenProperty Sheets kann nunder Text vonJMenu1aufFile geändert werden. Um die Änderungen zu überneh-men, muss man die Enter-Taste drücken, ein DruckknopfÜbernehmenist nichtvorgesehen.

Wenn man jetzt nacheinander einen Doppelklick aufJMenuItem1 und JMenu-

Item2 durchführt, springt derProperty Sheetdirekt zu derentext -Eigenschaften.Die Beschriftungen werden inOpenundExit geändert. Der gesamteJFrame sieht

30

2.3. Visaj

Abbildung 2.19.:Visaj Tutorial - Property Sheet

jetzt wie in Abb. 2.21 aus. Daraufhin werden im Class Editor gleich mehrereKomponenten markiert.

Die Eigenschafticon aus der Gruppejavax.swing.AbstractButton wird aus- Pfade

gewählt. Hier können zwei verschiedene Dateien angegeben werden. Die Eigen-schaftDesign-time filelegt fest, was während der Entwicklung mit Visaj ange-zeigt wird. ErstRuntime resource pathlegt den Pfad zu dem Icon fest, das zurLaufzeit angezeigt wird. Hier wird im Tutorial nicht wirklich klar, welche Pfadeangegeben werden müssen. Es soll für beide Eigenschaften das selbe Icon gewähltwerden, fürDesign-time fileallerdings mit dem kompletten absoluten Pfad vomWurzelverzeichnis aus gesehen, derRuntime resource pathaber in einem anderenVerzeichnis. An dieser Stelle wird nicht klar, wasRuntime resource pathbewirkt,ob das Icon einkompiliert wird etc. Immerhin wird für weitere Informationen aufeine andere Stelle imUser Guideverwiesen.

Da die drei Druckknöpfe nur Icons, aber keinen Text beinhalten sollen, wird jetztnoch dietext -Eigenschaft geleert. Die Größe desJEditorPane1 wird noch auf500 mal 500 Pixel geändert (EigenschaftpreferredSize in der GruppeJEdi-

torPane ). Die Beschriftung der beiden verbliebenen Druckknöpfe wird noch inStartundStopgeändert, die Beschriftung desJLabel1 in File to display:. Schließ-lich wird die Eigenschafttitle desJFrame1 noch aufVisaj Viewergeändert.

Die Beschriftungen der Komponenten sind imClass Editornicht sichtbar, ledig-lich die Variablennamen. Um den Variablennamen zu ändern, kann man imClassEditor einfach darauf klicken. Nach einigen Namensänderungen sieht derClass

31


Abbildung 2.20.:Visaj Tutorial - Property Sheet Text

Abbildung 2.21.:Visaj Tutorial - JMenu

Editor wie in Abb.2.22dargestellt aus.

Abbildung 2.22.:Visaj Tutorial - Variablennamen

Leider entsprechen die Empfehlungen für die Benennungen von Bezeichnernnicht den von den Java-Entwicklern vorgeschlagenen Konventionen [Hom99].Beispielsweise wirdJButton4 in das C-typischestart_button umbenannt, stattin startButton . Auch die von Visaj vergebenen Standardbezeichner entsprechennicht dem bei Java üblichencamelCasing, da sie mit einem Großbuchstaben an-fangen.

32

2.3. Visaj

Zum Schluss des zweiten Tutorial-Abschnitts werden jetzt noch die Eigenschaf-ten desticker1 geändert. Die Eigenschaftpause wird auf 2000 (wahrscheinlichMillisekunden) eingestellt. Als zweites wird die Eigenschaftlimit gewählt. Neuvorgestellt wird jetzt die Möglichkeit, im unteren Teil desProperty SheetstattValueden EintragPropertyaus der Optionsliste zu wählen. Daraufhin kann man,wie in Abb. 2.23gezeigt, aus einer Baumstruktur alle Eigenschaften aller Kom-ponenten desClass Editorwählen. Wenn man die EigenschaftitemCount derJComboBox wählt, entspricht jetzt der Wert derlimit -Eigenschaft desticker1

genau dem Wert deritemCount -Eigenschaft derJComboBox. Wenn die eine ge-ändert wird, ändert sich auch die andere. Momentan gibt es noch keine Einträgein derJComboBox, sodass beide Werte0 sind.

Abbildung 2.23.:Visaj Tutorial - Property Tree

Nachdem jetzt noch die Eigenschaftwrap auf True gesetzt wird, ist der zweiteTeil des Tutorials beendet. Diese letzte Eigenschaft bewirkt einen Neubeginn derTick-Zählung bei0, wenn der Wert der Eigenschaftlimit erreicht wird.

Einige Komponenten haben zusätzlich zumProperty SheeteinenCustomizer, um Using the

Customizerzusätzliche Nicht-Standard-Eigenschaften festlegen zu können. Zur Demonstra-tion wird die JComboBox1 ausgewählt. Dann muss im MenüObjectder Eintrag

33


Customize...gewählt werden, woraufhin ein neues Fenster erscheint. Leider istdieses Fenster nicht über das Kontextmenü der Komponente erreichbar.

Danach sollen vier html-Dateien hinzugefügt werden, was sich als relativ aufwän-dig herausstellt. Seltsam auch das Formatfile:/pfad/datei.html , das einemURL entsprechen soll, wie in Abb.2.24dargestellt.

Abbildung 2.24.:Visaj Tutorial - Customizing Eingabe

Nach dem Schließen entspricht die Vorschau nicht mehr dem, was man erwartet.Wie das Tutorial verrät, bringt es Abhilfe, denJFrame1 zu markieren und an-schließend im Kontextmenü aufResetzu klicken. Die Vorschau wird daraufhinkomplett neu und korrekt aufgebaut.

Das Tutorial umfasst die dreiLayoutManager BorderLayout , GridBagLayoutLayoutManager

undFlowLayout . Dabei wird nur von „Layouts“ gesprochen, nicht von „Layout-Managern“. Es wird erklärt, dass jeder Frame standardmäßig einBorderLayout

besitzt, welches eine Positionierung der Komponenten in den fünf BereichenNorth , South , East , West oderCentral erlaubt.

DerLayout Editorwird gestartet, indem derJFrame1 markiert wird und anschlie-ßend der Druckknopf für denLayout Editor in der Toolbar gedrückt wird. DerLayout Editoröffnet sich im in Abb.2.25gezeigten Fenster.

Genauso können auch Komponenten tiefer in der Vererbungslinie bearbeitet wer-den. Um Komponenten auf eine andere Position zu bringen, zieht man sie mit derMaus.

Anschließend wird die Eigenschaftlayout desJPanel1 vom standardmäßigenFlowLayout auf dasGridBagLayout umgestellt, dann wird derLayout Editorfürdiese Komponente aufgerufen.

Danach werden die Komponenten durch Ziehen mit der Maus umgestellt. Au-

34

2.3. Visaj

Abbildung 2.25.:Visaj Tutorial - Layout Editor

ßerdem werden zahlreiche Eigenschaften verändert, die Abstände, Positionierungbei Größenänderung des Fensters und ähnliches betreffen. DerLayout Editorsiehtschließlich wie in Abb.2.26dargestellt aus.

Abbildung 2.26.:Visaj Tutorial - GridBagLayout fertig

Der letzte Schritt im Tutorial ist das Hinzufügen von Funktionalität. Zuerst hältAdding Event

Bindingsman die Steuerungs-Taste gedrückt und zieht eine Linie mit gedrückter Maustas-te von derJComboBox1 zumJEditorPane1 (die Richtung ist wichtig). Daraufhinöffnet sich derEvent Binding Editor. Ganz rechts wirdsetPage(String) ausge-wählt. Wie in Abb.2.27zeigt, löst jetzt einActionEvent in derJComboBox1 diefolgende Operation aus:

35


JEditorPane1.setPage(String)

Abbildung 2.27.:Visaj Tutorial - Event Binding Editor

Nach Betätigen der SchaltflächeNext >wird wie in Abb.2.28gezeigt angegeben,dass der ParameterString den Wert derPropertyselectedItem der Komponen-te JComboBox1 annehmen soll.

Abbildung 2.28.:Visaj Tutorial - Event Binding Editor fertig

Nach Betätigen der SchaltflächeFinisherscheint imMethod Editordie Operation:

handleIOException(IOException arg1)

Im RegisterreiterEvent Bindingserscheint die Änderung, wie in Abb.2.29 ge-zeigt. ImClass Editorkann man sie nicht sehen. Im Tutorial werden jetzt nocheinige weitereEvent Bindingseingefügt.

Schließlich soll jetzt noch eine OperationmyExit eingefügt werden, die aufgeru-fen werden soll, wenn im MenüFile aufExit geklickt wird. Dazu wählt man zuerstPropertiesaus dem MenüClassaus, woraufhin sich das FensterClass propertiesöffnet. DerNamewird in VisajTutorialgeändert. Das Fenster wird geschlossen.

36

2.3. Visaj

Abbildung 2.29.:Visaj Tutorial - Event Bindings fertig

Im Menü Methodwird jetzt Add New Methodausgewählt. Daraufhin erscheintdie Operationmethod3() im Method Editor. Diesen Eintrag muss man markierenund dann auf den in Abb.2.30gezeigten RegisterreiterSignatureklicken, um dortden Bezeichner ändern zu können.

Jetzt soll derEvent Binding Editorder Komponenteexit_item angezeigt wer-den. AlsDestinationwird dort VisajTutorial.this ausgewählt, als OperationmyExit() .

Damit ist die Erstellung des Fensters abgeschlossen. Abb.2.31zeigt die Vorschaunach Auswahl einer HTML-Datei.

Schließlich wird das Erzeugen des Quellcodes besprochen. Dazu muss noch derGenerating Code

Konstruktor markiert und im MenüMethodauf Main Methodgeklickt werden,damit eine solche erstellt wird. Jetzt wird im MenüGenerateder EintragGenera-te Javagewählt, woraufhin ein Fenster erscheint, indem ein Ausgabeverzeichnisgewählt werden kann. Visaj kann jetzt beendet werden, der erzeugte Quellcodebefindet sich im gewählten Verzeichnis.

Der Tutorialcode umfasst übrigens etwa 10 KiB und gut 250 Zeilen Quellcode.Nacharbeit nötig

Leider wird die benötigte KlasseTicker nicht mit von Visaj gespeichert, sodassman sich um benötigte Pakete noch von Hand kümmern muss. Hier müssen ei-nige class-Dateien aus derdemos.jar in das entsprechende Verzeichnis kopiertwerden. Auch die Icons wurden nicht kopiert, sodass das Programm mit einerNullPointerException beendet wird. Wenn man die Icons in das richtige Unter-verzeichnis kopiert, funktioniert das Programm. Mehr zum erzeugten Code siehe

37


Abbildung 2.30.:Visaj Tutorial - Signature

unten.

Einen Editor bietet Visaj nicht, die OperationmyExit() implementieren wir inAdding your own

Code einem anderen Editor. Abb.2.32zeigt den erzeugten Code.

Der Code in Zeile 256 wurde nach der Generierung eingefügt. Im Bild wird deut-lich, dasssehr viele unnötige Markenerzeugt werden. Kompilierung aud Ausfüh-rung müssen ebenfalls manuell vorgenommen werden.

2.3.2. Erzeugter Code

Nur selbst entwickelter Code wird erzeugt, benötigte Pakete und Ressourcen blei-ben außen vor und müssen manuell kopiert werden17. Das Tutorial empfiehlt dieAufnahme des demos.jar-Verzeichnisses in den CLASSPATH, was übertriebenist. Besser wäre z.B. Kopie der demos.jar in den aktuellen CLASSPATH o.ä.

Visaj schreibt seinen eigenen Code in Markierungen://vj+ <VJ-EndAWT> //vj- <VJ-EndAWT>

17Das Programm startet nicht, wenn Icons nicht im richtigen Unterverzeichnis liegen, da eineNull-PointerException geworfen wird

38

2.3. Visaj

Abbildung 2.31.:Visaj Tutorial - Schluss-Vorschau

Das Format ist proprietär, es gibt viele unnötige und leere Markierungen. Derrestliche Code ist frei editierbar.

2.3.3. Fazit

Visaj kennt keinen Entwurfsmodus in dem Sinn, wie die meisten anderen Toolsdies unterstützen. WYSIWIG ist nicht vorgesehen, aber die Vorschau funktioniertgut. Eine Integration in Sun ONE Studio ist möglich, ansonsten gibt es keinenCode Editor. Benötigte Werkzeuge sind recht gut erreichbar. Die Lade- und Aus-führungsgeschwindigkeit ist gut, allerdings benötigt man für das Szenario längerals in einem herkömmlichen Entwurfsmodus.

Der erzeugte Code ist völlig inakzeptabel, vor allem der vielen von Visaj benötig-ten Kommentarzeilen wegen. Die Modifier sind schlecht gewählt (protected istStandard für Attribute). Diemain -Methode wird nicht explizit aufgeführt, statt-dessen erfolgt eine Kennzeichnung mit einem* am Konstruktor.

39


Abbildung 2.32.:Visaj Tutorial - Erzeugter Code

Es gibt keine Tooltips, stattdessen eine Anzeige in der Statusleiste. Die schwarzeOberfläche

Markierung von markierten Komponenten funktioniert manchmal nicht (z.B. beiJMenuItem ). Ausgrauungen nicht verfügbarer Komponenten sind nicht deutlich.Beschriftungen sind nur über den Property Sheet sichtbar.

Da ein herkömmlicher Entwurfsmodus fehlt, sind die Anforderungen E1 bis E4durchgehend negativ zu beurteilen. Eine Manipulation (beispielsweise die im Sze-nario gewünschte Ausrichtung) ist nur über das Eigenschaftsfenster der Kompo-nenten möglich. Insgesamt gibt es also viele Schwächen in der Ergonomie, dafürist das Konzept interessant. Die Vorgehensweise zur Erzeugung einer GUI ist al-lerdings für Anfänger völlig ungeeignet, da sie viel Vorwissen erfordert.

40

2.4. Visual Studio .NET


Betrachtet wird dasMicrosoft Visual Studio .NET 2003, eine umfangreiche IDEzur Entwicklung von Anwendungen für die .NET-Plattform. Es gibt mehrere Pro-grammiersprachen zur Auswahl, von denen hier J# gewählt wurde, da es Javaam ähnlichsten ist18. Das Visual Studio unterscheidet sich der genannten Unter-schiede wegen stark von den betrachteten Java-IDEs, daher wird gezielt nur derDesignmodus untersucht.


Nach Erstellen eines neuen Projektes wird direkt das Entwurfsfenster angezeigt.Abb. 2.33zeigt das komplette Programmfenster in diesem Entwurfsmodus.

Abbildung 2.33.:Visual Studio .NET - Programmfenster im Entwurfsmodus

18J# ist eine proprietäre Art Java, die einige Pakete (beispielsweise für die GUI) benutzt, die eine Program-mierung nur für Windows erlauben.

41


Deutlich zu erkennen ist das über das Fenster gelegte Raster. Rechts danebenAufbau GUI

zeigt derProjektmappen-Explorer(Projektfenster) die vorhandenen Dateien undVerweise, mit denen die Entwickler importierte Pakete bezeichnen. Der alternativeRegisterreiterKlassenansicht(Strukturfenster) zeigt die Klassen, ihreBasen(d.h.die Klassen, von denen sie abgeleitet sind) und Schnittstellen, sowie Attributeund Operationen. Das darunter gelegeneEigenschaftsfensterähnelt denen andererEntwicklungsumgebungen.

Die Palette nennt sich hierToolboxund blendet sich auf Wunsch am linken RandPalette

ein. Dabei liegt sie leider, wie in Abb.2.34 zu sehen, über dem zu bearbeiten-den Fenster, was das schnelle Einfügen etwas umständlich macht. Man kann dieToolbox jedoch als Fenster einblenden.

Abbildung 2.34.:Visual Studio .NET - Die Toolbox überlagert das zu bearbeitende Fens-ter

Alle Container verhalten sich wie Java-Container mit NullLayout. .NET bietetLayout

keine LayoutManager. Das Raster lässt sich pixelgenau einstellen; für jede Kom-ponente lässt sich bestimmen, ob sie sich am Raster ausrichten soll.

Abschließend zeigt Abb.2.35zwei Buttons, die einem Panel hinzugefügt wurden.Das Verschieben von Komponenten mit der Maus funktioniert zuverlässig und re-lativ ergonomisch. So verändert sich der Mauszeiger, wenn man eine Komponenteauf einen Container zieht.

Bei aktiviertem Ausrichten am Raster ist die bündige Positionierung und die Ein-stellung der gleichen Größe für die beiden Schaltflächen einfach.

Der Code unterscheidet sich deutlich von normalem Javacode und wird daher

42


Abbildung 2.35.:Visual Studio .NET - Zwei Buttons in einem Panel

nicht weiter betrachtet.

2.4.2. Fazit

Das Visual Studio ist historisch zur Erstellung von Windows-Applikationen ge-dacht. J# und Java sollten zwar syntaktisch gleich sein, doch das SDK unterschei-det sich grundlegend vom Java SDK. Die benutzbaren proprietären Klassen sindgezielt auf Windows und .NET ausgerichtet, die Anforderungen M2 und M3 sinddaher negativ zu bewerten. Die Ladezeit ist hoch, die Arbeitsgeschwindigkeit ak-zeptabel.

Die Programmoberfläche wirkt aufgeräumt, allerdings sind einige gewünschteOberfläche

Fenster nur schwierig aufzufinden. Die standardmäßige Einstellung, bei der dieToolbox (also die Palette) das Entwurfsfenster überlagert, ist unverständlich. DemNutzer werden kaum Hilfen geboten.

Einzige Besonderheit im Entwurfsmodus ist das Raster, an dem Komponenten au-Entwurf

tomatisch absolut ausgerichtet werden können. Dies macht die schnelle bündigeAusrichtung von Komponenten möglich. Die Toolbox ist unübersichtlich.

43


2.5. NetBeans

Die IDE NetBeansstammt ursprünglich von Sun Microsystems, ist aber seit Ju-ni 2000 OpenSource. Eine Version mit zahlreichen Zusatzprogrammen vor al-lem kommerzieller Natur wird weiterhin von Sun unter dem NamenJava Stu-dio, vormalsSun ONE19 Studio, vertrieben20. Dieser Entstehungsgeschichte hatNetBeans auch eine recht weite Verbreitung zu verdanken, so wird auf der JDK-Downloadseite von Sun auch gleich NetBeans als Download mit angeboten.

Wie auch Eclipse, bietet NetBeans offene APIs und eine modulare Architektur.Es wird kurz auf die Wizards, den Entwurf grafischer Oberflächen und den gene-rierten Code eingegangen.


Es gibt einen Wizard zum Erstellen eines neuen Projekts. Nach Wählen der Opti-New Project

onJava Applicationwird eine Klasse erstellt, die standardmäßig den NamenMain

trägt und einemain -Methode enthält.

Abbildung 2.36.:NetBeans - New File Wizard

19Open Net Environment, Suns Antwort auf Microsofts .NET.20Zur genauen Entstehungsgeschichte sei aufhttp://www.netbeans.org/about/history.

html verwiesen.

44

http://www.netbeans.org/about/history.html

http://www.netbeans.org/about/history.html

2.5. NetBeans

Das Erstellen grafischer Oberflächen wird durch einen Wizard erleichtert, der vie-New File

le Auswahlmöglichkeiten für neue Klassen bietet. So unter anderem auch einigeSwing-Klassen, aus denen für das folgende Beispiel einJFrame gewählt wird,wie in Abb.2.36gezeigt.

Nach Beenden des Wizards öffnet sich die neu erstellte Klasse im Entwurfsmo-dus. Das Programmfenster wirkt, wie in Abb.2.37zu sehen, recht aufgeräumt.

Abbildung 2.37.:NetBeans - Programmfenster im Entwurfsmodus

Das Entwurfsfenster ist nicht sehr ergonomisch. DerJFrame hat standardmäßig Design

ein BorderLayout . Nach dem Klick auf eine Komponente in der Palette ändertsich nichts an der Oberfläche, es ist also nicht erkennbar, ob bzw. was eingefügtwerden kann. Das Fenster verändert seine Erscheinung auch dann nicht, wenndie Maus sich darüber befindet. Bei einem Linksklick wird die Komponente ein-gefügt. Je nach gewähltemLayoutManager werden Komponenten oft nicht dorteingefügt, wo man sie haben möchte.

Das Layout erscheint je nach Komponente entweder gar nicht im Eigenschaften-fenster oder es hat eine andere Bedeutung als erwartet (nämlich die Position imLayout des Behälters). Die Bedienung erscheint ungewöhnlich und unkomforta-

45


bel. Das Ausrichten zweier Schaltflächen an einer virtuellen Linie ist, wie beiJBuilder, problematisch.

2.5.2. Erzeugter Code

Ähnlich JBuilder wird eine OperationinitComponents() erzeugt, welche dieSteuerung der GUI enthält. Auffällig sind die voll qualifizierten Klassennamen(s. Abb.2.38).

Abbildung 2.38.:NetBeans - Codeausschnitt Operation initComponents()

Der Codeausschnitt ist blau markiert, da er nicht editiert werden darf. Einige Tei-le des Quellcodes werden vom Designer generiert, eine Änderung führt zu Feh-lern im Designer, außerdem werden eigene Änderungen meist gelöscht. Abb.2.39zeigt, dass ein relativ großer Teil des Codes nicht änderbar ist.

2.5.3. Fazit

Auffällig ist die extrem lange Ladezeit. Selbst auf einem schnellen System benö-tigt NetBeans noch bis zu einer Minute für den Start. Im Lehrbetrieb wurden La-dezeiten von mehreren Minuten beobachtet, da die Software dort über das Netz-werk geladen wurde. Nicht änderbarer Code trübt das Bild weiter.

Die Oberfläche fällt weder positiv noch negativ auf, sie wirkt halbwegs aufge-Oberfläche

räumt und ist halbwegs benutzbar. Die Verwaltung der Arbeitsbereiche ist fürAnfänger ungeeignet.

Der Entwurfsmodus wirkt nicht gelungen, obwohl er mit etwas Vorwissen undEntwurf

Übung funktioniert. Ein bündiges Ausrichten ist grafisch nicht möglich, auchnach Deaktivierung des Layout Managers.

46

2.5. NetBeans

Abbildung 2.39.:NetBeans - Gesamter Erzeugter Code mit blauen Markierungen für dienicht änderbaren Bereiche

47


2.6. Bean Builder

Philip Milne von Sun Microsystems veröffentlichte 1999 den ArtikelLong-TermUrsprung

Persistence for JavaBeans[MW99], um eine persistente Speicherung von JavaBeans einzuführen. Die Lösung basierte auf der Serialisierungs-API und bot einexperimentelles Referenzpaketarchiver zum Download an, dass die Speiche-rung als XML-Datei, Java-Datei undBeanScript-Datei anbot. Weiterhin wurdeeine Referenz-Entwicklungsumgebung namensBean Builderzum Download an-geboten, welchearchiver nutzt und auf der älterenBean Boxaufsetzt.

Zu beachten ist, dass es sich nicht um eine vollständige Entwicklungsumgebungfür den Produktiveinsatz handelt. Philip Milne sagt im genannten Artikel selbst:„Like the original BeanBox, the builder is not a commercial product and is inten-ded to serve only as an example of how these techniques would be used in a realIDE. This builder takes the original BeanBox concept forward a little by showingnot just how the properties of a single Bean can be manipulated but how a groupof Beans can be „wired up“ to make the user interface part of an application.“

Der Artikel und die Downloads sollten eine Diskussionsgrundlage für Entwickler,vor allem aber auch fürIDE vendorsdarstellen.

2.6.1. Benutzeroberfläche

Der Bean Builder erstellt getrennt einen zu bearbeitendenJFrame , ein Fenster na-mensProperty Inspectorund ein Anwendungsfenster mit integrierter Palette. Alledrei Fenster bilden keine einheitliche Arbeitsfläche, sondern liegen als getrennteFenster in verschiedenen Prozessen vor, die alle in der Taskleiste angezeigt wer-den.

Abb. 2.40zeigt das Anwendungsfenster inklusive der Palette, die anderen beidenAnwendungsfenster

Fenster werden weiter unten nach Einfügen von Komponenten gezeigt.

Während des Screenshots war der Mauszeiger oberhalb der Schaltfläche zum Ein-fügen einesJButton (ganz links). Im unteren Bereich wird eine kleine Erklärungzu den verfügbaren Komponenten gegeben.


Der contentPane des Fensters ist einJPanel mit SpringLayout , das sich imSpringLayout

48

2.6. Bean Builder

Abbildung 2.40.:Bean Builder - Das Anwendungsfenster mit Palette

JDK im Paketjavax.swing befindet und mit dem JDK 1.4 neu eingeführt wurde.DieserLayoutManager ordnet die Komponenten so an, dass sie quasiabsolut zupositionieren sind, aber mitconstraintsBeziehungen zu anderen Komponentenhaben können. Dadurch ist es beispielsweise möglich, dass die Komponenten sichder Größe des Fensters anpassen.

Nach einem Klick auf eine Komponente in der Palette kann mit der linken Maustas-Einfügen

te der Bereich im contentPane aufgezogen werden, in dem die Komponente sichbefinden soll. Abb.2.41zeigt das Entwurfsfenster, also denJFrame , nach Einfü-gen einesJButton .

Abbildung 2.41.:Bean Builder - Das Entwurfsfenster

Die vier inneren Quadrate ermöglichen eine grafische Einstellung der Constraints.Die vier Quadrate rund um die Schaltfläche ermöglichen, Assoziationen und In-teraktionen herzustellen.

Das Eigenschaftsfenster, im Bean Builder Property Inspector genannt, zeigt, wieEigenschaften

in Abb. 2.42zu sehen, im oberen Bereich eine Baumansicht der Komponenten,unten die Eigenschaften der ausgewählten Komponente (hier des gerade einge-fügtenJButton s).

49


Sofort erkennbar sind besondere Editoren für einige Eigenschaften, während beiEditoren

anderen nur ein Textfeld angezeigt wird. Auf diese Editoren und Eigenschafts-fenster wird in5.4.7und6.3weiter eingegangen.

2.6.3. Fazit

Der Bean Builder ist eindeutig nur eine Referenzimplementierung. Die Geschwin-digkeit ist hoch. Klassen können nur als XML-Dateien gespeichert werden, waszu einer hohen Wiederverwertbarkeit führte, wenn andere Applikationen den Im-port unterstützten.

Die Oberfläche besteht praktisch nur aus dem Entwurfsfenster, der Palette undOberfläche

dem Eigenschaftsfenster. Sie ist einfach gehalten und daher relativ übersichtlich,wenn auch verbesserbar. Negativ erscheint die getrennte Anzeige der einzelnenFenster, es fehlt eine einheitliche Oberfläche.

Der Entwurfsmodus ist benutzbar, aber für Anfänger desSpringLayout wegenEntwurf

zu kompliziert. Das bündige Ausrichten einer zweiten Schaltfläche ist, wie beiden meisten anderen Lösungen auch, problematisch.

2.6.4. Bemerkung

DerBean Builderwurde genauer auf seine Architektur untersucht, da er Suns Re-ferenzimplementierung derLong-Term Persistence for JavaBeans Specification21

ist und die Weiterentwicklung des Paketsjava.beans begleitet hat. Die persis-tente Speicherung wird in der zu erstellenden Neuentwicklung umgesetzt.

Daher an dieser Stelle eine kurze Ausführung zur Entwicklung derLong-TermPersistence for JavaBeansin Bean BuilderundBean Box.

Die ursprüngliche Referenzimplementierung hat nochOutputStream s zur Seria-archiver

lisierung genutzt. Das folgende Beispiel nutzt einenObjectOutputStream füreine normale Serialisierung:

ObjectOutput os = new ObjectOutputStream(System.out);

os.writeObject(new JButton("Press Me"));

os.close();

Um mit dem Paketarchiver eine Bean als XML zu speichern, musste der Codenur geringfügig geändert werden:21http://jcp.org/en/jsr/detail?id=057

50

http://jcp.org/en/jsr/detail?id=057

2.6. Bean Builder

ObjectOutput os = new XMLOutputStream(System.out);

os.writeObject(new JButton("Press Me"});

os.close();

Im Februar 2000 wurde einJava Specification Requestgestartet, an dem auch JSR 57

Mitarbeiter von Firmen teilnahmen, die Entwicklungsumgebungen für Java be-reitstellen. Eine Fortsetzung des ersten Artikels22 beschreibt bisherige Änderun-gen und geht auf das Ziel ein, eine allgemein anerkannte Lösung in das nächsteJDK (1.4) integrieren zu wollen.

Von den im ersten Artikel vorgestellten Klassen ist keine übrig geblieben. FürXMLEncoder

das XML-Format gibt es die neuen KlassenXMLEncoder und XMLDecoder , dienicht mehr auf die Serialisierungs-API aufbauen. Die endgültigeLong-Term Per-sistence for JavaBeans Specificationwurde im Mai 2002 freigegeben23 und ist indas Paketjava.beans im JDK 1.4 eingeflossen. Ein weiterer Artikel geht auf dasXML Schemaein, dass die beiden genannten Klassen nutzen24.

Das Speichern einer Bean läuft jetzt wie folgt ab:

XMLEncoder encoder = new XMLEncoder(System.out);

encoder.writeObject(new JButton("Press Me"));

encoder.close();

Als Referenzimplementierung wurde wieder eine einfache IDE angeboten, dies-mal wieder mit NamenBean Box.

Während die frühe Version des Bean Builders in [MW99] noch Java-, XML- undBeanScript-Dateien speichern konnte, können die neueren Versionen das erstellteFenster lediglich im XML-Format sichern.

Leider gibt es an verschiedenen Stellen auf Suns Website verschiedene VersionenBean Box und Bean

Builderder Referenzumgebung. Für das unten angeführte Beispiel wurde Version 1.0-betavom Januar 2002 genutzt. Auf der Projektseite des Bean Builders25 steht dagegennur eine Version 0.6-alpha von August 2004 zur Verfügung, was deutlich macht,dass es keine geordenete Pflege der Umgebung gibt.

22http://java.sun.com/products/jfc/tsc/articles/persistence2/23http://jcp.org/en/jsr/detail?id=05724http://java.sun.com/products/jfc/tsc/articles/persistence3/25https://bean-builder.dev.java.net/

51

http://java.sun.com/products/jfc/tsc/articles/persistence2/



https://bean-builder.dev.java.net/


Abbildung 2.42.:Bean Builder - Das Eigenschaftsfenster (Property Inspector)

52

3. Folgerung

Die Ergonomie, aber auch Erwartungskonformität, Stabilität und Fehlerfreiheitder untersuchten Produkte, waren oft mangelhaft. Einige Produkte, vor allem Net-Beans, weisen eine hohe Ladezeit auf. Fast alle waren sehr komplex. Bei anderenist dafür die Installation schwierig, oder es müssen zusätzliche Plug-Ins in ei-ne Entwicklungsumgebung integriert werden (wie bei Eclipse). Falls sich eineOnline-Hilfe als nötig herausstellen sollte, muss sie so ausführlich wie nötig undso knapp wie möglich sein.

Einige sind auch einfach für die Problemstellung ungeeignet, da sie beispiels-weise nicht kostenfrei erhältlich sind. Visual Studio erstellt kein mit dem JDKkompatibles Java. Der Bean Builder ist nur eine Referenzimplementierung.

Keines der untersuchten Produkte erfüllt also die gestellten Anforderungen. DieUntersuchung war trotzdem erkenntnisreich, da bei allen Produkten Stärken undSchwächen gefunden wurden, die bei der Erstellung einer eigenen Lösung be-dacht werden müssen.

3.1. Erfüllung der Anforderungen

Tabelle3.1gibt eine Übersicht über die Bewertung, in wie weit die Lösungen diegestellten Anforderungen erfüllt haben. Dabei soll gelten:

++ entspricht den gestellten Anforderungen voll und ganz+ entspricht den Anfoderungen in akzeptablem Rahmeno die Anforderungen werden höchstens teilweise erfüllt- die Anforderungen werden nicht erfüllt-- die Eigenschaft fällt besonders negativ auf

Mit Eclipse ist auch das installierte Plug-In gemeint.

53

3. Folgerung

Tabelle 3.1.:Bewertung der untersuchten Lösungen

Anforderung JBuilder Eclipse Visaj .NET NetBeans BeanBoxO1: Einheitliche Oberfläche + o o o + oO2: Erreichbarkeit, Aufteilungund Manipulation derWerkzeugfenster + o + o + oO3: Begleitung des Nutzersbis ins Ziel; Hilfe -- -- - -- - -O4: Schnelles Erreichen desZiels; Vorlagen, Wizards o + o - + -E1: Ergonomie und Komplexi-tät des Entwurfsmodus - + -- - - -E2: Positionierung und Mani-pulation von Komponenten o + -- + o oE3: Absolute Positionierung - o -- + - -E4: Ausrichtung; Raster -- - -- + -- --M1: Ladezeit; Arbeits-geschwindigkeit o o + - -- ++M2: Lesbarer, kommentierterQuellcode o - -- -- - /M3: Wiederverwendbarkeit,Portierbarkeit o o - -- o +

3.2. Konkrete Folgerungen

Da die erstellten Oberflächen im Lehrbetrieb mit dem normalen JRE von SunSwing

ausgeführt werden, wurde die Entscheidung getroffen, nur Swing-Komponentenzu unterstützen. Daher kommen Visual Studio .NET oder Eclipse SWT nicht mehrin Betracht.

Gerade für Anfänger sind die Unterschiede zwischen AWT und Swing verwir-rend; viele IDEs bieten keine klare Abgrenzung. Die zu entwickelnde Applikati-on wird sich daher voll auf Swing spezialisieren und AWT außen vor lassen. Inder Endversion sollte die Applikation aber damit umgehen können, wenn Nicht-Swing-Beans in der Paletten-Datei aufgeführt sind.

3.2.1. Positionierung von Komponenten

Es wurde deutlich, dass keineLayoutManager eingesetzt werden sollten. Ei-LayoutManager

54

3.2. Konkrete Folgerungen

ne produktive Arbeit mit einem Designer erfordert zu viel Vorwissen über dieJFC1 und LayoutManager. Anfänger sind mit dem Verhalten von LayoutMana-gern überfordert, da Komponenten nicht an die gewünschte Stelle eingefügt wer-den. Die genaue Vorgehensweise eines LayoutManagers kann nicht als bekanntvorausgesetzt werden.

Stattdessen soll eine absolute Positionierung umgesetzt werden. Bei Window-Raster

Builder und Visual Studio wird der Anwender durch ein Raster unterstützt. Dieseswird durch eine Ausrichtung am Raster ergänzt werden, um eine einfache Anord-nung mehrerer Komponenten auf einer Linie zu ermöglichen.

Außerdem funktioniert das Einfügen einer Komponente bei vielen Lösungen nicht,Rechtsklick

wie ein Nutzer eines üblichen Fenstersystems dies erwartet. Nach einem Links-klick auf eine Komponente in der Palette wird oft die Komponente durch Links-klick auf das Entwurfsfenster eingefügt, manchmal nur durch Aufziehen einesBereichs zum Einfügen. Dies ist für Fenstersysteme eigentlich untypisch, da zumAusschneiden, Kopieren, Einfügen usw. die rechte Maustaste üblich ist. Gerade inKombination mit einem nicht verstandenen LayoutManager ist dieses Verhaltenunergonomisch.

Daher soll das Einfügen in der zu erstellenden Software durch ein KontextmenüKontextmenü

umgesetzt werden, das sich durch Klick mit der rechten Maustaste auf eine Kom-ponente öffnet. Hier können außerdem weitere Funktionen untergebracht werden.So ist die Vorgehensweise für das Löschen, Ausschneiden, Kopieren und Einfü-gen einheitlich. Um dies zu unterstützen und die Ergonomie weiter zu verbessernwird eine Zwischenablage (aus Implementierungssicht nichts weiter als ein Zei-ger auf ein Objekt; aus ergonomischer Sicht eine Visualisierung der einfügbarenKomponente) visualisiert. Dort werden Komponenten durch das Ausschneidenund Kopieren, aber auch durch das Klicken auf die Palette eingefügt, wodurcheine einheitliche Vorgehensweise entsteht.

3.2.2. Palette

Die verfügbaren Komponenten sollten thematisch sortiert in einem verschieb-Fenster

baren Fenster untergebracht sein. Eine Überdeckung des Entwurfsfensters (wiebei derToolboxdes Visual Studio) muss verhindert werden. Es sollten nicht al-le Swing-Komponenten wie bei NetBeans auf einem Registerreiter stehen, auchdürfen die Icons nicht so klein sein, da sonst die Auswahl schwerfällt.

1Java Foundation Classes.

55

3. Folgerung

Es sollte nur eine beschränkte Auswahl an Komponenten zur Verfügung stehen,Auswahl an

Komponenten um die Auswahl zu erleichtern. Selten benutzte Komponenten werden nicht oderauf einem getrennten Reiter angezeigt. Auch stellt die Auswahl verschiedenerFenstertypen Anfänger vor Probleme, weshalb diese nicht angezeigt werden soll-ten. Stattdessen wird einJFrame als oberstes Fenster geschaffen. Auf das AWTwird komplett verzichtet, weil gerade von Anfängern kein Vorwissen über Unter-schiede zwischen AWT- und Swing-Komponenten, deren Vererbungshierarchieund Containment System, erwartet werden kann.

3.2.3. Simplizität und einheitliche Oberfläche

Der Bean Builder, die Referenzimplementierung derLong-Term Persistence forJavaBeans Specification2 von Sun Microsystems, kommt von der Simplizität undLadezeit am ehesten an die Anforderungen heran. Er besitzt allerdings keine ein-heitliche Oberfläche, die Palette ist nicht in einem getrennten Fenster modulari-siert. Das Entwurfsfenster erscheint getrennt in der Taskleiste.

3.2.4. Probleme mit Editoren und Persistenz

Offensichtlich haben einige der Lösungen Probleme mit dem Parsen von Java-Java-Parser

Dateien, um sie im Entwurfsfenster anzuzeigen. Einige Lösungen schließen dahersogar Teile des Quellcodes von der Bearbeitung aus. Besser ist die Umsetzungdes Persistenzwunsches durch XML, wie in [Mil02] beschrieben (und schon dreiJahre früher in [MW99] eingeführt). Das Laden und Speichern von grafischenKomponenten ist auf diese Art relativ unkompliziert und wenig fehleranfällig.Java-Quellcode muss natürlich erstellt werden können, importiert wird aber nurXML. Es wird kein Quelltexteditor implementiert.

2http://jcp.org/en/jsr/detail?id=057

56


4. Zielsetzung

4.1. Überblick

Es zeigt sich die Notwendigkeit, eineinfach zu bedienendesSystem zu erstellen.Die vorhandenen Lösungen sind zu komplex (große IDEs wie NetBeans, JBuilderoder Eclipse) oder verfolgen einen Ansatz, der eine gewisse Einarbeitung oder einVorwissen benötigt, das eben nicht vorhanden ist (beispielsweise Visaj, siehe S.28ff.).

Ziel ist eine in Java geschriebene, (trotzdem) schnelle, leicht zu installierende undZiel

zu bedienende Software. Während der Prototyp nur wenig Funktionalität bereit-stellt, um OOA und OOD validieren und benutzte APIs testen zu können, wirddie endgültige Software ein ergonomisches Zusammenstellen und das Verändernvieler Eigenschaften per Maus unterstützen.

Ergebnis der Arbeit mit der Applikation soll eine Java-Klasse sein, die eine reineAusgabe

GUI bietet. Das dazugehörige Fachkonzept soll von Studierenden selbst entwi-ckelt werden. DasEvent Handlingist meist Gegenstand der Übung der Studie-renden und soll unterstützt werden. Dazu wird die GUI-Klasse automatisch oderauf Wunsch alsListenerbei den nötigen Komponenten registriert. Auf diese Wei-se ist sichergestellt, dass Studierende einen möglichst hohen Lerneffekt erreichen,ohne sich als Anfänger bereits mit Swing bzw. allgemein der Erstellung grafischerBenutzeroberflächen auskennen zu müssen.

Gegenstand dieser Projektarbeit ist die Planung der Software (in diesem Kapitel)Projekt & Diplom

und die Erstellung (Kap.5, S. 63) und Beschreibung (Kap.6, S. 87) des Proto-typen. In der anschließenden Diplomarbeit wird auf die endgültige Implemen-tierung, die Konzepte und die benutzten Technologien eingegangen. Auch dieCodegenerierung und damit das Event Handling werden dort besprochen.

57

4. Zielsetzung

4.2. Anforderungen

Auf die Erstellung vonJApplet s undJInternalFrame s wird verzichtet, da sienicht Thema der Veranstaltung für Anfänger ist und die Studierenden irritierenwürde. Wie bereits in3.2.2erwähnt, wird das Fenster einJFrame sein, da sichAnfänger ebenfalls nicht mit den Unterschieden zwischenJWindow , JFrame undJDialog auskennen.

Sowohl Palette und Konfiguration werden als XML-Datei gelesen und geschrie-XML zum

Datenaustausch ben, als auch erstellte Beans. Für die Palette und die Konfiguration müssenDo-cument Type Definitionsgeschrieben werden1, zum Speichern und Laden einerBean werden zur Serialisierung die KlassenXMLEncoder bzw. XMLDecoder ausjava.beans genutzt. Dadurch können die erstellten Beans auch in anderen IDEsgeöffnet und weiter modifiziert werden. In der Endversion muss sicher gestelltsein, dass es keine hohen Konformitätsanforderungen an die XML-Datei gibt,um Fehler bei Ex- und Import zu minimieren. Außerdem müssen aussagekräftigeFehlermeldungen angezeigt werden, falls Fehler beim Parsen auftreten.

4.2.1. Prototyp / Projektarbeit

Frühe Prototypen dienten als Kriterium für Entwurfsentscheidungen oder als Mach-barkeitsstudien. Sie werden hier nicht weiter beschrieben. In Abschnitt5.4 wer-den Entwurfsentscheidungen begründet.

Der hier besprochene Prototyp entspricht architektonisch weitgehend der geplan-ten Software. Er soll sowohl mit den TechnologienXML, JavaBeans ComponentArchitectureundSwingvertraut machen, als auch ein Grundgerüst für die spätereEntwicklung bereitstellen.

Als Musskriterien für den Prototypen werden daher festgelegt:

• PropertySheet zur Anzeige aller Eigenschaften einer Bean,Anforderungen

Prototyp • Speichern einer Bean als XML-Datei, Laden einer Bean aus einer XML-Datei,

• Selektieren einer Komponente und Anzeige ihrer Eigenschaften im Proper-tySheet,

• Einfügen einer Komponente an einer mit der Maus bestimmten Stelle,

1Für die einfach strukturierte Palettendatei als Inline-DTD, für die Konfigurationsdatei als XML Schema

58

4.2. Anforderungen

• Dynamisches Laden der Paletten aus einer XML-Datei zu Programmstartund

• Löschen von Komponenten.

4.2.2. Diplomarbeit - Musskriterien

Die Endversion soll eine Erweiterung des Prototypen sein, wobei vor allem aufGebrauchstauglichkeit und schnelle Entwicklung von Oberflächen geachtet wird.Auch soll dem Benutzer möglichst bei allen Arbeitsschritten Hilfe geboten wer-den. Musskriterien sind daher:

• Ausrichten der Komponenten auf einem Raster, Musskriterien

• PropertySheet zeigt nur ausgewählte Eigenschaften an und lässt Änderun-gen zu,

• Codegenerierung (s.u.),

• Ausschneiden, Kopieren und Einfügen von Komponenten2,

• Drag and Drop zum Verschieben und zur Größenänderung von Komponen-ten,

• Wizards zur Projekterstellung (Eigenschaften) und

• Portierbarkeit auf verschiedene Betriebssysteme3.

Die Codegenerierung soll einen übersichtlichen, gut lesbaren Code erzeugen. DieCodegenerierung

Studierenden sollen durch die Software zwar entlastet und von der Einarbeitungin Swing befreit werden, trotzdem muss der Code lesbar sein, um einen Lern-effekt zu erreichen. Auch soll die Codegenerierung von einem Wizard begleitetwerden, der dem Benutzer verständlich einige Optionen bietet. Anforderungen andie Generierung sind vor allem:

• Übersichtliches Codelayout nach [Hom99],

• Ausreichende Kommentierung,

• Vorbereitung der Registrierung von Listenern für typische Komponentenund

2Dabei soll die Kopie möglichst tief sein.3Die Implementierung in Java liegt nahe, da Java-Klassen benutzt und erzeugt werden sollen; sie ermöglichtgleichzeitig eine plattformunabhängige Umsetzung.

59

4. Zielsetzung

• Einhaltung der JavaBeans Component Architecture [Ham97].

4.2.3. Diplomarbeit - Kannkriterien

Im Zuge der Entwicklung wird sich herausstellen, ob die folgenden Kannkriteriensinnvoll sind:

• Expertenmodus, der die Anzeige aller Eigenschaften wieder erlaubt,Kannkriterien

• Laden und Speichern der Konfiguration in einer XML-Datei,

• Internationalisierung,

• Bearbeitung mehrerer Projekte gleichzeitig,

• Baumansicht der Komponenten (Strukturfenster),

• Wizards zur Template-Auswahl und

• eine Online-Hilfe.

Alle Kriterien, die nötig und sinnvoll sind, um die Gebrauchstauglichkeit zu ver-bessern, werden umgesetzt.

4.3. Abgrenzung

Die Applikation soll geradekeinevollständige IDE werden, d.h. folgende Featu-res wird sie nach Voraussetzungnicht bieten:

• Quelltext-Editor,

• Erzeugen von komplexen Strukturen mit mehreren Fenstern und

• Implementierung von Fachkonzept-Klassen.

Weiterhin werden nur vonJFrame abgeleitete Klassen erzeugt (s.4.2).

4.4. Zielgruppe

Benutzer werden hauptsächlich Studierende sein, die keine Erfahrung mit Java,Anfänger

oder zumindest mit grafischer Programmierung besitzen. Sie können die Software

60

4.5. Betriebsbedingungen und Umgebung

im Labor nutzen, um ohne Vorwissen GUIs zu erstellen, die sie für ihre Übungenoder zum Erlernen grafischer Konzepte benötigen.

Natürlich können auch andere Java-Anfänger die Software zur einfachen Erstel-lung grafischer Oberflächen nutzen. Da das Event Handling nur vorbereitet wird,muss der Nutzer aber wie die Studierenden das Fachkonzept selbst implementie-ren.

Das Lehrpersonal kann außerdem sehr schnell mit Hilfe der Software Code vor-Lehrpersonal

bereiten, den die Studierenden in Übungen benutzen können.

4.5. Betriebsbedingungen und Umgebung

Die Hardware-Anforderungen sollen so gering sein, dass die Leistungsfähigkeitdes genutzten Rechners keine große Wichtigkeit besitzt.

Für den Prototypen muss eine Java-Laufzeitumgebung in Version 1.4.2 installiertsein. Später wird geprüft, ob eine automatisierte Installation möglich ist, die beiBedarf auch eine Laufzeitumgebung installiert.

Es muss sicher gestellt werden, dass die Software sich sowohl als Einzelplatz-version, als auch über das Netzwerk starten lässt. Die Netzwerk-Anforderungensollen so gering ausfallen, dass mindestens 30 Rechner gleichzeitig mit der Soft-ware arbeiten können, ohne deutliche Geschwindigkeitseinbußen hinnehmen zumüssen.

Die Software wird unter Windows XP mit JBuilder X entwickelt, es wird dasJDK 1.4.2 verwendet. Getestet werden soll der Prototyp unter Windows XP undLinux, mit den JDK-Versionen 1.4.2 und 1.5.0, sowohl als Einzelplatzanwendungals auch über ein Netzwerk.

61

4. Zielsetzung

62

5. Prototyperstellung

Der Prototyp wird, wie die Endversion der Software auch, mit Hilfe des JBuil-Verwendete Soft-wareders von Borland erstellt, der in Abschnitt2.1 (S. 8) bereits vorgestellt wurde.

Entscheidend hierfür war unter anderem die Möglichkeit, recht problemlos Bi-bliotheken einbinden zu können, die Generierung von Zieldateien (auch unterZuhilfenahme von Ant) ausführlich beeinflussen zu können und die stabile undmächtige Oberfläche.

Für die OOA- und OOD-Diagramme wurden außerdem Together von Borlandund Microsoft Visio genutzt. Together ermöglicht eine Zusammenarbeit mit JBuil-der. Oft wurden vereinfachte Diagramme manuell mit Visio erstellt.

Im Folgenden wird auf statische und dynamische Konzepte der objektorientiertenAufbauAnalyse und des Entwurfs eingegangen. Wo es sinnvoll ist, werden im Entwurfauch einige Details der Implementierung angeschnitten. Als erstes wird allerdingsbetrachtet, welche Geschäftsprozesse vorliegen (5.1), um einen leichteren Ein-stieg in die Analyse zu gewährleisten.

63


5.1. Objektorientierte Analyse - Geschäftsprozesse

Als erstes werden die möglichen Geschäftsprozesse betrachtet, um den Sinn unddas Vorgehen der Software zu verdeutlichen und einen leichteren Einstieg in dieAnalyse zu gewährleisten. Es ergaben sich drei mögliche Geschäftsprozesse.

5.1.1. Erstellen einer grafischen Bean

Der eigentliche Zweck der Software ist auch der erste offensichtliche Use Ca-se der Applikation. Tab.5.1 zeigt eine klassische Aufstellung, wie alsuse casetemplatein [Bal99, S.64] vorgestellt.

Tabelle 5.1.:Geschäftsprozess: Erstellen einer GUI

Ziel: Speicherung einer lauffähigen Java-GUIKategorie: primärVorbedingung: -Nachbedingung:- Erfolg: Java-Quelltext ist erstellbar und in Java-ByteCode übersetzbar- Fehlschlag: Meldung über Fehlersituation, keine Übersetzung bei

fehlerhafter Quellcode-ErstellungAkteure: Nutzer des Systems (Dozenten zur Vorbereitung, Studenten

als Hilfe bei der Erstellung von GUIs)Beschreibung:1 Neues Projekt erstellen2 Projekt bearbeiten, d.h. Beans hinzufügen, entfernen oder ihre

Eigenschaften bearbeiten3 Projekt in Java-Quelltext umwandelnErweiterungen:1a Projekt-Wizard zum Festlegen der Projekt-Eigenschaften;

eventuell Wahl aus vorhandenen Templates möglich3a Projekt als XML-Datei speichernAlternativen:1a Bereits gespeichertes Projekt öffnen

Auf ein use-case-Diagramm wird der Einfachheit halber verzichtet. Stattdessenwerden in5.3die genauen Abläufe in diesem Geschäftsprozess durch andere Dia-gramme näher betrachtet.

64

5.1. Objektorientierte Analyse - Geschäftsprozesse

5.1.2. Verwalten der Paletten

Möglich ist weiterhin eine grafische Konfiguration der Palette. Ein Wizard kanndabei helfen, verschiedenen Registerreitern bestimmte Komponenten zuzuwei-sen.

Darauf wird verzichtet. Den Studenten soll eine sortierte Auswahl angeboten wer-den, deren Änderung durch Studenten nicht erwünscht ist. Um Komponenten hin-zuzufügen, müsste deren vollqualifizierter Klassenname bekannt sein, was zu vielVorwissen verlangt.

Stattdessen wird die Palette über eine XML-Datei definiert. Da die Applikationauf Swing spezialisiert ist, wird die Datei sehr einfach zu verstehen und damitauch sehr einfach mit einem Editor anpassbar sein.

5.1.3. Verwaltung von Templates

Den Benutzern sollen Vorlagen angeboten werden, die für häufige Anwendungs-fälle einen geringeren Arbeitsaufwand bedeuten.

Projekt-Templates sind für den Prototypen noch nicht relevant, daher wird dieserUse Case erst später noch einmal betrachtet. Zum Zeitpunkt der Fertigstellungdes Prototyps ist noch nicht klar, ob eine spezielle Behandlung von Templatessinnvoll ist.

Zunächst folgt daher eine Betrachtung des statischen Modells.

65


5.2. Objektorientierte Analyse - Statisches Modell

Nach [Bal99] geht man bei der Objektorientierten Analyse von Objekten aus,die sich in der realen Welt befinden. Bei der OOA werde nicht beschrieben, wieObjekte dargestellt oder gespeichert werden. Dem zufolge ist die Analyse derhier besprochenen Software trivial, denn das einzige klar zu erkennende Objektist die zu bearbeitende Bean. Die Objekte, mit denen die Software umgeht, sindjedochgrafischer Naturund existieren bereits, müssen also nicht mehr entworfenwerden.

Auf diese Umsetzung geht der Entwurf in5.4genauer ein. Dort wird untersucht,in wie weit das Fachkonzept bereits durch vorhandene Swing-Klassen abgebil-det werden kann. Daher wird während der Analyse nicht berücksichtigt, dass dieKomponenten nicht alle der selben Klasse angehören. An dieser Stelle wird an-genommen, alle Komponenten seien Erben der KlasseKomponente und besäßeneine OperationgetKlassentyp , um ihre eigentliche Klasse herauszufinden.

Betrachten wir das Fachkonzept genauer. Wir benötigen einenBehälter , der alleKlassendiagramm

anderen Komponenten (der KlasseKomponente ) enthält und praktisch die Ar-beitsfläche des Fensters (der KlasseFenster ) darstellt. Abb.5.1 zeigt diese dreiKlassen, die benötigten Attribute und Operationen.

Die Assoziationen verdeutlichen noch einmal, dass ein Fenster immer einen Be-hälter besitzt, der dann beliebig viele Komponenten besitzt. Das Verhalten derKomponenten wird durch den Behälter gesteuert. Er kann Komponenten aus-schneiden, kopieren, einfügen und löschen.

Der Behälter enthält das AttributZwischenablage , welches eine Komponenteenthält, die nicht sichtbar, aber bereit zum Einfügen ist. Die Operationnew er-zeugt eine neue Komponente und fügt sie der Zwischenablage hinzu. Die anderenOperationen sind selbsterklärend.

Der Entwurf wird zeigen, dass eine direkte Umsetzung nicht möglich ist. Zuerstsollte jedoch das dynamische Modell betrachtet werden, um einige Vorgänge zuverdeutlichen.

66

5.2. Objektorientierte Analyse - Statisches Modell

Abbildung 5.1.:Klassendiagramm OOA

67


5.3. Objektorientierte Analyse - Dynamisches Modell

Um zu verstehen, wie die Software arbeiten soll, ist es wichtig, die dynamischenAbläufe genauer zu betrachten.

5.3.1. Zustandsautomat

Das Zustandsdiagramm in Abb.5.2 veranschaulicht die beiden Zustände einerKomponente und die Übergänge zwischen den Zuständen. Die Übergänge ent-sprechen den Operationen des Behälters, die auf die Komponente angewendetwerden.

Abbildung 5.2.:OOA-Zustandsautomat einer Komponente

Nach der Instanziierung befindet sich eine Komponente im Behälter. Sie wird derZwischenablage hinzugefügt, um ein Einfügen in das Projekt an einer mit derMaus bestimmten Stelle zu ermöglichen.

5.3.2. Interaktionsdiagramme

Der in 5.1.1 vorgestellte Geschäftsprozess soll näher beleuchtet werden. Dazuwerden die vorhandenen Szenarios, die sich aus dem Geschäftsprozess ergeben,mit Interaktionsdiagrammen analysiert. Dazu werden die Operationen des Behäl-ters dargestellt. Das Erzeugen, Einfügen, Ausschneiden, Löschen und Kopierenwerden näher erläutert.

68


Verschiedene Sequenzdiagramme zeigen, wie dabei die Kommunikation zwischenden Komponenten stattfindet. Die Operationsnamen entsprechen dem statischenModell. Die Zwischenablage ist als Eigenschaft des Behälters definiert, daherwerden im Folgenden die OperationengetZwischenablage undsetZwischen-

ablage benutzt. Außerdem wird eine OperationsetPositionUndGröße genutzt,welche die Position und Größe einer Komponente festlegt.

Zur Einführung wird in Abb.5.3das Erzeugen einer Komponente gezeigt. Szenario: Erzeugen

Abbildung 5.3.:OOA-Sequenzdiagramm - Erzeugen einer Komponente

Das erzeugte Objekt befindet sich jetzt in der Zwischenablage des Behälters.

In Abb. 5.4 wird darauf aufbauend das Einfügen aus der Zwischenablage in denSzenario: Einfügen

Behälter gezeigt.

Abbildung 5.4.:OOA-Sequenzdiagramm - Einfügen einer Komponente

Der Einfachheit halber wird angenommen, dass die Komponente sichtbar wird,Zwischenablage

69


wenn sie aus der Zwischenablage entfernt wird, und umgekehrt. Jetzt wird auchdeutlich, warum die schon erwähnte Zwischenablage nicht als eigene Klasse be-trachtet wird. Es handelt sich lediglich um ein sprachliches Konstrukt, das besagt,dass ein Objekt nicht gelöscht wird, sondern unsichtbar im Speicher zur Verfü-gung steht. Dies muss auch für die Szenarios Ausschneiden und Kopieren bedachtwerden.

Das Ausschneiden einer Komponente wird in Abb.5.5gezeigt. Die KomponenteSzenario:

Ausschneiden und

Löschen

muss aus seinem Behälter entfernt werden.

Abbildung 5.5.:OOA-Sequenzdiagramm - Ausschneiden einer Komponente

Der Behälter fügt die Komponente in die Zwischenablage ein und macht sie sounsichtbar. Sie wird aus der Liste der enthaltenen Komponenten entfernt. DasLöschen läuft analog, mit dem Unterschied, dass die Komponente nicht in dieZwischenablage eingefügt wird und nach dem Ausschneiden nicht weiter exis-tiert.

Für das Kopieren einer Komponente wird wie im statischen Modell angenommen,Szenario: Kopieren

dass sich eine Komponente klonen kann. Abb.5.6zeigt dies grafisch.

Weiterhin gibt es noch das Szenario, dass eine Eigenschaft einer KomponenteWeitere Szenarios

geändert werden soll. Der Trivialität wegen wird auf ein Sequenzdiagramm ver-zichtet, stattdessen wird dieser Vorgang im Entwurf besprochen.

70


Abbildung 5.6.:OOA-Sequenzdiagramm - Kopieren einer Komponente

71


5.4. Objektorientiertes Design - Statisches Modell

5.4.1. AWT und Swing

In 3.2wurde die Entwurfsentscheidung begründet, dass sich die Applikation aufSwing spezialisieren soll. Die Vermutung liegt nahe, dass die beschriebenen Klas-senFenster , Behälter und Komponente bereits ähnlich in (AWT oder) Swingenthalten sind und nicht neu entwickelt werden müssen.

Daher wird als erstes versucht, die Struktur der Bean zu beschreiben. WelcheKomponenten der Bean stehen in welcher Beziehung zueinander, welche Kompo-nente kann welche andere beinhalten? Kann Swing ausgenutzt werden, um keineeigenen Klassen implementieren zu müssen?

Um dies zu beleuchten, wurde die Vererbungsstruktur im AWT und in SwingHierarchie

anhand der API-Spezifikation [Jav03] untersucht. Abb.5.7 stellt die Hierarchiedes AWT und die Beziehung der Swing-Klassen zum AWT dar. Innere Klassenund Schnittstellen wurden zur Vereinfachung nicht dargestellt, mit Ausnahme derSchnittstelleRootPaneContainer aus javax.swing , die weiter unten erläutertwird.

Deutlich zu erkennen ist, dass nur die vier hier blau hervorgehobenenSwing Hea-vyweight ContainerJApplet , JWindow , JFrame und JDialog direkt von ihrenAWT-Vorgängern erben. Der fünfte Heavyweight Container1, JInternalFrame ,erbt, wie alle anderen Swing-Komponenten, von dem in gelb dargestelltenJCom-

ponent .

Im AWT war eine Komponente, die andere Komponenten enthalten kann, leichtSwing-Komponenten

daran zu erkennen, dass sieContainer ausjava.awt beerbte. Den Containernkönnen Lightweight Components hinzugefügt werden.

Wie die Vererbungshierarchie hier jedoch zeigt, sindalle Swing-KomponentenErben vonContainer . Alle Swing-Komponenten unterstützen damit auch die ge-erbte Operationadd 2.

Wie in Abb.5.8am Beispiel eines zu einemJButton hinzugefügtenJTextField

ersichtlich ist, lassen sich in Swing tatsächlich, anders als im AWT, Komponentenzu anderen Komponenten hinzufügen. Das ist nicht immer sinnvoll, aber möglich.

1Im AWT waren alle Komponenten schwergewichtig, in Swing sind bis auf die fünf genannten Containeralle Komponenten Lightweight-Komponenten.

2Mit verschiedenen Signaturen, die alle internaddImpl aufrufen

72


Abbildung 5.7.:Vererbungshierarchie bei java.awt.Component

73


Die Containment Hierarchyvon Swing lässt sich erst verstehen, wenn die Hea-vyweight Container näher betrachtet werden. Swing verfolgt ein komplett neuesund differenzierteres Konzept als das AWT.

Abbildung 5.8.:JTextField innerhalb eines JButtons

Die oben genannten Heavyweight Container besitzen eine wesentlich komplexereJRootPane

Struktur, die dem Entwickler tiefere Eingriffsmöglichkeiten erlaubt. Die fünf ge-nannten Komponenten sind dieeigentlichenContainer in Swing. Als einzige be-sitzen Sie eineJRootPane , die Zugriff auf die hinzugefügten Komponenten bietet.Einen genauen Überblick bietet Abb.5.93. Um den Zugriff auf dierootPane unddie darunter liegenden Komponenten zu erleichtern, implementieren sie (wie inAbb. 5.7ersichtlich) die SchnittstelleRootPaneContainer . Diese schreibt die inTab.5.2beschriebenen Operationen vor.

Abbildung 5.9.:Die Struktur innerhalb eines JRootPane

Der LayoutManagerdes rootPane stellt dabei sicher, dass beispielsweise dieglassPane

3Dies ist eine korrigierte Fassung der Abbildung in der API-Spezifikation desJRootPane , siehehttp://java.sun.com/j2se/1.4.2/docs/api/javax/swing/JRootPane.html .

74

http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/JRootPane.html

http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/JRootPane.html


Tabelle 5.2.:Schnittstelle RootPaneContainer

JRootPane getRootPane()Container getContentPane()Component getGlassPane()JLayeredPane getLayeredPane()void setContentPane(Container contentPane)void setGlassPane(Component glassPane)void setLayeredPane(JLayeredPane layeredPane)

glassPane die gleiche Größe besitzt wie dierootPane . Die glassPane ist fürdie Software wichtig, da hier oberhalb aller anderen Komponenten Mausklicksabgefangen werden können.

Der layeredPane organisiert die Überlagerung und ist daher für Dialoge, Pop-layeredPane

Ups und Dragging zuständig. Dies geschieht jedoch automatisch, weshalb keindirekter Zugriff auf dielayeredPane benötigt wird.

Der contentPane schließlich enthält im Normalfall die dem Fenster hinzugefüg-contentPane

ten Komponenten. In Swing sollte man daher immer

rootPaneContainer.getContentPane().add(component);

schreiben, statt wie im AWT üblich:

awtContainer.add(component);

Je nach Konfiguration der Laufzeitumgebung kann das JDK diesen Fehler beimKompilieren abfangen, oder es wird eine Warnung ausgegeben.

Die OperationgetRootPane() ist desweiteren für die KlasseJComponent defi- rootPane

niert; ein näherer Blick zeigt jedoch, dass die Operation hier dieJRootPane desnächstübergeordnetenRootPaneContainer zurückgibt.

5.4.2. Fachkonzept durch Wrapper

Die Erstellung eines eigenen Fachkonzeptes macht kaum Sinn, da das Fachkon-Alternative Konzepte

zept der Software gleichzeitig ein Teil der GUI (also Swing) ist. Diese GUI-Klassen bieten bereits alle Operationen, die das Fachkonzept benötigt.

Anfangs wurden mehrere Konzepte ausprobiert, die eine bessere Analyse ermög-Wrapper

lichen könnten. Es wurde überlegt, ob dieses Problem mit Wrapper-Klassen gelöst

75


werden kann, d.h. einer Swing-Komponente würde innerhalb der Software eineentsprechende Klasse gegenüberstehen. Soll also einemJPanel einJButton hin-zugefügt werden, müsste intern beispielsweise eine Operationvoid addCompo-

nent(WrapperButton button) einer KlasseWrapperPanel aufgerufen werden.Diese Klassen tragen tatsächlich das Fachkonzept, die Entwicklung wäre anfangsvereinfacht worden.

Wrapper würden eine bessere Analyse ermöglichen, stellen sich aber als ungeeig-net heraus. Sie schränken die Auswahl der benutzbaren Komponenten ein. Fallsneue Komponenten unterstützt werden sollen, muss die Software erweitert wer-den. Es entsteht fast ausschließlich überflüssiger Code. Die Swing-Klassen stellenalle vom eigentlichen Fachkonzept benötigten Attribute und Operationen bereit.Anschaulich kann man sagen, dass Sun das Fachkonzept entwickelt hat, zu demdie Software die Benutzeroberfläche bietet.

Die Nachteile sind so gewichtig, dass das Wrapper-Konzept verworfen wurde.Stattdessen werden genau die Swing-Klassen erzeugt und manipuliert, die auchspäter genau so auf dem Bildschirm erscheinen.

5.4.3. Vergleich OOA und Swing

Da Swing-Komponenten andere Komponenten enthalten dürfen, muss der in5.2beschriebenenBehälter nicht mehr getrennt von den Komponenten betrachtenwerden, wenn wir annehmen, dass es sich um eineJComponent handelt4. DasFenster soll einemJFrame entsprechen. Damit besteht das Klassendiagrammfaktisch nur aus Erben der KlasseJComponent .

Daher wird direkt die KlasseJComponent benutzt, um mit dem OOA-Modell ver-gleichen zu können. Da es sich um eine Bean handelt, gibt es keine (relevanten)öffentlichen Attribute. Für die gewünschten Attribute gibt es dafürGetter undSetter, die der Einfachheit halber nicht gezeigt werden. Wir betrachten daher nurausgewählte Operationen der KlasseJComponent , um diese mit unseren Anfor-derungen vergleichen zu können (Abb.5.10).

Es ist deutlich zu erkennen, dass für das gewünschte Fachkonzept entweder genauEignung von

JComponent passende oder aber hilfsweise benutzbare Operationen vorhanden sind.

Die Verwaltung der Zwischenablage verschieben wir im Entwurf einfach vom Be-Zwischenablage

hälter in die umgebende GUI. Dort kann auch gespeichert werden, welche Kom-ponente gerade selektiert ist. Die Anwendung wird die Zwischenablage steuern,

4Später wird stattdessen ein JPanel verwendet, um weitere Feinheiten zu ermöglichen.

76


Abbildung 5.10.:OOD-Klassendiagramm einer JComponent

die selektierte Komponente sollte pro Projekt verwaltet werden. Mehr dazu in5.4.6.

Das Instanziieren einer Komponente (Operationnew) kann ebenfalls vom Behäl- Operationen

ter zur umgebenden GUI verschoben werden. Die Operationendelete und cut

können beide durchremove ersetzt werden. Fürcut muss die Komponente da-zu nur vor dem Entfernen von der GUI der Zwischenablage hinzugefügt werden.paste kann durchadd undsetBounds ersetzt werden.

Statt Wrapper-Klassen zu schreiben ist es also möglich, dass die GUI praktisch alsWrapper fungiert.MainUI wird daher die Kommandos des Nutzers entgegenneh-men und in die Operationen umsetzen. Mehr dazu im Klassendiagramm (5.4.6)und in den Sequenzdiagrammen (5.5).

5.4.4. Kopieren von Komponenten

Einzige Ausnahme ist das Kopieren einer Komponente. Hier gibt es verschiedeneKopie

Möglichkeiten, deren Eigenschaften abgewogen werden müssen.

Die geschützte Operationclone() der KlasseObject (ausjava.lang ) müsste clone

implementiert werden. Allerdings müsste sie für alle Unterklassen implementiertwerden, was nicht nur einen enormen Aufwand bedeutete, ebenso wäre die Aus-wahl an Komponenten eingeschränkt. Änderungen an einer Klasse in späterenJava-Versionen würden nicht berücksichtigt, neue Klassen auch nicht. Schließ-lich erscheint die Operation auch in der persistenten Form, was der wichtigsteGrund ist, eine andere Lösung zu suchen.

Dadurch, dass die Swing-Klassen Beans sind, lässt sich aber eine bessere LösungXML Bean

finden. Möglich wäre beispielsweise, die Bean im XML-Format zu speichern undaus dem XML eine neue Instanz zu erzeugen.

77


5.4.5. Trennung von Fachkonzept und GUI

Offensichtlich sind Wrapper-Klassen unnötig, die Swing-Klassen werden direktDrei-Schichten-

Architektur benutzt. Eine Trennung zwischen GUI und Fachkonzept scheint daher kaum mög-lich, wenn es sich doch bei dem Fachkonzept um GUI-Klassen handelt. DieseTrennung hat vor allem den Sinn, die GUI ohne Änderung des Fachkonzepts neuentwickeln oder besser warten zu können. Hier sind Fachkonzept und GUI aberso stark miteinander verwoben und vor allem voneinander abhängig, dass einevollständige Trennung unmöglich ist.

Im Objektorientierten Entwurf werden Modelle erstellt, die nach [Bal99] einSpie-OOD

gelbild des Programmssein sollen. Hier werden also von der Implementierungabhängige Faktoren berücksichtigt, die GUI wird eingefügt. Bezeichner sollenden Konventionen der Programmiersprache entsprechen.

Die Software besteht jedoch praktisch nur aus der GUI; das Fachkonzept sind dieSwing-Klassen.

Da die Software komplett in Englisch dokumentiert ist, wurden auch die Bezeich-ner in Englisch gewählt. Dies verhindert u.a. Probleme mit Sonderzeichen. Da dieSoftware Java-Klassen erzeugen soll ist es naheliegend, Java als Programmier-sprache zu wählen5. Die vorliegenden Diagramme entsprechen also sowohl derUML als auch den Java-Konventionen [Hom99].

5.4.6. Klassendiagramm

Für den Entwurf wurden neben den Komponenten vier GUI-Klassen inklusiveGUI

innerer Klassen berücksichtigt.MainUI ist das Hauptprogrammfenster, das beimStarten der Software erzeugt wird; beim Schließen des Fensters wird die Soft-ware beendet.ProjectUI enthält dencontentPane , dem die Komponenten hin-zugefügt werden.PaletteUI enthält Schaltflächen für die einzufügenden Beans.PropertySheetUI schließlich zeigt die Eigenschaften der ausgewählten Bean an.

Abb.5.11zeigt diese vier Klassen in einem stark vereinfachten Klassendiagramm.Symbolisch wurde eine Assoziation vom Entwurfsfenster (ProjectUI ) zu den imcontentPane des Projekts enthaltenen Swing-Komponenten eingefügt. Erweiter-te Konzepte, wie beispielsweise vorhandenePropertyChangeListener zum Ab-fangen von Bean-Eigenschaftsänderungen, wurden gezielt ausgespart, um eineneinfachen Einblick zu gewährleisten.

5De facto ist eine Umsetzung in einer anderen Programmiersprache kaum möglich.

78


Abbildung 5.11.:OOD-Klassendiagramm der GUI im Entwurf

79


Das Hauptfenster enthält das Gros der Programmlogik, da es wie in der Ana-MainUI

lyse erläutert keine GUI-Klassen zum Fachkonzept gibt. Es erzeugt die Objek-te der drei anderen Klassen. Den KlassenProjectUI und PaletteUI wird imKonstruktor ein Link zu den beiden inneren KlassenProjectUI_Adapter bzw.PaletteUI_Adapter übergeben, die daraufhin alsListenerfür diverseEventsre-gistriert werden6. Auf diese Weise bleiben die Assoziationen unidirektional undsomit der Code wartbarer, da die Zuständigkeiten immer vonMainUI ausgehen.

Im contentPane derMainUI befinden sich zweiDesktop Panes7, eines ist als At-tribut dargestellt und enthältJInternalFrame s für das Eigenschaftsfenster (Pro-

pertySheetUI ) und die Palette (PaletteUI ). Der andere ist das Entwurfsfenster(ProjectUI ), das der Einfachheit halber direkt vonJDesktopPane abgeleitet ist.

Das Projekt enthält einen Teil der Logik, die in der Analyse noch imBehälterProjectUI

lag, und ist hier gleichbedeutend mit einem Entwurfsfenster. Es enthält einenJInternalFrame , der die einzig aus den Überlegungen zu Wrapper-Klassen üb-rig gebliebene Klasse darstellt. Ein internes Fenster hatte einige gewichtige Vor-teile gegenüber dem später zu speicherndenJFrame , sodass hier bewusst Mehr-aufwand in Kauf genommen wurde. Zu beachten ist, dass der Prototyp nur einProjekt zur gleichen Zeit bedienen können soll.

Die schon erwähnteglassPane ist von JPanel abgeleitet und wurde als innereImplementierung der

glassPane in

ProjectUI

Klasse vonProjectUI realisiert, da hier viel Code für die grafische Darstellungnotwendig ist. MouseEvents werden auf derglassPane abgefangen und an denAdapter inMainUI geleitet.

Die OperationaddToContentPane fügt eine Komponente an einem gegebenenPunkt ein. Sie wird von den beidenpaste -Operationen ausMainUI aufgerufen.Die OperationfitToGrid richtet eine Komponente am Raster aus.

Die Palette nutzt die innere KlassePaletteUIButton , um Schaltflächen zu erzeu-PaletteUI

gen. Diese innere Klasse ist später auch für die Erzeugung der Icons zuständig.

Das Eigenschaftsfenster (Property Sheet) selbst ist im Prototypen noch sehr über-PropertySheetUI

schaubar. Nicht näher betrachtet werden hier jedoch das Tabellen- und Spalten-modell, in denen die komplette Logik zur Anzeige der Eigeschaften steckt. Außer-dem kann der Prototyp die Eigenschaften nur anzeigen, eine Änderung ist nochnicht möglich.

6Der PaletteUI_Adapter fungiert alsActionListener , um Klicks auf eine Komponenten-Schaltfläche abzufangen und eine neue Bean zu instanziieren. DerProjectUI_Adapter implemen-tiert verschiedene Listener, vor allem zum Abfangen von durch die Maus erzeugten Events.

7Ein Desktop Panestellt praktisch eine Arbeitsoberfläche dar und kann mehrereInternal Framesenthalten.Zusammen wirkt dies wie ein eigenes Fenstersystem.

80


5.4.7. Entwurf und Implementierung des Eigenschaftsfensters

Da derProperty Sheetrecht komplex ist, soll er gesondert betrachtet werden.table und column

modelDie verwendeten Klassen machen extensiv Gebrauch von Hilfsklassen aus demJDK-Paketjava.beans . Um eine komplette Neuentwicklung für den Prototypenzu vermeiden, wurden zahlreiche Klassen vonSun Microsystemsverwendet, dienicht im aktuellen JDK enthalten sind. Die Modelle für die Tabelle und ihre Spal-ten wurden in Anlehnung an SunsBean Buildererstellt, der Code ist teilweisenoch unverändert von Sun (siehe dazu auch die Lizenz in AnhangA).

Für grundlegende Datentypen sind bereits im PrototypenProperty Editoren vor- Property Editor

handen. DasTable Modeldes Property Sheet benutzt denPropertyEditorMana-

ger aus java.beans , um verschiedene Editoren zu registrieren. Die benutztenEditoren für die Datentypenint , Integer , float , Float , boolean , Boolean ,Color , Font , Border undString , sowie die Editoren für die AWT-KlassenDi-

mension , Point , Rectangle , Insets und der Editor fürObject sind Referenz-implementierungen von Sun Microsystems, die Entwicklern als Grundlage füreigene Entwicklungen dienen sollen.

Da die Editoren wiederverwendbar sind, befinden sie sich in dem außerhalb derPakete

eigentlichen Software liegenden Paketnet.intermitto.util.propertyeditor ,die drei KlassenPropertyValueEditor , PropertyColumnModel undProperty-

TableModel liegen innet.intermitto.jinbean.propertysheet .

Die KlassePropertySheetUI geht folgendermaßen vor: PropertySheetUI

1. ErzeugeJTable table,PropertyTableModel tableModel,PropertyColumn-

Model columnModel.

2. Registriere aktuelle Komponente im Modell:tableModel.setObject(bean)

3. Registriere den property sheet als Listener:tableModel.setTableModelListener(this)

Die Anzeige der Schlüssel und Werte (und damit der Editoren-GUIs) wird durchcolumnModel

das columnModel übernommen. Zwei innere Klassen enthalten fast die kompletteLogik. PropertyNameRenderer ist für die erste Spalte zuständig, dort werden dieEigenschaftsnamen eingetragen, die Beschreibung als Tooltip. Dazu wird auf dastableModel zurückgegriffen, das für jede Zeile denPropertyDescriptor (ausjava.beans ) liefern kann.PropertyValueRenderer nutzt ebenfalls das tableM-odel, um für jede Zeile denPropertyEditor zu bekommen:

81


PropertyEditor editor = tableModel.getPropertyEditor(row);

Component customEditor = editor.getCustomEditor();

In customEditor befindet sich dann die GUI des Editors. Die eigentliche Anzei-ge übernimmt dann die KlassePropertyValueEditor , die im Spaltenmodell alsZelleneditor für die Wertespalte registriert wird:column.setCellEditor(new PropertyValueEditor()) .

Das tableModel übernimmt offensichtlich die Organisation. Hier wird der Ver-tableModel

weis zur Bean gesichert, da auch hier die beanspezifischen Eigenschaften gespei-chert sind und ausgelesen werden8. PerIntrospector wird einBeanInfo -Objekterzeugt (beidejava.beans . Deskriptoren und weitere Informationen über dieBean werden hieraus abgeleitet. Schließlich wird derPropertyEditorManager

ausjava.beans verwendet, um für die verschiedenen Datentypen die vorhande-nen Editoren ausnet.intermitto.util.propertyeditor zu registrieren.

Abb. 5.12zeigt noch einmal die drei wichtigsten Klassen. Die Editoren wurdennicht extra aufgeführt. Ebenfalls ausgespart wurdePropertyValueEditor , dadiese von Sun kopierte Klasse wahrscheinlich in späteren Versionen nicht mehrnötig ist9.

5.4.8. Projekt und Entwurfsfenster

Wie bereits erwähnt, wurde das Wrapper-Konzept für das Entwurfsfenster beibe-Wrapper-Konzept

halten. Hier zeigen sich einige Vorteile, aber auch gewichtige Nachteile.

Da die GUI der Software Wert auf einfache Bedienung legen soll, wurde ent-Vorteile

schieden, das Entwurfsfenster alsJInternalFrame umzusetzen. So ist es in dieGUI der Software eingebettet, die eine homogene Umgebung bietet. Es ist durchden umgebendenJDesktopPane ProjectUI beschränkt und taucht nur in dessenKontext auf, nicht beispielsweise in der Windows-Taskleiste. Ebenso kann dasFenster keine anderen Teile der GUI überdecken.

Bei Speichern und Laden des Fensters muss es in einenJFrame umgewandeltNachteile

werden. Dies ist im Grunde nicht schwierig, da beim Speichern dercontentPane

desJInternalFrame einfach in einen neu erzeugtenJFrame eingefügt wird. Diesverhindert jedoch, dass dem Fenster Eigenschaften zugewiesen werden können.

8Später können durch das Modell auch Reihenfolge der Eigenschaften und Filter festgelegt werden. DurchFilter wird nur eine eingeschränkte Auswahl der Eigenschaften angezeigt.

9Die Logik der Klasse wird durch das Spaltenmodell übernommen.

82


Abbildung 5.12.:OOD-Klassendiagramm net.intermitto.jinbean.propertysheet

83


Daher muss später eine geeignete Lösung gefunden werden, die EigenschaftendesJFrame durch den Akteur manipulieren zu lassen.

Schließlich wurde pro Wrapper entschieden, da die Nachteile nur zusätzlichenProgrammieraufwand bedeuten, aber die Benutzbarkeit der Software nicht ein-schränken. Die Vorteile bringen eine klare Verbesserung der Bedienung.

84

5.5. Objektorientiertes Design - Dynamisches Modell

5.5. Objektorientiertes Design - Dynamisches Modell

Abschließend sollen die Sequenzdiagramme auf den Entwurf bezogen werden,um die Abläufe zu erläutern.

Auch das Ausschneiden ist jetzt etwas aufwändiger, aber sinnvoller. Abb.5.13 Ausschneiden und

Löschenzeigt das Ausschneiden einer Komponente aus dem contentPane eines Projektes,also die Operationcut ausMainUI .

Abbildung 5.13.:OOD-Sequenzdiagramm - Ausschneiden einer Komponente

Wenn nur gelöscht werden soll, ist die Nachrichtdeletedie erste Aktion. Diedarüber befindlichen Aktionen dienen dem Sichern der Komponente in der Zwi-schenablage.

Das Erzeugen einer neuen Komponente braucht im Entwurf nicht näher betrachtetErzeugen

zu werden. Der Behälter ist dafür nicht mehr zuständig,MainUI instanziiert eineBean und fügt diese der Zwischenablage hinzu. DieJavaBeans Component Ar-chitectureund damit das Instanziieren von Beans wird in der Diplomarbeit näherbetrachtet.

Das Einfügen dagegen ist jetzt etwas aufwändiger, da Swing-Operationen genutztEinfügen

werden. Das führt allerdings zum positiven Aspekt, dass die folgenden Sequenz-diagramme die Implementierung wirklich vollständig abbilden. Abb.5.14zeigt

85


das Einfügen einer Komponente (also die Operationpaste der KlasseMainUI )aus der Zwischenablage in den contentPane des Fensters.

Abbildung 5.14.:OOD-Sequenzdiagramm - Einfügen einer Komponente

Das Kopieren einer Komponente wird, wie in5.4.4 erwähnt, nicht so einfachKopieren

sein wie in der Analyse. Hier werden Klassen und Operationen ausjava.beans

genutzt.

Das Manipulieren von Eigenschaften ist relativ trivial, wenn man sich auf dieGetter und Setter

Eigenschaften vonJComponent beschränkt. Sollen jedoch auch spezifische Ei-genschaften der Unterklasse geändert werden, sind wiederum Klassen und Ope-rationen ausjava.beans nötig.

Daher werden diese Szenarios erst in der Diplomarbeit besprochen.

86

6. Prototypbeschreibung

Um Struktur und Bedienung möglichst komfortabel und gleichzeitig einfach zuGrundlegender

Aufbauhalten, basiert das Einfügen von Komponenten auf einer Zwischenablage. Diewichtigsten Fenster der Oberfläche sind

• das Eigenschaftsfenster(Property Sheet) zur Anzeige der Eigenschaften(Properties) einer Komponente,

• diePaletteder verfügbaren Komponenten und

• dasProjektfensterzum Entwurf der GUI.

Abb. 6.1zeigt die gesamte Anwendungsoberfläche mit den drei genannten Fens-tern und zwei eingefügten Schaltflächen, von denen eine ausgewählt ist.

Abbildung 6.1.:Gesamtansicht der Programmoberfläche

Nach einem Mausklick auf eine verfügbare Komponente in der Palette wird eineAblauf

87


neue Bean instanziiert und in der Zwischenablage1 gespeichert. In der Endver-sion wird es ein weiteres Fenster (das Assistentenfenster) geben, das den Inhaltder Zwischenablage und weitere Hilfe anzeigt. In dieser Zwischenablage werdenspäter ebenfalls Komponenten gespeichert, die aus einem Projekt kopiert oderausgeschnitten werden. Aus der Zwischenablage kann die Komponente nun inein geöffnetes Projekt eingefügt werden.

6.1. Projektfenster

Das FensterProjektenthält die zu erstellende Bean und stellt damit den BehälterEntwurfsfenster

für das Entwurfsfenster dar. Mit Erstellung eines neuen Projektes wird automa-tisch ein leeres Fenster erstellt, wie in Abb.6.2dargestellt.

Abbildung 6.2.:Projekt - Neues Entwurfsfenster

Das über das Fenster gelegte Raster soll die Ausrichtung von Komponenten er-leichtern und ist nur während des Entwurfs sichtbar. Die farbigen Markierungenan den Ecken einer Komponente (anfangs des Fensters) zeigen die Auswahl die-ser Komponente an und sollen später zur Veränderung der Größe mit der Mausdienen. Auch diese Markierungen sind natürlich nur während des Entwurfs sicht-bar.

Um Komponenten in das Fenster einzufügen, kann der Benutzer wahlweise mitKomponenten

einfügen der rechten Maustaste ein Pop-Up-Menü öffnen (Abb.6.3), um eine Komponentean einer bestimmten Stelle einzufügen, oder er benutzt den MenüpunktEinfügenaus dem MenüBearbeiten, woraufhin die Applikation versucht, selbst eine zumEinfügen passende Stelle imcontentPane zu finden.

Ein Klick mit der linken Maustaste auf eine bereits eingefügte Komponente selek-Selektieren

1Die Zwischenablage istnicht identisch mit der Zwischenablage des Betriebssystems.

88

6.2. Projektfenster - Technischer Ablauf

Abbildung 6.3.:Projekt - Pop-Up-Menü

tiert diese. Dadurch werden die oben genannten Markierungen in einer besonde-ren Farbe dargestellt (Abb.6.4) und ihre Eigenschaften werden im Property Sheetangezeigt (Abb.6.6). Durch die Selektion kann sie außerdem über das Menü aus-geschnitten, kopiert oder gelöscht werden.

Abbildung 6.4.:Projekt - Selektion von Komponenten

6.2. Projektfenster - Technischer Ablauf

Um eine möglichst einfache und komfortable Bedienung zu ermöglichen, ist dasEntwurfsfenster innerhalb der Software alsJInternalFrame realisiert, auch wennes natürlich nicht als solches gespeichert werden soll.

Wird eine Bean schließlich gespeichert, wird dercontentPane einem normalen XML-Bean

JFrame hinzugefügt und perXMLEncoder serialisiert. Dies ermöglicht eine hoheKompabilität zu anderen Entwicklungsumgebungen und Java-Applikationen, dasolch eine XML-Bean standardisiert ist [Ham97]. Wie in Abb. 6.5 zu sehen ist,werden in der XML-Datei alle Komponenten mit all ihren Eigennschaften abge-legt, die nicht ihren Default-Wert besitzen. Weitere Informationen zum Aufbausind in der API-Dokumentaion desXMLEncoder und in [Mil02] zu finden2.

2Das zu Grunde liegende XML Schema wird aufhttp://java.sun.com/products/jfc/tsc/articles/persistence3/ beschrieben.

89




Abbildung 6.5.:Projekt - XML-Datei

Bei Erzeugen eines neuen Projekts wird ein leererJInternalFrame erstellt, des-contentPane

sencontentPane (ein JPanel ) derRoot Containerdes Projektes wird. Dieser istbei einem neuen Projekt die einzige Komponente. Ihr werden im Folgenden alleweiteren Komponenten hinzugefügt.

Der JInternalFrame bekommt gleichzeitig eine neueglassPane zugewiesen.glassPane

Diese fängt zukünftig alle Events ab, die auf demcontentPane oder einer seinerKomponenten ausgeführt werden sollen. Dies macht eine Registrierung von Lis-tenern für die einzelnen Komponenten unnötig; stattdessen fängt dieglassPane

alle Maus-Events ab, berechnet die Mausposition und kann dadurch die gewählteKomponente bestimmen.

Zusätzlich dient dieglassPane zur Visualisierung des Rasters, auf dem die Kom-ponenten ausgerichtet werden, und der Markierungen, welche die Ränder derKomponenten visualisieren. Durch die Trennung desglassPane von der eigent-lichen Bean lassen sich Entwurfs- und Laufzeit gut trennen.

90

6.3. Eigenschaftsfenster

6.3. Eigenschaftsfenster

Der Property Sheetsoll die Eigenschaften der ausgewählten Komponente anzei-gen. Während im Prototyp noch alle Eigenschaften angezeigt werden, soll derProperty Sheet in der Diplomarbeit nur den für Anfänger wichtigen Teil anzeigenund Änderungen der Werte zulassen.

Abb. 6.6 zeigt einen Ausschnitt der Eigenschaften einerJCheckBox . Das Eigen-schaftenfenster ist von variabler Größe und daher mit einem Rollbalken ausgestat-tet, um alle Eigenschaften erreichen zu können. Im Titel wird angezeigt, welcherJava-Klasse die ausgewählte Komponente angehört. Die Breite der beiden SpaltenPropertyundValueist änderbar.

Abbildung 6.6.:Property Sheet - Eigenschaften einer Komponente

Für grundlegende Datentypen sind, wie in5.4.7 ausführlicher erläutert, bereits Property Editor

Property Editoren vorhanden. Einige Editoren bieten Dialogboxen, die eine fei-nere Einstellung erlauben. Abb.6.7 zeigt als Beispiel den Dialog des PropertyEditors für Properties vom TypColor .

91


Abbildung 6.7.:Property Sheet - Editor JColorChooser

6.4. Eigenschaftsfenster - Technischer Ablauf

DasTable Modeldes Property Sheet benutzt denPropertyEditorManager ausjava.beans , um verschiedene Editoren zu registrieren.

Im obigen Beispiel ist die in Abb.6.6 markierte Eigenschaftforeground vomBeispiel Editor

Typ Color und nutzt daher die KlasseSwingColorEditor , die mit den anderenoben aufgeführten Editoren im Paketnet.intermitto.util.propertyeditor

liegt. Dieser Editor wiederrum nutzt denJColorChooser ausjavax.swing , dereine zusätzliche Funktionalität ähnlich einem Customizer zur Verfügung stellt.Diese äußert sich dadurch, dass bei einem Klick auf den Farbkreis des Editors einJColorChooser geöffnet wird, der detailliertete Einstellungen erlaubt (s. Abb.6.7). Bei Klick auf das Feld links daneben öffnet sich eine kleine Combo Box, diezumindest eine beschränkte Auswahl bietet. Alternativ können auch die RGB-Werte im Editor ganz links eingegeben werden.

Im Zuge der Diplomarbeit wird geprüft werden, in wie weit eine Eigenentwick-lung von Editoren oder eine Änderung der gegebenen Editoren sinnvoll ist undob weitere Datentypen besser unterstützt werden sollten. Java bietet zusätzlichdie Möglichkeit,Customizerfür bestimmte Klassen zu implementieren, um eineWizard-Funktionalität bereitzustellen. Es zeichnet sich bereits bei der Erstellungdes Prototyps ab, dass Customizer i.A. nicht nötig sein werden; dies wird trotz-dem bei Erstellung der Diplomarbeit geprüft werden.

92

6.5. Palettenfenster

6.5. Palettenfenster

Das Palettenfenster besitzt verschiedene Register für unterschiedliche Klassenvon Komponenten, wie in Abb.6.8 dargestellt. Dadurch ist es beispielsweisemöglich, typische Container auf einem Registerreiter, Buttons und Checkboxesauf einem zweiten und unterschiedliche Textfelder auf einem dritten Reiter zuplatzieren, um die Komponenten strukturiert anbieten zu können.

Wie oben beschrieben führt ein Klick auf eine der Schaltflächen dazu, dass ei-ne Instanz der gewählten Klasse erzeugt und in die Zwischenablage gespeichertwird. Von dort kann es dann in das Entwurfsfenster eingefügt werden.

Abbildung 6.8.:Palette - Komponenten

6.6. Palettenfenster - Technischer Ablauf

Der Prototyp zeigt die angebotenen Komponenten noch als Klassennamen an (s.Abb. 6.8). Später soll die KlasseBeanInfo ausjava.beans genutzt werden, umstattdessen ein Icon anzeigen können. Icons sind aussagekräftiger, da sie für An-fänger eine grafische Auswahl ermöglichen. Der Klassenname kann alsTooltipeines Icons angezeigt werden.

Welche Reiter erzeugt werden und welche Komponenten ein Reiter enthält, wirdzum Programmstart aus einer XML-Datei gelesen. Diese Datei muss einfach auf-gebaut sein, da sie manuell zu ändern sein soll. Die Datei palette.xml muss imProgrammverzeichnis liegen. Auf hardcodierte Paletten wird absichtlich verzich-tet, um einen hohen Grad an Konfigurierbarkeit zu erlauben. Zum Aufbau einerPalettendatei siehe Abb.6.9.

93


Abbildung 6.9.:Palette - XML-Datei

94

7. Ausblick

7.1. Betrachtung des Prototyps

Der Prototyp zeigt, dass es möglich ist, eine unkomplizierte und schnelle Softwarezur Erstellung grafischer Oberflächen zu produzieren.

Die Palette ist bereits funktionstüchtig. Allerdings müssen die vollqualifiziertenPalettenfenster

Klassennamen durch Icons ersetzt werden. Eine Neuentwicklung der Icons solldadurch verhindert werden, dass das Paketjava.beans und die durch Sun Mi-crosystems bereitgestellten Icons zur Generierung genutzt werden.

Das Eigenschaftsfenster (Property Sheet) zeigt im Prototypen alle EigenschaftenEigenschaftsfenster

an. Letztlich soll nur eine für die Zielgruppe relevante Auswahl an Eigenschaf-ten angezeigt werden. Die Position einer Komponente muss gesondert behandeltwerden, da für sie keine Eigenschaft existiert.

Aufwändig wird die Implementierung der Möglichkeit, dass Änderungen im Ei-genschaftsfenster sich auf die Komponente auswirken. Es muss überprüft werden,wie die Änderung der Position vereinfacht werden kann.

In der Software sollen mehrere Projekte gleichzeitig bearbeitet werden können.Projektfenster

Jedes Projekt enthält ein Entwurfsfenster. Für dieses Entwurfsfenster müssen nochdas Positionieren und die Größenänderung von Komponenten durchDrag andDrop realisiert werden. Komponenten und das Fenster müssen am Raster ausge-richtet werden.

Auch Sonderfälle müssen betrachtet werden. So muss sichergestellt sein, dassKomponenten, die wiederum andere Komponenten enthalten, ein normales Ver-halten zeigen. Bei Klick mit der Maus auf solch eine Komponente sollte dieMutterkomponente ausgewählt werden, nicht einer der Bestandteile. Da Swing-Komponenten andere Komponenten beinhalten können, muss auf für diesen Fallein ergonomisches Verhalten sichergestellt werden.

Um die Ergonomie zu verbessern wird untersucht, obInternationalisierung, eine Ergonomie

Online-Hilfe mit JavaHelpoder eine automatisierte Installation unterstützt wer-

95

7. Ausblick

den können. Weiterhin wird geprüft, ob ein Konfigurationsfenster oder Templatesfür einen Nutzer sinnvoll sind. Es wird gezeigt, wieJavaDocund Ant für dieErstellung, Pflege und Verteilung der Anwendung genutzt wurden.

7.2. Theoretische Inhalte der Diplomarbeit

Die Diplomarbeit wird die weitere Entwicklung der Software begleiten. Es wirddie zugrundeliegende Theorie betrachtet (JFC, JavaBeans Component Architec-ture) und ein vollständiger objektorientierter Entwurf vorgenommen. Strukturund Implementierung (vor allem Codegenerierung und XML) werden erläutert.Schließlich wird die vollständige Programmoberfläche vorgestellt und ein bei-spielhafter Ablauf demonstriert.

96

A. Sun Software License

Copyright 2002 Sun Microsystems, Inc. All rights reserved.

Redistribution and use in source and binary forms, with orwithout modification, are permitted provided that the followingconditions are met:

- Redistributions of source code must retain the above copyrightnotice, this list of conditions and the following disclaimer.

- Redistribution in binary form must reproduce the abovecopyright notice, this list of conditions and the followingdisclaimer in the documentation and/or other materialsprovided with the distribution.

Neither the name of Sun Microsystems, Inc. or the names ofcontributors may be used to endorse or promote products derivedfrom this software without specific prior written permission.

This software is provided "AS IS," without a warranty of anykind. ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS ANDWARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBYEXCLUDED. SUN AND ITS LICENSORS SHALL NOT BE LIABLE FOR ANYDAMAGES OR LIABILITIES SUFFERED BY LICENSEE AS A RESULT OF ORRELATING TO USE, MODIFICATION OR DISTRIBUTION OF THIS SOFTWARE ORITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLEFOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, INDIRECT,SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVERCAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OFTHE USE OF OR INABILITY TO USE THIS SOFTWARE, EVEN IF SUN HASBEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

You acknowledge that this software is not designed, licensed orintended for use in the design, construction, operation ormaintenance of any nuclear facility.

97

A. Sun Software License

98

B. Verwendete Literatur

Das Literaturverzeichnis enthält nur solche Literatur, die in dieser Projektarbeitzitiert wurde. Bei der Erstellung der Software wurde wesentlich mehr Literatur,sowohl in Buchform als auch im Internet, konsultiert. Daher hier eine vollständigeListe der verwendeten Literatur.

B.1. Bücher

B.1.1. Java

Ralf Jesse,Das Einsteigerseminar - JavaBeans.verlag moderne industrie, Landsberg, Bonn, 2002.

James Gosling, Bill Joy, Guy Steele, Gilad Bracha,The Java Language Specifi-cation, Second Edition.Sun Microsystems, Mountain View (California), 2000.

Bernd Matzke,Ant - Das Java Build-Tool in der Praxis.Addison-Wesley, München, 2003.

Hendrik Schreiber,Performant Java programmieren.Addison-Wesley, München, 2002.

Brett McLaughlin,Java & XML.O’Reilly, Köln, 2002.

B.1.2. Softwaretechnik

Mario Jeckle, Chris Rupp, Jürgen Hahn, Barbara Zengler, Stefan Queins,UML 2glasklar.Hanser, München, Wien, 2004.

99


Heide Balzert,Lehrbuch der Objektmodellierung: Analyse und Entwurf.Spektrum, Akademischer Verlag, Heidelberg, Berlin, 1999.

Helmut Balzert,Lehrbuch der Software-Technik: Software-Entwicklung.Spektrum, Akademischer Verlag, Heidelberg, Berlin, 2000.

B.2. Webseiten von Sun Microsystems

B.2.1. Konventionen

Java Look and Feel Design Guidelines.http://java.sun.com/products/jlf/ , 2001.

Scott Himmel,Code Conventions for the Java Programming Language.http://java.sun.com/docs/codeconv/ , 1999.

B.2.2. Java API

Java 2 Platform, Standard Edition, v 1.4.2, API Specification.http://java.sun.com/j2se/1.4.2/docs/api/ , 2003.

Dale Green,Internationalization.http://java.sun.com/docs/books/tutorial/i18n/ .

Deborah Adair, Jennifer Ball, Monica Pawlan,2D Graphics.http://java.sun.com/docs/books/tutorial/2d/ .

B.2.3. Java Beans

Andy Quinn,JavaBeans.http://java.sun.com/docs/books/tutorial/javabeans/ .

Dale Green,The Reflection API.http://java.sun.com/docs/books/tutorial/reflect/ .

Tutorials & Training: Beans.http://java.sun.com/developer/onlineTraining/Beans/ .

100

http://java.sun.com/products/jlf/

http://java.sun.com/docs/codeconv/

http://java.sun.com/j2se/1.4.2/docs/api/

http://java.sun.com/docs/books/tutorial/i18n/

http://java.sun.com/docs/books/tutorial/2d/

http://java.sun.com/docs/books/tutorial/javabeans/

http://java.sun.com/docs/books/tutorial/reflect/

http://java.sun.com/developer/onlineTraining/Beans/

B.2. Webseiten von Sun Microsystems

Philip Milne, Kathy Walrath,Long-Term Persistence for JavaBeans.http://java.sun.com/products/jfc/tsc/articles/persistence/ ,11/1999.

Philip Milne, Long-Term Persistence: An Update.http://java.sun.com/products/jfc/tsc/articles/persistence2/ ,01/2001.

Long Term Persistence of JavaBeans Components: XML Schema.http://java.sun.com/products/jfc/tsc/articles/persistence3/ ,06/2001.

Philip Milne, Using XMLEncoder.http://java.sun.com/products/jfc/tsc/articles/persistence4/ ,01/2002.

B.2.4. Ressourcen

Java look and feel Graphics Repository.http://java.sun.com/developer/techDocs/hi/repository/ , 2000.

101

http://java.sun.com/products/jfc/tsc/articles/persistence/




http://java.sun.com/developer/techDocs/hi/repository/


102

Tabellenverzeichnis

3.1. Bewertung der untersuchten Lösungen. . . . . . . . . . . . . . . 54

5.1. Geschäftsprozess: Erstellen einer GUI. . . . . . . . . . . . . . . 645.2. Schnittstelle RootPaneContainer. . . . . . . . . . . . . . . . . . 75

103

Tabellenverzeichnis

104

Abbildungsverzeichnis

2.1. JBuilder - Frame class wizard. . . . . . . . . . . . . . . . . . . . 102.2. JBuilder - GUI . . . . . . . . . . . . . . . . . . . . . . . . . . .112.3. JBuilder - UML . . . . . . . . . . . . . . . . . . . . . . . . . . .142.4. JBuilder - Object Gallery. . . . . . . . . . . . . . . . . . . . . . 142.5. JBuilder - Project Wizard. . . . . . . . . . . . . . . . . . . . . . 152.6. JBuilder - Application Wizard . . . . . . . . . . . . . . . . . . . 162.7. JBuilder - Design. . . . . . . . . . . . . . . . . . . . . . . . . . 172.8. JBuilder - Code. . . . . . . . . . . . . . . . . . . . . . . . . . .192.9. Eclipse - Import. . . . . . . . . . . . . . . . . . . . . . . . . . .222.10. Eclipse - Project Wizard. . . . . . . . . . . . . . . . . . . . . . 232.11. Eclipse - Class Wizard. . . . . . . . . . . . . . . . . . . . . . . 242.12. Eclipse - WindowBuilder Auflösung. . . . . . . . . . . . . . . . 252.13. WindowBuilder - Hinzufügen BorderLayout. . . . . . . . . . . . 262.14. WindowBuilder - Hinzufügen NullLayout. . . . . . . . . . . . . 262.15. WindowBuilder - Code. . . . . . . . . . . . . . . . . . . . . . . 272.16. Visaj Tutorial - Class Editor . . . . . . . . . . . . . . . . . . . . 292.17. Visaj Tutorial - Container. . . . . . . . . . . . . . . . . . . . . . 292.18. Visaj Tutorial - Schlussbild Building the Hierarchy. . . . . . . . 302.19. Visaj Tutorial - Property Sheet. . . . . . . . . . . . . . . . . . . 312.20. Visaj Tutorial - Property Sheet Text. . . . . . . . . . . . . . . . 322.21. Visaj Tutorial - JMenu . . . . . . . . . . . . . . . . . . . . . . . 322.22. Visaj Tutorial - Variablennamen. . . . . . . . . . . . . . . . . . 322.23. Visaj Tutorial - Property Tree. . . . . . . . . . . . . . . . . . . . 332.24. Visaj Tutorial - Customizing Eingabe. . . . . . . . . . . . . . . . 342.25. Visaj Tutorial - Layout Editor. . . . . . . . . . . . . . . . . . . . 352.26. Visaj Tutorial - GridBagLayout fertig. . . . . . . . . . . . . . . 352.27. Visaj Tutorial - Event Binding Editor. . . . . . . . . . . . . . . . 362.28. Visaj Tutorial - Event Binding Editor fertig. . . . . . . . . . . . 362.29. Visaj Tutorial - Event Bindings fertig. . . . . . . . . . . . . . . . 372.30. Visaj Tutorial - Signature. . . . . . . . . . . . . . . . . . . . . . 38

105

Abbildungsverzeichnis

2.31. Visaj Tutorial - Schluss-Vorschau. . . . . . . . . . . . . . . . . . 392.32. Visaj Tutorial - Erzeugter Code. . . . . . . . . . . . . . . . . . . 402.33. VS.NET - Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . 412.34. VS.NET - Toolbox . . . . . . . . . . . . . . . . . . . . . . . . . 422.35. VS.NET - Container . . . . . . . . . . . . . . . . . . . . . . . . 432.36. NetBeans - New File Wizard. . . . . . . . . . . . . . . . . . . . 442.37. NetBeans - Programmfenster. . . . . . . . . . . . . . . . . . . . 452.38. NetBeans - initComponents. . . . . . . . . . . . . . . . . . . . . 462.39. NetBeans - Erzeugter Code. . . . . . . . . . . . . . . . . . . . . 472.40. Bean Builder - Anwendungsfenster. . . . . . . . . . . . . . . . . 492.41. Bean Builder - Entwurf. . . . . . . . . . . . . . . . . . . . . . . 492.42. Bean Builder - Properties. . . . . . . . . . . . . . . . . . . . . . 52

5.1. OOA-Klassendiagramm. . . . . . . . . . . . . . . . . . . . . . . 675.2. OOA-Zustandsautomat Komponente. . . . . . . . . . . . . . . . 685.3. OOA-Sequenzdiagramm Erzeugen. . . . . . . . . . . . . . . . . 695.4. OOA-Sequenzdiagramm Einfügen. . . . . . . . . . . . . . . . . 695.5. OOA-Sequenzdiagramm Ausschneiden. . . . . . . . . . . . . . 705.6. OOA-Sequenzdiagramm Kopieren. . . . . . . . . . . . . . . . . 715.7. Vererbungshierarchie java.awt.Component. . . . . . . . . . . . . 735.8. Ein JTextField innerhalb eines JButtons. . . . . . . . . . . . . . 745.9. Struktur JRootPane. . . . . . . . . . . . . . . . . . . . . . . . . 745.10. OOD-Klassendiagramm JComponent. . . . . . . . . . . . . . . 775.11. OOD-Klassendiagramm GUI. . . . . . . . . . . . . . . . . . . . 795.12. OOD-Klassendiagramm PropertySheetUI. . . . . . . . . . . . . 835.13. OOD-Sequenzdiagramm Ausschneiden. . . . . . . . . . . . . . 855.14. OOD-Sequenzdiagramm Einfügen. . . . . . . . . . . . . . . . . 86

6.1. Gesamtansicht der Programmoberfläche. . . . . . . . . . . . . . 876.2. Projekt - Neu . . . . . . . . . . . . . . . . . . . . . . . . . . . .886.3. Projekt - Pop-Up-Menü. . . . . . . . . . . . . . . . . . . . . . . 896.4. Projekt - Komponenten. . . . . . . . . . . . . . . . . . . . . . . 896.5. Projekt - XML-Datei . . . . . . . . . . . . . . . . . . . . . . . . 906.6. Property Sheet - Eigenschaften einer Komponente. . . . . . . . . 916.7. Property Sheet - Editor JColorChooser. . . . . . . . . . . . . . . 926.8. Palette - Komponenten. . . . . . . . . . . . . . . . . . . . . . . 936.9. Palette - XML-Datei . . . . . . . . . . . . . . . . . . . . . . . . 94

106

Literaturverzeichnis

[Bal99] BALZERT, HEIDE: Lehrbuch der Objektmodellierung.Spektrum, Akad. Verl., Heidelberg, Berlin, 1999.

[Ham97] HAMILTON , GRAHAM : JavaBeans API Specification.Sun Microsystems,

http://java.sun.com/products/javabeans/docs/spec.html, 1997.[Hom99] HOMMEL , SCOTT: Code Conventions for the Java Programming Lan-

guage.Sun Microsystems,

http://java.sun.com/docs/codeconv/, 1999.[Jav03] Java 2 Platform, Standard Edition, v 1.4.2 - API Specification.

Sun Microsystems,http://java.sun.com/j2se/1.4.2/docs/api/, 2003.

[Mil02] M ILNE , PHILIP: Using XMLEncoder.Sun Microsystems,

http://java.sun.com/products/jfc/tsc/articles/persistence4/, 2002.[MW99] M ILNE , PHILIP und KATHY WALRATH : Long-Term Persistence for

JavaBeans.Sun Microsystems,

http://java.sun.com/products/jfc/tsc/articles/persistence/, 1999.

107

Literaturverzeichnis

108

Index

Bean,13, 72, 77

contentPane,75, 90Customizer,33, 92

Eigenschaftsfenster,78, 80, 91Entwurfsfenster,78, 88

glassPane,74, 90

IDE, 1, 60

Komponente,68Ausschneiden,55, 70, 85Einfügen,55, 69, 85, 88Erzeugen,66, 69, 85Kopieren,55, 70, 77Löschen,55, 70, 85

LayoutManager,54BeanBuilder,48Eclipse,25JBuilder,16JRootPane,74NetBeans,45SpringLayout,48Visaj, 34VS.NET,42

Palettenfenster,55, 78, 80, 93Property Editor,50, 81, 91

RootPaneContainer,74

Together,13, 63

UML, 13, 63, 78

Wizard,15, 23, 44Wrapper,75, 77, 82

XMLKonfiguration,58Palette,58, 65, 93Persistenz,48, 58, 77

Zwischenablage,55, 68, 70, 76, 93

109

JinBean - Java GUI Builder - intermitto.net

Documents

Transcript of JinBean - Java GUI Builder - intermitto.net