Java Framework Development zur ... - RheinAhrCampus

Java Framework Development zur
biomedizinischen Bildverarbeitung und
Vorhersage
Predict 4H
Bachelorarbeit
im Studiengang Biomathematik
Fachhochschule Koblenz, Rheinahrcampus Remagen
Vorgelegt von:
Martin Haunhorst
Geb. am 17.12.1985 in Bonn
Interner Betreuer: Prof. Dr. Heiko Neeb
Zweitbetreuer: Marcus Fassbender
Remagen, 14.08.2009

Danksagung
D a n k s a g u n g | I
Ich möchte an dieser Stelle einigen Personen danken, ohne deren Hilfe diese Arbeit sicherlich
nicht erschienen wäre, schon gar nicht in dieser Form.
Zunächst danke ich meinem Betreuer Prof. Dr. Heiko Neeb, der zu jederzeit ein offenes Ohr
für mich hatte und mir bei vielen Problemen zur Seite stand, was oftmals viel Zeit und mit
Sicherheit auch viele Nerven in Anspruch genommen hat.
Auch Jürgen Redwanz, Dieter Gruschinski sowie meinem Zweitbetreuer Marcus Fassbender
möchte ich meinen Dank aussprechen, da sie zusammen diverse Probleme, die beim Arbeiten
aufgetreten sind, behoben haben, was nicht selten etwas länger gedauert hat.
Nicht vergessen darf ich an dieser Stelle meine Kommilitonen Lisa, Vyara und Roman Benke,
die mir bei Problemen jederzeit hilfsbereit zur Seite standen. Speziell Roman, der mit mir an
diesem Projekt gearbeitet hat, musste oft für meine Fragen herhalten.
Zu guter Letzt möchte ich meiner Familie und insbesondere meiner Freundin Melanie Reuß
danken, die viele Stunden auf mich verzichten musste, damit ich diese Arbeit anfertigen
konnte. Ihr möchte ich diese Arbeit widmen.

Zusammenfassung
Z u s a m m e n f a s s u n g | II
Die Aufgabe dieser Bachelorarbeit ist die Implementierung eines Konzeptes in Java. Konkret
geht es um die Entwicklung eines Java-basierten Bildverarbeitungstools – predict 4H
(Haunhorst, 2009 S. 3). Hintergrund hierbei ist, dass es nach wie vor keine Software gibt, mit
deren Hilfe sich Studienergebnisse schnell und unkompliziert in praxisrelevante Ergebnisse
oder Vorhersagemodelle umwandeln lassen (Neeb-Burlacu, 2008). Dies liegt zu einem großen
Teil daran, dass die Studienergebnisse zwar oftmals in praxisrelevante Programme ‚übersetzt‘
werden, diese aber in der Regel nur Prototypen sind. Zudem beruhen diese Prototypen meist
auf kommerzieller Software, sodass keine Weiterentwicklung stattfindet. Die Programme
werden also letztlich nicht im klinischen Alltag eingesetzt. Hier setzt predict 4H an, indem es
eine Open-Source Software anbietet, mit der dieser Schritt getätigt werden kann. Die zu
erzeugende Plattform wird deshalb alle allgemein benötigten Module enthalten, sodass das
dabei entstehende Programm später leicht an verschiedene Studien angepasst werden kann,
z.B. für Multiple Sklerose. Hierzu müssen lediglich die spezifischen Funktionen als weitere
Module ‚angemeldet‘ werden und können so genutzt werden.
Das Programm soll also so modular aufgebaut sein, dass es als Plattform für spezialisierte
Anwendungen dienen kann. Die Idee ist, dass sich Funktionen hinzufügen, ändern oder
löschen lassen, ohne viele Änderungen an dem Programm-Framework, also dem Programm-
Grundgerüst, vornehmen zu müssen.
Das Konzept dazu wurde im Rahmen eines Praxisprojektes (Haunhorst, 2009) ausgearbeitet.

Inhaltsverzeichnis
I n h a l t s v e r z e i c h n i s | III
DANKSAGUNG ............................................................................................................... I
ZUSAMMENFASSUNG ................................................................................................. II
INHALTSVERZEICHNIS ............................................................................................... III
VERZEICHNIS DER ABKÜRZUNGEN UND AKRONYME ......................................... V
1. MOTIVATION .......................................................................................................... 1
1.1. Programmaufbau .....................................................................................................................................2
1.2. Einführung in die verwendeten Programme .........................................................................................3
1.2.1. Eclipse RCP ..........................................................................................................................................3
1.2.2. DICOM .................................................................................................................................................4
1.2.3. ImageJ ...................................................................................................................................................4
1.2.4. MySQL .................................................................................................................................................4
2. IMPLEMENTIERUNG DES KONZEPTES ............................................................. 5
2.1. Grundlagen...............................................................................................................................................5
2.1.1. DataBrowser .........................................................................................................................................5
2.1.2. Question ................................................................................................................................................5
2.1.3. Atom_OID ............................................................................................................................................6
2.1.4. PDAtom ................................................................................................................................................6
2.2. Modularität ..............................................................................................................................................7
2.2.1. Perspektiven ........................................................................................................................................10
2.2.2. Maus-Klick-Aktionen .........................................................................................................................11
2.2.3. Benutzereingabe ..................................................................................................................................15
2.2.4. Modularität – Fazit ..............................................................................................................................18
2.3. Trennung der Benutzeroberfläche .......................................................................................................19
2.4. Persistente Speicherung ........................................................................................................................21
2.4.1. Datenbankanbindung ..........................................................................................................................21
2.4.2. Chain of Responsibility .......................................................................................................................22

I n h a l t s v e r z e i c h n i s | IV
2.5. Item Tree ................................................................................................................................................23
2.5.1. Observer Pattern ..................................................................................................................................25
3. VALIDIERUNG DER PROGRAMMFUNKTIONALITÄT ..................................... 29
4. AUSBLICK ............................................................................................................ 32
ABBILDUNGSVERZEICHNIS ...................................................................................... VI
LITERATURVERZEICHNIS ......................................................................................... VII
SELBSTSTÄNDIGKEITSERKLÄRUNG .................................................................... VIII

V e r z e i c h n i s d e r A b k ü r z u n g e n u n d A k r o n y m e | V
Verzeichnis der Abkürzungen und Akronyme
GUI Graphical User Interface
ID Identifier
OID Object Identifier
SQL Structured Query Language
IDE Integrated Development Environment
API Application Programming Interface
CT Computertomographie
MRT
RCP
Magnetresonanztomographie
Rich Client Platform

1. Motivation
M o t i v a t i o n | 1
Diese Bachelorarbeit ist ein Teilprojekt von predict 4H – ‚Professional Remagen Diagnostic
Imaging and Classification Toll - For Health‘ – und wurde unter der Leitung von Prof. Dr.
Heiko Neeb absolviert. predict 4H soll „eine Open-Source Software-Plattform hervorbringen,
mit deren Hilfe es ermöglicht werden soll, in kurzer Zeit individualisierte Anwendungen zu
erzeugen, die bei der Durchführung klinischer Studien sowie radiologischer Diagnostik helfen
und schließlich einen schnellen Übertrag der Forschungsergebnisse in klinische
Routineanwendungen gewährleisten. Mit anderen Worten sollen die später entstehenden
Programme helfen, Krankheiten, Krankheitsverläufe etc. vorherzusagen“ (Haunhorst, 2009 S.
3). Damit predict 4H für verschiedene Studien einsetzbar ist, ohne dass für jede Studie große
Änderungen an dem Programm vorgenommen werden müssen, muss das Programm-
Grundgerüst – auch Framework genannt – modular aufgebaut sein. Ein Verändern der
Funktionalität darf also nur in wenigen Bereichen Änderungen hervorrufen.
Neben der Modularität sind die persistente Speicherung 1 der Daten und die einfache
Handhabung der Benutzeroberfläche hier die wichtigsten Ziele. Persistent bedeutet in diesem
Zusammenhang sowohl, dass die Daten beim Beenden des Programms nicht verloren gehen,
als auch, dass sämtliche Daten eindeutig abgespeichert werden. Eine einfache Handhabung
meint hier vor allem, dass die Benutzeroberfläche selbsterklärend sein muss, alle Funktionen
also direkt zu finden sein müssen. Auch soll die Benutzeroberfläche unverändert bleiben, egal
für welche Problemstellung das Programm spezialisiert wurde. Selbsterklärend muss die
Oberfläche sein, damit nicht nur ausgebildete Analysten, sondern auch Ärzte und die
Patienten selbst mit dem Programm arbeiten können. Die Unveränderlichkeit der Oberfläche
ist wichtig, um den Arbeitsaufwand im Praxiseinsatz zu minimieren. Ist ein Arzt oder Analyst
zum Beispiel für mehrere Studien zuständig, muss er sich auf diese Weise nicht jedes Mal neu
in das Programm einarbeiten.
1 Persistente Speicherung meint die Speicherung von Daten (oder Objekten) in nichtflüchtigen Speichermedien
wie Dateisystemen oder Datenbanken. Dabei erhalten die Daten/Objekte eindeutige und dauerhafte
Identifikatoren.

1.1. Programmaufbau
Abb. 1.1 Programmaufbau
M o t i v a t i o n | 2
Wie in Abb. 1.1 zu sehen, ist die Programmoberfläche grundsätzlich in zwei Teile gegliedert.
Auf der linken Seite befindet sich der so genannte Item Tree, also ein Objekt-Baum. In diesem
sollen zunächst die im Programm näher definierten ‚Hauptlisten’ dargestellt werden, hier
Patient und Study (siehe Kapitel 2.5). Besitzt ein Objekt ihm zugehörige ‚Unterobjekte’, soll
ein +-Zeichen neben diesem Objekt angezeigt werden. Klickt man auf ein solches +-Zeichen
neben diesen Namen, sollen alle zu dieser Liste gehörenden Objekte erscheinen. Bei Patient
sollen also alle Patienten erscheinen, bei Study alle Studien.
Klickt man auf das +-Zeichen neben einem solchen Objekt, soll angezeigt werden, was es für
Unterkategorien bei diesem Objekt gibt. Wie in der Abbildung zu sehen, wird für den
Patienten ‚Müller‘ aufgeführt, dass es die Unterkategorie Measurement gibt. Es gibt zu
diesem Patienten also Messungen, welche man mit einem Klick auf das entsprechende +-
Zeichen angezeigt bekommt. Analog ist in dieser Abbildung zu erkennen, dass die Studie
Schlafzeiten die Unterkategorie Patient besitzt, die wiederum den Patienten ‚Müller‘ enthält.
Das Patientenobjekt Müller muss hier über dieselben Unterkategorien und Unterobjekte
verfügen wie in der Patientenhauptliste, da es sich auf denselben Patienten bezieht. Prinzipiell

