Diplomarbeit
 HTML-Version
 HTML (eine Datei 300 Kb)
 PDF-Version
 

Links
 Startseite
 Empfohlene Seiten

Suchportale Campingplätze in Deutschland bei Campingplatz-suchen.de

Reiterhöfe in Deutschland bei Reiterhof-suchen.de

5 Evaluation ergonomischer Oberflächen

Die Evaluierung von interaktiven Systemen dient dazu, die Benutzbarkeit einer Schnittstelle zu testen und zu verbessern (vgl. [Prei99] S. 232). Evaluation im Sinne von Qualitätssicherung und Qualitätsverbesserung stellt einen wichtigen Aspekt bei der Gestaltung ergonomische Software dar. Mangelhafte Oberflächen können nicht nur zu Einbußen bei der Effizienz der Aufgabenerledigung, sondern auch zu Fehlern führen. Diese können abhängig vom Aufgabenbereich des Anwendungssystems erhebliche Konsequenzen nach sich ziehen. Aus diesem Grund muss das Ausmaß der Evaluation immer dem Softwareprojekt angepasst werden. Studien belegen, dass schon mit relativ geringen Einsatz bis zu 80 Prozent des Verbesserungspotential erkannt und umgesetzt werden können (vgl. [ReMo95] S. 248). Soll ein höherer Prozentsatz erreicht werden, steigen die Kosten überproportional.

Die ISO 14598 beschreibt den Evaluierungsprozeß für Software. Da die Norm dafür gedacht ist, ein gesamtes Softwareprojekt zu beurteilen, kann sie auch bei Benutzungsschnittstellen eingesetzt werden. Grundsätzlich werden drei verschiedene Ausgangssituationen betrachtet. So kann der Evaluierungsprozeß entweder im Rahmen der Entwicklung oder Anschaffung von Software oder unabhängig von beidem durchgeführt werden (vgl. [ISO14598-1] S. 6). Die entsprechenden Anpassungen des Prozesses werden in den Teilen drei bis fünf der Norm speziell behandelt. Den folgenden Ausführungen liegt der im Teil eins spezifizierte allgemeine Evaluierungsprozeß zu Grunde. Dieser wird in vier Phasen gegliedert (vgl. Anhang A.10). Im ersten Schritt werden die Anforderungen festgelegt. Dabei wird der Zweck der Evaluierung definiert. Handelt es sich beispielsweise um ein Endprodukt, so entscheidet die Evaluierung zwischen Auslieferung oder Überarbeitung der Software. Zu den Anforderungen gehört ebenfalls die Spezifikation eines quality model. Ein Qualitätsmodell (engl. quality model) besteht aus einer Menge von Eigenschaften einer Software und deren Beziehungen untereinander (vgl. [ISO9126-1] S. 21). Die ISO 9126-1 beschäftigt sich umfassend mit Qualitätsmodellen. Das dort vorgestellte Modell quality in use kann als Ausgangspunkt für die Evaluierung einer Benutzungsschnittstelle gesehen werden (vgl. Anhang A.12). Nach der Definition der Anforderungen beginnt der zweite Schritt des Evaluierungsprozesses. Da die vier beispielhaft genannten Eigenschaften Leistungsfähigkeit, Produktivität, Sicherheit und Zufriedenheit nicht direkt messbar sind, müssen dafür Indikatoren gefunden werden. Zeidler und Zellner sehen in der Definition dieser scharfen, softwareergonomischen Kriterien ein Hauptproblem der Evaluierung (vgl. [ZeZe92], S.: 189). Wurden geeignete Kriterien gefunden, kann die Wichtung der einzelnen Merkmale sowie die

Skala für die Messung festgelegt werden. Anhang A.11 zeigt einen Vorschlag der ISO 14598-1 für eine mögliche Einteilung. Der dritte Prozessschritt umfasst die Entwicklung eines Evaluierungsplanes. Dazu gehört die Auswahl der Testpersonen, die Festlegung des Verantwortlichen, die Art der Datenerfassung und -auswertung. Es können beispielsweise Daten durch Fragebögen, Interviews oder Videoaufnahmen gesammelt werden. In dieser Phase werden auch die maximalen Kosten festgelegt. Im abschließenden vierten Schritt findet die eigentliche Evaluierung statt. Hier werden die einzelnen Kriterien in den Skalen erfasst, mit den Vorgabewerten verglichen und Auswertungen durchgeführt. Wurden Probleme bei der Gebrauchstauglichkeit festgestellt, werden diese anschließend analysiert. In den meisten Fällen existieren mehrere Lösungsansätze. Diese müssen diskutiert und entsprechend umgesetzt werden. Dabei sind die Kosten für die Realisierung zu beachten. Vor allem die Erfassung der Daten wird in vielen Publikationen ausführlich beschrieben. Eine erfolgreiche Evaluierung ist jedoch ohne sorgfältige Vorbereitung kaum durchzuführen. Aus diesem Grund sollten alle Schritte des Evaluierungsprozesses durchlaufen werden.

Grundsätzlich kann die Evaluierung sowohl durch externe MCI-Experten, das Designerteam oder durch Anwender erfolgen. Experten sind mit vielen offiziellen Style Guides vertraut. Sie besitzen umfangreiche Erfahrungen mit Benutzungsschnittstellen und können viele der vorhanden Probleme an einem Prototypen schnell erkennen. Ein Nachteil dieser Evaluationsmethode besteht darin, dass Experten die praktischen Probleme bei der Aufgabenerfüllung nicht kennen (vgl. [ReMo95] S. 252). Dieses Problem besteht in abgeschwächter Form auch bei der Evaluierung durch das Designerteam. Allerdings können Designer den aktuellen Entwicklungsstand kontinuierlich mit den definierten Style Guides und allgemeinen Gestaltungsprinzipien (vgl. Abschnitt 3.3) abgleichen. Auch die in dieser Arbeit entwickelten Checklisten (vgl. Anhang B) nutzen Sie, um Arbeitsschritte sofort zu prüfen. Beide Formen der Begutachtung, bei der methodisches Vorgehen zur Identifikation von Problemen führt, werden mit dem Begriff heuristische Evaluation bezeichnet (vgl. [Prei99] S. 242). Nielsen definiert sie als systematische Prüfung der Benutzungsschnittstelle auf Gebrauchstauglichkeit (vgl. [Niel93] S. 155f). Dabei zeigt er anhand von Studien, dass bereits fünf Testpersonen ca. 75 Prozent der Probleme erkannt haben.

Bei der empirischen Evaluierung wird der Test durch die Benutzer durchgeführt. Dabei unterscheidet man zwischen subjektiven und objektiven Evaluationsmethoden. Bei beiden Verfahren werden die Probanden mit dem Prototyp konfrontiert. Erfolgt die anschließende Bewertung durch den Benutzer persönlich, so nennt man das Ergebnis subjektiv. Wird die Bewertung anhand von Prüflisten durchgeführt, ergibt sich eine objektive Evaluierung. Inhalt dieser Prüflisten sind beispielsweise Fehlerraten oder Lernaufwand.

