-
Die Erfindung bezieht sich auf ein Verfahren zur Steuerung einer Benutzeroberfläche einer (Software-)Applikation, die in einer Laufzeitumgebung ausgeführt wird. Die Erfindung bezieht sich weiterhin auf ein (Hard- und/oder Software-)System zur Durchführung des Verfahrens.
-
Moderne Softwareapplikationen (d. h. Anwendungsprogramme), insbesondere Softwareapplikationen für die medizinische Bildgebung, haben häufig eine komplexe Benutzeroberfläche (auch: User Interface, oder kurz: UI), die aus einer Vielzahl von einzelnen (UI-)Elementen zusammengesetzt ist. Bei diesen Elementen handelt es sich in an sich üblicher Technik zum Beispiel um alphanumerische Eingabefelder, Anzeigefelder für Text oder Bilder, oder graphische Nachbildungen von Tasten (Buttons), Ankreuzfeldern (Check Boxes), Schiebereglern (Sliders), Drehknöpfen (Knobs), etc. Ein UI-Element kann seinerseits aus einer Kombination mehrerer untergeordneter UI-Elemente bestehen. Als „atomar” sind im Gegensatz hierzu solche UI-Elemente bezeichnet, die ohne Funktionsverlust nicht noch weiter in Untereinheiten aufgeteilt werden können, z. B. ein einzelner Schieberegler.
-
In der Regel können aufgrund der Vielzahl der in der Benutzeroberfläche enthaltenen Elemente nicht alle gleichzeitig in übersichtlicher Form auf einem Bildschirm angezeigt werden. Die Benutzeroberfläche einer medizintechnischen Softwareapplikation weist daher üblicherweise mehrere Schichten auf, von denen stets nur eine vollständig angezeigt wird, und zwischen denen nach Art von Registerkarten „geblättert” werden kann. Zusätzlich oder alternativ erstreckt sich die Benutzeroberfläche einer medizinischen Softwareapplikation oft über mehrere Bildschirme.
-
Bei einer solchen komplexen Benutzeroberfläche stehen Flexibilität und Performance im Vordergrund. Wünschenswert ist insbesondere eine Steuerung der Benutzeroberfläche, die es ermöglicht, einzelne UI-Elemente nicht bereits beim Start der Softwareapplikation zu erzeugen, sondern erst später zur Laufzeit der Applikation. Dies ist insbesondere zweckmäßig für UI-Elemente,
- a. die einer Lizensierung unterliegen, die also beispielsweise mit Funktionen der Applikation verknüpft sind, die nur bei einem bestimmten Lizenzlevel zur Verfügung stehen,
- b. die aus Gründen der Performance nicht zum Start der Applikation erzeugt werden sollen, da sie zum Beispiel nur selten benutzt werden,
- c. die sich erst zur Laufzeit der Applikation aufgrund der Interaktion mit dem Benutzer als notwendig erweisen (z. B. Felder für Such- und Sortierkriterien), oder
- d. die Versionierungsaspekten unterliegen, die Z. B. also nur bei bestimmten Versionen der Applikation, einzelner Applikationsteile oder weiterer damit zusammenhängender Programme oder Dateien zur Verfügung stehen sollen, oder die bei verschiedenen Versionen der Applikation einzelner Applikationsteile oder damit zusammenhängender weiterer Programme oder Dateien unterschiedlich aussehen und/oder unterschiedlich funktionieren sollen.
-
Als „Steuerung” der Benutzeroberfläche werden dabei computer-technische Anweisungen verstanden, durch die UI-Elemente erzeugt, zerstört oder in ihren Eigenschaften, insbesondere dem graphischen Erscheinungsbild, der Funktion und/oder der Anordnung auf der Benutzeroberfläche, beeinflusst werden.
-
Um Benutzeroberflächen flexibel, insbesondere applikations-spezifisch, gestalten zu können, werden die UI-Elemente herkömmlicherweise oft programmatisch, d. h. durch den Programmcode der Softwareapplikation selbst erzeugt. Dieser programmatische Ansatz ist aber in Hinblick auf Versionierungsaspekte problematisch. Hierbei muss die Applikation nämlich üblicherweise über einen statischen Link mit einer Controls-Library verknüpft werden. Ändert sich die Controls-Library zu einem späteren Zeitpunkt, kann es nachteiligerweise erforderlich sein, alle Applikationen, die diese Library benützen, umzuschreiben.
-
Nach einer anderen Methode werden beim Start der Applikation auch die nicht oder nicht sofort benötigten UI-Elemente verdeckt mit erzeugt. Diese UI-Elemente sind also beim Start der Applikation zwar vorhanden, aber noch nicht sichtbar, und werden erst zu einem späteren Zeitpunkt von der Applikation auf der Benutzeroberfläche einblendet. Dieser Ansatz trägt allerdings nicht wesentlich zur Reduzierung der Rechenleistung beim Start der Applikation bei und ist daher unter dem Aspekt der Performanceoptimierung kritisch.
-
In
DE 10 2007 052 813 B3 wird wiederum alternativ vorgeschlagen, nach dem Start der ursprünglichen Applikation eine mit dieser logisch verknüpfte Sub-Applikation zu starten, und der Applikation sowie der Sub-Applikation jeweils eigene Anzeigebereiche, insbesondere verschiedene Bildschirme zuzuweisen. Verschiedene Gruppen von UI-Elementen werden hier also jeweils durch eine eigene Sub-Applikation erzeugt, wodurch diese Gruppen auch zur Laufzeit der ursprünglichen Applikation erzeugt werden können. Diese Vorgehensweise ist somit mit den oben aufgezählten Szenarien vereinbar. Ihre Umsetzung erfordert aber einen vergleichsweise großen Aufwand, insbesondere für den Applikationsentwickler.
-
Der Erfindung liegt die Aufgabe zugrunde, ein vergleichsweise einfach zu realisierendes Verfahren anzugeben, das eine flexible Steuerung einer Benutzeroberfläche einer Softwareapplikation ermöglicht, insbesondere die Erzeugung von flexibel konfigurierbaren Elementen der Benutzeroberfläche nach dem Start (d. h. zur Laufzeit) der Applikation. Der Erfindung liegt weiterhin die Aufgabe zugrunde, ein zur automatischen Durchführung des Verfahrens besonders geeignetes (Hard- und/oder Software-)System zu realisieren.
-
Bezüglich des Verfahrens wird die Aufgabe erfindungsgemäß gelöst durch die Merkmale des Anspruchs 1. Bezüglich des Systems wird die obige Aufgabe erfindungsgemäß gelöst durch die Merkmale des Anspruchs 6. Vorteilhafte Ausgestaltungen und Weiterentwicklungen der Erfindung sind in den Unteransprüchen und der nachfolgenden Beschreibung dargelegt.
-
Das erfindungsgemäße System umfasst eine Laufzeitumgebung, in der die Softwareapplikation ausführbar ist, sowie ein (nachfolgend kurz als „Part-Factory” bezeichnetes) Elementerzeugungsmodul zur Erzeugung sowie optional auch zur Zerstörung mindestens eines Elements der Benutzeroberfläche (UI-Element).
-
Bei der Laufzeitumgebung handelt es sich um sogenannte Middleware, also Software, die dem Betriebssystem und der eigentlichen Applikation zwischengeschaltet ist. Konkret ist die Laufzeitumgebung eine Software, die gemeinsam mit einer Softwareapplikation, die nicht direkt mit dem Betriebssystem kommunizieren kann, ausgeführt wird und die Applikation auf dem jeweiligen Computer lauffähig, also ausführbar macht, indem es zwischen der Applikation und Betriebssystem vermittelt.
-
Bei der Part-Factory handelt es sich um eine von der Applikation separate Software, die bevorzugt in derselben Laufzeitumgebung abläuft wie die Softwareapplikation. Die Part-Factory ist dabei vorzugsweise applikationsübergreifend als Teil eines Frameworks implementiert, das auch die Laufzeitumgebung enthält. Bei dem „Framework” handelt es sich um ein Softwaregerüst oder einen Softwarerahmen, der selbst keine Applikation darstellt, sondern der einer darauf aufsetzenden Applikation vorgefertigte Funktionen oder Komponenten zur Verfügung stellt. Bei dem Framework, in dessen Rahmen die Part-Factory implementiert ist, handelt es sich bevorzugt um ein sogenanntes domain-spezifisches Framework, das spezialisierte Funktionalitäten für den Bereich der medizinischen Bildgebung zur Verfügung stellt.
-
Erfindungsgemäß ist vorgesehen, mindestens für ein (insbesondere atomares) Element der Benutzeroberfläche eine Spezifikation zu hinterlegen, die die Art und Eigenschaften dieses Elements bestimmt. Die Spezifikation kann im Rahmen der Applikation selbst hinterlegt sein. Bevorzugt ist sie aber in einer der Applikation zugeordneten Konfigurationsdatei hinterlegt. Als Information zu der „Art” des UI-Elements ist im Rahmen der Spezifikation beispielsweise eine der Elementarten „Texteingabefeld”, „Textanzeigefeld”, „Graphikanzeigefeld”, „Taste”, „Umschalter”, „Schieberegler” und „Drehknopf” angebbar. Als „Eigenschaften” können im Rahmen der Spezifikation beispielsweise die Größe, graphische Erscheinungsform, Farbgestaltung und das Verhalten des jeweiligen Elementtyps bestimmt werden. Das „Verhalten” ist dabei beispielsweise durch Angaben zum Schaltverhalten, Ausgabe- oder Randwerte und/oder Rasterung bestimmbar. So kann zum „Schaltverhalten” eines Elements vom Typ „Taste” beispielsweise bestimmt werden, ob die Taste als „Toggle” (d. h. bistabiler Druckknopf) oder monostabiler Impulsgeber wirken soll. Die im Rahmen der Spezifikation angebbaren Angaben zu Art und Eigenschaften der zu konfigurierenden UI-Elemente können im Rahmen der Erfindung aber grundsätzlich frei gewählt werden. Die Spezifikation kann insbesondere eine beliebige Unterkombination aus den vorstehend genannten Angaben und/oder weitere Angaben enthalten. Desweiteren können herkömmliche Möglichkeiten zur flexiblen Konfiguration von UI-Elementen, wie sie an sich z. B. aus
DE 10 2005 041 629 A1 bekannt sind, in vollem Umfang auch bei den erfindungsgemäßen Spezifikationen genutzt werden.
-
Erfindungsgemäß wird das Element durch die Part-Factory nach Maßgabe der zugehörigen Spezifikation nach dem Start der Applikation, also zur Laufzeit der Applikation erzeugt.
-
Die Spezifikation spezifiziert in bevorzugter Ausgestaltung „Element-Typen”, d. h. Modelle oder Vorlagen für UI-Elemente, die durch die Part-Factory jeweils mehrfach instanziiert werden kann. Die Part-Factory kann in diesem Fall also z. B. jeden dem Typ nach spezifizierten Taster, Schieberegler, etc. in mehrfacher Instanz (d. h. Verkörperung) auf der Benutzeroberfläche erzeugen. In alternativer Ausführung der Erfindung kann aber auch vorgesehen sein, dass jedes in der Spezifikation beschriebene UI-Element durch die Part-Factory nur einmal auf der Benutzeroberfläche erzeugt werden kann.
-
Durch die von der eigentlichen Applikation separierte Part-Factory wird vorteilhafterweise ermöglicht, UI-Elemente völlig unabhängig von dem Start der Applikation zu beliebig vorgebbaren Zeitpunkten während der Laufzeit der Applikation erzeugen und gegebenenfalls zu zerstören, ohne dass der Applikationsentwickler die eigentliche Erzeugungslogik selbst erstellen müsste. Durch die wiederum von der Part-Factory unabhängige Spezifikation kann der Applikationsentwickler dabei aber dennoch Art und Eigenschaften der UI-Elemente weitgehend frei gestalten. Die Kombination der von der Applikation separierten Part-Factory, die die Erzeugungslogik für die UI-Elemente enthält, mit einem applikationsspezifischen Konfigurationsabschnitt, der die Spezifikation dieser Elemente enthält, ermöglicht somit eine hoch flexible, gleichzeitig aber – insbesondere für den Applikationsentwickler – leicht realisierbare und handhabbare Steuerung der Benutzeroberfläche.
-
In einer bevorzugten Weiterentwicklung der Erfindung ist vorgesehen, zu mindestens einem (insbesondere atomaren) Element der Benutzeroberfläche zusätzlich zu der Spezifikation eine Verteilungsanweisung zu hinterlegen, die die Anordnung des Elements oder einer Instanz desselben auf der Benutzeroberfläche und/oder die Zuordnung des Elements bzw. der Instanz zu einer bestimmten Struktur der Benutzeroberfläche bestimmt. Bei der „Struktur” der Benutzeroberfläche handelt es sich insbesondere um einen Rahmen, ein Fenster oder eine Schicht (Registerkarte) der Benutzeroberfläche. In einer bevorzugten Ausführung der Erfindung, bei der die Benutzeroberfläche auf mehrere Bildschirme verteilt ist, wird als Struktur bevorzugt ein bestimmter Bildschirm, genauer eine einem bestimmten Bildschirm zugeordnete Teilfläche der Benutzeroberfläche zugewiesen. Die Verteilungsanweisung kann – ebenso wie die Spezifikation – wahlweise im Rahmen der Applikation oder in einer dieser zugeordneten Konfigurationsdatei angeordnet sein. In letzterem Fall können die Spezifikation und die Verfahrensanweisung wahlweise in derselben Konfigurationsdatei oder in verschiedenen Konfigurationsdateien niedergelegt sein.
-
Die Erzeugung und/oder Zerstörung eines jeden UI-Elements nimmt die Part-Factory in bevorzugter Ausführung der Erfindung auf entsprechenden Aufruf bzw. entsprechende Anweisung durch die Applikation vor. Die Part-Factory, in bevorzugter Ausbildung konkret eine Laufzeitkomponente derselben, die die eigentliche Logik zur Erzeugung (Instantiierung) und Zerstörung des UI-Elements umfasst, weist hierzu eine definierte Schnittstelle auf, über die die Applikation auf die Part-Factory bzw. deren Laufzeitkomponente zugreift.
-
Die Part-Factory umfasst in bevorzugter Ausbildung weiterhin ein Parsing-Modul, das die hinterlegte Spezifikation und – falls vorhanden – die Verteilungsanweisung einliest.
-
Im engeren Sinne besteht das vorstehend beschriebene System aus einer Software, die die vorstehend beschriebene Funktionalität aufweist. So handelt es sich insbesondere bei der Laufzeitumgebung und der Part-Factory um Software-Komponenten. In einem weiteren Sinne wird aber auch eine Rechneranlage, also eine Computerhardware, auf der diese Komponenten im betriebsfähigen Zustand notwendigerweise implementiert sind, als Teil des Systems betrachtet. Das System umfasst in dieser weiteren Definition Hardware- und Softwarekomponenten.
-
Nachfolgend wird ein Ausführungsbeispiel der Erfindung anhand einer Zeichnung näher erläutert. Darin zeigt die einzige Figur in einem schematisch grob vereinfachten Blockschaltbild ein System zur Steuerung der Benutzeroberfläche einer medizinischen Softwareapplikation.
-
Das System umfasst im weiteren Sinn eine Rechneranlage 1, an die zwei Bildschirme 2 und 3 und (nicht näher dargestellte) Eingabegeräte wie z. B. eine Tastatur, eine Computermaus etc. angeschlossen sind. Bei der Rechneranlage 1 kann es sich um einen einzelnen Computer handeln. Bevorzugt besteht die Rechneranlage aber (in nicht näher dargestellter Weise) aus mehreren in einer Client-Server-Struktur datenübertragungstechnisch vernetzten Computern.
-
Im engeren Sinn wird das System im Wesentlichen durch ein in der Rechneranlage 1 implementiertes Framework 4 gebildet, das unter anderem eine Laufzeitumgebung 5 sowie ein in der Laufzeitumgebung 5 ausführbares Elementerzeugungsmodul (nachfolgend als Part-Factory 6 bezeichnet) umfasst. Bei dem Framework 4 handelt es sich insbesondere um ein domain-spezifisches Framework für den Bereich der medizinischen Bildgebung. Die domain-spezifischen Anteile des Frameworks 4 können ihrerseits aber auf einem sogenannten generischen, also von einem bestimmten Anwendungsbereich unabhängigen Framework, beispielsweise dem .NET-Framework der Fa. Microsoft aufbauen. In letzterem Fall handelt es sich bei der Laufzeitumgebung 5 insbesondere um die Common Language Runtime des .NET-Frameworks. Das Framework 4 baut seinerseits auf einem Betriebssystem 7 der Rechneranlage 1 auf.
-
In der Figur ist beispielhaft weiterhin eine (Software-)Applikation 8 dargestellt, die bestimmungsgemäß in dem Framework 4 und der zugeordneten Laufzeitumgebung 5 abläuft. Die Applikation 8 umfasst unter anderem eine Benutzeroberfläche 9. Im dargestellten Beispiel umfasst die Benutzeroberfläche 9 zwei Teilflächen 10 und 11, wobei die Teilfläche 10 auf dem Bildschirm 2, und die Teilfläche 11 auf dem Bildschirm 3 angezeigt wird.
-
Der Applikation 8 sind zwei Konfigurationsdateien 12 und 13 zugeordnet, die in einem (nicht näher dargestellten) Speicher der Rechneranlage 1 hinterlegt sind. Die Konfigurationsdatei 12 umfasst eine Anzahl von Spezifikationen S für atomare Elemente 14 der Benutzeroberfläche 9, die die Art und Eigenschaften der Elemente 14 auf die eingangs beschriebene Weise festlegen. Beispielsweise enthält die Konfigurationsdatei 12 u. a. eine Spezifikation S eines Elements 14 der Art „Schieberegler”. Im Rahmen der Spezifikation S werden zu diesem Element 14 z. B. folgende Eigenschaften festlegt: - Verweis auf eine Graphikdatei, die das optische Erscheinungsbild des Schiebereglers inklusive der Farbgestaltung definiert,
- – Größe, z. B. 120 × 45 Pixel oder Skalierungsfaktor,
- – Randwerte, z. B. –5 und +5, und
- – Rasterung, z. B. 0,1.
-
In der Konfigurationsdatei 13 ist zu jedem in der Konfigurationsdatei 12 spezifiziertem Element 14 eine zugehörige Verteilungsanweisung V hinterlegt, die die Anordnung des jeweiligen Elements 14 auf der Benutzeroberfläche 9, und insbesondere die Zuordnung des Elements 14 zu einer der Teilflächen 10 und 11 festlegt. Bezüglich des vorstehend beschriebenen Schiebereglers ist in der Konfigurationsdatei 13 beispielsweise die Verteilungsanweisung hinterlegt, den Schieberegler an einer bestimmten Position der Teilfläche 10 anzuordnen.
-
Die Konfigurationsdateien 12 und 13 werden in der Regel von dem Applikationsentwickler bei der Entwicklung der Applikation 8 mit erstellt und im Zuge der Installation der Applikation 8 im Speicher der Rechneranlage 1 hinterlegt. Die Konfigurationsdateien 12 und 13 stehen somit beim Start der Applikation 8 bereits zur Verfügung.
-
Die Part-Factory 6 dient dazu, die Elemente 14 auf der Benutzeroberfläche 9 zur Laufzeit der Applikation 8 zu erzeugen und zu zerstören. Sie umfasst hierzu eine Laufzeitkomponente 15 und ein Parsing-Modul 16.
-
Beim Start der Applikation 8 wird durch die Applikation 8 die Benutzeroberfläche 9 zunächst in einem initialen Zustand aufgebaut. In diesem initialen Zustand umfasst die Benutzeroberfläche 9 nur eine Untermenge ihrer insgesamt zur Verfügung stehenden UI-Elemente. Insbesondere werden die von der Part-Factory 6 gesteuerten Elemente 14 nicht sofort erzeugt und angezeigt.
-
Korrespondierend zu der Benutzeroberfläche 9 wird durch das Framework 4 ein Objektmodell 17 erzeugt, das den den UI-Elementen zugeordneten Code enthält. Das Objektmodell 17 enthält konkret zu jedem in der Benutzeroberfläche 9 enthaltenen UI-Element Anweisungen, die die Folge einer Betätigung des jeweiligen UI-Elements definieren, die also zum Beispiel ein bestimmtes Ausgabesignal erzeugen, wenn eine in der Benutzeroberfläche 9 als UI-Element enthaltene Taste betätigt wird. Das Objektmodell 17 enthält zudem Anweisungen, die die Zusammenwirkung verschiedener Elemente der Benutzeroberfläche 9 bestimmen, beispielsweise die Anweisung, eine bestimmte in der Benutzeroberfläche 9 als UI-Element enthaltene Leuchtanzeige zu illuminieren, wenn eine bestimmte, in der Benutzeroberfläche 9 als weiteres UI-Element enthaltene Taste betätigt wird.
-
Zum Aufbau des Objektmodells 17 greift das Framework 4 auf die in den Konfigurationsdateien 12 und 13 enthaltene Information zu den jeweiligen UI-Elementen zurück.
-
Wie die Benutzeroberfläche 9 wird auch das Objektmodell 17 beim Start der Applikation 8 zunächst in einem initialen Zustand erzeugt, in dem es nur Anweisungen zu den initial vorhandenen UI-Elementen der Benutzeroberfläche 9 enthält.
-
Wenn zur Laufzeit der Applikation 8 eines der nicht bereits beim Programmstart erzeugten Elemente 14 benötigt wird, greift die Applikation 8 über eine dafür vorgesehene Schnittstelle 18 der Laufzeitkomponente 15 auf letztere zu, worauf die Laufzeitkomponente 15 das Element 14 in der Benutzeroberfläche 9 der Applikation 8 erzeugt. Ebenso zerstört die Laufzeitkomponente 15 das Element 14 zur Laufzeit der Applikation 8 wieder, löscht es also aus der Benutzeroberfläche 9, sobald es über die Schnittstelle 18 eine entsprechende Anweisung von der Applikation 8 erhält.
-
Mit jeder Erzeugung oder Zerstörung eines Elements 14 zur Laufzeit der Applikation 8 wird auch das Objektmodell 17 durch die Part-Factory 6 in entsprechender Weise aktualisiert. Mit der Erzeugung eines jeden neuen Elements 14 in der Benutzeroberfläche 9 ergänzt insbesondere die Part-Factory 6 das Objektmodell 17 um die diesem Element 14 zugeordneten Anweisungen. Zur Erzeugung dieser Anweisungen liest die Part-Factory 6 mittels des Parsing-Moduls 16 dabei die zugehörige Information aus den Konfigurationsdateien 12 und 13 ein. Entsprechend löscht die Part-Factory auch mit der Zerstörung eines jeden Elements 14 die jeweils zugehörigen Anweisungen aus dem Objektmodell 17.
-
Bezugszeichenliste
-
- 1
- Rechneranlage
- 2
- Bildschirm
- 3
- Bildschirm
- 4
- Framework
- 5
- Laufzeitumgebung
- 6
- Part-Factory
- 7
- Betriebssystem
- 8
- (Software-)Applikation
- 9
- Benutzeroberfläche
- 10
- Teilfläche
- 11
- Teilfläche
- 12
- Konfigurationsdatei
- 13
- Konfigurationsdatei
- 14
- Element
- 15
- Laufzeitkomponente
- 16
- Parsing-Modul
- 17
- Objektmodell
- 18
- Schnittstelle
- S
- Spezifikation
- V
- Verteilungsanweisung
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- DE 102007052813 B3 [0008]
- DE 102005041629 A1 [0014]
