Der
derzeitige Stand der Softwaretechnik zeichnet sich dadurch aus,
dass im allgemeinen verschiedene Applikationen auf Basis bestehender
Software-Frameworks programmiert werden. Es bestehen ebenfalls Erweiterungsmöglichkeiten
für bestehende
Frameworks.
Ein
Paradigma bei der Erstellung von Programmen ist die so genannte
Komponenten-basierte Programmierung, bei der – ähnlich wie bei der objekt-orientierten
Programmierung – ein
Programm aus in sich geschlossenen Entitäten erstellt wird. Im Gegensatz
zur objekt-orientierten Programmierung werden jedoch die Komponenten
von Anbietern bereit gestellt und sind bereits kompilierte und damit
binär vorliegende
Programmelemente, von denen dem jeweiligen Programmierer lediglich
die Schnittstellendefinitionen zur Interaktion mit anderen Komponenten
bekannt sind. Erweiterungen von Frameworks sind in der Regel binär, insbesondere
bei Komponenten, so dass ein binäres,
nach den Regeln des erweiterten Frameworks geschaffenes Modul erzeugt
und angeschlossen werden muss, um das Framework insgesamt erweitern
zu können.
Ein
Programmsystem im Sinne der vorliegenden Beschreibung ist als ein
aus mehreren Programmelementen bestehendes Gesamtprogramm zu verstehen,
in dem die einzelnen Programmelemente, beispielsweise Komponenten
etc. miteinander durch Softwareschnittstellen verbunden sind, um
ihre Interaktion zu gestatten. Typischerweise besteht eine Applikation
aus einer Reihe solcher interagierenden Komponenten. Wenn die Komponenten
einer Applikation bzw. eines Programmsystems logisch miteinander
verbunden sind, ist es unmöglich,
die Verbindungen an die sich ändernden
Anforderungen für
das Programmsystem anzupassen, ohne den Quellcode des Programmsystems
zu ändern
und anschließend
neu kompilieren zu müssen.
Bei
Anforderungsänderungen
musste das Programmsystem im Quelltext angepasst und neu übersetzt werden,
was ohne Verfügung über den
Quellcode des Programmsystems bzw. der zu ändernden Komponenten unmöglich war.
Falls sich beispielsweise ein Darstellungsprogramm für visuelle
Elemente in einem bestimmten Format auch zur Darstellung visueller
Elemente in einem anderen Format eignet, so dass beispielsweise
eine NMR-Applikation
auch zur Anzeige von AX-Bildern geeignet ist, jedoch einer gewissen
Anpassung bedarf, um die anderen Darstellungsformate anzeigen zu
können,
war es bislang unmöglich,
das Programm zu verändern,
wenn der Quelltext nicht verfügbar
war, was in der Regel gegeben war. Damit musste eine vollständig neue
Anzeige für
die neuen visuellen Daten programmiert werden.
Bei
objekt-orientierten Systemen, bei denen die Verknüpfung der
Elemente (das sogenannte Linken) erst während der Laufzeit des Programmsystems
vorgenommen wird, ist es möglich,
Objekte noch beim Programmstart durch andere Objekte mit anderen,
beispielsweise erweiterten Fähigkeiten
zu ersetzen. Auf diese Weise lässt
sich das Verhalten einer Anwendung insoweit beeinflussen, als das
objekt-interne Verhalten einzelner Objekte betroffen ist. Auch bei
einem solchen Objektorientierten System mit einem Linken zur Programmstartzeit
(oder sogar erst während
des Programmlaufs) ist es jedoch nicht möglich, ohne Kenntnis des Quelltexts
die Interaktion zwischen verschiedenen Objekten zu ändern. Objekt-orientierte
und komponenten-orientierte Programmsysteme sind in aller Regel
Ereignis-getrieben. Dies bedeutet, dass die einzelnen Komponenten
oder Objekte eines Programmsystems bei Ablaufen des Programmsystems
sogenannte Ereignisse (Events) erzeugen können, die über einen oder mehrere Ereigniswarteschlangen
(event queues) an andere, durch die Programmierung vorgegebene Objekte
gesendet werden, wo die mit dem Ereignis verknüpften Daten gemäß der Art
des Ereignisses weiterverarbeitet werden. Das Weiterleiten der Ereignisse
wird im Rahmen der Applikationserstellung fest verknüpft, wie
oben beschrieben. Auch die Reaktion von Ereignishandhabern auf die
an sie geleiteten Ereignisse ist nicht beeinflussbar, da auch diese
mit den zur Verfügung
stehenden Programmierwerkzeugen erstellt und kompiliert werden.
Dies gilt wiederum insbesondere für die Rückreaktion der Ereignishandhaber,
die neue Ereignisse generieren und an andere Objekte bzw. Komponenten
eines Programmsystems weiterleiten.
Um
das Verhalten eines solchen Programmsystems tatsächlich ändern zu können, wäre es notwendig, die Verteilung
der Ereignisse, d.h. die Verbindung zwischen den einzelnen vorhandenen
Schnittstellen, sowie die Reaktion der Ereignishandhaber verändern zu
können.
Es
ist daher die Aufgabe der vorliegenden Erfindung, ein entsprechendes
System bereitzustellen, um auch ohne Kenntnis des Quellcodes der
verwendeten Komponenten eine Veränderung
der die Komponenten verwendenden Applikation bzw. des Programmsystems
zu gestatten.
Diese
Aufgabe wird erfindungsgemäß gelöst durch
die Bereitstellung eines Verfahrens zur Konfiguration des Programmsystems
gemäß dem unabhängigen Patentanspruchs
1, durch eine Systemanordnung zur Konfiguration eines Programmsystems
gemäß dem unabhängigen Patentanspruch
12 sowie durch eine Frameworksystemanordnung gemäß dem unabhängigen Patentanspruch 19.
Der
Erfindung liegt die Idee zugrunde, die tatsächliche Ausgestaltung der Ereignis-Handhaber
und gegebenenfalls die Ver knüpfung
von Komponenten mit den Ereignis-Handhabern einfach konfigurierbar
und nachträglich
anpassbar zu gestalten.
Daher
ist die Erfindung zunächst
auf ein Verfahren zum Konfigurieren eines Programmsystems gerichtet,
das die folgenden Schritte aufweist:
- – Initialisieren
von Binär-Programmkomponenten
des Programmsystems, die dazu bestimmt sind, Ereignisse zu erzeugen,
- – Initialisieren
eines Quellcode-Interpretierers, der zumindest einen Quellcode-Ereignishandhaber
interpretiert;
- – Herstellen
von logischen Verbindungen zwischen Schnittstellen der Binär-Programmkomponenten
und Schnittstellen des interpretierten Quellcode-Ereignishandhabers
zur Verarbeitung von Ereignissen durch zumindest einen Quellcode-Ereignishandhaber.
Hierbei
ist unter einem Programmsystem ein ausführbares Computerprogramm zu
verstehen, dass aus mehreren, isolierten und über Schnittstellen interagierenden
Komponenten besteht. Unter einer Laufzeitumgebung ist die Gesamtheit
des Programmcodes zu verstehen, der von einem Betriebssystem bereitgestellt wird,
um Programme einer bestimmten Machart ablaufen zu lassen. Sie umfasst
neben Systemfunktionsaufrufen (system calls) auch für eine bestimmte
Programmierumgebung spezifische Bibliotheken etc. und beinhaltet
grundsätzlich
alle Vorkehrungen, die notwendig sind, um das Programmsystem auf
der gewählten
Datenverarbeitungsanlage ablaufen zu lassen. Unter Binärprogrammkomponenten
sind solche komponenten-artigen Bestandteile eines Programms zu
verstehen, die bereits vor dem Starten des Programmes mittels eines Compilers
kompiliert, d.h. in eine binär
von dem verwendeten Prozessor ausführbare Form umgewandelt worden
sind. Hierzu zählen
klassische Komponenten und Objekte genauso wie neuartige Variationen
dieser Konstrukte.
Ein
Ereignis-Handhaber (Eventhandler) ist ein Programm oder Teilprogramm,
das der Bearbeitung eines von einer anderen Komponente gesendeten
Ereignisses und ggf. der Ausgabe eines Ergebnisses, z.B. eines Ergebnisereignisses
dient. Ein Quellcode-Interpretierer ist ein Programm, ein Programmteil
oder eine Programmkomponente, beispielsweise eine weitere Binärprogrammkomponente,
die in der Lage ist, einen Quellcode zu interpretieren, die im Quellcode
enthaltenen Anweisungen sukzessive abzuarbeiten und direkt in binär arbeitende
Befehle umzusetzen, wobei dieser Vorgang im Gegensatz zu Kompilation
schrittweise bei jeder Ausführung
des Quellcodeprogrammes durchgeführt
wird. Klassische Beispiele von interpretierten Programmen sind in
der Programmsprache "BASIC" geschriebene Programme
oder in Skriptsprachen geschriebene Skripte. Im Sinne der Erfindung
soll ein Quellcode-Interpretierer auch ein Programm sein, das in
der Lage ist, bei Aufruf einer Quellcode-Datei aus dieser in einem
Durchgang ein binäres
Programm zu erstellen, sofern bei dieser Programmerstellung bei
jedem Aufruf der Quellcode-Datei erneut vorgenommen wird und kein
Wert darauf gelegt wird, als Ergebnis der Interpretation ein in
der Laufzeitumgebung selbständig
ablauffähiges
Programm zu generieren.
Unter
einer Schnittstelle ist ein softwaretechnisches Konstrukt zu verstehen,
welches über
einen vordefinierten Mechanismus den Austausch von Informationen
zwischen zwei Komponenten, Objekten oder Programmen gestattet. Im
vorliegenden Fall sind die ausgetauschten Informationen Ereignisse,
wobei ein Ereignis zumindest aus einem Identifikator für die Art
des Ereignisses, ggf. Meta-Informationen sowie ggf. Daten, die mit
dem Ereignis zusammenhängen,
besteht. Ereignisse können
in Reaktion auf bestimmte Vorkommnisse erzeugt werden, die entweder
hardware-seitig (Tastaturtaste gedrückt, Maus geklickt, Füllung eines
Puffers der seriellen Schnittstelle etc.) oder innerhalb einer Komponente
(Abarbeitung einer Unterfunktion, Feststellen eines Grenzwerts innerhalb
eines Algorithmus, Fehlerbedingung etc.) auftreten können.
In
einer besonders bevorzugten Ausführungsform
der Erfindung umfasst das Verfahren ein Auswerten einer Konfigurationsdatei
durch eine in einer Laufzeitumgebung laufende Konfigurations-Binär-Programmkomponente,
wobei die Konfigurationsdatei Informationen über die Binar-Programmkomponenten,
den zumindest einen Quellcode-Ereignishandhaber und deren logische
Verbindungen zueinander enthält.
Eine
Konfigurationsdatei ist im Sinne der vorliegenden Erfindung eine
Datei, die in einer editierbaren, also im Klartext vorliegenden,
Art und Weise Informationen darüber
enthält,
welche Binärprogrammkomponenten
und Quellcode-Ereignishandhaber
das Programmsystem bilden und wie diese miteinander verbunden werden
sollen, um den Austausch von Ereignissen zu gestatten.
Durch
das erfindungsgemäße Verfahren
ist es nunmehr möglich,
weitgehend in die Funktionalität
eines Programmsystems einzugreifen, indem sowohl die Art und Weise,
in der Ereignisse vom Programmsystem behandelt, bedient, abgearbeitet
oder beantwortet wird, in einem leicht editierbaren Quelltextformat
im System enthalten ist, als auch optional die Interaktion der einzelnen
Komponenten des Programmsystems in einer leicht editierbaren Konfigurationsdatei
enthalten sind. Damit sind gerade die Aspekte eines Programmsystems, bei
denen praxisbezogene Änderungen
am häufigsten
vorkommen dürften,
einer einfachen Anpassung auch ohne Kenntnis eines Quellcodes der
einzelnen Programmkomponenten möglich.
Anders
ausgedrückt,
wird die gesamte logische Verschaltung der das Programmsystem bildenden Programmkomponenten
erst zur Laufzeit des Programms, vorzugsweise beim Programmstart,
konfiguriert und in der Laufzeitumgebung eingerichtet.
Vorzugsweise
erfolgt das Herstellen der logischen Verbindungen durch Konfigurieren
eines Ereignis-Verteilers, dessen Aufgabe darin besteht, Ereignisse
zentral zu empfangen und anhand einer Verteilungstabelle o.ä. an die
vorab zugewiesenen Ereignis-Handhaber weiterzuleiten. Der Ereignis-Verteiler
kann der üblicherweise
in der Laufzeitumgebung verwendete Verteiler oder ein spezieller,
in das Programmsystem eingebauter (beispielsweise durch eine weitere
Programmkomponente) Verteiler sein.
Die
erfindungsgemäß bereitgestellten
neuen Komponenten Konfigurations-Binär-Programmkomponente, Quellcode-Interpretierer
und Ereignis-Verteiler können
voneinander getrennte Komponenten sein oder können zumindest teilweise in
einer einzelnen Komponente zusammengefasst sein, welche beispielsweise dann
sowohl in der Lage ist, die Konfigurationsdatei zu lesen, als auch,
die Scripte auszuführen
und gegebenenfalls sogar, die Ereignisse weiterzuleiten. So ist
es vorstellbar, dass alle beteiligten Binärkomponenten ihre Ereignisse
automatisch an die erfindungsgemäße neue
Komponente weiterleiten, und diese eine Verteilung an die einzelnen
Ereignis-Handhaber vornimmt.
Die
Auswertung der Konfigurationsdatei zur Verknüpfung von Programmkomponenten
und Ereignishandhabern durch die Konfigurations-Binär-Programmkomponente
erfolgt vorzugsweise beim Starten des Programmsystems. In einer
alternativen Ausführungsform
erfolgt die Auswertung der Konfigurationsdatei durch die Konfigurations-Binär-Programmkomponente
in zeitlich vorgegebenen Abständen
während
der Ausführung
des Programmsystems. Während
die erste der beiden möglichen
Varianten zur Auswertung der Konfigurationsdatei die Leistung des
Programmsystems verbessert, da eine entsprechende Konfiguration
der Komponenten nur einmal durchgeführt werden muss, gestattet
die komplexere, aufwendigere und langsamere zweite Variante einen
Eingriff selbst in laufende Programmsysteme, beispielsweise bei
Anwendungen, die rund um die Uhr laufen müssen und nicht abgeschaltet
werden können.
Bei
bestimmten Ausführungsformen
der Erfindung ist der Quellcode-Interpretierer ebenfalls eine Binärprogrammkomponente,
die in derselben Laufzeitumgebung ablaufen kann, wie die Binärprogrammkomponenten.
Diese Maßnahme
dient der Integration des Gesamtsystems, da innerhalb einer Laufzeitumgebung
bereits Mechanismen zum Austauschen von Informationen zwischen Komponenten
existieren und damit nicht eigens für die vorliegende Erfindung
neu implementiert werden müssen.
Der Quellcode-Interpretierer kann ein handelsüblicher Interpretierer sein,
der mit entsprechenden Ergänzungen
so ummantelt ist, dass er autark in der Laufzeitumgebung und unter
Verbindungsaufnahme mit den anderen Programmkomponenten lauffähig ist. Zur
Implementierung der Quellcodeereignis-Handhaber können der
Laufzeitumgebung angepasste Sprachen verwendet werden. Es können vollwertige
Programmiersprachen verwendet werden, die interpretiert werden, wie
beispielsweise BASIC oder FORTH, bevorzugterweise allerdings leicht
zu programmierende, in modernen Laufzeitumgebungen in der Regel
enthaltene bzw. durch Dritte integrierte Script-Sprachen. Demzufolge
ist der Quellcode des Ereignis-Handhabers ein in einer Script-Sprache
geschriebenes Script. Mögliche
Scriptsprachen können
beispielsweise Javascript, Jscript.NET, VBScript, Perl, VBScript.NET,
Python, Ruby, Tcl, C# und dergleichen sein.
Die
Konfigurationsdatei ist vorzugsweise eine Klartextdatei mit einer
vorgegebenen, von der Konfigurations-Binärprogrammkomponente
auswertbaren Syntax. Auch hier bietet es sich an, auf bereits existierende Modelle
zurückzugreifen,
um den programmtechnischen Aufwand bei der Implementierung der vorliegenden Erfindung
zu minimieren. So kann es beispielsweise möglich sein, Dateibrowser zu
verwenden, die bereits auf dem Markt existieren, beispielsweise
Browser für
sogenannte Auszeichnungssprachen, wie SGML oder XML. Dementsprechend
ist die Konfigurationsdatei eine Datei, welche der XML-Syntax gehorchen
muss. Zur Implementierung der Erfindung kann ein Standard-XML-Browser
verwendet werden, dem wiederum eine Dokumententypdefinition oder
dergleichen an die Seite gestellt wird, welche die Interpretation
der XML-Daten der Konfigurationsdatei festlegt.
Die
Erfindung ist weiterhin auf ein System zur Erzeugung eines Programmsystems
gerichtet. Alles bezüglich
des erfindungsgemäßen Verfahrens
Gesagte gilt sinngemäß auch für das System
und umgekehrt, so dass wechselweise Bezug genommen wird.
Die
Erfindung ist daher auf ein System zur Erzeugung des Programmsystems
gerichtet, welches aufweist:
- – einen
Quellcodeinterpretierer zur Interpretation zumindest eines Quellcode-Ereignishandhabers;
- – eine
Laufzeitumgebung zum Initialisieren und Ausführen von Binär-Programmkomponenten
für das
Programmsystem; und zum Ausführen
des Quellcode-Interpretierers, und
- – eine
Vorrichtung zur Herstellung von logischen Verbindungen zwischen
Schnittstellen der Binär-Programmkomponenten
und Schnittstellen des interpretierten Quellcode-Ereignishandhabers zur Verarbeitung
von, von den Binär-Programmkomponenten
erzeugten, Ereignissen durch zumindest einen Quellcode-Ereignishandhaber.
Die
Begrifflichkeiten entsprechen den oben bereits erläuterten.
Das
erfindungsgemäße System
kann dadurch gekennzeichnet sein, dass die Verbindungsvorrichtung eine
Konfigarations-Binär-Programmkomponente
zur Auswertung einer Konfigurationsdatei aufweist, die Informationen über die
Binar-Programmkomponenten
des zu erzeugenden Programmsystems, über zumindest einen Quellcode-Ereignishandhaber
für das
Programmsystem und über
deren Verbindung zueinander enthält.
Wie
ersichtlich, wird bei dem erfindungsgemäßen System darauf Wert gelegt,
dass die verschiedenen Komponenten in einer ge meinsamen Laufzeitumgebung
lauffähig
sind. Auf diese Weise wird die Integration der einzelnen Bestandteile,
beispielsweise der Binärprogrammkomponenten,
des XML-Browsers und der Komponente mit dem Script-Interpretierer,
ermöglicht.
Wie zuvor erläutert,
ist der Quellcode-Interpretierer vorzugsweise eine Binär-Programmkomponente,
die in derselben Laufzeitumgebung abläuft wie die Binär-Programmkomponenten,
und der Quellcodeereignis-Handhaber ist vorzugsweise ein in einer
Scriptsprache, beispielsweise Javascript, Jscript.NET, VBScript,
Perl, VBScript.NET, Python, Ruby, Tcl oder C# etc. geschriebenen
Script.
Die
Konfigurationsdatei ist wiederum vorzugsweise eine Klartextdatei
mit einer vorgegebenen, von der Konfigurationsbinärprogrammkomponente
auswertbaren Syntax, beispielsweise einer XML-Syntax.
Schließlich ist
die Erfindung auf ein mittels der obigen Mechanismen erstelltes
Programmsystem gerichtet, welches aufweist:
- – eine Mehrzahl
von Binär-Programmkomponenten,
die während
der Ausführung
Ereignisse erzeugen können
und über
Schnittstellen nach außen
abgeben können;
- – zumindest
ein interpretierter Quellcode-Ereignishandhaber, der zur Bearbeitung
von, von zumindest einer der Binärprogrammkomponenten über logische
Verbindungspfade empfangenen, Ereignissen bestimmt ist,
wobei
der Quellcode-Ereignishandhaber zur Laufzeit oder/und zur Startzeit
des Programmsystems durch einen Quellcode-Interpretierer interpretiert wird, und
wobei die Binär-Programmkomponenten
und zumindest ein interpretierter Quellcode-Ereignishandhaber zur
Ausführung
in einer Laufzeitumgebung bestimmt sind.
Der
interpretierte Quellcode-Ereignishandhaber ist in einer bevorzugten
Ausführungsform
zur Abgabe von Ergebnissen der Reaktion auf empfangene Ereignisse
als Ergebnisereignisse an Binärprogrammkomponenten
bestimmt. Dies stellt einen Rückkanal
dar, der es gestattet, dass nicht nur Ereignisse an die entsprechenden
Ereignis-Handhaber gesendet werden, sondern dass umgekehrt auch
die Ereignis-Handhaber als Ergebnis ihrer Ereignisbearbeitung neue
Ereignisse oder andere Vorgänge
erzeugen können,
die wiederum an andere Binärprogrammkomponenten
gesandt werden können.
So ist es beispielsweise möglich,
zum Auftreten eines bestimmten Berechnungsereignisses vom Ereignis-Handhaber
eine Bearbeitung des Ereignisses durchführen zu lassen, die dann in
einer Anzeigenprogrammkomponente dargestellt werden soll, wozu das
Ereignis mit den Ergebnissen der Kalkulation an diese Anzeigenkomponente
geschickt wird.
Zum
Programmsystem kann weiterhin eine Konfigurations-Binär-Programmkomponente
gehören,
die zur Herstellung von logischen, gerichteten Verbindungspfaden
zwischen Schnittstellen der Binärprogrammkomponenten
und Schnittstellen der Ereignis-Handhaber
anhand der ausgewerteten Konfigurationsdatei bestimmt ist. Der Zweck
der Konfigurationsbinärprogrammkomponente
ist bereits oben erläutert
worden. Die Verbindungpfade zwischen den Schnittstellen sind als
programmtechnische bzw. logische Verbindungspfade aufzufassen und
nicht als physikalische. Sie sind gerichtet, weil der Informationsfluss
in eine bestimmte Richtung erfolgt, wobei es durchaus vorstellbar
ist, dass eine im System vorhandene Binär-Programmkomponente sowohl
Daten an einen Ereignis-Handhaber ausgibt als auch von diesem wiederum
bearbeitete Daten als Ergebnisereignis empfängt. Wie erläutert, wird üblicherweise
beim Start des Programmsystems die Konfigurationsdatei ausgewertet.
Damit muss die Konfigurations-Binär-Programmkomponente im strengen
Sinne kein Bestandteil des konfigurierten Programmsystems sein,
da sie für
die Ausführung
des Programmsystems zur Laufzeit nicht mehr notwendig wäre. Soll
jedoch auch während
des Programmlaufs ein Eingriff möglich
sein, muss die Konfigurations-Binär-Programmkomponente
zum Programmsystem gehören,
um in vorgegebenen Zeitabständen
dynamisch die Konfigurationsdatei neu auswerten und die Verbindungspfade
entsprechend neu an passen zu können.
Wie bereits bezüglich
des Verfahrens ausgeführt,
kann der Quellcode-Interpretierer in einer bevorzugten Ausführungsform
ebenfalls eine Binär-Programmkomponente
sein, die in derselben Laufzeitumgebung ablaufen kann wie die Binär-Programmkomponenten.
Der
Quellcodeereignis-Handhaber kann ein in einer Script-Sprache geschriebenes
Script sein, beispielsweise in Javascript, Jscript.NET, VBScript,
Perl, VBScript.NET, Python, Ruby, Tcl, C# usw. Die erfindungsgemäß eingesetzte
Konfigurationsdatei ist vorzugsweise eine Klartextdatei mit einer
vorgegebenen, in der Konfigurations-Binärprogrammkomponente auswertbaren
Syntax, beispielsweise einer XML-Syntax.
Durch
die Einführung
zumindest einer Komponente, die die Interaktionen anderer Komponenten
untereinander abkapselt, werden diese Interaktionen lokalisiert.
Zudem ist es möglich,
die Interaktionen in einer Scriptsprache zu spezifizieren. Durch
die Anpassung vom Scriptcode kann das Verhalten der Applikation
angepasst werden, ohne den Quellcode der ganzen Applikation verfügbar zu
haben. Außerdem
ist es möglich, die
Applikation durch die Konfiguration der Komponenten zu erweitern
und ihre Komponenten auszutauschen.
Mit
dem erfindungsgemäßen System
und Verfahren wird es möglich,
Applikationen (Programmsysteme) zu bauen, deren Business-Logik erweitert,
ausgetauscht und sogar adaptiert werden kann. Die Verdrahtung der
Komponenten einer Applikation kann durch den Einsatz eines Scripts
von außen
flexibel verändert werden.
Damit kann eine Applikation, beispielsweise eine Applikation auf
dem Gebiet der Medizintechnik, auf eine einfache Weise an die Gegebenheiten
ihres Einsatzes angepasst werden, ohne dass der Quellcode der Applikation
verändert
werden muss.
Das
vorstehend beschriebene, erfindungsgemäße Verfahren und die Systeme
können
insbesondere als Computerprogrammprodukt ausgebildet sein, mit einem
von einem Computer lesbaren Medium und einem Computerprogramm und
zugehörigen
Programmcodemitteln, wobei der Computer nach Daten des Computerprogramms,
also des Programmsystems, zur Durchführung des oben beschriebenen,
erfindungsgemäßen Verfahrens
veranlasst wird.
Eine
alternative Aufgabenlösung
sieht ein Speichermedium vor, das zur Speicherung des vorstehend beschriebenen,
computerimplementierten Verfahrens bzw. Systems bestimmt ist und
von einem Computer lesbar ist.
Weitere
vorteilhafte Ausgestaltungen, Aspekte und Details der vorliegenden
Erfindung ergeben sich aus den abhängigen Patentansprüchen, der
detaillierten Beschreibung und den beigefügten Zeichnungen.
