Konzeption einer generischen AJAX-Benutzerschnittstelle für das Naked-Objects-Framework

Inhaltsverzeichnis

1 Einleitung
1.1 Begriffe
1.2 Gegenstand und Motivation
1.2.1 Gegenstand
1.2.2 Problematik
1.2.3 Motivation

2 Das Naked-Objects-Framework
2.1 Einführung
2.1.1 Aufbau einer Naked-Objects-Anwendung
2.2 Entwicklung einer Naked-Objects-Anwendung
2.2.1 Implementierung der Domänenschicht
2.2.2 Implementierung von Fixtures
2.2.3 Implementierung von Services
2.3 Darstellung der Domäne im DND-Viewer
2.4 Die Repräsentation der Domänenschicht in der Applikationsschicht

3 Das Google Web Toolkit
3.1 Einführung
3.1.1 Das Konzept AJAX
3.1.2 Die Architektur des GWT und die Betriebsarten
3.1.3 Der GWT-Compiler
3.2 Die Konzepte des GWT
3.2.1 Aufbau einer GWT-Applikation
3.2.2 Die Kommunikation mit dem Server
3.2.3 Die grafischen Komponenten des GWT

4 Analyse und Umsetzung
4.1 Analyse der generischen Interaktion im Naked-Objects-Framework
4.1.1 Analyse der beteiligten Klassen
4.1.2 Identifizierung der signifikanten Daten
4.2 Entwurf des Datentransfer-Modelles
4.2.1 Vorüberlegung
4.2.2 Abbildung der Daten auf das DTM
4.2.3 Das resultierende DTM
4.3 Integration des DTMs in das Gesamtsystem
4.3.1 Transformation der Daten zwischen NOF und DTM
4.4 Die Verwendung des DTM
4.4.1 Abrufen einer Collection
4.4.2 Erstellung von Objekten am Client
4.4.3 Modifikation von Daten am Client

5 Fazit und Ausblick
5.1 Die Nutzung des DND-Viewers
5.2 Der Datenaustausch zwischen Client und Server
5.3 Ergebnis der praktischen Arbeit
5.4 Ausblick

Literaturverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

Tabellenverzeichnis

1 Einleitung

1.1 Begriffe

Client-Server-Architektur ist eine Systemarchitektur für verteilte Anwendungssysteme bei der Subsysteme (‚Server‘) bestimmte Dienste anbieten, die von anderen Subsystemen (‚Clients‘) nutzbar sind.[Fet])

Domänenobjekt wird in dieser Arbeit als Bestandteil der Anwendungslogik, das je nach Entwurfsabsicht geartet ist, verstanden. Es enthält bspw. Informationen darüber, wie es in einer generischen Benutzerschnittstelle dargestellt werden soll.

Framework wird laut der Definition von Michael Seemann benutzt: „Ein Framework zeichnet einen Lösungsweg vor [, an den man sich halten muss.] Technisch wird das so umgesetzt, dass der eigene Code vom Framework aufgerufen wird“ [S. 5 Rahmen See08])

Generische Benutzerschnittstelle ist eine Benutzerschnittstelle, die nicht für eine spezielle Anwendung entwickelt wird, sondern universell für verschiedene Anwendungen eingesetzt werden kann.

1.2 Gegenstand und Motivation

Funktionell, intuitiv, skalierbar und barrierefrei sind nur einige von vielen Anforde- rungen, die an grafische Benutzeroberflächen heutiger Softwareprodukte gestellt wer- den. Es liegt nahe, dass diese mit zunehmendem Aufwand entwickelt werden müs- sen. Wird bspw. der gesamte Zeitaufwand eines Softwareprojektes ins Verhältnis zum Zeitaufwand der Erstellung einer grafischen Benutzerschnittstelle gesetzt, so ergibt sich, dass ein erheblicher Teil der Arbeit ausschließlich darin besteht, einen intuitiven sowie vereinfachenden Zugang zum Kern einer Anwendung zu ermöglichen.

Für Softwareentwickler stehen verschiedene Hilfsmittel zur Verfügung, um grafische Benutzerschnittstelle einer Anwendung schnell und intuitiv per Drag & Drop zu er- stellen. Leider handelt es sich dabei nur um eine visuelle Darstellung ohne jegliche Funktionalität. Die Logik der Benutzerschnittstelle - die Interaktion zwischen Be- nutzer und Anwendungskern - muss weitestgehend Stück für Stück in jedem Projekt neu programmiert werden. Das hat zur Folge, dass sich bestimmte Arbeitsschritte in jedem Projekt ähnlich gestalten. Dadurch bietet sich allein schon aus ökonomischer Sicht genug Potential, Zeit und damit einhergehend Kosten zu sparen.

