gms | German Medical Science

53. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e. V. (GMDS)

Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie

15. bis 18.09.2008, Stuttgart

Entwurf und Implementierung eines Plugin-Frameworks für die Strahlentherapieplanungssoftware VIRTUOS

Meeting Abstract

Search Medline for

  • Michael Müller - Deutsches Krebsforschungszentrum Heidelberg, DKFZ, Heidelberg, Deutschland
  • Armin Stoll - Deutsches Krebsforschungszentrum Heidelberg, DKFZ, Heidelberg, Deutschland
  • Martin Haag - Medizinische Informatik, Hochschule Heilbronn, Heilbronn, Deutschland
  • Rolf Bendl - Deutsches Krebsforschungszentrum Heidelberg, DKFZ, Heidelberg, Deutschland

Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie. 53. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie (gmds). Stuttgart, 15.-19.09.2008. Düsseldorf: German Medical Science GMS Publishing House; 2008. DocSD1-2

The electronic version of this article is the complete one and can be found online at: http://www.egms.de/en/meetings/gmds2008/08gmds240.shtml

Published: September 10, 2008

© 2008 Müller et al.
This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by-nc-nd/3.0/deed.en). You are free: to Share – to copy, distribute and transmit the work, provided the original author and source are credited.


Outline

Text

Einleitung und Fragestellung

Am Deutschen Krebsforschungszentrum wird das Strahlentherapieplanungssystem VIRTUOS (VIRTUal RadiOtherapy Simulator [2]) entwickelt. Die Pflege des Systems ist aufwendig, da das Adaptieren und die Integration neuer Verfahren über die Jahre mit unterschiedlichen Konzepten erfolgte. Es resultierten lange Entwicklungszyklen und die Erweiterung um neue Funktionalität erfordert die Neukompilierung der gesamten Anwendung.

Ziel dieser Arbeit ist es ein sicheres Konzept zu erarbeiten und zu implementieren, das das dynamische Einbinden ausgewählter Funktionalität während der Laufzeit ermöglicht. Dynamische Komponenten entsprechen in diesem Kontext Plugins. Aufwendiges Neukompilieren soll reduziert und somit zu einer einfacheren Pflege beitragen werden. Für den Entwurf eines solchen Frameworks muss festgelegt werden, welche der vorhandenen Programm-Module als Plugins realisierbar sind. Es muss definiert werden, wie „das System das Plugin findet und welche Sicht es auf das Plugin hat“ [1]. Darüber hinaus muss festgelegt werden, welche Funktionalität das System dem Plugin zu Verfügung stellt und wie die Abläufe zur Steuerung und Entfernung solcher Komponenten auszusehen haben.

Material und Methoden

Der Weg zu einem dreidimensionalen Patientenmodell mit segmentierten anatomischen Strukturen gestaltet sich folgendermaßen (vgl. dazu Kapitel „Basics of 3D Imaging“ in [2]):

1.
Schnittbilder von verschiedenen bildgebenden Modalitäten werden importiert und geladen.
2.
Sie werden registriert, um multimodal Information ableiten zu können.
3.
Alle therapierelevanten Strukturen werden segmentiert und entsprechende VOIs (engl.: volumes of interest) definiert.

Für die Registrierung von Bilddaten und die Segmentierung von Strukturen stehen mehrere semi-automatische Verfahren zur Verfügung. Desweiteren existieren Verfahren zur funktionellen Bildanalyse, mit denen z.B. Stoffwechselvorgänge visualisiert und untersucht werden können. Der Umstand, dass sich diese Funktionalität nur in der konkreten Implementierung, nicht aber in ihrem Zweck unterscheidet, prädestiniert sie zur Kapselung in wiederverwendbaren Plugin-Klassen.

Die Entwicklung und Anwendung von VIRTUOS findet plattformübergreifend unter Microsoft Windows und Linux statt. Dies erfordert zusätzlich die Portierbarkeit von Programmcode, die im Rahmen dieser Arbeit erstellt wird. Das dynamische Laden von Programm-Code wird unter Microsoft Windows durch sog. „Dynamic Linked Libraries“ (DLLs) und unter Linux durch „Shared Objects“ ermöglicht. Unter Verwendung der jeweils ähnlichen Betriebssystem-API, können Ressourcen aus diesen Bibliotheken zur Laufzeit zugänglich gemacht werden. Da beim dynamischen Linken allerdings keine Typüberprüfung stattfindet, müssen gegebene Schnittstellen eingehalten werden.