M o t i v a t i o n | 3
sind für jedes Objekt beliebig viele Unterkategorien denkbar. Die Realisierung des Item Tree
mit den aufgeführten Eigenschaften ist die Hauptaufgabe dieser Bachelorarbeit gewesen.
Die rechte Seite enthält das von Roman Benke programmierte Bildvisualisierungstool (Benke,
2009) auf das in dieser Arbeit nicht näher eingegangen wird.
Die beiden Teile der Oberfläche und ihre zugehörigen Klassen gehören beide zur GUI und
müssen auch miteinander kommunizieren können. Dennoch sollen sie unabhängig
voneinander gehalten werden, sodass jeder Teil unabhängig von dem anderen verändert oder
gar ausgetauscht werden kann (siehe Kapitel 2.3).
1.2. Einführung in die verwendeten Programme
Grundsätzlich wurde mit Hilfe der kostenfreien Programmieroberfläche Eclipse in der
Programmiersprache Java gearbeitet. Die genauere Auflistung der verwendeten Programme
und Eclipse-Plugins findet sich in der Diplomarbeit von Roman Benke (Benke, 2009).
Diese Arbeit beschränkt sich auf die hierfür wichtigsten Programme und Eclipse-Plugins,
welche im Folgenden kurz vorgestellt werden.
1.2.1. Eclipse RCP
Hier ist vor allem die so genannte Rich Client Platform, kurz RCP, wichtig. Dieses Eclipse-
Plug-In ermöglicht es, Anwendungen zu erzeugen, die zwar auf dem Eclipse Framework
basieren, von der Eclipse-IDE, also der Eclipse-Entwicklungsumgebung, jedoch unabhängig
sind (Wik09). Mit anderen Worten erhält man auf diese Weise eine grundlegende grafische
Oberfläche, auch Graphical User Interface – kurz GUI – genannt, ohne viel Zeit für deren
Erstellung zu benötigen. Dies ist für dieses Projekt besonders wichtig, da die zu erstellende
Plattform viele Funktionalitäten bieten und, wie bereits erwähnt, modular aufgebaut sein soll,
was beides mit viel Zeitaufwand verbunden ist. Dank des RCP-Plugins konnte das
Augenmerk auf diese Ziele gelegt werden, da nicht viel Zeit für die Erstellung der Oberfläche
und des Programmgrundgerüstes erübrigt werden musste.
Bei der Erstellung eines RCP-Projektes wird auch eine plugins genannte Datei erstellt, in der
unter anderem definiert wird, welche Klasse die Startklasse des Programms sein soll, welche
Klassen Perspektiven und welche Views definieren. Diese Einstellungen lassen sich mit Hilfe
dieser Datei jederzeit leicht verändern und bedingen somit keinen Programmieraufwand.

1.2.2. DICOM
M o t i v a t i o n | 4
Digital Imaging and Communications in Medicine, kurz DICOM, ist ein
Datenspeicherstandard, der im klinischen Umfeld von den meisten Anwendern genutzt wird,
meist zur digitalen Bildspeicherung. Über die reine Bildinformationsspeicherung hinaus
ermöglicht dieses Format das Speichern von Zusatzinformationen, etwa Patientendaten oder
Kommunikationsprotokollen.
Die predict 4H -Programmplattform nutzt dieses Format zur Speicherung und Verwaltung der
Mess-und Analysebilder.
1.2.3. ImageJ
ImageJ ist ein auf Java basierendes, frei zugängliches Bildverarbeitungstool, dessen
application programming interface, kurz API, also die Schnittstelle zur
Anwendungsprogrammierung auf Quelltextebene, so gestaltet ist, dass es als Bibliothek in ein
Java-Programm aufgenommen werden kann. Dadurch kann dieses Programm auf sämtliche
Funktionen von ImageJ zugreifen.
Für dieses Projekt ist dies insbesondere deswegen wichtig, da hier viel mit Bildern, vor allem
im DICOM-Format, umgegangen werden muss. Diese Arbeit nutzt die Funktionen von
ImageJ vor allem, um Bilder bearbeiten und anschließend ohne Informationsverlust im
DICOM-Format speichern zu können. Dies ist relevant, da jeder Informationsverlust eine
spätere klinische Auswertung der Daten erheblich verschlechtern würde.
1.2.4. MySQL
MySQL ist ein Datenbankverwaltungssystem, das auf der Datenbanksprache SQL, Structured
Query Language, aufbaut. SQL gehört zu den so genannten relationalen Datenbanksprachen,
also denen, die Tabellen mathematisch beschreiben. Das Besondere an den relationalen
Datenbanken ist, dass sie trotz dieser abstrakten mathematischen Grundlage im Vergleich zu
anderen Datenbanken leicht zu handhaben sind.
Das fertige Programm soll später zwar viele verschiedene Datenbanksysteme verwenden
können, bislang wurde jedoch nur die Datenbankanbindung für MySQL und PostgreSQL
implementiert. Gearbeitet wurde bislang zudem nur mit MySQL. So konnten die
grundlegenden Funktionen der Datenbankanbindung an dieser Datenbank getestet werden,
was einen späteren Übertrag auf andere Systeme erleichtert.

2. Implementierung des Konzeptes
I m p l e m e n t i e r u n g d e s K o n z e p t e s | 5
Das zuvor ausgearbeitete Konzept sieht, wie bereits erwähnt, einen modularen Aufbau vor, da
predict 4H eine Plattform für individuell einsetzbare Bildverarbeitungstools sein soll. Dazu
wurden verschiedene Design Pattern (Haunhorst, 2009) verwendet, die einen groben Aufbau
des Programms vorschlagen. Im Folgenden wird immer wieder darauf eingegangen, wie diese
Design Pattern implementiert wurden.
Des Weiteren muss die Programm-Plattform eine persistente Speicherung der Daten
garantieren und sämtliche Daten in Form eines Objekt-Baumes anzeigen (siehe Kapitel 1.1).
Auch die Lösung dieser Problemstellung wird in den folgenden Kapiteln vorgestellt.
2.1. Grundlagen
Zunächst einmal werden einige grundlegende Klassen des Programms vorgestellt, die im
weiteren Verlauf immer wieder benutzt werden.
2.1.1. DataBrowser
Der DataBrowser dient als Vermittler zwischen den Programmelementen (siehe Kapitel 2.2).
Er ist statisch 1 aufgebaut, so dass jede Klasse Zugriff auf seine Funktionen hat, ohne ihn
erzeugen zu müssen. Somit werden auch sämtliche Attribute nur einmal erzeugt, weshalb die
im DataBrowser gespeicherten Werte eindeutig bleiben. Auf diese Weise wird eine
konsistente Speicherung dieser Werte sichergestellt, solange das Programm läuft.
2.1.2. Question
Diese Klasse ist neben dem DataBrowser die einzige, die allen Programmelementen bekannt
ist. Sie dient dazu, Benutzereingaben abzufragen, indem in dieser Klasse die Frage bzw.
Aufforderung zur Eingabe, die Art der Eingabe und ein paar zusätzliche Informationen
gespeichert werden können. Die Art der Eingabe wird mittels Integer-Klassenkonstanten
festgelegt. So kann zum Beispiel die Frage ‚Name eingeben‘ lauten und die Art der Eingabe
die Klassenkonstante für eine ‚normale Benutzereingabe’ sein. Als weitere Eingabearten sind
1 Eine statisch aufgebaute Klasse besitzt nur statische Methoden und Variablen.
Auf eine statische Methode/Variable kann von anderen Klassen direkt zugegriffen werden, sofern auf die
Methode/Variable überhaupt von außen zugegriffen werden kann, diese also öffentlich ist. Es muss dazu keine
Instanz der statischen Klasse erzeugt werden.

I m p l e m e n t i e r u n g d e s K o n z e p t e s | 6
Eingaben mit Browse-Button und Combo-Inputs implementiert. Des Weiteren gibt es die
Möglichkeit über weitere Integer-Klassenkonstanten festzulegen, ob als Antwort nur ein
Datum, ein Alter, eine ganze Zahl oder ähnliches akzeptiert werden soll und ob diese Antwort
auch ausgelassen werden darf (siehe Kapitel 2.2.3).
2.1.3. Atom_OID
Das Programm muss mit vielen Daten umgehen können, sei es von Patienten oder Studien
oder mit diversen Bildern. Das bedeutet auch, dass die Datenmenge mitunter sehr groß wird.
Um dabei alle Daten eindeutig zuordnen zu können, wurde ein Object Identifier, also ein
eindeutiger ‚Objekt-Identifizierer‘, namens Atom_OID erstellt. In diesem Object Identifier,
kurz OID, werden unter anderem der Typ des Objektes und eine eindeutige ganze Zahl
gespeichert. Der Typ könnte also zum Beispiel Patient, Studie oder Messung sein. Für jeden
dieser Typen gibt es dann eine eindeutig zugeordnete ganze Zahl. Da viel mit
Datenbankobjekten gearbeitet wird, gibt es zudem eine DB_OID, welche eine Unterklasse
von Atom_OID ist und speziell für Datenbankobjekte gedacht ist.
Aus diesen OIDs kann das Programm jederzeit erfragen, um welchen Datentyp es sich
handelt. Auf diese Weise können die verschiedenen Anwendungen ihre Zuständigkeit für
dieses Objekt überprüfen.
2.1.4. PDAtom
Um die vorhandenen Daten, sei es aus einer Datenbank oder einem Filesystem, in dem
Programm nutzen zu können, werden Sie als PDAtom-Objekte gespeichert. Diese Objekte
enthalten alle wichtigen Informationen der Daten, vor allem ist hier auch die Atom_OID
gespeichert. Für Datenbankobjekte gibt es die spezielle Unterklasse DBEntry. Sowohl
PDAtom als auch DBEntry sind abstrakte Klassen und können nicht direkt als Objekte erzeugt
werden. Aus diesem Grunde gibt es für sämtliche Datenbankobjekt-Typen jeweils eine eigene
Unterklasse von DBEntry, also beispielsweise Patient, Measurement und Study. In diesen
speziellen Unterklassen sind dann typspezifische Informationen gespeichert. Gleiches gilt
auch für PDAtom, für das es eine Unterklasse zur Speicherung von Bildern gibt, nämlich
P4Image (Benke, 2009).
Für jeden dieser Objekt-Typen gibt es eine PDAtomList bzw. eine DBEntryList, in denen
jeweils alle Objekte dieses Typs gespeichert werden. Jede dieser Listen besitzt zudem eine

I m p l e m e n t i e r u n g d e s K o n z e p t e s | 7
PDAtomFactory bzw. eine DBEntryFactory, die zum Erzeugen der Objekte dient (siehe
Kapitel 2.4.1).
2.2. Modularität
Wie bereits erwähnt muss zu entwickelnde Programm-Plattform leicht an konkrete
Bedürfnisse einer Studie angepasst werden können. Es ist also wichtig, dass ein zusätzlicher
Filter oder sogar eine Sammlung von Filtern in das Programm eingebaut werden kann, ohne
dass an dem Programm selber große Änderungen nötig sind.
Dazu ist es zum einen wichtig, dass jede Anwendung dieselbe Schnittstelle implementiert.
Diese Schnittstelle heißt hier Application. Zum Anderen soll die Benutzeroberfläche nicht
direkt mit den Anwendungen kommunizieren, sondern über einen sogenannten Adapter,
gemäß dem Adapter Pattern (Haunhorst, 2009 S. 12 f).
Ersteres birgt den Vorteil, dass mit jeder Anwendung gleich kommuniziert werden kann, die
Programm-Plattform, auch Framework genannt, also die Anwendungen nicht genauer kennen
muss. Die Kommunikation über Schnittstellen ist Teil des MVC Pattern (Haunhorst, 2009 S.
5 f), welches die Trennung der Hauptelemente – Anwendung, GUI, Datenmodell – eines
Programms beschreibt. Hier ist vor allem die Trennung der Anwendungen von der GUI
wichtig. Eine exakte Trennung zwischen Datenmodell und Anwendung ist weder nötig noch
möglich, da jedes Modell im Datenmodell zu einer Anwendung gehört.
Die Verwendung eines Adapters ermöglicht es, Änderungen an einem zentralen Ort, nämlich
der Adapter-Klasse auszuführen. Soll also zum Beispiel eine Anwendung hinzugefügt
werden, die völlig neue Methoden beinhaltet, können unter Umständen Änderungen an der
Anwendungs-Schnittstelle notwendig werden. Dies führt jedoch dazu, dass all die Stellen im
Framework, die sich auf die Anwendungs-Schnittstelle beziehen, geändert werden müssen.
Mitunter können diese Stellen aber im gesamten Framework verteilt sein, sodass die
Änderungen sehr aufwendig werden können. Nutzt man hier einen Adapter, ist die Änderung
nur noch in dieser Klasse zu tätigen, da alle anderen Programmteile weiterhin dieselben
Methoden im Adapter aufrufen können.

