|
Inhalt
• Einleitung
• Ziele •
Psychologie
• Entwurf •
Style Guide
• Prototyp
• Ausblick
• Literatur
• Anhänge
Anhang
Ergänzende Abbildungen
A.1
Vergleich der Entwicklungsumgebungen anhand einer Checkliste
| Produkt |
|
Forte for Java,
Community Edition 1.0 |
JBuilder 4.0
Foundation |
VisualCafé 4.1
Standard Edition |
VisualAge for Java,
Entry Edition 3.0 |
|
|
|
|
|
|
| Hersteller |
|
Sun |
Borland/Inprise |
WebGain |
IBM |
- Internet
|
|
www.forte.com |
www.borland.com/jbuilder |
www.visualcafe.com |
www.software.ibm.com/ad/vajava |
| OS |
Solaris |
ja |
ja |
nein |
ja |
| |
Windows |
ja |
ja |
ja |
ja |
| |
Linux |
ja |
ja |
nein |
ja |
| Anforderung (Hersteller) |
CPU (MHz) |
Pentium 133 |
Pentium II 233 |
Pentium 133 |
- |
| |
Speicher (MB) |
64 |
128 |
128 |
64 |
| |
Festplatte (MB) |
30 |
115 |
300 |
100 |
| |
Geschwindigkeit (1..10) |
3 |
7 |
8 |
7 |
| Funktionen |
GUI Builder |
integriert |
integriert |
integriert |
integriert |
| |
Swing Klassen |
ja |
ja |
ja |
ja |
| |
Debugger |
integriert |
integriert |
integriert |
integriert |
| |
distributed Debugger |
- |
Enterprise Edition |
Enterprise Edition |
ja |
| |
Teamunterstützung |
nein |
Enterprise Edition |
ab Expert Edition |
Enterprise Edition |
| |
Java 2 |
ja |
ja |
ja |
ja |
| |
Versionskontrolle |
Enterprise Edition |
Enterprise Edition |
ab Expert Edition |
ja |
| |
JavaDoc |
integriert |
integriert |
integriert |
integriert |
| |
JDK unabhängig |
ja |
ja |
nein |
nein |
| |
Bedienung |
6 |
8 |
9 |
8 |
| Hilfesystem |
Tutorial |
ja |
ja |
ja |
ja |
| |
Wizards |
nein, Templates |
ja |
nein, Templates |
ja |
| |
Hilfe |
ja |
ja |
ja |
ja |
| |
Sprache |
englisch |
englisch |
englisch |
englisch |
| |
localizition tools |
- |
ja |
ab Expert E. |
ja |
| |
Bewertung der Hilfe (1..10) |
8 |
4 |
7 |
7 |
Testsystem: AMD Duron 700 MHz
Prozessor, 98 MB Speicher und MS Windows NT 4.0
A.2 Das E3-Modell
A.3 Mehrstufige Sichtenbildung im E3-Modell
Umfangreiche Methoden machen eine mehrstufige
Sichtenbildung notwendig (vgl. [GrEs01] S. 11f). Dabei wird eine weitere
Sicht auf eine bereits vorhandene definiert. Die folgende Abbildung stellt
solche teilweise nachgeordneten Views dar.
A.4 Abbildung des
Workspace
Der Workspace ist in die drei Bereiche Projektbrowser,
Arbeitsbereich und Aufgabenmanager gegliedert.
A.5
Wizards im Prototyp
A.5.1 Unterstützung beim Anlegen eines
neuen Schemas
A.5.2
Unterstützung beim Anlegen eines neuen Projektes
A.6 Fehlersystem im
Prototyp
Die folgende Abbildung zeigt eine Fehlermeldung. Der
Benutzer kann weitere Hinweise über den Schalter Hilfe abfordern.
Bei nicht kritischen Fehlern kann die Meldung ignoriert und der aktuelle
Prozess fortgesetzt werden. Auf der Karte "Service-Kontakt" sind sowohl
die Adresse eines verantwortlichen Mitarbeiters, dem Systemadministrator,
als auch die Adresse der Hotline.
A.7 Hilfesystem im
Prototyp
Die folgende Abbildung zeigt ein Fenster des
Hilfesystems. Dieses kann auch genutzt werden, um aufgetretene Fehler
näher zu spezifizieren. Wie im Abschnitt 3.4.6 gefordert, soll die Hilfe
in einem separaten Fenster dargestellt werden. Die Funktion des
Hilfebrowsers sollte möglicht einfach sein. Aus diesem Grund wurden auch
nur die Funktionen Anfangsseite, Zurück, Vorwärts und
Drucken zur Verfügung. Es ist zu überlegen, ob die Funktionalität
von Lesezeichen noch hinzugefügt werden soll. Damit wird dem
Benutzer die Möglichkeit gegeben, eigene Kommentare anzufügen.
A.8 Design von
Benutzungsschnittstellen
Die folgende Grafik stellt den von der ISO geforderten
benutzerorientierten Gestaltungsansatz für interaktive Softwaresysteme dar
(vgl. [ISO13407] S. 6).
A.9 Gesamtprozeß
der Piktogrammentwicklung
Die folgende Abbildung stellt den Prozess der
Produktion und Evaluation von Piktogrammen dar (vgl. [Stau87] S. 133).
Dabei wird besonders auf die Phase der Evaluation hingewiesen.
A.10
Evaluierungsprozeß von Software
Die folgende Grafik illustriert den Evaluierungsprozeß
von Software (vgl. [ISO14598-1] S. 9).
A.11 Rating Level
Die Skala dient zur Einordnung von Kriterien bei der
Evaluierung von Software (vgl. [ISO14598-1] S. 16).
A.12 Qualitätsmodell für
Benutzungsschnittstellen (grob)
Das folgende Bild zeigt ein Qualitätsmodell das auf
Benutzbarkeit ausgerichtet ist (vgl. [ISO9126-1] S. 12). Die vier
einzelnen Charakteristika müssen noch durch messbare Attribute
quantifizierbar gemacht werden.
B Checklisten
B.1 Evaluierung von Fenstern
Für jedes Fenster müssen die folgenden Checklisten
durchgearbeitet werden. Die Checklisten für Panele und Bildschirmelemente
müssen jeweils für alle im Fenster befindlichen Elemente durchgearbeitet
werden. Werden alle Punkte mit "ja" beantwortet, sind die wichtigsten
Aspekte des ergonomische Design beachtet worden. Jede Frage die mit "nein"
beantwortet wurde, muss für diesen speziellen Fall diskutiert werden. Auch
wenn alle Fragen korrekt durchgearbeitet wurden, können ergonomische
Schwächen vorliegen. Aus diesem Grund können die Checklisten nur
unterstützend wirken. Görner und Machete haben in ihrem Beitrag eine
GUI-Checkliste entwickelt (vgl. [GöMa00] S. 48), die ebenfalls genutzt
werden sollte.
B.1.1
Überprüfung von Struktur und
Layout des GMEJFrame
|
Frage |
Ja |
Nein |
|
|
|
| Wurde ein Fenstertitel vergeben? |
|
|
| Ist eine Standardgröße beim Öffnen des
Fensters vorgegeben? |
|
|
| Werden wichtige Funktionen als Icon
angeboten? |
|
|
| Werden shortcuts (Beschleunigungstasten)
für wichtige Funktionen bereitgestellt? |
|
|
| Besteht jederzeit die Möglichkeit des
Abbruchs? |
|
|
| Wurde ein Standardbutton festgelegt? |
|
|
| Ist die Hilfefunktion verfügbar? |
|
|
| Ist diese schnell und einfach erreichbar
(shortcut) ? |
|
|
| Wurde eine minimale Größe des Fensters
festgelegt? |
|
|
| Werden Bildschirmlaufleisten (scroll bar)
beim Verkleinern sichtbar, um nicht sichtbare Bereiche anzeigen zu
können? |
|
|
| Sind die Abstände der Elemente zum Rand
eingehalten? |
|
|
| Werden die Texte in gemischter
Schreibweise angezeigt? (Erhöhung der Lesegeschwindigkeit gegenüber
reiner Großschreibung um 13 Prozent) |
|
|
B.1.2
Überprüfung von Panelen (inkl. JScrollPane und
JTabbedPane)
|
Frage |
Ja |
Nein |
|
|
|
|
Beträgt der Abstand zu anderen Panelen jeweils 6? |
|
|
|
Wurden minimale Größe angegeben? |
|
|
|
Sind bei Bedarf Bildschirmlaufleisten verfügbar? |
|
|
|
Wurden die Vorgaben aus
Abschnitt 4.2.2 beachtet? |
|
|
B.1.3
Überprüfung sonstiger Bildschirmelemente
|
Frage |
Ja |
Nein |
|
|
|
| Wurden die definierten Standardfarben
verwendet? |
|
|
| Wurden die definierten Standardgrößen
verwendet? |
|
|
- Wurden für inhaltlich gleiche Elemente in ähnlichen Fenstern
auch gleiche Positionen verwendet?
|
|
|
| Wurden sinnvolle Vorgabewerte angegeben? |
|
|
| Wurde eindeutige Sprache (kein
Englischdeutsch Mix) verwendet? |
|
|
- Wurde das Element, falls nötig, eindeutig und klar verständlich
durch einen Bezeichner (JLabel)
beschrieben?
|
|
|
| Wurden bei Bedarf die Ränder entsprechend
den Konventionen des Style Guide gesetzt. |
|
|
| Wurden Bildschirmlaufleisten
bereitgestellt, wenn sich das Element im eigenen Darstellungsbereich
ändern kann (z.B. JTree,
JList,
JTable) |
|
|
B.1.4
Verhalten von Bildschirmelementen
|
Frage |
Ja |
Nein |
|
|
|
| Entspricht das Verhalten des Elementes
dem allgemeingültigen Interaktionsverhalten (gleiche Elemente agieren
in allen Fenstern auch gleich)? |
|
|
| Werden bei Listen, Verzeichnisbäumen u.ä.
Kontextmenüs angeboten? |
|
|
| Werden Fehlermeldungen bei Fehleingaben
angezeigt? |
|
|
| Sind Hilfetexte zu Fehlermeldungen
abrufbar? |
|
|
| Ist der Fokus (aktives Bildschirmelement)
nach dem Öffnen eines Fensters sinnvoll gesetzt? |
|
|
| Wird eine Fortschrittsanzeige bei
Prozessen, die länger als 3 Sekunden dauern angezeigt (vgl. DIN 9241)
? |
|
|
| Wird eine Rückmeldung bei erfolgreicher
Ausführung einer Option angezeigt? |
|
|
| Steht der Cursor bzw. die Selektion nach
dem Einfügen von Objekten in Listen, Tabellen oder Bäumen auf diesen? |
|
|
| Wurde das Fenster möglichst nicht-modal
(der Benutzer kann in ein anderes Fenster wechseln) implementiert? |
|
|
C Spezifikation des Prototyp
C.1
Statische Sicht
C.1.1
Use Case Diagramme des Prototyp GME 2001
C.1.2
Klassendiagramme des GME Prototyp
C.1.3 Klassendiagramm
einzelner Interaktionselemente
Klasse GMEJCombobox
Klassendiagramm GMEJFrame
Klassendiagramm JDateField
C.2
Dynamische Sicht
C.3 Detaillierte
Beschreibung ausgewählter Klassen
C.3.1 Spezifikation der Klasse
Project
|
Attribut |
Typ |
Beschreibung |
|
|
|
|
createdOn |
Datum |
Datum, an dem das Projekt erstellt wurde |
|
startetOn |
Datum |
Datum, an dem die Bearbeitung beginnen
soll |
|
state |
Integer |
Der aktuelle Projektstatus: 1 = initial,
2 = ...., |
|
projectLeader |
User |
Der Projektleiter. |
|
description |
Text |
Eine kurze Beschreibung des Projektes.
Die genauere Spezifikation wird im Rahmen der Dokumentation
durchgeführt. |
|
deadline |
Datum |
Der Termin des Projektes. |
|
realDeadline |
Datum |
Der tatsächlich realisierte Termin. |
|
password |
Text |
Das Passwort des Projektes. |
|
customer |
Adresse |
Der Auftraggeber des Projektes. |
|
internCustomer |
Boolean |
Ist der Auftraggeber ein interner oder
externer Kunde? |
|
documentation |
Documentation |
Diese Klasse beinhaltet die gesamte
Projektdokumentation. Sie wurde im Rahmen der Diplomarbeit von
Christian Kluge spezifiziert. |
|
models |
Liste: Model |
Enthält die Liste der Modelle. |
|
schemata |
Liste: Schema |
Enthält die Liste der Schemata. |
|
collaborators |
Liste: User |
Enthält alle am Projekt beteiligten
Mitarbeiter. Die Klasse User ist Teil des Benutzermanagements und des
Rechteverwaltungssystems. Sie wird an dieser Stelle nicht weiter
spezifiziert. |
|
scripts |
Liste: Script |
Enthält alle Scripte, die programmiert
wurden. Die Klasse Script wird an dieser Stelle nicht weiter
spezifiziert. |
|
changeRequests |
Liste: ChangeRequest |
Enthält alle Änderungsanträge. Die Klasse
ChangeRequest wurde im Rahmen der Diplomarbeit von Christian Kluge
spezifiziert. |
|
other |
Liste |
Diese Liste enthält nur Verweise auf
Dokumente. Diese sind u.U. vom Auftraggeber bereit gestellt worden. |
|
Methoden |
Beschreibung |
|
|
|
login() |
Ermöglicht unter Benutzung der Klasse
UserLogin das Anmelden eines Benutzers |
|
logout() |
Meldet den zur Zeit angemeldeten Benutzer
ab |
|
createNewProject() |
Erstellt mit Hilfe der Klasse
NewProjectWizard ein neues, leeres Projekt. |
|
openProject() |
Lädt ein vorhandenes Projekt aus dem
Repository. |
|
checkIn() |
Überführt Konfigurationseinheiten vom
Workspace in das Repository. |
|
checkOut() |
Lädt Konfigurationseinheiten aus dem
Repository in den Workspace. |
|
print() |
Ermöglicht das Drucken von Modellen,
Schemata, Dokumentation, Aufgaben und Änderungsanträgen. |
|
newModel() |
Fügt ein neues Modell mit Hilfe des
NewModelWizard in das Projekt ein. |
|
newSchema() |
Fügt ein neues Schema mit Hilfe der
Klasse NewSchemaWizard in das Projekt ein. |
C.3.2 Spezifikation der
Klasse Task
|
Attribut |
Typ |
Beschreibung |
|
|
|
|
createdOn |
Datum |
Datum, an dem die Aufgabe angelegt wurde. |
|
startOn |
Datum |
Datum, an dem die Aufgabe beginnt. |
|
deadline |
Datum |
Datum, an dem die Aufgabe erledigt sein
soll. |
|
realDeadline |
Datum |
Datum der tatsächlichen Fertigstellung
der Aufgabe. |
|
createdFor |
Liste:User |
Enthält die Mitarbeiter, für die diese
Aufgabe erstellt wurde. |
|
createdBy |
User |
Enthält den Mitarbeiter, der die Aufgabe
angelegt hat. |
|
state |
Integer |
Status der Aufgabe: 0 = neu, 1 = in
Bearbeitung, 2 = erledigt. |
|
priority |
Integer |
Priorität der Aufgabe: 0 = gering, 1 =
mittel, 2 = hoch. |
|
description |
Text |
Beschreibung der Aufgabe. |
|
expenditure |
Integer |
Der tatsächliche Gesamtaufwand. |
|
estimatedExpenditure |
Integer |
Vorher geschätzter Aufwand. Diese
Aufwandsgrößen sind für die Projekt-Kalkulation von Bedeutung. |
|
Methoden |
Beschreibung |
|
|
|
createNewTask() |
Ermöglicht unter Benutzung der Klasse
NewTaskWizard das Anlegen einer neuen Aufgabe. |
|
print() |
Druckt die Aufgabe aus. |
C.3.3 Spezifikation der
Klasse Model
Die Klasse Model ähnelt in ihrem Aufbau sehr stark der Klasse
Schema. Aus diesem Grund wird lediglich sie genauer spezifiziert.
|
Attribut |
Typ |
Beschreibung |
|
|
|
|
name |
Text |
Enthält den Namen des Modells. |
|
description |
Text |
Beschreibung des Modells. |
|
createdOn |
Datum |
Datum, an dem das Modell erstellt wurde. |
|
createdBy |
User |
Enthält den Projektmitarbeiter, der das
Modell erstellte. |
|
deadline |
Datum |
Datum, an dem die Aufgabe erledigt sein
soll. |
|
realDeadline |
Datum |
Datum der tatsächlichen Fertigstellung
der Aufgabe. |
|
createdFor |
Liste:User |
Enthält die Mitarbeiter, die dieses
Modell bearbeiten. |
|
owner |
User |
Enthält den Mitarbeiter, der die
Verantwortung für das Modell innehat Aufgabe angelegt hat. |
|
stateObserver |
Liste: (State, Datum, User) |
Enthält die Liste der verschiedene
Zustände, die das Modell bereits durchlaufen hat. Zu jede
Zustandsänderung wird Datum und auslösender Mitarbeiter gespeichert.
Status: 0 = angelegt, 1 = inEdit, 2 = stable, 3 = tested, 4 =
qualityAssured, 5 = released |
|
changeRequests |
Liste: ChangeRequest |
Enthält eine Liste aller zu diesem Modell
gehörenden ChangeRequests |
|
changeObserver |
Liste: ChangeDescription |
Enthält eine Liste aller Änderungen. |
|
estimatedExpenditure |
Integer |
Geschätzte Gesamtbearbeitungszeit des
Modells. |
|
expenditure |
Integer |
Tatsächliche Bearbeitungszeit. Diese wird
durch die im changeObserver gelisteten ChangeDescription berechnet. |
|
data |
ModelData |
Hier werden die Daten des Modells
abgespeichert. Dazu gehören alle benutzen E3-Elemente und
ihre Beziehungen zueinander. |
|
Methoden |
Beschreibung |
|
|
|
createNewModelData() |
Erstellt ein leeres Modell. |
|
changeState() |
Überführt das Modell in einen neuen Status. |
|
print() |
Druckt das Modell aus. |
|
addChangeDescription() |
Fügt nach einer Modifikation eine Beschreibung
dieser Änderung ein. |
C.3.4
Spezifikation der Klasse
ChangeDescription
|
Attribut |
Typ |
Beschreibung |
|
|
|
|
description |
Text |
Beschreibung der vorgenommenen
Modifikationen. |
|
createdOn |
Datum |
Datum, an dem die Veränderung vorgenommen
wurde |
|
createdBy |
User |
Enthält den Projektmitarbeiter, der die
Modifikation vorgenommen hat. |
|
reasons |
Text |
Beschreibung der Gründe für die
Modifikation. |
|
expenditure |
Integer |
Dauer der vorgenommenen Modifikation.
|
C.3.5 Alle bisher
definierten Randtypen
| Name |
Typ |
Rand oben |
Rand links |
Rand unten |
Rand rechts |
Bemerkung |
|
|
|
|
|
|
|
| OBEN_LINKS_UNTEN_RECHTS |
0 |
3 |
3 |
3 |
3 |
Standardränder für alle Panele der
untersten Ebene. |
| OBEN |
1 |
3 |
0 |
0 |
0 |
|
| LINKS |
2 |
0 |
3 |
0 |
0 |
|
| UNTEN |
3 |
0 |
0 |
3 |
0 |
|
| RECHTS |
4 |
0 |
0 |
0 |
3 |
|
| OBEN_LINKS |
5 |
3 |
3 |
0 |
0 |
|
| LINKS_UNTEN |
6 |
0 |
3 |
3 |
0 |
|
| UNTEN_RECHTS |
7 |
0 |
0 |
3 |
3 |
|
| OBEN_UNTEN |
8 |
3 |
0 |
3 |
0 |
|
| OBEN_RECHTS |
9 |
3 |
0 |
0 |
3 |
|
| LINKS_RECHTS |
10 |
0 |
3 |
0 |
3 |
|
| OBEN_LINKS_UNTEN |
11 |
3 |
3 |
3 |
0 |
|
| OBEN_LINKS_RECHTS |
12 |
3 |
3 |
0 |
3 |
|
| OBEN_UNTEN_RECHTS |
13 |
3 |
0 |
3 |
3 |
|
| LINKS_UNTEN_RECHTS |
14 |
0 |
3 |
3 |
3 |
|
| DEFAULT_BUTTON |
15 |
4 |
4 |
4 |
4 |
Rand für den Standardbutton eines
Fensters |
| TOOLBAR |
16 |
0 |
0 |
0 |
0 |
Bei Verwendung mehrerer JToolBar
innerhalb eines JToolBar diesen Rand zuweisen |
| DIVIDE_WINDOW |
17 |
0 |
0 |
0 |
0 |
Abgrenzung des Haupt-Panels, wenn kein
JTabbedPane bzw. JSplitPane verwendet wurde |
| EDITORPANE |
18 |
0 |
0 |
0 |
0 |
Der Rand für JEditorPane, JTree usw. Er
entspricht dem Standardrand, der bei allen Eingabeelementen genutzt
wird. |
© yves köth |
|