Auch umfangreiche Maßnahmen der Evaluation geben keine Garantie für die Entwicklung einer ergonomische Benutzungsschnittstelle. Wichtig ist, dass schon während der Entwicklung flankierende Maßnahmen, wie der Einsatz von Werkzeugen oder die Abstellung eines Designerteams für die Entwicklung der Oberfläche eingeführt werden. Da alle Evaluationsmethoden zumindest einen Prototypen benötigen, sollte auf dessen schnelle Entwicklung großen Wert gelegt werden. Vor allem Schichtenkonzepte, die die Oberfläche von der Anwendung selbst trennen, ermöglichen die parallele Entwicklung eines solchen. Es sei an dieser Stelle beispielhaft auf das 1983 entwickelte Seeheim-Modell hingewiesen.

5.1 Prototyping

Die Benutzung von Prototypen ist auch außerhalb der Informatik weit verbreitet. Aus diesem Grund gibt es verschiedenste Ansätze für eine Definition. Aus Sicht des Entwicklers von Benutzungsschnittstellen ist ein Prototyp die Simulation von Aussehen und Verhalten eines Softwaresystems (vgl. [HoHi97] S. 368). Damit kann bereits während der Entwicklung einer Anwendung ein konstruktiver Dialog zwischen Benutzern, Programmierern und Oberflächendesignern in Gang gesetzt werden. Dieser lenkt die grundsätzlich iterative Entwicklung von Prototypen. Studien ergaben, dass durch den engen Kontakt zu den Benutzern die entwickelten Oberflächen leichter zu erlernen und zu benutzen sind (vgl. [HiHa93] S. 258). Hinzu kommt, dass Anwender die Brauchbarkeit eines vorhandenes System besser bewerten können als Anforderungen an dieses zu beschreiben. Ein weiterer positiver Aspekt besteht darin, dass die Benutzer sich mit dem neuen System bereits vertraut machen können. Dadurch verkürzt sich die Lernphase nach der Produkteinführung. Durch die Einbeziehung der Benutzer steigt gleichzeitig die Akzeptanz gegenüber dem Anwendungssystem. Daraus folgt, dass Prototypen in einer kurzen Zeitspanne für Demonstrationszwecke einsetzbar sein müssen. Aus diesem Grund können sie nur einen begrenzten Umfang der Gesamtfunktionalität enthalten. Durch ständige Evaluierung durch Benutzer und Entwickler und anschließende Erweiterung und Anpassung des Prototypen wird dieser nach und nach in das Endprodukt überführt. Um den Funktionsumfang einzugrenzen, können entweder horizontale oder vertikale Prototypen entwickelt werden. Diese können nur Teile des Gesamtsystems darstellen. Vor allem in frühen Projektphasen ist es oft nicht möglich, einen komplett integrierten Prototypen zu erstellen.

5.1.1 Horizontaler Prototyp

Bei dieser Art von Prototypen wird die Tiefe, die die Funktionalität des Systems widerspiegelt, ausgeblendet. Die Oberfläche ist im allgemeinen komplett dargestellt. Typische Beispiele sind komplette Fenster mit Menüeinträgen, Listen, Kombinationsfeldern und anderen Bildschirmelementen. Eine Dateneingabe ist genauso wenig möglich, wie die Auswahl einer Systemfunktion. Der Benutzer bekommt damit einen Gesamteindruck, wie die Anwendung später aussehen wird und welche Funktionen an welchen Stellen bereit gestellt werden. Damit kann beispielsweise die globale Metapher des Systems evaluiert werden. Eine Bewertung der Effizienz ist nicht möglich, da keine Aufgaben durchgespielt werden können. Es lassen sich lediglich begrenzte Aussagen über die Effektivität machen. Horizontales Prototyping wird meist für sehr zeitig entwickelte Prototypen eingesetzt.

5.1.2 Vertikaler Prototyp

Bei dem vertikalen Prototypen wird die Funktionalität eines kleinen Teilbereiches komplett realisiert. Damit kann der Benutzer diese Teilaufgabe umfassend bearbeiten. Sowohl Dateneingabe, -verarbeitung und -ausgabe sind möglich. Der Prototyp stellt insofern bereits eine fortgeschrittene, dem Endprodukt nahe Realisierung dar. Damit lässt sich eine konkrete Evaluierung der umgesetzten Funktionen vornehmen.

5.1.3 Szenario

Werden beide Strategien gemischt eingesetzt, nennt man den so entstehenden Prototypen Szenario. In diesem ist eine minimale Funktionalität implementiert. Der Benutzer kann sowohl Oberflächendarstellung als auch Funktionalität bewerten. Es werden jedoch keinerlei Freiheiten im Sinne von alternativen Lösungsmöglichkeiten für den Benutzer angeboten. Das Szenario bestimmt die Umstände und Zeitabläufe der modellierten Aufgabe. Damit kann bereits in einer frühen Phase die Nutzung einer bestimmter Funktionen beschrieben und getestet werden, ohne einen kompletten Prototyp entwickeln zu müssen.

5.1.4 Entwicklung des Prototypen

Bei der Entwicklung von Prototypen steht das Hauptziel, schnell ein Ergebnis zu erzielen im Vordergrund. Dabei ist der Grad an Ausgereiftheit eines Prototypen nicht gleichzeitig der Grad an aussagekräftigen Ergebnissen (vgl. [Prei99] S. 236). In Studien wurde gezeigt, dass Benutzbarkeitsprobleme sowohl an einem realen System als auch an Papierskizzen gleichermaßen erkannt wurden. Ganz im Gegenteil laden unfertig aussehende Skizzen vielmehr dazu ein, über Varianten nachzudenken. Fertig scheinende Prototypen sind für eine kreative Diskussion nicht geeignet. Das legt nahe, am Anfang eines Projektes, durchaus mit Skizzen o.ä. zu arbeiten. In späteren Phasen folgt die Entwicklung eines Systems, um eine reale Demonstration zu ermöglichen. Dabei gibt es einige Punkte zu beachten, die eine Beschleunigung des Prototyping ermöglichen (vgl. [Prei99] S. 235). Speicher- oder Zeitoptimierung sind im allgemeinen zu vernachlässigen. Um eine effiziente Entwicklung zu ermöglichen, sollte ein leistungsfähiges Computersystem genutzt werden, dass durchaus deutlich besser als das spätere Zielsystem sein kann. Ein Prototyp kann auch mit fehlerhaftem Kode hilfreich für die Weiterentwicklung sein, da davon der Test nur wenig beeinflusst wird. Sonderfälle sollten im allgemeinen nicht im Prototyp realisiert werden, sondern erst im Endprodukt. Viel Zeit kann auch durch den Einsatz von Pseudodaten eingespart werden. Dabei wird die Komplexität der realen Daten gesenkt indem Datensätze geringeren Umfangs benutzt werden.