In unserem Programm kommen
diese Prinzipien ebenfalls zur
Anwendung, wie in Abb. 2.1 zu
erkennen. Dabei wird der Adapter
als DataBrowser bezeichnet. Dieser
kennt zum Einen sämtliche
Schnittstellen, also die Schnittstellen
der Anwendungen und der GUI, und
zum Anderen weiß der
I m p l e m e n t i e r u n g d e s K o n z e p t e s | 8
DataBrowser, welche Anwendungen es gibt. Als Beispiel sind derzeit die Anwendungen
Admin, Reconconstruction – Recon – und Analysis vorhanden. Soll nun eine weitere
Anwendung verwendet werden, etwa Predict, so muss diese zunächst die Anwendungs-
Schnittstelle implementieren 1 – sowie die bereits vorhandenen Anwendungen auch – und
zudem beim Start des Programms beim DataBrowser angemeldet werden. Da der
DataBrowser als statische Klasse nicht erzeugt werden muss und in diesem Programm auch
nicht erzeugt wird, geschieht die Anmeldung der Anwendungen im statischen Block der
Klasse. Dabei besitzt der DataBrowser eine applications genannte Liste, zu der die einzelnen
Anwendungen hinzugefügt werden (vgl. Abb. 2.1), was mit dem zuvor erwähnten
‚Anmelden‘ gemeint war.
Der DataBrowser erfragt dann alle wichtigen Daten bei den angemeldeten Anwendungen.
Dass diese die Fragen ‚beantworten’ können, ist über die Implementierung der gemeinsamen
Anwendungs-Schnittstelle sichergestellt worden. Konkret erfragt der DataBrowser
beispielsweise die ID der Perspektive, die zu der Anwendung gehört. Hintergrund hierbei ist,
dass jede Anwendung eine eigene Perspektive erhält, da der Nutzer auf diese Weise über das
Öffnen bzw. Wechseln der Perspektive bestimmen kann, welche Anwendung gestartet werden
soll. Im weiteren Verlauf der Arbeit wird der Grund für dieses Vorgehen noch erläutert
werden (siehe Kapitel 2.2.1).
1 Die Anwendungs-Schnittstelle meint hier kein Interface, sondern eine abstrakte Klasse, von der alle
Anwendungs-Klassen erben. Der Vorteil einer abstrakten Klasse gegenüber einem Interface ist, dass hier neben
den abstrakten auch fertig implementierte Methoden angeboten werden können. Diese Schnittstelle wird also
nicht im klassischen Sinne implementiert, sondern die Unterklasse muss von dieser Klasse erben und die nötigen
Methoden bereitstellen.
Abb. 2.1 Anmeldung von Anwendungen

I m p l e m e n t i e r u n g d e s K o n z e p t e s | 9
Die erste angemeldete Anwendung wird automatisch zur ‚Hauptanwendung’ deklariert, das
heißt, dass die zu dieser Anwendung gehörige Perspektive beim Start des Programms geöffnet
wird. Auch bestimmt diese Anwendung, welche Listen in den Item Tree eingebaut werden
(siehe Kapitel 2.5).
Sobald eine Perspektive geöffnet wird – also schon beim Start des Programms das erste Mal –
erfragt diese beim DataBrowser, für welche Perspektiven ShortCuts, also Zugriff-Buttons,
erstellt werden sollen, wobei der DataBrowser die Perspektiven-IDs übergibt, die er von den
angemeldeten Anwendungen erhalten hat.
Abb. 2.2 verdeutlicht dieses Schema noch einmal. Im DataBrowser werden alle
Anwendungen in der Liste applications und alle PerspektivenIDs in der Liste perspectives
gespeichert. Nachdem, wie bereits am Anfang des Kapitels beschrieben, die Anwendungen
angemeldet wurden, wird im statischen Block des DataBrowsers die setPerspectives-Methode
aufgerufen. Diese durchläuft eine Schleife über alle Anwendungen aus der Liste applications,
wobei von der jeweiligen Anwendung die ID der zugehörigen Perspektive über die
getPerspectiveID-Methode erfragt und in der Perspektiven-Liste gespeichert wird. Daraufhin
erfragt der DataBrowser bei der Hauptanwendung, also der Anwendung, die in der
Anwendungs-Liste an erster Stelle steht, über die getMainLists-Methode die Hauptlisten, die
dann im Item Tree dargestellt werden sollen (siehe Kapitel 2.5).
Abb. 2.2 Sequenzdiagramm Programmstart
Hier ist keine konkrete Anwendung, sondern die Anwendungsschnittstelle dargestellt, um zu
verdeutlichen, dass diese für die Sicherstellung der benötigten Methoden zuständig ist.

I m p l e m e n t i e r u n g d e s K o n z e p t e s | 10
Aus diesem Grunde wurden die beiden genannten Methoden – getPerspectiveID und
getMainLists – nochmals separat aufgeführt.
Wird nun eine Perspektive erstellt, ruft diese im DataBrowser die Methode setShortCuts auf,
wobei sie das zur Perspektive gehörende Layout 1 übergibt. In dieser Methode läuft eine
Schleife über alle PerspektivenIDs aus der Perspektiven-Liste, wobei für jede Perspektive die
Methode addPerspectiveShortCut des übergebenen Layouts aufgerufen wird. Dabei wird
jeweils die PerspektivenID als Argument übergeben (vgl. Abb. 2.2). Hier zeigt sich, wie
vorteilhaft die Verwendung von Eclipse RCP ist. Statt jeden ShortCut aufwendig kreieren zu
müssen, reicht es, die addPerspectiveShortCut-Methode des Layouts mit der jeweiligen
PerspektivenID aufzurufen, wodurch der entsprechende ShortCut automatisch erstellt wird.
2.2.1. Perspektiven
Wie bereits erwähnt, gehört zu jeder Anwendung eine eigene Perspektive, die die
Perspektiven-Schnittstelle implementiert. So könnte die Admin-Anwendung die
Hauptanwendung des Programms sein und ihre Perspektive somit beim Start des Programms
geöffnet werden (vgl. Abb. 2.3 A). Möchte der Nutzer nun beispielsweise Funktionen der
Reconstruction-Anwendung nutzen, muss er dazu lediglich über den entsprechenden ShortCut
die Reconstruction-Perspektive öffnen (vgl. Abb. 2.3 B und C). Die Admin-Anwendung/-
Perspektive bleibt zwar geöffnet, ihre Funktionen können jedoch nur genutzt werden, wenn
der Nutzer über den entsprechenden ShortCut diese Perspektive wieder als aktiv deklariert,
was die Reconstruction-Anwendung/-Perspektive automatisch inaktiv – aber weiterhin
geöffnet – werden lässt (vgl. Abb. 2.3 D).
Wie in Abb. 2.3 zu sehen, ist die derzeit aktive Anwendung/Perspektive jeweils weiß
unterlegt, die inaktiven grau.
Diese Perspektiven verwenden derzeit alle dieselben Views, scheinen also zunächst nicht
wichtig zu sein. Der DataBrowser muss allerdings zu jeder Zeit wissen, welche Anwendung
der Nutzer gerade verwendet bzw. verwenden möchte (siehe Kapitel 2.2.2). Dazu kann der
DataBrowser den Namen der gerade geöffneten Perspektive abrufen und mit den Namen der
Anwendungen vergleichen. Auf diese Weise ist jederzeit bekannt, welche Anwendung
geöffnet ist. Die Alternative dazu wäre ein zusätzlicher Button gewesen, mit dessen Hilfe der
Nutzer bestimmen kann, welche Anwendung geöffnet sein soll. Dies über die Perspektiven zu
1 Mit Hilfe der Layout-Klasse kann auf das durch Eclipse-RCP erstellte Design und Menü der
Benutzeroberfläche zugegriffen und dieses dementsprechend verändert werden

I m p l e m e n t i e r u n g d e s K o n z e p t e s | 11
lösen birgt den Vorteil, dass auf diese Weise prinzipiell jede Anwendung eigene Views
erhalten kann, falls dies nötig sein sollte (siehe auch Kapitel 2.3).
Abb. 2.3 Perspektivenwechsel
Bisher ist eine View für den Item Tree und eine für den bildvisualisierenden Teil der
Oberfläche definiert (siehe Kapitel 1.1). Denkbar ist zum Beispiel eine weitere View, die statt
der bildvisualisierenden View für spezielle Anwendungen eingesetzt wird. So könnte für eine
Krankheitsvorhersage-Anwendung eine spezielle View zum Visualisieren und Bearbeiten von
Diagrammen benötigt werden.
Auch hier ist dem MVC Pattern genüge getan. Zwar sind die Perspektiven, die Teil der GUI
sind, direkt mit ihren zugehörigen Anwendungen assoziiert und für einige Anwendungen
können spezielle Views nötig sein, doch davon abgesehen kennt die GUI keine Anwendung,
sondern bezieht sämtliche Informationen von dem DataBrowser. Da die meisten
Anwendungen keine spezielle View benötigen, wird meist als einzige Veränderung in der GUI
die Erstellung einer Perspektive nötig sein. Auch diese Veränderung entfällt, falls nur
Änderungen innerhalb einer Anwendung vorgenommen werden.
2.2.2. Maus-Klick-Aktionen
Innerhalb des Item Trees soll der Nutzer Maus-Klick-Aktionen ausführen können. Sowohl
Doppel- wie auch Rechts-Klick-Aktionen. Natürlich hängt die Auswahl der Aktionen von der
geöffneten Anwendung und dem Objekt ab, das angeklickt wurde.