Mit dieser Motivation sucht man in der Softwareentwicklung nach Lösungen, die den Prozess der Benutzerschnittstellen-Entwicklung möglichst vollständig automatisieren. Der Vorteil hierbei liegt nicht nur darin begründet, Zeit für die substanziellen Bestandteile eines Softwareproduktes zu gewinnen, sondern auch, was auf lange Sicht wichtiger ist: Wiederverwendbarkeit von verifiziertem Quelltext zu erreichen. Nach Definition und Umsetzung einer generischen Benutzerschnittstelle, kann diese mit jeglicher Art von Anwendung verwendet werden.

Die Realisierung solcher Benutzerschnittstelle ist bspw. durch die Spezifikation des Naked-Objects-Architekturmusters gefordert. Dieses wurde von Richard Pawson und Simon Dobson entwickelt und auf der OOPSLA -Konferenz (Object-Oriented Pro- gramming, System, Languages & Applications) im Jahre 2001 einer breiten Öffent- lichkeit vorgestellt. Laut Definition wird unter anderem festgelegt, dass zu jedem Do- mänenobjekt eine Darstellung in einem so genannten Object Oriented User Interface (OOUI), zu deutsch Objektorientierte Benutzerschnittstelle, existiert. Diese ist vollau- tomatisch zu generieren. Seit Veröffentlichung des Naked-Objects-Architekturmusters entstehen Implementierungen in unterschiedlichen Programmiersprachen. Beispiele sind etwa Typical Objects for C++, dotObjects (eine Umsetzung in C#) und das Naked-Objects-Framework (Eine Umsetzung in Java und C#). Mit Letztgenanntem wird sich diese Arbeit ausführlich beschäftigen. Es handelt sich dabei um ein Open- Source-Framework, welches eine Umsetzung des Naked-Objects-Architekturmusters darstellt. Es wurde von Robert Matthews im letzten Jahrzehnt entworfen und fortlau- fend weiterentwickelt. Die zu dieser Arbeit vorliegende Version ist die 4.0.0. [Vgl. Nof]

Mit dem Framework wird nicht, wie in der klassischen Thin-Client-Architektur (Vier- Schichten-Architektur: Präsentationsschicht, Verarbeitungsschicht, Logikschicht, Per- sistenzschicht), auf vier Schichten verteilt entwickelt, sondern ausschließlich auf der so genannten Domänenschicht. Dort sind z. B. die Anwendungslogik, sowie Re- geln für die Darstellung in der OOUI definiert. Unter Nutzung des Naked-Objects- Frameworks (NOF) wird ausschließlich diese Schicht implementiert. Das spezielle Programmiermodel des Frameworks ermöglicht es bspw. Eigenschaften, Verhaltens- weisen und Validatoren von bzw. zwischen Objekten imperativ, durch Methodenauf- ruf, oder deklarativ, durch Java-Annotationen, zu definieren. Folglich befinden sich diese Charakteristika an der semantisch korrekten Stelle. Das begünstigt die Über- sichtlichkeit von aufwändigen Anwendungen. Eine weiterer Vorteil ergibt sich aus dem Fakt, dass es sich um eine Implementierung des Architekturmusters Naked- Objects handelt. Die vollautomatisch generierte objektorientierte Benutzerschnittstel- le ist in Form verschiedener Viewer umgesetzt. Diese können, sobald in der Domänen- schicht Verhalten definiert sind, eingesetzt werden. Die Entwicklung des so genann- ten DND-Viewers, der eine Benutzerschnittstelle umgesetzt mit dem AWT (Abstract Window Toolkit, Java) darstellt, und des HTML-Viewers ist am weitesten vorange- trieben. Darüber hinaus existieren noch weitere Viewerprojekte unterschiedlichster Entwicklungsstadien. Beispiele hierfür sind die Projekte Wicket-Objects (Viewerpro- jekt welches das Apache-Wicket-Framework einsetzt) und Scimpi-Viewer (Scimpi: ein leichtgewichtiges Webframework).

Ein aus heutiger Sicht wichtiges Konzept, welches in den letzten Jahren große Be- deutung für Webanwendungen erlangt hat, ist Asynchronous Javascript And XML (AJAX). Leider fehlt dieses gänzlich bzw. ist lediglich durch Dan Haywood, Mitent- wickler des NOF, als geplantes Projekt benannt worden. Ein positiver Aspekt, der für den Einsatz von AJAX - auch im Kontext von Naked-Objects - spricht, soll an die- ser Stelle besondere Erwähnung finden. AJAX-Anwendungen ‚fühlen‘ sich für den Benutzer wie Desktop-Anwendungen - trotz der Client-Server-Architektur - an. Es werden während der Benutzerinteraktion keine kompletten Webseiten, samt ihrer Gra- fikelemente, Stylesheets uvm., geladen, sondern ausschließlich die benötigten Daten. Hieraus ergibt sich die Möglichkeit eine AJAX-Benutzerschnittstelle in ähnlicher Art und Weise zu bedienen, wie es bspw. im NOF-eigenen DND-Viewer realisierbar ist.

Für die Umsetzung einer AJAX-Benutzerschnittstelle bietet sich unter anderem das Google Web Toolkit (GWT) an. Es wurde im Mai 2006 von Google veröffentlicht. Das besondere am GWT ist der enthaltene Java-zu-Javascript-Compiler (GWT-Compiler), der es ermöglicht die gesamte Anwendung, ob clientseitig oder serverseitig, komplett in Java zu implementieren. Das Benutzerinterface wird auf ähnliche Art und Weise, wie die Swing -Grafikbibliothek, welche einem großen Teil der Javaentwickler bekannt sein dürfte.

1.2.1 Gegenstand

Zentral betrachtet werden das Naked-Objects-Framework (NOF) und das GWT. Im Kapitel 2 wird nach der Einführung in die Entwicklung mit dem NOF eine beispiel- hafte Kundenverwaltungsanwendung vorgestellt. Darauffolgend wird veranschaulicht wie die NOF-eigene generische OOUI, in Form des DND-Viewer s, die Anwendung interpretiert bzw. umsetzt.

Kapitel 3 führt in die Konzepte des GWTs ein. Zunächst werden die zu Grunde liegende Technologie AJAX, die Architektur des GWT sowie die Funktionsweise des GWT-Compilers vermittelt. Danach wird dem Leser die Umgebung, in der GWTAnwendungen entwickelt werden, nahegelegt. Im Weiteren werden die Themen Kommunikation mit dem Server und die grafischen Komponenten des GWT näher erläutert, welche von entscheidender Bedeutung für den Praxisteil sind.

Nachdem durch die einleitenden Kapitel, die verwendeten Technologien NOF und GWT vorgestellt wurden, folgt in Kapitel 4 die Umsetzung der Aufgabenstellung die- ser Arbeit. Es wird erörtert, welche Voraussetzungen für die Entwicklung einer ge- nerischen Benutzerschnittstelle gelten. Darüber hinaus wird die Interaktion zwischen Präsentations- und Anwendungsschicht innerhalb des NOF untersucht und aus den Er- gebnissen abgeleitet, welche Informationen für die generische AJAX-Benutzerschnitt- stelle erhalten bleiben müssen. Dabei werden die wichtigsten Klassen einzeln unter- sucht und die Informationsträger ermittelt. Die Erkenntnisse daraus werden verwen- det, um ein Modell zu entwickeln, welches die Informationen aus dem NOF auf die clientseitige AJAX-Benutzerschnittstelle überträgt. Anschließend wird der Entwurf des Modelles im Einzelnen motiviert, dessen Verwendung verdeutlicht und die Inte- gration in das Gesamtsystem konkretisiert.

In den nachstehenden Abschnitten werden verschiedene Anwendungsfälle (Abrufen einer Collection, Erstellen eines Objektes, Ändern eines Objektes) behandelt und par- allel dazu gezeigt, wie das Modell genutzt wird, um zwischen dem GWT und dem NOF Daten auszutauschen. Weiterhin werden an dieser Stelle einzelne mit dem GWT entworfene grafische Komponenten erläutert, die sich am DND-Viewer orientieren.

Im letzten Kapitel werden die aus der praktischen Arbeit gewonnenen Erkenntnisse zusammengefasst und diskutiert. Abschließend wird durch einen Ausblick aufgezeigt, welche Funktionalitäten für die generische AJAX-Benutzerschnittstelle fehlen und welche weiterentwickelt werden müssen.

1.2. Gegenstand und Motivation

1.2.2 Problematik

Die Entwicklung von AJAX-Anwendungen mit dem GWT hat den entscheidenden Vorteil, dass entgegengesetzt der herkömmlichen Herangehensweise, für den Client Javascript-Quelltext zu schreiben, ausschließlich mit der Java-Programmiersprache gearbeitet wird. Dennoch wird der Entwickler vor die Aufgabe gestellt, den Quelltext des NOFs so anzupassen, dass dieser GWT konform, d. h. durch den GWT-Compiler, verarbeitet wird. Der Java-Quelltext, der auf der Clientseite erreichbar sein muss, ge- nauer gesagt nach Javascript kompiliert wird, muss verschiedenen Einschränkungen genügen. Bspw. werden nur die Klassen innerhalb des Paketes Java.lang und ei- nige Klassen des Paketes Java.util nach Javascript übersetzt. [Vgl. Goob] Eine weitere Einschränkung ist, dass die Objekte, die zwischen Client und Server trans- feriert werden, die Schnittstelle Serializable oder isSerializable imple- mentieren müssen. Daraus resultierend kann die Implementierung nicht völlig frei gestaltet werden. Es muss mindestens ein Standard-Konstruktor vorhanden sein, was den Entwicklungsspielraum erheblich einschränkt.

Um für das NOF eine generische Benutzerschnittstelle zu entwickeln, ist es unerläss- lich mit der Applikationsschicht dieses Frameworks zu kommunizieren. Dies hat zur Folge, dass nicht mit den entwickelten Klassen der Domänenschicht interagiert wird, sondern mit einem so genannten Wrapperobject NakedObject (NO). Dieses kapselt sämtliche, für die generische Darstellung notwendige, Informationen. Dessen Abhän- gigkeiten beruhen nicht auf den emulierten Java-Klassen des GWT. Deshalb muss eine Adaption des Quelltextes erfolgen. Dabei gilt es einen Großteil der generischen Informationen zu erhalten und zu analysieren, welche für das Client-Server-Umfeld überhaupt notwendig sind.

1.2.3 Motivation

Das NOF bietet die Möglichkeit in kurzer Zeit die Logik einer Anwendung - die Domänenschicht - zu entwickeln und dabei die Funktionsweise auf einer der ver- fügbaren Oberflächen zu überprüfen, ohne diese aufwändig erstellen zu müssen. Mit dem Framework ausgeliefert wird ein DND- und ein HTML-Viewer. Diese sind für den heutigen Gebrauch in ihrem Erscheinungsbild etwas veraltet, dennoch für Test- zwecke sehr gut einsetzbar.

Das angestrebte Ziel - ein Konzept für eine moderne AJAX-Benutzerschnittstelle zu entwickeln - erweitert das Framework um die Möglichkeit Anwendungen mit dem GWT generisch darzustellen. Dies dürfte am NOF-interessierte Personengruppen, gerade auch Einsteiger, motivieren sich mit dem Framework genauer zu beschäftigen, da diese Möglichkeit einen weiteren Vorteil darstellt. Daher ist der Nutzen dieser Arbeit für Entwickler wie auch Nutzer des Frameworks, gleichermaßen zu sehen.

2 Das Naked-Objects-Framework

It’s all very well creating an agile domain object model, but if any change to that model also dictates the modification of one or more layers underneath it (dealing with persistence) and multiple layers on top (dealing with presentation), then that agility is practically worthless.

(Richard Pawson [Foreword Hay09, 4. Abschnitt])

Dieses Zitat von Richard Pawson zeigt einen Schwachpunkt agiler Softwareentwick- lung von mehrschichtigen Systemen auf und verdeutlicht somit einen wesentlichen Vorzug des Naked-Objects-Architekturmusters. Agile Softwareentwicklung stellt eine Methodik dar, mit der sich von den klassischen Vorgehensmodellen (z. B. V-Model) der Softwareentwicklung entfernt wird. Im Fokus stehen die zu erreichenden Ziele: die Kommunikation der Mitarbeiter; Verträge gelten nur als Voraussetzung für die Zusammenarbeit; Offenheit für Änderungen spielt eine wichtigere Rolle als das Ab- arbeiten eines Planes. [Vgl. Agi] Dieser Sachverhalt erweist sich, bezogen auf das Framework Naked-Objects, als vorteilhaft.

Dieses Kapitel führt hauptsächlich in die grundsätzliche Verwendung des NOFs ein. Parallel dazu wird die im praktischen Teil, ab Kapitel 4 als Grundlage dienende, An- wendung vorgestellt. Dabei werden Besonderheiten, wichtigsten theoretischen Grund- lagen und die Darstellung einer NOF-Anwendung durch eine generische Benutzer- schnittstelle vorgestellt.

2.1 Einführung

Das NOF ist ein komplexes (> 1200 Klassen) Softwaresystem. Unter Nutzung dieses Systems wird ausschließlich die, in Abbildung 2.1 dargestellte, Domänenschicht (Domain Layer) entwickelt. Sie ist von keiner der Anderen abhängig. Im Einzelnen sind das die Präsentations-, Applikations- und Persistenzschicht. Die Applikationsschicht wird in Kapitel 4.1 genauer untersucht. Denn in dieser befinden sich die Klassen für die generische Interaktion mit der Domänenschicht.

Die entwickelte Domäne kann folglich auch in anderen Umgebungen weiter- bzw. wiederverwendet werden. Wie die dafür vorausgesetzte lose Kopplung der Domänen- schicht realisiert ist, wird im Abschnitt 2.4 genauer beschrieben. Aufgrund der Exis- tenz verschiedener Viewer und Persistenzmechanismen sowie des gesamten Kerns des Frameworks, ist von vornherein ein erheblicher Verwaltungs- und Konfigurationsaufwand notwendig. Durch den Einsatz des Build-Management-Systems Maven wird dieser minimiert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Die Schichtenarchitektur des NOFs. Dargestellt ist die Interaktion der vier Schichten untereinander, initiiert durch eine Benutzereingabe auf der grafi- schen Benutzeroberfläche. [Hay09, S. 244]

Maven wurde von der Apache-Software-Foundation entwickelt und gilt als Ablöser für das, über lange Zeit als Standard geltende, Build-System Ant, obwohl „ANT unter den Build Tools immer noch [häufiger verwendet wird und] vor dem neueren Maven liegt“. [Ueb, 2. Hälfte]

Maven bietet Entwicklern Automatismen für das Generieren von Softwareprojekten. Zu nennen sind unter anderem die initiale Erstellung von Anwendungsstrukturen, Kompilierung und Test von Quelltexten sowie Möglichkeiten des Paketierens und der Verteilung von Software auf möglichen Anwendungsrechnern. Diese Automatismen und weitere Konfigurationsoptionen werden in einer so genannten POM-Datei (Pro- ject Object Model) pom.xml, welche sich im Hauptverzeichnis des Projektes befin- det, definiert. In dieser werden die projektspezifischen Abhängigkeiten von Modulen angegeben, die Maven bei einem Kompilierungsaufruf versucht mit dem lokalen Ver- zeichnis aufzulösen. Falls eines der Module nicht existiert, wird versucht dieses vom zentralen Maven -Verzeichnis herunterzuladen.

2.1. Einführung

2.1.1 Aufbau einer Naked-Objects-Anwendung

Die Erzeugung einer initialen NOF-Anwendung mithilfe einer Entwicklungsumgebung, die Maven unterstützt, stellt sich folgendermaßen dar:

- Es wird ein neues Maven -Projekt erstellt. Im Weiteren wird gefordert einen Archetype anzugeben. Ein Archetype ist als fertiges Projektgerüst zu sehen. Ein „Naked-Objects-Application“-Archetype, der alle nötigen Projektstrukturen ausliefert, existiert.
- Nach Eingabe der GroupID, welche als universeller Identifikator der Organisa- tion des Projektes steht und auf der kompletten Domain, d. h. in umgekehrter Reihenfolge (z. B.: de.htwk-leipzig), des Unternehmens basiert, und der Arti- factID, die eine Bezeichnung oder Namen des Projektes repräsentiert, wird der Dialog bestätigt.
- Maven lädt alle abhängigen Quellen herunter, falls diese noch nicht im lokalen Verzeichnis vorhanden sind.

Sind diese Vorgänge abgeschlossen, bietet sich dem Benutzer im Allgemeinen die in Abbildung 2.2 gezeigte Projektstruktur.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Die (Multi-)Projektstruktur einer Naked-Objects-Anwendung

Diese stellt den standardisierten Weg der Naked-Objects-Entwickler dar, Anwendun- gen zu organisieren. Auffallend ist die strenge Trennung von Zuständigkeiten. So wird mit dem Multi-Projekt-Setup das SOC-Prinzip (Separation of Concerns) verfolgt.

Die Zuständigkeiten der einzelnen Projekte sind nach [Hay09, S. 12] folgendermaßen zu erklären:

- Das Projekt ohne Suffix stellt ein so genanntes Maven -Remote-Projekt dar, in dessen POM-Datei die Abhängigkeiten für die weiteren Projekte enthalten sind. Es muss demnach für alle in Abbildung 2.2 gezeigten Projekte nur ein Aufruf zum Paketieren erfolgen.
- dom (domain object model): In diesem Projekt werden die Domänenklassen, das Datenmodell mit seinen Entitäten, Wertobjekten, Assoziationen und Vererbungshierarchien, gespeichert
- fixture: Hier wird Quellcode für die programmatische Erstellung von Objekten, so genannte Fixtures, für Testläufe oder Präsentationszwecke untergebracht.
- service: Im Service-Projekt befinden sich Funktionalitäten, die nicht unmittelbar in die Domänenobjekte gehören. Diese Funktionalitäten werden beiderseits - vom Client oder vom Domänenobjekt selbst - genutzt.
- commandline: Ist das Projekt, welches die Startroutinen und Properties-Dateien enthält.
- webapp: Durch dieses Projekt wird die Möglichkeit zur Verfügung gestellt, die Anwendung auch als Webapplikation auszuliefern.

2.2 Entwicklung einer Naked-Objects-Anwendung

Anhand der als Grundlage dieser Arbeit dienenden Anwendung wird in diesem Abschnitt erläutert, wie sich ein Entwicklungszyklus unter Nutzung dieses Frameworks gestaltet. In diesem Teil kommt es darauf an, die wesentlichen Konzepte, mit denen es sich auseinanderzusetzen gilt, zu veranschaulichen.

Es handelt sich um eine allgemein als CRM-Anwendung (Customer Relationship Ma- nagement) bezeichnete Software. Da für die Untersuchung die wesentlichen Funktio- nalitäten genügen, wurde das Datenmodell (Abb. 2.3) auf seine elementaren Bestand- teile differenziert. Die wichtigste Entität Company, die mit den Grundbestandteilen Branch, Contact modelliert ist, hält eine Liste von Order und fungiert damit als Customer.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Das vereinfachte Datenmodell der, für den Untersuchungsgegenstand, zu Grunde liegenden Anwendung. Zur Vereinfachung werden nur die Eigen- schaften dargestellt.

Auf die initiale Erzeugung des Projektes, welche im Abschnitt 2.1.1 verdeutlicht wurde, schließt sich die Umsetzung des Datenmodells an. Als Voraussetzung für die Implementierung ist es notwendig mit dem Naked-Objects-Programmiermodell vertraut zu sein. Dieses Modell setzt sich aus einer Reihe von Namenskonventionen, reservierten Methodennamen und unterstützenden Annotationen für die Domänen-getriebene Entwicklung zusammen. [Hay09, Appendix A] In Tabelle 2.1 auf der folgenden Seite sind die wichtigsten Bestandteile aufgelistet.

Anwendungsspezifische Logik kann imperativ, wie auch deklarativ definiert werden. An dieser Stelle sei angeführt, dass mithilfe der Methode hideXxx() Eigenschaften imperativ, an sich zur Laufzeit ergebende Bedingungen gekoppelt, ausgeblendet wer- den. Z. B. könnte dies für eine Datumseigenschaft gelten, die ein bestimmtes Zeitfens- ter überschritten hat und infolgedessen nicht mehr angezeigt wird. Dem gegenüber bietet die deklarative Variante in Form der Annotation @Hidden einen Satz an vor- definierten Bedingungen, durch ein festgelegtes Enum, an. Die durch dieses Enum de- finierten Werte sind: ALWAYS; NEVER; ONCE_PERSISTED; UNTIL_PERSISTED. Der Entwickler hat den Vorteil, zwischen der zeitaufwändigeren, aber flexibleren Va- riante der Methodenimplementierung und der Annotation, die durch eines der vorde- finierten Elemente möglicherweise den konkreten Anwendungsfall abdeckt, wählen zu können.

Zusätzlich zu den Annotationen werden durch das Paket applib unter anderem ver- schiedene Basisklassen, deren Nutzung nicht verbindlich ist, aber die Verwendung zu einer Vereinfachung des Quellcodes führt, zur Verfügung gestellt. Von diesen wird häufig die Klasse AbstractDomainObject benutzt, welche von Domänenobjek- ten, genauer gesagt Entitäten, abgeleitet wird. Diese erben Methoden zur transienten Erzeugung von Objekten, zum Auffinden von Instanzen, für die Persistierung und Feedbackmethoden für die Präsentationsschicht. Letztgenannte, z. B. warnUser() oder informUser(), stellen somit allgemein Möglichkeiten zur Verfügung den Be- nutzer der Software über ein bestimmtes Ereignis, bspw. über das oben benannte über- schreiten des Zeitfensters, zu informieren.

Darüber hinaus bietet die applib Exceptions, nützliche Hilfsklassen, Parser, Fil- ter uvm. zur Verwendung an. Eine Unterstützung bspw. für die Validation von Ob- jekten bietet die Klasse AbstractSpecification<T>. Sie verlangt eine Me- thode namens satisfiesSafely(T object) zu implementieren. Die zu vali- dierende Assoziation eines Objektes wird an ihrer Get-Methode mit der Annotation @MustSatisfy(SpecClass.class) markiert. Das NOF ruft daraufhin die im-

2.2. Entwicklung einer Naked-Objects-Anwendung

plementierte Methode der Spezifikation automatisch auf. Auf ähnliche Art und Weise funktioniert der Mechanismus des DefaultsProvider (Standardwerte für Asso- ziationen) und des ValueSemanticsProvider (Information zur Darstellung ei- nes Wertobjektes).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1: Auszug der Konventionen des Naked-Objects-Programmiermodells. [Hay09, Appendix A]

2.2.1 Implementierung der Domänenschicht

In den vorherigen Abschnitten wurde des Öfteren erwähnt, dass die Entwicklung von Anwendungsdomänen mithilfe des NOFs besonders einfach und schnell ist. Dieser Teil der Arbeit wird das anhand kurzer Beispiele belegen. Weiterhin werden die we- sentlichen Abläufe der Entwicklung einer Naked-Objects-Anwendung verdeutlicht.

Die Entwickler des Frameworks haben unterschiedliche Hilfsmittel für die schnelle Domänenentwicklung bereitgestellt. Es gibt für verschiedene Implementierungssitua- tionen Hilfen, wie etwa die im letzten Abschnitt angesprochenen Basisklassen der applib, welche die Produktivität enorm steigern. Eine weitere umfangreiche Un- terstützung für eine beschleunigte Entwicklung sind so genannten Code-Templates, mit denen z. B. durch Eingabe eines Kürzels und der Tastenkombination für den Vervollständigungs-Assistenten ganze Methodenrümpfe, teilweise mit fertigen Co- defragmenten, entstehen. Zum verringerten Aufwand an ‚Schreibarbeit‘ kommt noch die Sicherstellung der korrekten Methodennamen, welche durch das Framework als Grundlage für die Darstellung bspw. von Eigenschaften dienen. Weiterhin werden Annotationen, wie @MemberOrder, schon mit eingebunden. Außerdem bieten die Code-Templates weitere Vorteile für die Validierung und Modifizierung von Eigen- schaften, Aktionen und für Lebenszyklus-Methoden, wie persist(), load(), update() uvm.

Nach der Implementierung der Operationen, Aktionen und Attribute einer Entität steht die Möglichkeit zur Verfügung durch die reservierten Methoden title() und iconName() so genannte Identifikatoren für die Benutzerschnittstelle zu implementieren. Diese dienen dazu durch einen Titel-String und einem Symbol einen Wiedererkennungswert auf der Benutzerschnittstelle zu schaffen.

2.2.2 Implementierung von Fixtures

Fixtures sind zur Laufzeit generierte Datensätze, die entweder als persistente oder transiente Daten installiert werden. Diese vorinstallierten Daten können im Graphical User Interface (GUI) für Präsentationszwecke eingesetzt werden. Auf diese Art ist es möglich zu einem frühen Entwicklungspunkt Daten ins System zu bringen ohne ein Persistenzsystem anzubinden. Das Projekt mit dem Suffix fixture ist dafür vorgesehen diese ‚künstlich‘ erzeugten Datensätze in das System zu integrieren. Die applib des NOF bietet eine abstrakte Klasse AbstractFixture, deren abstrakte Methode install() überschrieben wird. Diese wird vom Framework aufgerufen und dadurch das Einbinden der Datensätze initiiert.

2.2.3 Implementierung von Services

Services sind Operationen auf der Anwendungsdomäne, die konzeptionell nicht in Domänenobjekte (Entitäten oder Wertobjekte) gehören. [Vgl. Eva04, S. 106] Diese sind im NOF Voraussetzung für den Einsatz einer Anwendung. Existiert in der Domä- nenschicht kein Service, d. h. insbesondere keine Aktionen, so ist diese Anwendung auch nicht ausführbar. Services werden bei der Entwicklung der Anwendungsdomäne in Form von Interfaces, mit den Aktionssignaturen, im Projekt mit dem Suffix dom de- finiert. Die Implementierung dieser Service-Interfaces erfolgt im Projekt mit dem Suf- fix service. Das in Abbildung 2.4 dargestellte Symbol Contact Finder stellt einen Service dar, der über sein Kontextmenü ausführbare Aktionen anbietet. Jeder Service muss über die nakedobjects.properties-Datei im commandline- Projekt registriert werden. Dies wird realisiert indem in letztgenannter Datei für den Schlüssel nakedobjects.services ein Wert in Form des vollqualifizierten Klas- senbezeichners des Services angegeben wird. Aufgrund dieser Informationen ist das NOF in der Lage diesen Service in die Anwendung zu integrieren.

2.3 Darstellung der Domäne im DND-Viewer

Dieser Abschnitt vermittelt wie die entwickelte Anwendungsdomäne generisch durch die Präsentationsschicht des NOFs interpretiert und zur Darstellung gebracht wird. Für die in diesem Kapitel vorgestellte CRM-Anwendung zeigt die Benutzerschnitt- stelle in Form des DND-Viewers zunächst zwei Symbole an. Über das Kontextmenü eines Symbols erfolgt der Zugriff auf eine der angebotenen Funktionalitäten. Nach Aufruf der Aktion wird dem Benutzer der Anwendung in einem Fenster das Ergebnis präsentiert. Hierbei handelt es sich exakt um die Bestandteile der entwickelten En- titäten. Felder werden je nach ausgewählter Fenstersicht (Grid, List, Table) und Typ angezeigt.

Abbildung 2.4 auf der folgenden Seite zeigt einen Zustand des DND-Viewers während der Benutzung. Zu sehen ist hier, wie Objektreferenzen, String-Felder, Wahlobjekte und auch Aktionen dargestellt sind. Die Objektreferenzen werden durch ihre Identi- fikatoren (Iconname, Titel) repräsentiert. Diese werden aus der Implementierung der reservierten Methoden title() und iconname() generiert. (Vgl. Tabelle 2.1, S. 13) Besitzen die assoziierten Objekte zusätzlich noch Aktionsmethoden, so besteht je nach Kontext die Möglichkeit, diese über das Kontextmenü aufzurufen. Diese Be- nutzerschnittstelle interpretiert die Datentypen int, float usw. und String als Textfelder, welche je nach deklarierter Geschäftsregel unterschiedlich angezeigt werden. Sind Felder einer Entität mit @Disabled annotiert, setzt diese Benutzer- schnittstelle das so um, dass die Bezeichnung des Feldes in kursiver Schrift angezeigt wird und der Wert im Textfeld nicht modifizierbar ist. (Siehe dazu in der Abbildung unten das Title-Attribut als auch im oberen Bereich das Id- und das Head-Attribut) Weiterhin stellt die Benutzerschnittstelle die Attribute der Domänenobjekte struktu- rell laut ihrer annotierten MemberOrder dar. Diese Reihenfolge zeigt sich in der Tabellensicht durch die Anordnung der Spalten und in der Objektsicht (Fenster oben, mitte) anhand der Zeilen. Darüber hinaus zeigt die Objektsicht, dass für das Attribut Notes drei Zeilen vorgesehen sind. Dafür bietet das NOF Annotationen, welche für die generische Benutzerschnittstelle als Hinweis für die Darstellung genutzt wird. Zu dieser Art gehört auch unter anderem die MaxLength-Annotation.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4: Die objektorientierte Benutzerschnittstelle des NOF

[...]