Prototyping, als Vorgang der Entwicklung eines Prototyps, sollte jedoch nicht nur schnell sondern auch flexibel und einfach gestaltet sein. Zum einen ist es wichtig, die Kosten für Prototyping gering zu halten, zum zweiten soll vermieden werden, dass sich der Entwickler zu sehr mit dem Prototyp identifiziert und gegen Veränderungen inflexibel wird.

Um die oben genannten Anforderungen zu unterstützen, wurde in der Vergangenheit ein Vielzahl von Werkzeugen entwickelt. Damit soll der Aufwand für die Programmierung gesenkt oder ganz beseitigt werden. Die Entwicklung von Prototypen unter Einsatz von Werkzeugen wird unter dem Begriff Rapid Prototyping subsumiert. Eine Erweiterung stellt das Interactive Prototyping dar. Bei diesem kann der Benutzer den Prototyp während des Testlaufs manipulieren.

5.2 Werkzeuge

Werkzeuge sind im hier betrachteten Kontext Anwendungssysteme, die die Entwicklung von Software unterstützen. Sie sind auf verschiedenen Abstraktionsebenen – von systemnaher Programmierung bis zu benutzungs- und anwendungsnaher Modellierung – angesiedelt (vgl. [VoNe98] S. 12). Ein genereller Trend geht zu den objektorientierten Systemen mit vorgefertigten Dialogelementen hin. Das Baukastenprinzip, das in den meisten Werkzeugen die zugrunde liegende Metapher ist, ermöglicht eine einfache Anpassung der Elemente durch Änderung von Parametern. Durch die Vererbungstechniken können den Dialogelementen neues Verhalten und Aussehen verliehen werden. In modernen Werkzeugen werden die statischen Aspekte einer Benutzungsschnittstelle grafisch entwickelt. Dabei wird die WYSIWYG-Technik angewandt, bei der der Entwickler sofort sehen kann, wie der Dialog in der Anwendung später aussieht. Der Programmieraufwand wird dadurch entscheidend gesenkt. Werden Dialogelemente in ihrer Funktionalität erweitert oder verändert, so können diese in den meisten Werkzeugen integriert und benutzt werden. Ein Beispiel dafür ist das Konzept der Java Beans. Die einheitliche Verwendung von Dialogelementen führt auch anwendungsübergreifend zu einem hohem Grad an Konsistenz. Zusätzlich unterstützen Style Guides die Konformität. Dieser hohe Grad an Standardisierung hat jedoch auch Nachteile. So sind viele Komponenten weit verbreitet und bei Benutzern akzeptiert. Änderungen bzw. Innovationen an diesen Elementen werden als störend empfunden. Durch die fehlende Toleranz des Anwenders können sich diese nicht durchsetzen.

Die einfachste Unterstützung bilden User Interface Toolkits (UI-Toolkits). Ein UI-Toolkit stellt sich dem Programmierer als Bibliothek von Prozeduren oder Klassen mit standardisierten Dialogelementen dar (vgl. [VoNe98] S. 13). Durch Aufruf der Prozeduren oder Instanziierung der Klassen werden Interaktionselemente erzeugt. Entsprechend den Anforderungen können diese Elemente auf dem Bildschirm angeordnet, miteinander kombiniert und konfiguriert werden. Die Begrenzung der Darstellungsmöglichkeiten durch Parameter führt zu einem einheitlichen Look and Feel. Objektorientierte UI-Toolkits bieten die Möglichkeit, neue Klassen zu bilden. Durch diese kann neues Aussehen und Verhalten für bestimmte Elemente erzeugt werden. Application Frameworks sind erweiterte und spezialisierte objektorientierte UI-Toolkits. Ein Framework ist eine Sammlung von kooperierenden Objekten, die eine integrierte Lösung eines bestimmten Anwendungsgebietes anbieten und durch den Entwickler oder Benutzer angepasst werden können (vgl. [Buzb98]). Damit liefert der Framework bereits einen Lösungsvorschlag, der durch Unterklassenbildung der vorgegeben Elemente konkretisiert wird.

Im Gegensatz zu den bisher besprochenen Werkzeugen bewegen sich User Interface Builder oberhalb des Programmiersprachenniveau (vgl. [VoNe98] S. 15). Ein UI-Builder gibt dem Entwickler die Möglichkeit, die Benutzungsschnittstelle grafisch zu konstruieren. Er stellt die Elemente eines Toolkits durch Menüs oder Paletten dar. Diese können durch den Entwickler direkt-manipulativ ausgewählt und positioniert werden. Die Modifikation der Eigenschaften, wie beispielsweise Farbe, Höhe und Breite wird auch grafisch unterstützt. Ein UI-Builder setzt auf einem UI-Toolkit auf. Die durch den Entwickler konstruierten Bildschirmdarstellungen werden in Kode gewandelt. Dieser kann durch das unterstützte Toolkit interpretiert werden, womit wieder ein einheitliches Look and Feel erzeugt wird. Der Vorteil der UI-Builder besteht darin, dass sich der Entwickler die Prozeduren, Klassen und Parameter des Toolkits nicht merken muss. Damit können sie auch von Designern ohne Programmierkenntnisse genutzt werden. UI-Builder bieten in den meisten Fällen einen Testmodus an. In diesem kann die entwickelte Oberfläche evaluiert werden, ohne zuvor eine länger dauernde Kodegenerierung und Übersetzung durchzuführen.

Eine noch umfangreichere Unterstützung bieten User Interface Management Systeme (UIMS). Diese beinhalten sowohl ein UI-Toolkit als auch einen UI-Builder. Zusätzlich bieten sie eine eigene Sprache an, um das Dialogverhalten formal zu spezifizieren. Analog zu einem Datenbank Management System (DBMS) wird während der Laufzeit der Anwendung daraus die Oberfläche generiert. Einige Systeme steigern die Leistung während der Ausführung, indem sie die Spezifikation vor der Ausführung in eine effizienter interpretierbare Form übersetzen. Moderne UIMS passen ihre eigene Sprache an die Objektstruktur des benutzten UI-Toolkits an. Neuere Systeme enthalten eine Vielzahl von einzelnen Werkzeugen. Sie können beispielsweise einen Icon-Designer oder Bildeditor integrieren. In diesen Fällen spricht man auch von User Interface Development Environments (UIDE).

Zur Veranschaulichung der verschiedenen Werkzeugebenen dient die in Abbildung 10 gezeigte Architektur. Jede einzelne Schicht nutzt die direkt zugänglichen darrunterliegenden Schichten.