I m p l e m e n t i e r u n g d e s K o n z e p t e s | 12
In Abb. 2.4 ist zu erkennen, dass der Nutzer sich in der Analysis-Anwendung (weiß unterlegt)
befindet. Beim Rechts-Klick auf das Messungs-Objekt ‚MRT’ erscheint ein Auswahldialog
von verschiedenen Aktionen. Ebenso in Abb. 2.5, allerdings ist hier die Admin-Anwendung
geöffnet, weshalb der angezeigte Auswahldialog andere Möglichkeiten bietet. Hier ist schön
zu sehen, wie flexibel das Programm mit Rechts-Klicken umgehen können muss.
Abb. 2.4 Rechts-Klick in der Analysis-Anwendung
Normalerweise müsste nun für jede Aktion eine eigene Klasse geschrieben werden. Dies
würde aber jedwede Modularität zunichte machen, da die Aktionen von den Anwendungen
abhängig sind, die Anwendungen aber der GUI nicht bekannt sein sollen.
Die Lösung liegt in der flexiblen Definition der Klick-Aktions-Klassen. Hiervon wurden nur
zwei erstellt, eine für Doppel- und eine für Rechts-Klick-Aktionen. Die ItemTreeView, also
die Ansicht des Item Trees, erstellt beim Start des Programms nur ein Doppel-Klick-Objekt
und eine Liste mit Rechts-Klick-Objekten. Die Größe dieser Liste erfragt die ItemTreeView
beim DataBrowser, welcher wiederum alle angemeldeten Anwendungen durchgeht und die
jeweils maximale Anzahl an Rechts-Klick-Aktionen erfragt. Das Maximum davon wird
wiederum an die ItemTreeView übergeben.
Abb. 2.5 Rechts-Klick in der Admin-Anwendung
In Abb. 2.6 wird dieses Vorgehen veranschaulicht, wobei noch einmal gut zu erkennen ist,
wie der DataBrowser als ‚Vermittler‘ zwischen der GUI und den Anwendungen fungiert.
Auch hier wurde die Anwendungs-Schnittstelle mit der Methode getMaxRightsClicks
aufgeführt, um zu verdeutlichen, dass diese Methode durch die Schnittstelle garantiert wird.
Nachdem die ItemTreeView die maximale Anzahl an Rechts-Klick-Aktionen erhalten hat,
erstellt sie zunächst nur eine Liste mit eben so vielen Rechts-Klick-Aktionen wie die
maximale Anzahl angibt. In der Abbildung wurde vereinfacht new List(maxRightClicks)

I m p l e m e n t i e r u n g d e s K o n z e p t e s | 13
geschrieben, was jedoch bedeuten soll, dass eine Liste des Typs
LinkedList, also eine Liste, die Rechts-Klick-Aktionen speichern kann,
erstellt und mit der entsprechenden Anzahl an Rechts-Klick-Aktionen – Objekten des Typs
RightClickAction – gefüllt wird.
Abb. 2.6 Erstellen der Rechts-Klick-Aktionen
Doppel-Klick-Aktionen sind hierbei sehr einfach zu handhaben, da bei einem Doppel-Klick
lediglich das angeklickte Objekt, bzw. dessen OID 1 , an den DataBrowser übergeben werden
muss, welcher diese OID dann an die geöffnete Anwendung weitergibt. Die Anwendung kann
von der OID dann den Typ des Objektes erfragen und eine dazu passende Aktion starten.
Rechts-Klick-Aktionen sind insofern schwieriger zu handhaben, als bei einem Rechts-Klick
auf ein Objekt verschiedene Aktionen aufgelistet werden müssen (siehe Abb. 2.4 und Abb.
2.5) aus denen der Nutzer dann eine auswählen kann. Hier muss also schon bekannt sein,
welche Aktionen zur Auswahl stehen.
Die Lösung liegt in der variablen Gestaltung der Rechts-Klick-Objekte. Diese müssen
lediglich beim Start des Programms erzeugt werden, weshalb hier wie zuvor beschrieben die
maximale Anzahl an Rechts-Klick-Aktionen aller Anwendungen bekannt sein muss. Ein
späteres Erzeugen von Klick-Aktionen ist nicht mehr möglich bzw. sinnlos, da eine View nur
die Klick-Aktionen akzeptiert, die bei Erzeugung der View mit erzeugt wurden.
Nun kann bei diesen Klick-Aktionen nachträglich der anzuzeigende Text verändert werden.
Ebenso kann in einer View jederzeit bestimmt werden, welche der zu Beginn erzeugten Klick-
Aktionen aktiviert sein sollen. Genau dieses wird nun ausgenutzt, indem die ItemTreeView bei
jedem Rechts-Klick des Nutzers das angeklickte Objekt, bzw. dessen OID, über den
1 Allgemein eine Atom_OID, bei Objekten aus einer Datenbank eine DB_OID, siehe Kapitel 2.1.3.

I m p l e m e n t i e r u n g d e s K o n z e p t e s | 14
DataBrowser an die geöffnete Anwendung übergibt. In dieser ist definiert, welche Aktionen
für diesen Objekt-Typ angeboten werden. Diese Aktionen, bzw. die dazugehörigen
Aktionstexte, werden von der Anwendung als Liste an den DataBrowser zurückgegeben, der
diese an die ItemTreeView weitergibt.
Abb. 2.7 Bezeichnung der Rechts-Klick-Aktionen
In Abb. 2.7 ist dieses Vorgehen dargestellt. Hierbei wurde symbolisch das Setzen der
Aktionstexte aufgeführt als rightClicks.get(i).setText(action). Dabei ist rightClicks die Liste
der Rechts-Klick-Aktionen, die nun in einer Schleife durchlaufen werden muss, wobei ‚i‘ der
Laufindex ist. Nun werden so viele Rechts-Klick-Aktionen aktiviert, wie Aktionen übergeben
wurden. Für jeden Text in der Aktionsliste aktiviert die ItemTreeView also eine Rechts-Klick-
Aktion und ändert den Text dieser Aktion in den entsprechenden Text aus der Liste, indem es
für das entsprechende Objekt die setText-Methode aufruft und den Text aus der Liste
übergibt. Auf diese Weise kann der Nutzer nun zwischen all den von der geöffneten
Anwendung für dieses Objekt angebotenen Aktionen auswählen, ohne dass diese in der
ItemTreeView bekannt sein müssen.
Wählt der Nutzer nun eine Aktion aus, verläuft der Vorgang analog zu dem bei Doppel-Klick-
Aktionen:
Das ausgewählte Objekt wird zusammen mit der ausgewählten Aktion, bzw. dem zugehörigen
Text, über den DataBrowser an die geöffnete Anwendung übergeben, welche ihre für dieses
Objekt und diesen Aktionstext definierte Aktion ausführt.
Dank dieser Vorgehensweise bleibt die Unabhängigkeit zwischen GUI und den
Anwendungen und damit die Modularität vollständig bewahrt.

2.2.3. Benutzereingabe
I m p l e m e n t i e r u n g d e s K o n z e p t e s | 15
Nachdem der Nutzer eine Maus-Klick-Aktion getätigt hat, wie in Kapitel 2.2.2 beschrieben,
führt die Anwendung eine entsprechende objektspezifische Aktion durch. Einige der Rechts-
Klick-Aktionen bedingen jedoch eine Benutzereingabe, zum Beispiel um ein neues
Patientenobjekt anzulegen. Die Anwendung selber darf allerdings keinerlei Anfragen an den
Nutzer stellen, da dies Aufgabe der GUI ist und somit die Modularität aufgegeben werden
müsste. Aus diesem Grund stellt die Anwendung nun eine Anfrage an den DataBrowser,
wobei eine Liste der Fragen – als Question 1 -Objekte – sowie ein Titel für das zu öffnende
Eingabefenster und die übergreifende Fragestellung übergeben werden. Für einen neuen
Patienten könnte die Frageliste also Fragen nach Name, Vorname, Geschlecht und Alter
enthalten, der Fenstertitel könnte ‚Patienten hinzufügen‘ lauten und die übergreifende
Fragestellung ‚Bitte geben Sie die Patientendaten ein. ‘ (vergleiche
Abb. 2.8). In den einzelnen Question-Objekten ist dabei jeweils gespeichert, welchen
Fragetyp diese Frage hat und welche Antwortmöglichkeiten der Nutzer dabei hat. Der
DataBrowser leitet die Anfrage an die ItemTreeView weiter, welche als Teil der GUI einen
Dialog gemäß den Angaben der Question-Objekte erstellt und die entsprechenden
Benutzereingaben als Liste – analog zur Frageliste – über den DataBrowser an die
Anwendung zurückgibt. Genauer erstellt nicht die ItemTreeView selber den Dialog, sondern
überlässt dies der Klasse InputDialog. Diese Klasse wurde erstellt, um die komplexe
Funktionalität zur Erstellung dieser Dialoge aus der ItemTreeView-Klasse auszulagern und
diese somit übersichtlicher zu halten. Die InputDialog-Klasse erstellt dazu ein neues Fenster
mit dem von der Anwendung festgelegten Fenstertitel. Die erste Zeile dieses Fensters wird
dann mit der von der Anwendung gelieferten allgemeinen Fragestellung gefüllt (vgl.
Abb. 2.8). Dann wird in einer Schleife die ebenfalls übergebene Liste der Question-Objekte
durchlaufen. Dabei wird für jedes Objekt eine neue Zeile erstellt. Jede dieser Frage-Zeilen ist
in mehrere Spalten unterteilt. In der ersten Spalte wird die in dem zugehörigen Question-
Objekt gespeicherte Frage aufgeführt. Daneben wird ein Text 2 -Feld erzeugt, in das der
Benutzer seine Eingabe tätigen kann. Es wird ebenfalls eine dritte Spalte erstellt, worauf noch
eingegangen wird.
1 Die Question-Klasse dient als Übermittler von Benutzereingabe-Einstellungen. Siehe dazu Kapitel 2.1.2.
2 Die Klasse Text dient zur Abfrage von Benutzereingaben. Sie erzeugt ein Feld, in dem der Nutzer seine
Eingabe tätigen kann.

In Abb. 2.8 ist gut zu
erkennen, dass die Fragen
nach Name, Vorname und
Alter beantwortet werden
müssen (rote Felder). In
jedem Question-Objekt wird
also gespeichert, ob eine
Frage beantwortet werden
muss oder nicht. Muss sie
beantwortet werden, wird das
I m p l e m e n t i e r u n g d e s K o n z e p t e s | 16
entsprechende Text-Feld rot markiert, bis die Frage beantwortet ist. Die Antwort auf die Frage
nach dem Geschlecht des Patienten kann in diesem Beispiel nur aus einer Liste
(männlich/weiblich) ausgewählt werden. Dies wird erreicht, indem als Eingabeart der
sogenannte Combo-Input ausgewählt wird. Dabei kann von der Anwendung frei definiert
werden, welche Auswahlmöglichkeiten angeboten werden sollen. Dazu werden diese
Möglichkeiten in dem zugehörigen Question-Objekt als Liste gespeichert.
Werden nun andere Parameter gewählt, um beispielsweise eine Messung hinzuzufügen, wie in
Abb. 2.9 zu sehen, wird ein völlig anderer Dialog erstellt und angezeigt. In diesem Fall ist
sowohl der Fenstertitel ‚Messung hinzufügen‘ als auch die übergreifende Fragestellung ‚Bitte
geben Sie die Messdaten ein‘ eine andere als in Abb. 2.8. Auch die Anzahl der Fragen beträgt
nun nur noch drei. Hier ist also gut zu erkennen, dass ein solcher Dialog flexibel gestaltet
werden kann.
Bei der ersten Frage – nach dem Pfad der Messungs-Datei – hat man nun die Möglichkeit
über einen Browse-Button eine Datei auszuwählen und so den Pfad der Datei zu bestimmen
(Abb. 2.9, im Hintergrund). Die zweite Frage – nach dem Aufnahmedatum der Messung –
wurde mit ‚heute' beantwortet, was aber nicht als Eingabe akzeptiert wird. In diesem Fall
wurde von der Anwendung der Eingabetyp als Datum gesetzt, weshalb nur Eingaben dieser
Form angenommen werden.
Abb. 2.8 Benutzereingabe eines neuen Patienten
Sowohl solche zusätzliche Buttons sowie derartige Fehler werden auf der rechten Seite des
Dialogs angezeigt, also in der zuvor erwähnten dritten Spalte der entsprechenden Frage-Zeile.