Das Design eines objektorientierten Frameworks kann durch den Einsatz von Entwurfsmustern unterstützt werden. Schmidt et al. [3] präsentiert hier die zwei Muster Component Configurator und Extension Interface, die bei der Konzeptionierung einer Plugin-Architektur hilfreich sind.

Ergebnisse

Abstrakte Basisklassen und Schnittstellen-Definitionen für Plugins und Hostanwendung bilden einen „Vertrag“ zwischen den Akteuren. Als Steuerungsmodul wurde ein Plugin-Manager entworfen und implementiert. Aufbauend auf diesem Konzept wurde die Schnittstellen für vier Plugins deklariert und die Funktionalität adaptiert:

  • BioImageAnalysis: Ein Plugin dieses Typs erhält eine 4D-Bildserie und gibt eine oder mehrere Parameterkarten zurück, die die Analyseergebnisse in visueller Form darstellen.
  • Filter: Kapseln Filteralgorithmen zum Aufbereiten von Bilddaten.
  • Registration: Plugins von diesem Typ werden dazu verwendet Bilder multimodal zu überlagern.
  • Segmentation: Komponenten dieses Typs erstellen, durch Benutzerinteraktion gesteuert, VOIs in den Bilddaten. Intern werden VOIs als ein Stapel von Polygonen repräsentiert.

Um Fehlern vorzubeugen, unterliegt die Schnittstellenbeschreibung einer Versionierung. Hierzu wird jedem Interface eine eigene, ganzzahlige Versionsnummer zugeordnet. Sie wird inkrementiert, sobald sich die Deklaration des Interfaces ändert. Damit Plugins Objekte aus dem Hauptprogramm nutzen können, muss es zuvor die ihm bekannte Version des jeweiligen Interfaces übergeben. Verwendet die Anwendung eine aktuellere Version dieses Interfaces, wird der Vorgang unterbunden und die Funktionalität wird nicht zur Verfügung gestellt.

Das Sequenzdiagramm in Abbildung 1 [Abb. 1] zeigt das Einbinden und Ausführen eines Filter-Plugins. Wählt der Benutzer im Hauptprogramm das Filtermenü, so wird der PluginManager veranlasst alle Bibliotheken aus einem speziellen Verzeichnis zu laden.

Jede geladene DLL erhält in der init-Funktion eine Referenz auf den PluginManager und kann nun beliebig viele Plugins anmelden. Dazu muss sie den Interface-Typ, die Version und den Namen des Plugins angeben. Möchte das Hauptprogramm das Plugin verwenden, so kann es dazu den PluginManager befragen. Dafür muss wiederum der Name, der Interface-Typ und zugehörige Version übergeben werden. Sind die Versionsnummern unterschiedlich meldet der PluginManager einen Fehler.

Diskussion

Die bestehende Arbeit demonstriert, wie Teile der Funktionalität eines bestehenden Softwaresystems in dynamische Komponenten transferiert werden können. Hierzu wurden Schnittstellen geschaffen und vier Typen von Plugins identifiziert. Die Funktionstüchtigkeit wurde durch die exemplarische Erstellung jeweils eines Plugins einer Klasse untermauert. Das vorgestellte Versionierungskonzept bedarf sorgfältiger Pflege, macht das gesamte System aber flexibel und skalierbar. Ob sich durch zusätzliche Funktionsaufrufe wesentliche Performanceeinbuße ergeben, kann subjektiv mit nein beantwortet werden. Es wird darauf hingewiesen, dass die erstellten Plugins auf die Datenmodelle von VIRTUOS angewiesen sind. Sollen diese in einem anderen bildverarbeitenden Anwendungssystem zum Einsatz kommen, so müsste diese Anwendung ihre Datenmodelle entsprechend adaptieren.


Literatur

1.
Eilebrecht, Karl & Starke, Gernot (2007) Patterns kompakt. Entwurfsmuster für effektive Software-Entwicklung. Spektrum Akad. Verl., München
2.
Schlegel, Wolfgang and Adler, John R., eds. (2006) New technologies in radiation oncology. With 39 tables. Springer, Berlin
3.
Schmidt, Douglas C., Stal, Michael, Rohnert, Hans & Buschmann, Frank (2007) Patterns for concurrent and networked objects. Wiley, Chichester