Wie die Abbildung andeutet, sind anspruchsvolle Benutzungsschnittstellen nur realisierbar, wenn man für bestimmte Teilbereiche direkt auf das Basis-Window-System zugreift. Dies zeigt auch die Begrenztheit aktuell verfügbarer Werkzeuge.

Bei der Entwicklung von Software gibt es viele Gebiete, die durch Werkzeuge unterstützt werden können. Jedes Werkzeug hat sowohl Stärken als auch Schwächen, die aus den verschieden Zielen resultieren. So sind beispielsweise UIMS für industrielle Anwendungen besonders auf zeitliche Aspekte ausgerichtet. Aus diesem Grund müssen für jedes Entwicklungsprojekt die Anforderungen an das zu verwendende Werkzeug definiert werden. Diese Kriterien werden von den Zielen und Rahmenbedingungen des Softwareprojektes beeinflusst. Im Ergebnis entsteht eine Katalog, der die Auswahl von geeigneten Werkzeugen ermöglicht.

Im folgenden werden vier Werkzeuge getestet und ihre Brauchbarkeit für Prototyping bewertet. Die Auswahl wurde durch folgende Bedingungen eingegrenzt. Da der GME 2001 auf der Basis von Java entwickelt wird, sollte das Werkzeug ebenfalls diese Sprache unterstützen. Der Prototyp soll nicht nur horizontal sondern auch vertikal ausgerichtet sein. Das heißt, dass teilweise Funktionalität implementiert werden muss. Damit entfallen alle Werkzeuge, die lediglich eine statische Oberfläche darstellen können. Bei der abschließenden Bewertung standen vor allem Aspekte des Prototyping und damit der Geschwindigkeit im Vordergrund. Die Ergebnisse des Vergleichs wurden im Anhang A.1 in einer Tabelle zusammengefasst. An dieser Stelle befindet sich auch die Spezifikation des benutzten Testsystems. Dieses ist laut Herstellerangaben der zu prüfenden Werkzeuge als ausreichend beschrieben.

5.2.1 VisualAge for Java, Entry Edition 3.0

IBM bietet mit seinem VisualAge for Java eine integrierte Entwicklungsumgebung für die Programmiersprache Java an. Das Produkt wird in drei Versionen ausgeliefert. Die hier betrachtete Entry Edition wird kostenlos vertrieben. Sie beinhaltet alles um einfache Applikationen bzw. Applets zu programmieren. Allerdings darf bei ihr ein Projekt maximal aus 750 Klassen bestehen. Die Professional und Enterprise Edition sind kostenpflichtig und erweitern den Funktionsumfang. Alle Versionen stehen für die Plattformen MS Windows, Solaris und Unix zur Verfügung. Das JDK ist fest im Programm integriert. D.h. dass neuere Versionen erst genutzt werden können, wenn IBM dafür ein Update released. Die Version 3.0 wird mit dem Java Development Kit 1.2 sowie mit der Java Foundation Class Version 1.0.3 ausgeliefert.

Die Installation gestaltet sich sehr einfach und benötigt ca. 200 MB Festplattenkapazität. Nach dem Programmstart, der knapp eine Minute dauert, erscheint als erstes ein Wizard, der durch die Erstellung eines neuen Projektes führt. Die empfohlenen 64 MB Arbeitsspeicher erscheinen zu wenig, da das Programm bereits ca. 50 MB Speicher belegt. Hinzu kommt, dass für jedes neue Bearbeitungsfenster weiter fünf MB belegt werden. Nachdem das neue Projekt erstellt wurde, befindet man sich im Workbench, dem Arbeitsplatz. Dieser ist Ausgangspunkt für alle Aktivitäten. Er listet alle Projekte, Packages, Klassen und Interfaces auf. Von hier aus können Arbeitsstände importiert und exportiert sowie die Versionierung durchgeführt werden. Damit ermöglicht er die Navigation durch das gesamte Projekt. Der Import bzw. Export wird benötigt, da IBM in VisualAge for Java ein Repository für die Speicherung aller Daten benutzt. D.h., dass sowohl alle Quellkodes als auch die übersetzten Bytekode in einer eigenen Datenbank gesichert werden. Um die Daten im Repository anzusehen, hat IBM den Repository Explorer integriert. Mit ihm kann durch die gesamte Datenbank navigiert werden. Projekte, Klassen, Interfaces können von hier aus in den Workbench transferiert werden. Erst dann ist eine Bearbeitung bzw. Nutzung dieser möglich. Das Repository unterstützt ebenfalls eine Versionsverwaltung. Es ist möglich, einem Projekt, einzelnen Klassen oder Interfaces Versionen zuzuteilen und zu verwalten. Dies stellt jedoch nur einen einfachen Mechanismus und kein durchgängiges Konfigurationsmanagement dar.

Nach Anlegen oder Öffnen eines Projektes kann man neue Klassen mit Hilfe eines Wizard erstellen. Diese werden in einem Bearbeitungsfenster modifiziert, in dem die eigentliche Programmierung stattfindet. Das Hauptaugenmerk liegt dabei auf dem Visual Composition Editor. In diesem werden alle visuellen Komponenten angezeigt. Auf der linken Seite befindet sich eine Palette aller im Moment verfügbaren Beans. Standardmäßig sind alle AWT und Swing Komponenten eingestellt. Weitere Standardelemente sowie eigene Entwicklungen können hinzugefügt werden. Die einzelnen Komponenten werden mittels Drag and Drop in dem Arbeitsbereich platziert. Mit Hilfe eines Eigenschaftseditor können ihre Eigenschaften (engl.: property), wie Größe, Namen, Ausrichtung usw. geändert werden. IBM hat in dem Visual Component Editor das Konzept der Connections umgesetzt. Damit kann jedem Ereignis (engl. event), welches von einem Bildschirmelement ausgelöst wird, eine entsprechende Aktion zugewiesen werden kann. Dazu klickt man mit der Maus auf das entsprechende Ereignis der Quellkomponente und anschließend auf eine Methode des Zielobjektes. Rein theoretisch ist es damit möglich, ganze Anwendungen zu programmieren, ohne eine einzige Zeile Kode zu schreiben. Über das Symbol Run kann die programmierte Anwendung gestartet werden. Positiv überrascht die schnelle Ausführungsgeschwindigkeit. Das liegt vor allem in der Maßnahme begründet, dass Klassen beim Speichern im Repository gleichzeitig übersetzt werden und damit auch als Bytekode vorliegen.