I m p l e m e n t i e r u n g d e s K o n z e p t e s | 17
Abb. 2.9 Benutzereingabe einer neuen Messung
Um die Benutzereingaben auf solche Bedingungen zu prüfen, wurde die Klasse InputListener
erstellt. Sie implementiert die Schnittstelle Listener 1 , wodurch sie einem Text-Feld als
Listener zugewiesen werden und somit auf Eingaben in dieses Text-Feld reagieren kann. Jedes
Text-Feld – und somit jede Frage – erhält ein eigenes InputListener-Objekt, welches gemäß
den im zugehörigen Question-Objekt gespeicherten Parametern die Eingabe überprüft. Hier
wird also unter anderem geprüft, ob eine Eingabe zwingend erforderlich ist, ob nur Zahlen
oder nur ein Datum eingegeben werden dürfen und ob die Eingabe eine bestimmte Anzahl an
Zeichen enthalten soll. Dazu sind in der InputListener-Klasse verschiedene Methoden
bereitgestellt. Hier ist es wieder von Vorteil, die Klassen flexibel zu gestalten, da so nur eine
einzige Listener-Klasse geschrieben werden muss. Als Ergänzung dazu wurde die Klasse
InputException erstellt. Diese erbt von der Klasse Exception und kennzeichnet somit einen
speziellen Fehlertyp. Der Vorteil, diesen speziellen Fehlertyp zu erstellen, liegt darin, dass in
dieser Klasse weitere Parameter definiert werden können. So enthält sie unter anderem den
boolean-Parameter toDelete, welcher standardmäßig auf false, also falsch, eingestellt ist, bei
Bedarf aber geändert werden kann. Die InputListener-Klasse verwendet diesen Parameter, um
1 Die Aufgabe eines Listeners ist es, beim Auftretens eines bestimmten Ereignisses eine zuvor definierte Aktion
auszuführen (Sehring, 2002). Zu diesem Zweck kann ein Listener beispielsweise einem Text-Objekt/Text-Feld
zugeweisen werden, um auf eine Eingabe in dieses Feld reagieren zu können.

I m p l e m e n t i e r u n g d e s K o n z e p t e s | 18
zu bestimmen, ob eine falsche Benutzereingabe gleich bei der Eingabe gelöscht wird –
toDelete hat den Wert true, also wahr – oder ob die Eingabe stehen gelassen wird – toDelete
hat den Wert false, also falsch. Die Eingabe zunächst stehen zu lassen ist immer dann
sinnvoll, wenn sie durch weitere Zeichen korrigiert werden kann. Ist also zum Beispiel eine
ganze Zahl gefordert, die nicht kleiner als 100 sein darf, ist die Eingabe 5 falsch. Gibt der
Nutzer nun aber noch die Ziffern 2 und 3 an, lautet die gesamte Eingabe 523, womit sie die
Bedingung erfüllt. Würde die falsche Benutzereingabe hier direkt gelöscht werden, könnte der
Nutzer die Bedingung niemals erfüllen. Hingegen ist es für die gleiche Bedingung durchaus
sinnvoll, dass Eingaben von Buchstaben oder anderen Zeichen, die keine Zahlen sind, sofort
gelöscht werden.
Neben diesen gibt es noch unzählige weitere Einstellungsmöglichkeiten. So kann man etwa
ein Mindest- oder Höchstalter, ein frühestes oder spätestes Aufnahmedatum und eine
minimale oder maximale Länge der Eingabe setzen.
Wichtig ist hierbei, dass all diese Einstellungen von der gerade aktiven Anwendung gesetzt
werden, die Anwendung also eine Benutzereingabe flexibel gestalten und entgegennehmen
kann, ohne, dass sich GUI und Anwendung hierbei näher kennen müssen. Auch muss hier
nicht für jede Benutzereingabe eine eigene Klasse geschrieben werden, sondern es genügt,
dank der flexiblen Gestaltung der Klassen, eine einzige Klasse, die InputDialog-Klasse, der je
nach Anforderung verschiedene Parameter übergeben werden können. Die einzige Bedingung
dafür ist, dass sowohl GUI als auch Anwendung die Question-Klasse kennen. Diese wird in
diesem Programm aber ohnehin als Teil des Adapters angesehen, da die in der Question-
Klasse definierte Funktionalität auch im DataBrowser hätte gespeichert werden können, was
aber zu einer sehr unübersichtlichen Klasse geführt hätte.
2.2.4. Modularität – Fazit
Dank dieser Vorgehensweise ist es gelungen, die Programm-Plattform stark modular zu
gestalten:
Soll nur eine Funktion innerhalb einer bereits bestehenden Anwendung hinzugefügt werden,
reicht es, diese in der Anwendung selbst an der entsprechenden Stelle einzubauen. Soll also
beispielsweise in der Reconstruction-Anwendung ein Mittelwertfilter als Rechts-Klick-Aktion
neu angeboten werden, so muss zunächst ein entsprechender Text erstellt werden, etwa
‚Wende Mittelwertfilter an‘. Dieser Text soll dem Nutzer sinnvollerweise beim Rechts-Klick
auf Bild-Objekte im Item Tree angezeigt werden, entsprechend muss dies in der

I m p l e m e n t i e r u n g d e s K o n z e p t e s | 19
Reconstruction-Anwendung abgefragt werden. Damit der Mittelwertfilter beim Tätigen dieser
Rechts-Klick-Aktion angewendet wird, muss er in der Reconstruction-Anwendung an
entsprechender Stelle eingebaut werden. Sämtliche andere Klassen bleiben hierbei
unverändert.
Soll eine komplett neue Anwendung in das Programm integriert werden, etwa ein
Vorhersage-Anwendung predict, so muss diese zunächst die Anwendungs-Schnittstelle
korrekt implementieren. Tut sie das, muss sie lediglich in dem static-Block des DataBrowsers
angemeldet werden. Zusätzlich muss eine entsprechende Perspektive erstellt werden, deren ID
in der Anwendung gespeichert ist.
Unter Umständen kann es notwendig sein, verschiedene Methoden in den DataBrowser zu
implementieren, falls die neue Funktion oder eine Funktion der neuen Anwendung Zugriff auf
Werte benötigt, die der DataBrowser bis dahin nicht angeboten hat. Im Regelfall sollte aber
eine solche Änderung entfallen, da der DataBrowser Zugriff auf alle wesentlichen Elemente
bietet und sämtliche speziellere Daten in der Regel nur in der Anwendung selbst bzw. dem
zugehörigen Datenmodell definiert sind, die Anwendung diese also nicht beim DataBrowser
erfragen muss.
Auf diese Weise ist es möglich komplexe Funktionalitäten in das Programm einzubauen, ohne
große Änderungen im Framework vornehmen zu müssen. Die Änderungen beschränken sich
im Wesentlichen auf die zu ändernde oder hinzuzufügende Anwendung selbst, unter
Umständen eine neue Perspektive und den DataBrowser.
2.3. Trennung der Benutzeroberfläche
In Kapitel 1.1 wurde die grundsätzliche Trennung der eingesetzten Views beschrieben. Diese
ist wichtig, da die Views unabhängig voneinander verändert und ausgetauscht werden sollen.
Letztlich trägt auch diese Forderung zum modularen Aufbau bei. Dennoch wird sie hier
separat betrachtet, da sie nicht unmittelbar mit dem Verändern der Programm-Funktionalität
verbunden ist. Vielmehr kann es sogar sinnvoll sein, bei der gleichen Studie – also auch bei
gleicher Funktionalität – für verschiedene Nutzer unterschiedliche Views einzusetzen. Zum
Beispiel ist für den Arzt hauptsächlich die administrative Funktionalität des Programms
wichtig, so dass eine entsprechend ausgerichtete View unter Umständen genügt und weitere
Views den Arzt nur stören würden. Der Analyst hingegen möchte vor allem Bilder
visualisieren und bearbeiten können, so dass eine darauf ausgelegte View eingebaut sein
muss. Wichtig ist jedoch, dass solche Veränderungen der Views nach Möglichkeit zu

I m p l e m e n t i e r u n g d e s K o n z e p t e s | 20
vermeiden sind, da jede Änderung an einem Programm ein gewisses Fehlerrisiko mit sich
bringt und zusätzliche Arbeit bedeutet. Vielmehr sollte auf eine allgemein nutzbare und
intuitiv aufgebaute Oberfläche hingearbeitet werden. In Einzelfällen kann eine solche
Veränderung aber durchaus sinnvoll sein.
Da die Views Teile der GUI sind, scheint eine Trennung zunächst nicht machbar und
tatsächlich sind hier der Modularität Grenzen gesetzt. Allerdings ist es doch gelungen, die
Verknüpfung zwischen diesen Views auf ein Minimum zu reduzieren.
Dazu müssen die Views zunächst als Eclipse RCP Views gekennzeichnet werden, um von dem
Eclipse RCP Projekt akzeptiert zu werden. Wie in Abb. 2.10 dargestellt, müssen die Views
von der abstrakten Klasse ViewPart erben, welche
sowohl von der abstrakten Klasse WorkbenchPart
erbt als auch die Schnittstelle IViewPart
implementiert. Dies ist nötig, um von Eclipse RCP als
View akzeptiert zu werden. Nun wird in jeder View
eine ID als String-Parameter gespeichert. Die View
kann nun in der plugins-Datei 1 des Projektes als
Projekt-View definiert werden, wobei die in der View
gespeicherte ID angegeben werden muss. Jede so
definierte View kann dann in jedwede Perspektive mit Hilfe der jeweiligen ID eingebaut
werden. Dabei kann angegeben werden, welche Größe die View – relativ zur gesamten
Perspektive – beim Öffnen der Perspektive haben soll. Diese Größen können später manuell
vom Nutzer angepasst werden. Somit ist es also möglich, in zwei Perspektiven dieselben
Views zu verwenden, jedoch mit unterschiedlichen Startgrößen. Dies kann nützlich sein, falls
sich der Verwendungszweck der Perspektiven unterscheidet und unterschiedliche Views als
‚wichtig‘ angesehen werden. Dies ist auch eine Lösung, um die Benutzeroberfläche mit
einfachen Änderungen den Anforderungen des Nutzers anzupassen. So könnten die Ärzte und
Analysten mit den selben Views arbeiten, wobei die jeweils wichtigen Views entsprechend
größer erstellt werden, anstatt dass hier, wie am Anfang des Kapitels beschrieben,
unterschiedliche Views verwendet werden. Prinzipiell ist die Anzahl der eingebauten Views
nicht beschränkt, wobei viele verschiedene Views schnell zu Unübersichtlichkeit führen und
somit vermieden werden sollten.
1 In der plugins-Datei eines RCP-Projektes werden verschiedene Einstellungen gespeichert, siehe dazu Kapitel
1.2.1
Abb. 2.10 Erstellung einer View