VisualAge for Java bietet einen integrierten Debugger. Threads können gestoppt und wieder fortgesetzt werden, Variablenwerte angesehen und modifiziert werden. Breakpoints werden ebenfalls unterstützt. Zusätzlich ist die Nutzung relationaler Datenbanken möglich. Die Internationalisierung wird mit dem von IBM implementierten Java Internationalization Framework unterstützt. Das Programm ermöglicht die Anbindung von externen Konfigurationsmanagementsystemen. Der größte Nachteil von VisualAge for Java liegt bei dem fest integriertem JDK. Da der GME 2001 mit dem JDK 1.3 implementiert werden soll, eignet sich das Produkt für die Entwicklung des Prototypen nicht.

5.2.2 Forte for Java, Community Edition 1.0

Sun microsystems selbst bietet mit Forte for Java eine Integrierte Entwicklungsumgebung an. Wie IBM gibt es auch dieses Produkt in drei Versionen. Die Community Edition ist für nicht kommerzielle Nutzung ohne Einschränkung frei benutzbar. Ein Teamunterstützung ist in dieser Version nicht enthalten. Die Internet Edition sowie die Enterprise Edition sind kostenpflichtig. Auch Sun microsystems unterstützt die Plattformen Solaris, MS Windows und Unix.

Die Installation gestaltet sich ähnlich einfach bei VisualAge for Java. Der einzige zusätzliche Schritt ist die Abfrage des Installationspfades des JDK. Da Forte for Java nicht explizit an eine bestimmte Version des JDK gebunden ist, wird es auch ohne ein solches ausgeliefert. Dadurch lässt sich ein Update auf eine neue Version des JDK durchführen, ohne eine neue Version von Forte for Java zu benötigen. Mit nur 30 MB Festplattenbedarf benötigt es am wenigsten Platz von den hier getesteten Tools. Nach dem Start des Programms, erscheinen Haupt-, Explorer- und Eigenschaftsfenster. Bereits zu diesem Zeitpunkt werden knapp 60 MB Arbeitsspeicher belegt.

Anschließend kann man mit einem neuen Projekt beginnen oder den Einstieg mit dem Hilfesystem suchen. Der Getting Started Guide beschreibt kurz die Erstellung einer kleinen Applikation.

Startet man ein neues Projekt können anschließend neue Klassen wie beispielsweise Fenster, Java Beans oder JSP über den Template Chooser angelegt werden. Dieser stellt eine einfachere Form eines Wizard dar. Er ermöglicht lediglich die Auswahl aus vorgefertigten Mustern. Navigiert wird in Forte for Java mit Hilfe über des Explorerfensters. In diesem erscheinen alle visuellen sowie nicht visuellen Komponenten. Im Hauptfenster kann man zwischen den fünf Workspaces Editing, GUI-Editing, Browsing, Running und Debugging wechseln. Alle Fenster sind grundsätzlich einem Workspace zugewiesen. Der Editing Workspace dient ausschließlich zum modifizieren der Java Quelldateien. Forte for Java verzichtet auf die Benutzung eines speziellen Repository und speichert alle Daten in normalen Java-Quelldateien. Den Designmodus stellt der Workspace GUI-Editing bereit. Hier wird der aktuell ausgewählte Container, z.B. ein Fenster, grafisch dargestellt. In diesen können Komponenten über die Komponentenpalette eingefügt werden. Die Komponentenpalette kann durch den Benutzer selbst erweitert werden. Über den Eigenschaftseditor werden die Attribute wie Farbe, Position oder Name gesetzt. Ebenso können hier den Ereignissen Methoden zugeordnet werden. Übersetzt und startet man das Projekt, wird automatisch in den Workspace Running gewechselt. Hier findet sich das typische Outputfenster sowie ein Execution View Fenster. Dieses listet alle aktiven Threads der Java-Applikation auf. Im Workspace Debugging kann man sein Projekt nach Fehlern durchsuchen. Er ermöglicht das Setzen von Breakpoints sowie die Anzeige der überwachten Variablen und Ausdrücke.

Eine gute Unterstützung bei der Eingabe bietet die dynamic code completion. Nach dem Eintippen eines Klassennamens öffnet sich eine Liste, die alle dazugehörigen Methoden und Eigenschaften anzeigt. Zum einen verkürzt sich die Zeit beim Schreiben, zum anderen wird die Anzahl der Tippfehler gesenkt. Durch den modularen Aufbau des Produktes kann es ständig ergänzt und erweitert werden. Dabei müssen diese Module nicht von Sun microsystems sein.

Beim Ausführen eines Projektes steigt der Ressourcenverbrauch stark an. So werden selbst bei kleinen Anwendungen 130 MB Speicher genutzt. Daraus resultieren relativ lange Wartezeiten während der Entwicklung. Auch der Wechsel von Workspaces kann sehr lange dauern. Damit ist Forte for Java für die Entwicklung von Prototypen ungeeignet.

5.2.3 VisualCafé 4.0 Standard Edition

Die Firma WebGain bietet ebenfalls eine IDE für Java an. Auch dieses Produkt gibt es in drei Varianten, die hier getestete Standard Edition, eine Expert Edition sowie eine Enterprise Edition. Die Standard Edition ist für den privaten Gebrauch frei. WebGain unterstützt lediglich die Plattform MS Windows. Die entwickelten Java Anwendungen können auch auf anderen Plattformen genutzt werden.

Die normale Installation benötigt ca. 500 MB Festplattenspeicher und ist mit über 13.000 Dateien sehr umfangreich. Die Konzentration auf nur eine Plattform hat positive Auswirkungen auf den Ressourcenverbrauch des Produktes. So startet das Programm innerhalb von acht Sekunden und belegt lediglich 20 MB Hauptspeicher. Beim Anlegen eines neuen Projektes kann man sich zwischen verschiedenen Vorlagen entscheiden. Diese können durch eigene Projekte erweitert werden.

Anschließend befindet man sich im Workspace Edit. Dieser besteht aus dem Hauptfenster, in dem sich die Komponentenpalette befindet, dem Projektexplorer, dem Formdesigner sowie dem Property-List Fensters. Im Projektexplorer werden alle Objekte, Klassen und Dateien des aktuellen Projektes angezeigt. Er dient zum navigieren. Der Formdesigner stellt alle visuellen und nicht visuellen Komponenten des aktuellen Container dar. Die Darstellung der zweiten Gruppe ist für die Nutzung des Connection Wizard sinnvoll. Das Property-List Fenster zeigt alle Eigenschaften eines Objektes an. Hier können beispielsweise Größe, Farbe oder Positionen eingestellt werden. Der Connection Wizard verbindet, ähnlich wie bei VisualAge for Java, Ereignisse mit bestimmten Aktionen. Die Zuordnung wird mit der Maus durchgeführt. VisualCafé bietet für häufig benötigte Aktionen vorbereitete Methoden an. Benötigte Parameter können entweder automatisch durch Eigenschaften anderer Objekte oder manuell übergeben werden. Bei Anwendung des Connection Wizard können sehr schnell Anwendungen mit umfangreicher Funktionalität entwickelt werden. Dabei muss kein Java Quellkode eingegeben werden.

Der zweite Standard Workspace heißt Debug, mit dem ein Testen des Projektes ermöglicht wird. Es werden Fenster zur Variablenüberwachung eingeblendet. VisualCafé gestattet es dem Benutzer eigene Workspace zu erstellen, umzubennen sowie zu löschen. Hinzu kommen umfangreiche Möglichkeiten die Entwicklungsumgebung anzupassen. Die Speichernutzung steigt während der Projektausführung auf ca. 50 MB. Damit benötigt das Produkt von den getesteten Werkzeugen den wenigsten Speicher.

Dieser Vorteil wird hauptsächlich durch die Plattformabhängigkeit erkauft. Diese ist aber vor allem beim Oberflächendesign von Nachteil. Es ist unbedingt zu empfehlen, ein Projekt auf allen Plattformen zu testen, auf denen es später angewendet werden soll. Ein weiterer Nachteil ist die Abhängigkeit vom mitgelieferten JDK. Damit ist auch dieses Tool nicht für die Entwicklung des Prototypen GME 2001 geeignet.

5.2.4 JBuilder 4.0 Foundation

Borland/Inprise bietet mit dem JBuilder ebenfalls eine Java Entwicklungsumgebung an. Auch dieses Produkt gibt es in drei verschiedenen Varianten. Die Foundation Edition ist kostenlos zu erhalten. Die Professional sowie die Enterprise Edition erweitern den Umfang der Foundation um Funktionen wie Datenbankzugriff, Teammanagement oder Versionsverwaltung.

Das Programm richtet bei der problemlos verlaufenden Installation das JDK Version 1.3 ein. Dieses kann jedoch gegen eine beliebige Version ausgetauscht werden. Nach dem Programmstart, ist das Hauptfenster sichtbar. Die Speicherbelastung, ist mit 30 MB relativ gering. Der JBuilder besteht im Gegensatz zu den anderen Werkzeugen nur aus einem Fenster, in dem alle Elemente wie Projektbrowser, Strukturbrowser, GUI-Builder und Editor eingebettet sind.

Der Projektbrowser ermöglicht die Navigation durch das gesamte Projekt. Er zeigt alle verfügbaren Klassen an. Der Strukturbrowser zeigt die innere Organisation der aktuell ausgewählten Klasse an. Dies ist vor allem für Fenster von Vorteil. Im Arbeitsbereich kann zwischen verschiedenen Sichten gewechselt werden. Diese sind analog zu den Workspaces der anderen Werkzeugen. Der Editor ist wie auch in forte for Java mit einer dynamic code completion ausgestattet. Bei visuellen Klassen kann die Darstellung im GUI-Builder erfolgen. Zusätzlich wird ein Eigenschaftseditor und die Komponentenleiste angezeigt. Mittels Drag and Drop können die Bildschirmelemente in dem Fenster platziert werden. Die Manipulation ihrer Attribute erfolgt mit Hilfe des Eigenschaftseditor. Dieser zeigt auch alle Ereignisse des momentan aktiven Elementes an. Diesen kann direkt Java Quellkode zugewiesen werden, der jedoch programmiert werden muss. Weitere Sichten im Arbeitsbereich sind die Dokumentation und die Versionsverwaltung. Die Versionsverwaltung ist ähnlich einfach wie bei VisualAge for Java gehalten. Die Dokumentation wird in HTML-Form verwaltet.

Der JBuilder bietet eine Vielzahl von Individualisierungsmöglichkeiten. So kann man beispielsweise Quellkode als Vorlage (engl.: template) anlegen. Diese kann mit einem Ereignis einer Klasse verknüpft werden. Damit kann ein ähnliches Konzept wie das des Connection Wizards in VisualCafé aufgebaut werden.

Auch während der Ausführung bleibt der Speicherbedarf mit ca. 55 MB relativ gering. Lediglich im Debug-Modus wird die Entwicklungsumgebung deutlich langsamer. Vorteile sind die Unabhängigkeit sowohl von der Version des JDK als auch von der Plattform des Betriebssystems. Die grafische Gestaltung von Fenstern ist einfach und schnell durchzuführen. Eine Erweiterung mit Funktionalität ist ohne Schwierigkeiten durchführbar.

Aus den genannten Gründen wird der Prototyp GME 2001 mit Hilfe des Werkzeuges JBuilder 4.0 entwickelt.

5.3 Entwicklung des Prototypen GME 2001

Im Rahmen der Diplomarbeit wurde ein Prototyp für den Generischen Modelleditor 2001 (GME 2001) entwickelt. An diesem Projekt wird seit Februar 2000 an der TU Dresden am Lehrstuhl für Systementwicklung intensiv gearbeitet (vgl. [Grei00a]). Das Ziel ist die Entwicklung eines innovativen Modellierungswerkzeuges.

Der Prototyp ist in dem Bereich Division Client des Projektes angesiedelt. Dieser Teil beschäftigt sich mit der Entwicklung der Clients. Diese sind auf die Servermodule aufgesetzte Anwendungen, die die Kommunikation zwischen Modellierern und Datenbank (Repository) übernehmen. Damit fällt in diesen Bereich auch die Entwicklung einer Benutzungsschnittstelle. Der hierfür entwickelte Prototyp soll vor allem die herausgearbeiteten ergonomischen Aspekte beachten. Der GME 2001 wird mit der Programmiersprache Java implementiert. Daraus ergibt sich, dass auch der Prototyp für die Oberfläche in Java umgesetzt wird. Die Benutzung einer einheitlichen Sprache ist zwar nicht zwingend erforderlich, vereinfacht aber die iterative Entwicklung. Für die Umsetzung wird das Werkzeug JBuilder 4.0 verwendet. Es ist eine der schnellsten Entwicklungsumgebungen für Java-Applikationen. Zusätzlich kann das aktuelle Java Development Kit 1.3 verwendet werden, mit dem bereits vorhandene Teile des GME 2001 implementiert wurden.

5.3.1 Beschreibung des E³-Ansatz

Der Generische Modelleditor 2001 basiert auf dem E³-Ansatz. Dieser Ansatz verfolgt das Ziel, Modellbeschreibungen zu standardisieren. Unter einem Modell wird eine formale Sprache zur Beschreibung von Schemata verstanden. Schemata sind formale Abbildungen von realen Sachverhalten bzw. Problembereichen (vgl. [GrEs01] S. 5). Ein Meta-Modell ist eine formale Sprache zur Beschreibung von Modellen (vgl. [FeSi98] S. 119). Eine Gruppe von Bestandteilen oder der Ausschnitt eines Schemas wird als View bezeichnet. Die Darstellung einer View wird als Präsentation definiert.