I m p l e m e n t i e r u n g d e s K o n z e p t e s | 21
Die einzelnen Views sind auf diese Weise völlig unabhängig voneinander gehalten und
müssen lediglich in den Perspektiven bekannt sein.
Zusätzlich muss der DataBrowser die jeweiligen View-Klassen und deren angebotenen
Methoden kennen, da er auf diese zugreifen können muss. Auch hier wird der Vorteil des
Einsatzes eines Adapters wieder deutlich:
Sämtliche Anwendungen rufen auch nach Veränderungen an den Views dieselben Methoden
im DataBrowser auf. Lediglich dieser muss angepasst werden, womit die Änderungen wieder
zentral in dieser Klasse vorgenommen werden können.
2.4. Persistente Speicherung
Ebenso wichtig wie die Anpassungsfähigkeit des Programms an neue Funktionen ist die
persistente Speicherung der (erzeugten) Daten. Hierzu ist eine komplexe
Datenbankanbindung nötig, die nach Möglichkeit jedoch komplett im Datenmodell, also
völlig unabhängig von GUI und den Anwendungen, sein soll. Eine Einschränkung gibt es
hierbei allerdings, da eine Anwendung je nach Typ eines Objektes die auszuführende Aktion
wählt. Jede Anwendung muss also zumindest die Datentypen kennen, mit denen sie umgehen
kann. Die Datenspeicherung und das Einlesen der Daten jedoch bleibt Aufgabe des
Datenmodells.
2.4.1. Datenbankanbindung
Die Datenbankanbindung ist hauptsächlich in der Klasse DB_Connect definiert. Dies ist die
einzige Klasse, die die gesamte Datenbank kennen muss. Hier werden sämtliche Tabellen als
DBEntryLists gespeichert. Diese DBEntryLists erben von PDAtomList, welche im
Wesentlichen eine Liste von PDAtom-Objekten bzw. DBEntry-Objekten ist. In diesen Listen
werden allerdings noch zusätzliche Informationen wie der Typ der Liste, die zugewiesene
PDAtomFactory und eine Liste mit bekannten PDAtomLists gespeichert.
Das Einlesen der Daten aus der Datenbank übernehmen spezifische DBEntryFactory-
Unterklassen, es gibt also für jede Tabelle in der Datenbank eine eigene Unterklasse. Eine
Änderung der Datenbank bedingt somit eine große Änderung im Datenmodell, da für jede
neue Tabelle eine neue Klasse definiert werden muss. Dies ist aber nicht weiter schlimm, da
jede Datenbankanbindung exakt an die zugehörige Datenbank angepasst werden muss, also
schon das Umbenennen einer einzigen Spalte zu notwendigen Änderungen in der
Datenbankanbindung führt. Gerade aus diesem Grund ist es wichtig, die Datenbank zentral

I m p l e m e n t i e r u n g d e s K o n z e p t e s | 22
auf einem Server zu verwalten, um versehentliche Falschbenennungen von Tabellen oder
Spalten seitens der einzelnen Anwender zu vermeiden (siehe Kapitel 4).
In den DBEntryFactory-Unterklassen und der allgemeinen DBEntryFactory-Klasse sind die
genauen SQL-Abfragen definiert. An dieser Stelle und in der Klasse DB_Connect ist noch
Handlungsbedarf, da bislang nur SQL-basierte Datenbanken genutzt werden können.
Der Vorteil des Factory Pattern (Haunhorst, 2009 S. 6 ff) wird dennoch jetzt bereits deutlich:
Der größte Teil der Datenbankanbindung – der Teil, der bei einer Veränderung der Datenbank
ebenfalls verändert werden muss – ist in den Fabriken definiert, sodass die einzelnen
PDAtom-Unterklassen unverändert bleiben können. Da ein ganzer Teil der
Datenbankanbindung für alle Fabriken gleich ist, kann dieser Teil sogar in der Fabrik-
Oberklasse definiert werden. Somit machen Veränderungen in diesem Bereich nur in dieser
einen Klasse Veränderungen notwendig. In diesen Fabriken können zudem Verknüpfungen
zwischen mehreren Tabellen der Datenbank erzeugt werden, falls dies notwendig ist. Die
zugehörigen PDAtom-Unterklassen bleiben somit unverändert und voneinander unabhängig.
2.4.2. Chain of Responsibility
Interessant ist in diesem Zusammenhang auch die Verwendung des Chain of Responsibility
Pattern (Haunhorst, 2009 S. 10 ff). Dieses kommt ins Spiel, sobald ein Objekt in einer
Tabelle bzw. der zugehörigen PDAtomList gesucht wird, sich das Objekt jedoch nicht in
dieser Tabelle, sondern in einer anderen, befindet. In der Praxis bedeutet das, dass
beispielsweise ein bestimmter Patient gesucht wird, dem Anfragesteller jedoch lediglich die
Studienliste bekannt ist. Als Anfragesteller wird hier der Programmteil bezeichnet, der die
Suchanfrage nach dem Patienten stellt. Aufgrund der Modularität kann es dabei schnell
vorkommen, dass der Anfragesteller nicht alle Listen kennt. Dann stellt er die Suchanfrage an
alle Listen, die er kennt.
Wie in Kapitel 2.4.1 beschrieben ist jede Tabelle der Datenbank in der DB_Connect- Klasse
als DBEntryList gespeichert. Beispielsweise könnte es die Tabellen ‚Studie’, ‚Patient’ und
‚Messung’ geben, wobei dem Anfragesteller nur die Tabelle ‚Studie‘ bekannt ist. Wird nun
nach einem Patienten gesucht, muss dies in der Tabelle ‚Studie’ geschehen, da die Tabelle
‚Patient’ dem Anfragesteller hier nicht bekannt ist. Die Suchanfrage muss also an die
zugehörige DBEntryList gestellt werden, welche ihre gespeicherten Einträge – die Studien –
nach einem passenden Eintrag durchsucht. Dazu überprüft die Liste zunächst, ob das gesuchte
Objekt überhaupt vom Typ der Listeneinträge ist, ob der Patient also eine Studie ist. In der

I m p l e m e n t i e r u n g d e s K o n z e p t e s | 23
DBEntryList ist zudem gespeichert, welche Listen bekannt sind. Der Studienliste ist zum
Beispiel die Patientenliste bekannt, der Patientenliste wiederum ist die Messungsliste bekannt.
Da der gesuchte Objekttyp ‚Patient‘ nicht zum eigenen Typ ‚Studie‘ passt, leitet die
Studienliste die Suchanfrage an alle ihr bekannten Listen weiter, welche wiederum prüfen, ob
der gesuchte Datentyp zu ihren jeweiligen Daten passt. Passt er nicht, wird die Suchanfrage
wiederum an alle bekannten Listen weitergeleitet. Falls der Datentyp jedoch passt, werden
alle Listeneinträge nach dem gesuchten Objekt durchsucht. Hier würde also die Studienliste
die Anfrage unter anderem an die Patientenliste übergeben, bei welcher der Datentyp ‚Patient’
passt. Die Patientenliste wird also durchsucht und das gesuchte Objekt, falls bereits
vorhanden, zurückgegeben.
Ist das gesuchte Objekt nicht vorhanden, kann mittels eines weiteren Parameters bestimmt
werden, ob es erzeugt werden soll oder nicht.
2.5. Item Tree
Wie in Kapitel 1.1 beschrieben soll dem Nutzer ein Objekt-Baum, ein so genannter Item Tree,
angezeigt werden. Dieser soll zunächst die im Programm definierten Hauptlisten anzeigen.
Diese Listen werden von der Hauptanwendung, also der zuerst beim DataBrowser
angemeldeten Anwendung, bzw. von deren Hauptmodel – ebenfalls das zuerst angemeldete
Model – definiert. In diesem Modell sind die Hauptlisten als PDAtomLists gespeichert.
Wird nun das Programm gestartet, also auch die ItemTreeView erstellt, wird durch die
ItemTreeView die Methode initialize der MakeTree-Klasse aufgerufen. Diese erfragt zunächst
die Hauptlisten vom DataBrowser,
der die Anfrage an seine
Hauptapplikation weiterleitet,
welche die Hauptlisten schließlich
von ihrem Hauptmodel erfragt und
über den DataBrowser an die
MakeTree-Klasse zurückgibt (vgl.
Abb. 2.11). Die Hauptanwendung
ist hierbei die erste Anwendung in
der Anwendungsliste des
DataBrowsers und deren
Hauptmodel ist das erste Model in
Abb. 2.11 Initialisierung des Item Trees

I m p l e m e n t i e r u n g d e s K o n z e p t e s | 24
deren Modelliste. Daraufhin erstellt die initialize-Methode für jede Hauptliste ein Objekt in
dem Item Tree, wobei dieses Objekt nach dem Namen der jeweiligen Hauptliste benannt wird.
Zunächst war es das Ziel, es dabei zu belassen und alle weiteren Objekte erst bei Bedarf zu
erstellen, um möglichst wenige Systemressourcen für den Item Tree zu benötigen. Die Inhalte
einer Hauptliste sollten also erst angezeigt werden, wenn auf das +-Zeichen neben dem
entsprechenden Objekt im Item Tree geklickt wird. Das Problem dabei ist jedoch, dass die
+-Zeichen nur dann zu sehen sind, wenn bereits Untereinträge für dieses Objekt vorliegen.
Aus diesem Grunde wird nun immer eine Ebene mehr geladen als benötigt.
Abb. 2.12 veranschaulicht dieses Prinzip:
Zu Beginn ist im Item Tree jede Hauptliste als Objekt dargestellt und deren Einträge bereits
im Programm geladen. In der Abbildung gibt es also die drei Hauptlisten ‚Element1‘,
‚Element2‘ und ‚Element3‘, welche angezeigt werden. Zusätzlich sind deren jeweiligen
Unterelemente bereits geladen. Klickt man nun auf das +-Zeichen neben einer der
Hauptlisten, werden deren Einträge – Unterelemente – angezeigt und die nächste Ebene wird
geladen. Hier ist zu erkennen, dass die Hauptliste ‚Element1‘ expandiert wurde und somit nur
deren Einträge angezeigt und die entsprechenden nächsten Unterelemente geladen werden.
Die anderen Hauptlisten bleiben davon unberührt. Analog lässt sich das Schema weiterführen,
falls nun ‚Element1a‘ expandiert würde, was ‚Element1b‘ unverändert lassen würde.
Abb. 2.12 Laden des Item Trees
Konkret heißt das, dass zunächst zum Beispiel die Hauptlisten Patient und Study geladen
werden und die gleichnamigen Objekte angezeigt werden. Expandiert man nun die Patient-
Liste werden alle Patienten angezeigt und zu jedem Patienten die nächste Ebene geladen.
Diese Ebene beinhaltet nun Objekte, die die verschiedenen Datentypen repräsentieren, die zu
diesem Patienten gehören. Also könnte dort zum Beispiel Measurement stehen, da es zu
diesem Patienten Messungen gibt. Diese Objekte werden nun alle erstellt, aber nicht
angezeigt. Da diese Objekte jedoch nur einen Namen enthalten und pro Patient und Datentyp