Das E³-Modell ist ein Meta-Modell, das die einheitliche Definition von Modellen ermöglicht. Es gliedert sich in zwei Teile, der Typebene und der Instanzenebene. Die Typebene nimmt alle Modelle der Beschreibungsmodelle auf (vgl. [GrEs01] S. 8). Die Modelle werden im GME 2001 im Typeneditor erstellt und bearbeitet. Die Instanzenebene nimmt alle Ausprägungen dieser Modelle, also alle Schemata auf. Diese werden im GME 2001 im Schemaeditor bearbeitet. Die Typ und Instanzenebene werden vertikal in die drei Teile Kontextebene, Viewebene und Präsentationsebene unterteilt. Das Modell wird zur Verfeinerung auch horizontal in drei Ebenen gegliedert. Daraus ergeben sich insgesamt 18 Berührungspunkte, die als E³-Elemente bezeichnet werden (vgl. Anhang A.2). Auf die genaue Beschreibung der einzelnen Elemente und ihre Beziehungen untereinander wird hier nicht eingegangen.

5.3.2 Ziele des Prototypen

Bei der Erstellung des Prototypen ergeben sich zwei Hauptgebiete. Die erste Aufgabe umfasst die Beschreibung der Oberfläche des gesamten GME 2001. Hierzu wurde der Prototyp horizontal ausgerichtet. Dabei standen verschiedene Anforderungen im Vordergrund:

• Unterstützung eines Konfigurationsmanagement
• Teamfähigkeit
• verteilte Architektur

Die zweite Aufgabe betrifft die Entwicklung des Typeneditors. Bei diesem wurde auch Funktionalität implementiert. Dazu wurde der Prototyp zusätzlich vertikal ausgerichtet. Besondere Beachtung muss dem Umstand beigemessen werden, dass es in der neuen Spezifikation des E3-Modells möglich ist, Views auf Views zu bilden (vgl. Anhang A.3). Der Schemaeditor wurde im Prototyp nicht implementiert.

5.3.3 Spezifikation des Prototypen

Die Entwicklung des Prototypen begann mit der Erfassung der nötigen Informationen. Für den Arbeitsablauf war die bereits vorhandene Version 0.91 des GME hilfreich. Diese beinhaltet sowohl den Typeneditor, als auch den Schemaeditor. Die Anforderungen, die im Abschnitt 5.3.2 beschrieben wurden, erfordern jedoch eine umfassende Projektverwaltung. Der Benutzer wurde in der Anforderungsspezifikation des GME 2001 (vgl. [Grei00b]) als Modellierer definiert. Dieser hat ein grundsätzliches Verständnis über den Ablauf eines Modellierungsprojektes. Aus diesem Grund wurde auch diese Metapher im Workspace eingesetzt. Der Benutzer erhält den Eindruck, ein Projekt durchzuführen, in dessen Rahmen Modelle und Schemas erstellt bzw. bearbeitet werden. Diese Projektsicht wird in vielen Werkzeugen eingesetzt, was zu einer hohen Erwartungskonformität führt. Um eine entsprechende funktionale Oberfläche zu erhalten, wurden im zweiten Schritt Use case Diagramme sowie Klassendiagramme entwickelt (vgl. Anhang C.1). Diese wurden dann mit Hilfe des Tools JBuilder 4.0 in einen Prototypen umgesetzt.

Dabei wurde vor allem dem Workspace und dem Typeneditor Beachtung geschenkt. Beide Teile werden deshalb noch näher spezifiziert. Das Hilfesystem wurde durch einen HTML-fähigen Browser dargestellt (vgl. Abschnitt 3.4.6). Diese enthält keine Möglichkeiten zum Information Retrieval. Eine entsprechende Funktionalität muss noch ergänzt werden. Die Individualisierungsmöglichkeiten wurden angedeutet, jedoch nicht implementiert. Auch sie müssen noch ergänzt werden. Die im Prototyp verwendeten Icons sind zum größten Teil aus dem GME 0.91. Sie müssen entsprechend den Empfehlungen und Richtlinien dieser Arbeit (vgl. Abschnitt 3.4.4) noch überarbeitet werden.

5.3.3.1 Workspace

Der Workspace übernimmt die Verwaltung des gesamten Modellierungsprojektes. Er ist in die Bereiche Projektbrowser, Arbeitsbereich und Aufgabenmanagment unterteilt (vgl. Anhang A.4). Der Projektbrowser enthält alle Objekte des aktuell ausgewählten Projektes. Dazu gehören die Projektdaten, alle Schemata und Modelle, die Dokumentation, die beteiligten Mitarbeiter, Scripte und die Change Requests. Letzteres sind Änderungsanträge, die erst bei einem fortgeschrittenen Projektstatus erforderlich sind. Zusätzlich wurde die Kategorie sonstiges eingeführt, die als Ordner für alle zum Projekt gehörenden Dokumente dient. Das können beispielsweise vom Auftraggeber gelieferte Spezifikationen vorhandener Style Guides o.a. sein. Jedes Projekt wird durch die Klasse Project abgebildet. Die Spezifikation befindet sich im Anhang C.3.1. Der Arbeitsbereich passt seinen Inhalt entsprechend der Auswahl im Projektbrowser an. Hier werden die Detailinformationen zum gewählten Objekt angezeigt. Diese Informationen können an dieser Stelle direkt geändert werden. Voraussetzung ist eine entsprechende Berechtigung beim Benutzer. Das Aufgabenmanagement wird im Workspace durch eine Tabelle dargestellt. Diese zeigt für den angemeldeten Benutzer alle verfügbaren Einträge an. Eine Aufgabe wird im Prototyp durch die Klasse Task (vgl. Anhang C.3.2) abgebildet. Die Tabelle kann durch den Benutzer nach Verlangen entsprechend sortiert werden. Überfällige Aufgaben werden farblich hervorgehoben. Die Einführung des Aufgabenkonzeptes bringt zwei Vorteile. Zum einen kann der Benutzer seinen Arbeitsablauf selbst strukturieren. Zum anderen kann durch die Erstellung von Aufgaben, sowohl durch den GME 2001 selbst als auch durch andere Mitarbeiter, der Prozess gesteuert werden. Wechselt beispielsweise der Modellierer den Status eines Schemas von edit auf stable so kann der GME 2001 automatisch die Aufgabe "Schema testen" generieren. Sind mehrere Tester im Projekt vorhanden, so muss der Modellierer nur noch den entsprechend verantwortlichen Mitarbeiter auswählen. Die so generierte Aufgabe erscheint anschließend nicht im eigenen sondern im Workspace des Testers. Zusätzlich kann im Aufgabenmanager zu jedem Mitarbeiter eine Liste aller Aufgaben eingesehen werden. Der Aufgabenmanager wird in einem eigenen Fenster dargestellt. Damit können Engpässe durch den Projektleiter erkannt und beseitigt werden. Bei dieser Funktion sind jedoch Datenschutzbestimmungen zu beachten.