I m p l e m e n t i e r u n g d e s K o n z e p t e s | 25
nur ein Objekt erstellt wird, benötigt dieser Vorgang nur wenige Systemressourcen.
Expandiert man nun ein Patientenobjekt, werden die eben genannten Unterkategorien dieses
Patienten angezeigt und zu jeder Unterkategorie die nächste Ebene geladen. Wird also das
Patientenobjekt ‚Müller‘ expandiert, wird angezeigt, welche Datentypen für Müller zur
Verfügung stehen, also zum Beispiel Messungen, und gleichzeitig lädt das Programm die
nächste Ebene dieses Patienten, in diesem Fall also alle Messungen. Sämtliche andere
Einträge des Item Tree bleiben dabei unverändert. Das heißt, dass trotz dieses Umstands,
immer eine Ebene mehr laden zu müssen als angezeigt wird, kaum zusätzliche
Systemressourcen benötigt werden. Hierbei können auch mehrere Datentypen, also
Unterkategorien, vorhanden sein, wenn zum Beispiel zu einem Patienten nicht nur
Messungen, sondern auch rekonstruierte Bilder, Analyseergebnisse oder ähnliches vorhanden
sind.
2.5.1. Observer Pattern
Für den Item Tree sind die Vorteile des Observer Pattern (Haunhorst, 2009 S. 9 f) von
entscheidender Bedeutung. Das Observer Pattern beschäftigt sich mit der Frage, wie Objekte,
die einander nicht näher kennen, Informationen über ihren jeweiligen Zustand austauschen
können. Die wichtigste Aufgabe, die mit Hilfe dieses Pattern bewerkstelligt werden kann, ist
die Verknüpfung der im Item Tree angezeigten Elemente mit den dazugehörigen PDAtom-
Objekten. Dies ist vor allem dann von Bedeutung, wenn ein PDAtom-Objekt mit mehreren
Elementen im Item Tree verknüpft ist. So ist jeder Patient in der Patientenliste und in jeder
Studie, an der er teilnimmt, aufgeführt. Es gibt also entsprechend viele Einträge für diesen
Patienten im Item Tree. Soll nun der Name des Patienten geändert werden, muss dies sowohl
bei dem zugehörigen PDAtom-Objekt wie bei all seinen Einträgen im Item Tree geschehen.
Bisher ist diese Observer-Funktionalität nicht implementiert. Geplant ist das Vorgehen
folgendermaßen:
Die im Item Tree angezeigten Elemente sind vom Typ AdminTreeObject und bieten zunächst
keinerlei diesbezügliche Funktionen. Die AdminTreeObject-Klasse wurde speziell für den
Item Tree entwickelt und dient in erster Linie dazu, den Namen und die Atom_OID des
Elementes zu speichern. Der Name wird benötigt, um ihn im Item Tree anzeigen zu können.
Mit Hilfe der Atom_OID ist jederzeit überprüfbar, mit welchem Daten-Objekt dieses Element
assoziiert ist. Wenn nun die AdminTreeObject-Klasse zusätzlich die Observer-Schnittstelle
implementiert, stehen ihr viele Funktionen des Observer Pattern zur Verfügung. Jede

I m p l e m e n t i e r u n g d e s K o n z e p t e s | 26
AdminTreeObject-Instanz ist damit ein potentieller Beobachter anderer Objekte. Mit jeder
dieser Instanzen ist zudem ein PDAtom-Objekt assoziiert, welches über die in beiden
Objekten gespeicherte Atom_OID leicht zu identifizieren ist. In diesem PDAtom-Objekt sind
alle wichtigen Parameter des Daten-Objektes gespeichert. Auf diese Weise muss für das
Erstellen des Item Trees nur eine Instanz der AdminTreeObject-Klasse mit wenigen
Parametern erzeugt werden. Erst wenn auf das Datenobjekt konkret zugegriffen wird, muss
auch das PDAtom-Objekt erzeugt werden, welches aufgrund der höheren Anzahl an
Parametern mehr Systemressourcen benötigt. Nun muss die PDAtom-Klasse noch die
Observable-Schnittstelle implementieren, wodurch ihr ebenfalls viele Funktionen des
Observer Pattern zugänglich sind, diesmal jedoch Funktionen des beobachteten Objektes.
Jedes PDAtom-Objekt ist somit ein potentielles Subjekt und kann von Beobachtern – etwa des
Typs AdminTreeObject – beobachtet werden. Auf diese Weise werden alle wichtigen Daten,
wie der anzuzeigende Name des Objektes, in den AdminTreeParent-Instanzen, die im Item
Tree angezeigt werden, aktuell gehalten.
Konkret werden hier nur ein paar Funktionen des Observer Pattern benötigt:
Zum Einen braucht die PDAtom-Klasse eine Liste, in der die Beobachter gespeichert werden
und eine Methode, mit Hilfe derer sich ein Beobachter anmelden – also in die Liste eintragen
– kann. Desweiteren muss eine update-Methode in dieser Klasse vorhanden sein, die bei einer
Veränderung des Namens oder der Atom_OID die Beobachter benachrichtigt. Um die
Beobachter benachrichtigen zu können, müssen diese entsprechende Methoden anbieten, etwa
‚benachrichtige‘ oder ‚aktualisiere‘. Dabei sollte der veränderte Wert mit übergeben werden.
Abb. 2.13 zeigt, wie dieses Schema konkret zu implementieren ist. Dabei sind die hierfür
wichtigen Parameter ‚name‘, ‚oid‘ und ‚observer‘ und die wichtigen Methoden ‚aktualisiere‘,
‚registriere‘ und ‚update‘ dargestellt.
Bei den Methoden ist in Klammern der jeweils zu übergebende und hinter der Methode der
zurückgegebene Wert dargestellt. Die Liste mit den angemeldeten Beobachtern ist hier
‚observer‘ genannt und die dazugehörige Methode zum An- und Abmelden der Beobachter
heißt ‚registriere‘. Diese Methode kann also von einem Beobachter aufgerufen werden, wobei
er sich selbst als Argument übergibt. Dadurch wird er in die Beobachterliste eingetragen.
Analog sollte eine Methode angeboten werden, mit Hilfe derer sich ein Beobachter wieder aus
dieser Liste austragen kann. Da dieser Vorgang jedoch analog zum Anmelden abläuft, wird
dieser Punkt hier nicht weiter aufgegriffen. In der Abbildung ist ebenfalls zu erkennen, dass in
der AdminTreeObject-Klasse die aktualisiere-Methode implementiert sein muss, wobei diese
für die Werte ‚name‘, also einen String-Wert, und OID, also eine Atom_OID, gelten muss.

I m p l e m e n t i e r u n g d e s K o n z e p t e s | 27
Abb. 2.13 Realisierung des Observer Pattern
Diese Methode wird wiederum von der update-Methode derjenigen PDAtom-Objekte
aufgerufen, bei denen diese AdminTreeObject-Instanz als Beobachter registriert ist. Da in der
OID auch der Name des Objektes gespeichert ist (siehe
Abb. 2.13), reicht es, die aktualisiere-Methode für die OID, also den Objekttyp Atom_OID,
anzubieten. Dass der Name überhaupt in einem separaten Parameter gespeichert wird, liegt an
dem modularen Aufbau des Programmes, da es Programmteile in der GUI gibt, die zwar den
Namen eines Objektes benötigen – etwa zum Anzeigen desselben – jedoch die Klasse
Atom_OID nicht kennen. In der Methode zur Aktualisierung der Atom_OID muss folgerichtig
der separat gespeicherte Name ebenfalls auf den neuen Wert aus der OID geändert werden.
Ebenso muss sichergestellt werden, dass bei einer Veränderung des separat oder in der
Atom_OID gespeicherten Namens in einem PDAtom-Objekt der jeweils anders gespeicherte
Name mit aktualisiert wird. Dies lässt sich gut in der update-Methode dieser Klasse
realisieren, die, wie zuvor gefordert, bei jeder Veränderung dieser Parameter aufgerufen wird.
Abb. 2.14 zeigt einen möglichen Ablauf der update-Methode der PDAtom-Klasse:
Die update-Methode wird immer dann aufgerufen, wenn eine Änderung an dem PDAtom-
Objekt vorgenommen wurde. In diesem Fall führen jedoch nur Änderungen an dem Namen
oder der OID zu weiteren Aktionen. Wird einer dieser Werte geändert, muss, wie zuvor
gefordert, der separat und der in der OID gespeicherte Name abgeglichen werden. Ist also der
separat gespeicherte Name verändert worden (erster Fall in der Abbildung), wird der in der
OID gespeicherte Name auf diesen Wert gesetzt. Wird umgekehrt der in der OID gespeicherte
Name geändert (zweiter Fall in der Abbildung), wird analog dazu der separat gespeicherte
Name aktualisiert. Wird die OID geändert, der in der OID und der separat gespeicherte Name
jedoch nicht, ist kein Abgleich nötig. Es könnte also zum Beispiel die in der OID gespeicherte

Zahl verändert werden. Dadurch wird die
update-Methode zwar aktiv, ein
Abgleich der Namen ist aber nicht nötig.
In jedem Fall durchläuft die update-
Methode danach in einer Schleife alle
AdminTreeObject-Instanzen, die bei
diesem PDAtom-Objekt als Beobachter
registriert sind, also alle Beobachter in
der Liste observer. Bei jedem dieser
Beobachter wird die aktualisiere-
Methode aufgerufen, wobei die
aktualisierte OID übergeben wird. In der
aktualisiere-Methode wird nun zunächst
I m p l e m e n t i e r u n g d e s K o n z e p t e s | 28
die in der AdminTreeObject-Instanz gespeicherte OID der vom PDAtom-Objekt übergebenen
OID gleichgesetzt. Daraufhin wird der separat gespeicherte Name auf den in der – jetzt bereits
aktualisierten – OID gespeicherten geändert.
Abb. 2.14 Sequenzdiagramm der update-Methode

V a l i d i e r u n g d e r P r o g r a m m f u n k t i o n a l i t ä t | 29
3. Validierung der Programmfunktionalität
Zwar sind derzeit bereits exemplarisch Anwendungen zur Administration, Rekonstruktion
und Analyse der Daten definiert, explizite Funktionen bieten diese jedoch bislang nicht. Zur
Demonstration der Funktionsweise des Programmes wurde aus diesem Grunde eine
Differenzbilderzeugungsfunktion in der Analysis-Anwendung implementiert. Diese zunächst
sehr einfache Operation dient im Wesentlichen zur Veranschaulichung des prinzipiellen
Ablaufs. So müssen hierfür, ebenso wie für jeden anderen Filter, Bilder – in dem Fall zwei –
einer Anwendung zugänglich gemacht werden. Ebenso muss die Anwendung die von ihr
produzierten Bilder – oder allgemein Daten – dem Programm zugänglich machen können.
Was genau die Anwendung mit den Bilder macht, ist dabei also für die Anbindung an das
Programm unwichtig und nur in der Anwendung selbst definiert.
Diese Differenzbild-Funktion soll als Rechts-Klick-Aktion angeboten werden, wenn der
Nutzer die Analysis-Perspektive geöffnet hat – sich also in der Analysis-Anwendung befindet
– und auf ein Bild-Objekt klickt. Dazu ist in der Analysis-Anwendung ein Rechts-Klick-Text
definiert, nämlich ‚Von diesem Bild ein Differenzbild erzeugen‘, welcher bei einem
entsprechenden Rechts-Klick an die ItemTreeView zurückgegeben wird (siehe Kapitel 2.2.2).
Wird diese Aktion nun ausgewählt, speichert die Analysis-Anwendung die übergebene OID
des Bildes in dem Parameter firstOID. Zusätzlich wird der boolean-Parameter namens
secondElement, der standardmäßig auf false gesetzt ist, auf true geändert. Somit weiß die
Anwendung, dass das erste Element bereits gewählt ist. Um das zweite Element zu wählen, ist
ein neuer Rechts-Klick-Text nötig. Hierbei ist die variable Gestaltung der Rechts-Klick-
Aktionen nützlich, da nun bei einem Rechts-Klick auf ein weiteres Bild ein anderer Text
übergeben werden kann, nämlich ‚Dieses Bild von dem ersten subtrahieren‘.
In Abb. 3.1 ist zu erkennen, dass dazu lediglich eine simple if-Abfrage in der Anwendung
nötig ist, wobei der Parameter secondElement als Argument genutzt wird. Ist der Wert von
secondElement false, wird der erste Text zurückgegeben, bei true der zweite. Eine solche if-
Abfrage wird auch in der Doppel-Klick-Methode genutzt, da bei einem Doppel-Klick auf ein
zweites Bild – ein erstes Bild wurde also schon ausgewählt – ebenfalls die
Differenzbildfunktion aufgerufen werden soll. Ist hingegen noch kein erstes Bild ausgewählt,
soll bei einem Doppel-Klick das Bild lediglich angezeigt werden. Wird nun eine solche
Doppel-Klick-Aktion oder die entsprechende Rechts-Klick-Aktion bei einem zweiten Bild
ausgeführt, wird die eigentliche Differenzbild-Methode in der Analysis-Anwendung
aufgerufen, wobei die OID des zweiten Bildes übergeben wird.