Für die Erstellung eines neuen Projektes, Modells, Schemas oder einer neuen Aufgabe wurden Wizards (vgl. Anhang A.5) implementiert. Diese unterstützen den Benutzer bei der Erfassung relevanter Daten. In den Wizards nicht erfasste Daten können zu einem späteren Zeitpunkt im Arbeitsbereich modifiziert und ergänzt werden.

Der aktuelle Arbeitsstand wird immer lokal gespeichert. Für die Überführung der lokalen Daten in das Repository bzw. zurück stellt der Workspace die zwei Funktionen Checkin und Checkout zur Verfügung. Beide Operationen werden ebenfalls mittels eines Wizards unterstützt. Vor allem für den Checkin, also die Überführung der lokalen Daten in das Repository, wird dieser benötigt. Ist die einzubringende Konfiguration bereits vorhanden, so muss der Benutzer über die weitere Behandlung entscheiden. Wird weder die Funktion branch noch die Funktion merge durchgeführt so muss lediglich eine neue Versionsnummer gebildet werden. Beim branch wird eine Verzweigung der Version vorgenommen. Es entstehen damit zwei Elemente mit einem gemeinsamen Vorgänger. Beim merge werden die lokalen Elemente mit den im Repository vorhandenen zu einem einzigen vereint. Es entsteht ein neues Element mit zwei Vorgängern.

Die jeweilig verfügbaren Versionen werden sowohl textuell, d.h. in Listen und Bäumen angezeigt, als auch als durch einen Konfigurationsgraph visualisiert. Dies ist im Prototyp nur durch entsprechende Bildschirmelemente angedeutet, jedoch nicht implementiert.

Der Workspace ermöglicht ebenfalls den Zugriff auf das Benutzermanagement, das Konfigurationsmanagement und die statistische Auswertung. Die Funktionen wurden nur angedeutet, jedoch nicht implementiert. Die statistische Auswertung soll vor allem zur Nachkalkulation der Projektkosten sowie als Erfahrungspool für zukünftige Projekte dienen.

Der Workspace gestattet es dem Benutzer ein neues Modell anzulegen. Dabei wird eine neue Instanz der Klasse Model erzeugt. Diese sammelt alle Informationen über das Modell (vgl. Anhang C.3.3). Der eigentliche Vorgang der Modellierung findet im Typeneditor statt. Dieser wird vom Workspace aus unter Angabe des relevanten Modells gestartet.

5.3.3.2 Typeneditor

Der Typeneditor dient zur Entwicklung von Modellen. Um die Gliederung des E3-Modells widerzuspiegeln, wurden die Kontext-, View- und Präsentationsebene nebeneinander dargestellt. Jede Ebene wird durch einen Baum visualisiert. Damit lassen sich die Verfeinerungen innerhalb der Ebene ebenfalls abbilden (vgl. Abbildung 11). Jedes Element in einem dieser Bäume entspricht einem E3-Element.

In der Kontextebene lassen sich ObjektTypen und ObjektPropertyTypen anlegen und löschen. Die neu erstellten Elemente dieser Ebene werden grundsätzlich grau dargestellt. In der Viewebene lassen sich nur ViewTypen anlegen. Diese können hierarchisch gegliedert werden. Damit können View- auf ViewTypen abgebildet werden. ViewObjektTypen und ViewPropertyTypen werden nur indirekt angelegt bzw. entfernt. Dazu wird der entsprechende ObjektTyp bzw. ObjektPropertyTyp selektiert und dem ViewTypen zugeordnet. Ist eine Zuordnung erfolgt, so wird das Element in der Kontextebene nicht mehr grau, sondern schwarz dargestellt. Daraus ergibt sich, dass alle grau dargestellten Elemente der Kontextebene in dem selektierten ViewTypen verfügbar sind. Wird ein untergeordneter ViewTyp selektiert, so werden alle dem übergeordneten ViewTyp zugeordneten ObjektTypen bzw. ObjektPropertyTypen grau dargestellt. Die restlichen Elemente sind in dem untergeordneten ViewTypen nicht verfügbar und werden ausgeblendet. Ein PräsentationsObjektTyp ist ebenfalls immer genau einem ViewTypen zugeordnet. Aus diesem Grund ändert sich die Menge der angezeigten PräsentationsTypen in Abhängigkeit der Selektion in der Viewebene. Die folgende Grafik verdeutlicht diesen Sachverhalt.

Die Abbildung 11 stellt den Typeneditor während der Benutzung dar. Aus der farblichen Gestaltung der Kontextebene lässt sich erkennen, dass ObjektTyp1 und ObjektTyp3 inklusive ObjektPropertyTyp0 bis ObjektPropertyTyp2 dem ViewTyp1 zugeordnet wurden. Der ObjektTyp0 und ObjektTyp2 werden hier nicht dargestellt, da diese für den selektierten ViewAufViewTyp0 nicht verfügbar ist. Diesem Typ wurde der ObjektTyp3 und zwei ObjektPropertyTypen zugeordnet, die damit in möglichen untergeordneten ViewTypen sichtbar sind. Dem ViewAufViewTyp2 ist ein PräsentationsTyp zugeordnet. Rechts von der Präsentationsebene ist der Eigenschaftseditor eingeblendet. Die in der Symbolleiste angezeigten Piktogramme weisen derzeit drei verschiedene Stilarten auf. Im Rahmen der iterativen Entwicklung muss diese ergonomische Schwäche noch beseitigt werden.

Die E3-Elemente besitzen unterschiedliche Eigenschaften, die im Eigenschaftseditor bearbeitet werden können. Dieser kann je nach Wunsch ein- bzw. ausgeblendet werden. Das Hinzufügen, Entfernen und Bearbeiten von Elementen wird über die jeweils links vom Baum abgebrachten Buttons realisiert. Die aktuelle Selektion in den verschiedenen Bäumen steuert ihre Verfügbarkeit. So kann ein PräsentationsObjektTyp nur angelegt werden, wenn in der Kontextebene ein ObjektPropertyTyp selektiert ist und dieser in der aktuell ausgewählten View eingebunden ist. Sind die Voraussetzungen nicht erfüllt, wird der Button disabled, d.h. der Benutzer kann ihn nicht anklicken. Der Zustand wird durch eine graue Darstellung des Button signalisiert.

Im unteren Teil des Typeneditor soll eine grafische Darstellung des E3-Modells angezeigt werden. Denkbar ist eine automatische Generierung von Struktur- oder Kontextdiagrammen. Die Darstellung wurde mit einer Grafik angedeutet, eine funktionale Implementierung existiert im Prototyp nicht.

 © yves köth