V a l i d i e r u n g d e r P r o g r a m m f u n k t i o n a l i t ä t | 30
Abb. 3.1 Erzeugung eines Differenzbildes
An dieser Stelle könnte also jedwede andere Funktionalität eingebaut werden, ohne dass an
dem prinzipiellen Vorgang etwas geändert werden müsste.
In diesem Fall werden in der Differenzbild-Methode zunächst die Parameter firstOID und
secondElement auf ihre ursprünglichen Werte gesetzt, damit nach Ausführung dieser Funktion
wieder ein neues erstes Bild gewählt werden könnte – für ein neues Differenzbild. Der Wert
von firstOID wird also gelöscht und secondElement wird wieder auf false gesetzt. Dabei wird
die in firstOID gespeicherte OID jedoch temporär innerhalb der Methode gespeichert, um
noch genutzt werden zu können. Um nun an das tatsächliche Bild zu gelangen gibt es
verschiedene Möglichkeiten. Hier wurde der in der OID gespeicherte Pfad des Bildes genutzt,
um es zu laden. Prinzipiell könnte auch das dazugehörige PDAtom-Objekt – hier also ein
P4Image 1 -Objekt – genutzt werden. Da die ursprünglichen Bilder – und somit die P4Image-
Objekte – jedoch nicht verändert werden, ist dies hier nicht nötig.
Nachdem das Differenzbild nun durch simple Subtraktion der jeweiligen Pixelwerte erzeugt
wurde, muss es dem restlichen Programm wieder zur Verfügung gestellt werden. Dazu wird
ein P4Image-Objekt mit den Pixelwerten des erzeugten Bildes erstellt. Der darin gespeicherte
Name wird aus den Namen der verwendeten Bilder zusammengestellt. Zudem werden die
OIDs der verwendeten Bilder in der Liste partnerOIDs 2 dieses Objektes gespeichert, sodass
jederzeit erkenntlich ist, welche Bilder genutzt wurden. Dieses Objektes wird nun an die
addChildToTree-Methode des DataBrowsers übergeben, die dieses Objekt in den Item Tree
einbaut. Auf diese Weise ist das erzeugte Bild also dem restlichen Programm zugänglich
gemacht worden. Hierbei muss noch an der Speicherung der erzeugten Bilder gearbeitet
werden, da diese derzeit nicht im DICOM-Format gespeichert werden können. Dabei ist
denkbar, das Bild direkt bei seiner Erzeugung in der Datenbank und in einem Filesystem zu
1 P4Image ist eine Unterklasse von PDAtom und dient der Bildspeicherung. Siehe dazu Kapitel 2.1.4.
2 In der Liste partnerOIDs speichert ein PDAtom-Objekt, mit welchen anderen Objekten es verknüpft ist.

V a l i d i e r u n g d e r P r o g r a m m f u n k t i o n a l i t ä t | 31
speichern, oder aber erst nach entsprechender Aufforderung des Nutzers. Sobald das Bild
gespeichert wird, muss der entsprechende Pfad in der OID des zugehörigen P4Image-
Objektes gespeichert werden.
Bislang geht bei einem Programmneustart die Information, welche Bilder verwendet wurden,
verloren. Eine mögliche Lösung dieses Problems ist, die erzeugten – und in einem Filesystem
gespeicherten – Bildern nach einem bestimmten Muster zu benennen, aus dem das Programm
bei einem Neustart diese Information erhalten kann. Ein sinnvolles Muster ist beispielsweise,
in dem Namen des erzeugten Bildes die OIDs der verwendeten Bilder mit einzubauen. Eine
weitere Variante ist, in einer zusätzlichen Datenbank-Tabelle solche Verlinkungen zu
speichern. Dabei dürfen jedoch keineswegs die Bilder selbst in der Datenbank gespeichert
werden, sondern die zugehörigen Pfade.

4. Ausblick
A u s b l i c k | 32
So gut ein Konzept auch ausgearbeitet ist, bei der Realisierung/Implementierung desselben
tauchen immer wieder Fehler auf bzw. werden immer wieder Teile des Konzeptes verändert.
Sei es, weil Funktionen leichter als zuvor geplant realisiert werden können oder aber weil
gewisse Teile der Planung sich so nicht implementieren lassen. Dies hat sich vor allem durch
den Einsatz von Eclipse RCP bemerkbar gemacht. Zwar wurde durch dieses Plug-In das
Erstellen eines lauffähigen Programms erleichtert, doch kam es immer wieder zu
Schwierigkeiten, da es mit vielen Funktionen anderer Klassen nicht zurecht kommt.
Von diesen Änderungen abgesehen, ist es gelungen, die im Konzept festgelegten Ziele zu
erreichen. Jetzt bereits ist ein großer Teil der grundlegenden Funktionalität realisiert worden.
Dabei ist es bisher gelungen das Programm als Plattform zu gestalten, also so modular
aufzubauen, dass Änderungen in einem Programmteil keine – oder möglichst wenige –
Änderungen in anderen Programmteilen bedingen. Gleichzeitig wurde eine
Benutzeroberfläche geschaffen, die unabhängig von den eingebauten Anwendungen ist. Auf
diese Weise kann das Programm für unterschiedliche Zwecke genutzt werden, ohne dass der
Nutzer sich jedes Mal in die Benutzeroberfläche einarbeiten muss.
Noch ausgearbeitet werden muss die Datenbankanbindung, speziell die Speicherung von
neuen Daten und das Anbinden von weiteren Datenbanktypen. Ziel ist es, mit zentral auf
Servern gespeicherten Datenbanken zu arbeiten, auf die der Nutzer dann zugreifen kann.
Bisher muss die Datenbank lokal auf dem verwendeten Rechner gespeichert werden. In
Kapitel 2.4.1 wurde beschrieben, wie eng eine Datenbankanbindung an die jeweilige
Datenbank gebunden ist. Muss die Datenbank nun bei jedem Nutzer lokal erstellt werden, ist
dies eine große Fehlerquelle, da schon das versehentlich falsche Benennen einer einzigen
Tabelle oder Spalte zu Problemen führt. Wird die Datenbank hingegen zentral auf einem
Server verwaltet, wird nicht nur dieses Problem umgangen, sondern zugleich auch
sichergestellt, dass jeder Nutzer auf dieselben Daten zugreift, die Daten also eindeutig
abgespeichert sind. Auch die in Kapitel 3 angesprochene Speicherung erstellter Daten in
einem Filesystem muss noch ausgearbeitet werden, sodass diese Daten nach einem
Programmneustart wieder eindeutig zuzuordnen sind.
Zudem existiert noch keine Rechteverwaltung. So soll ein Arzt auf die Patientendaten
derjenigen Patienten Zugriff haben, die er behandelt. Ein Patient selbst soll jedoch nur auf
seine eigenen Daten Zugriff haben und auch diese nur bedingt verändern können.
Auch muss das Observer Pattern für die Kommunikation von AdminTreeObject-Objekten
und PDAtom-Objekten nach dem in Kapitel 2.5.1 erwähnten Schema umgesetzt werden.

Abbildungsverzeichnis
A b b i l d u n g s v e r z e i c h n i s | VI
Abb. 1.1 Programmaufbau ......................................................................................................................................2
Abb. 2.1 Anmeldung von Anwendungen ..................................................................................................................8
Abb. 2.2 Sequenzdiagramm Programmstart ...........................................................................................................9
Abb. 2.3 Perspektivenwechsel ................................................................................................................................11
Abb. 2.4 Rechts-Klick in der Analysis-Anwendung..................................................................................................12
Abb. 2.5 Rechts-Klick in der Admin-Anwendung ....................................................................................................12
Abb. 2.6 Erstellen der Rechts-Klick-Aktionen..........................................................................................................13
Abb. 2.7 Bezeichnung der Rechts-Klick-Aktionen ...................................................................................................14
Abb. 2.8 Benutzereingabe eines neuen Patienten ..................................................................................................16
Abb. 2.9 Benutzereingabe einer neuen Messung ...................................................................................................17
Abb. 2.10 Erstellung einer View .............................................................................................................................20
Abb. 2.11 Initialisierung des Item Trees .................................................................................................................23
Abb. 2.12 Laden des Item Trees .............................................................................................................................24
Abb. 2.13 Realisierung des Observer Pattern .........................................................................................................27
Abb. 2.14 Sequenzdiagramm der update-Methode ...............................................................................................28
Abb. 3.1 Erzeugung eines Differenzbildes ..............................................................................................................30

Literaturverzeichnis
L i t e r a t u r v e r z e i c h n i s | VII
Diplomarbeit / Verf. Benke Roman // Objektorientiertes Design und Entwicklung einer
Applikation zur biomedizinischen Bildverarbeitung - predict4H. - Remagen : [s.n.], 2009.
Interdisziplinäres Hauptpraktikum für Studierende der Elektrotechnik [Online] / Verf.
Sehring Hans-Werner. - April 2002. - 9. August 2009. - http://www.sts.tu-
harburg.de/~r.f.moeller/lectures/ihp-sose-04/Listener.html.
Open Source: Framework predict4H überbrückt die Kluft zwischen
Grundlagenforschung und Diagnostik [Artikel] / Verf. Neeb-Burlacu Paula // RESOOM. -
2008. - November/Dezember.
Praxisprojektbericht [Buch] / Verf. Haunhorst Martin. - Remagen : [s.n.], 2009.
Wikipedia [Online]. - 14. Juli 2009. - http://de.wikipedia.org/wiki/Eclipse_(IDE).

Selbstständigkeitserklärung
S e l b s t s t ä n d i g k e i t s e r k l ä r u n g | VIII
Hiermit versichere ich, Martin Haunhorst, dass ich den vorliegenden Bericht selbstständig und
nur unter Verwendung der angegebenen Quellen und Hilfsmittel verfasst habe.
Remagen, 14.08.2009 Martin Haunhorst