DE102007049958A1 - Verfahren und System zur Aktualisierung einer mehrschichtigen Applikation - Google Patents

Verfahren und System zur Aktualisierung einer mehrschichtigen Applikation Download PDF

Info

Publication number
DE102007049958A1
DE102007049958A1 DE102007049958A DE102007049958A DE102007049958A1 DE 102007049958 A1 DE102007049958 A1 DE 102007049958A1 DE 102007049958 A DE102007049958 A DE 102007049958A DE 102007049958 A DE102007049958 A DE 102007049958A DE 102007049958 A1 DE102007049958 A1 DE 102007049958A1
Authority
DE
Germany
Prior art keywords
modules
module
application
updated
existing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102007049958A
Other languages
English (en)
Inventor
Andreas Siwick
Hans-Martin von Dr. Stockhausen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to DE102007049958A priority Critical patent/DE102007049958A1/de
Priority to US12/285,922 priority patent/US20090106750A1/en
Publication of DE102007049958A1 publication Critical patent/DE102007049958A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates

Abstract

Ein Verfahren zur Aktualisierung einer Applikation in einem Datenverarbeitungssystem (1) umfasst folgende Schritte: - Bereitstellen einer mehrschichtig aufgebauten Applikation (A1, A2) in dem Datenverarbeitungssystem (1), wobei die Applikation (A1, A2) eine Mehrzahl an Modulen (M1, ...M5) aufweist, die jeweils einer von mehreren Hierarchieebenen (E1, E2, E3) zugeordnet sind, - Bereitstellen aktualisierter Module (M1', M2'), die jeweils zum Ersatz eines existierenden Moduls (M1, M2) vorgesehen sind, - automatische Kontriolle der existierenden Module (M1, M2) daraufhin, ob ein zugehöriges aktualisiertes Modul (M1', M2') bereitgestellt ist, - Erneuerung derjenigen Module (M1, M2), zu welchen aktualisierte Module (M1', M2') vorliegen, unter unveränderter Beibehaltung der übrigen Module (M3, M4, M5).

Description

  • Die Erfindung betrifft ein Verfahren sowie ein System zur Verwaltung mehrschichtiger Datenverarbeitungsprozesse, insbesondere in der Medizintechnik.
  • Aus der DE 103 51 351 A1 ist ein Verfahren und ein System zur dynamischen Generierung von Benutzerschnittstellen, so genannten User Interfaces, bekannt. Dieses Verfahren sieht vor, dass User Interfaces plattformunabhängig generiert werden sowie dynamisch geändert und remote konfiguriert werden können. Damit soll der Programmierungs- und Wartungsaufwand im Vergleich zu älteren Systemen gering gehalten werden.
  • Von Datenverarbeitungsprogrammen, beispielsweise in der Medizintechnik, wird häufig eine möglichst universelle Einsetzbarkeit gefordert, sowohl was die Hardware- als auch was die Softwarekonfiguration betrifft. Bei Anwendungen, die in einem Datenverarbeitungsnetzwerk zum Einsatz kommen, müssen je nach Architektur der Zielumgebung typischerweise bestimmte Anteile der Anwendung auf einen lokalen Rechner und andere Anteile auf entfernte Rechner geladen und installiert werden.
  • In einem Extremfall, der Vollinstallation, wird die komplette Anwendung auf den lokalen Rechner, den so genannten Anwendungsklienten, geladen und installiert. Im Fall einer mehrschichtigen Anwendung umfasst die zu installierende Software beispielsweise eine Darstellung-, eine Geschäfts- und eine Dienstleistungsschicht. Die Vollinstallation, welche einen Betrieb der gesamten Software auf dem Anwendungsklienten ermöglicht, setzt voraus, dass dieser über ausreichende Hardwareressourcen verfügt.
  • Im Unterschied zur Vollinstallation wird im Fall einer Teilinstallation lediglich eine Teilmenge der insgesamt für die Nutzung der Anwendung benötigten Schichten auf dem Anwendungsklienten installiert, während die übrigen Schichten auf entfernten Datenverarbeitungsgeräten, beispielweise so genannten Anwendungs- und Dienstleitungsservern, geladen und installiert werden. Im Vergleich zu einer Vollinstallation stellt eine Teilinstallation geringere Anforderungen an die Hardwareausstattung eines Anwendungsklienten.
  • Während bei einer Vollinstallation einer Anwendung im Fall einer Aktualisierung der Software lediglich der Anwendungsklient betroffen ist, müssen bei einer Teilinstallation unter Umständen Softwarekomponenten auf verschiedenen Rechnern in abgestimmter Weise aktualisiert werden.
  • Der Erfindung liegt die Aufgabe zugrunde, die Verwaltung mehrschichtiger Datenverarbeitungsprozesse, insbesondere in der Medizintechnik, hinsichtlich der Aktualisierbarkeit gegenüber dem Stand der Technik weiterzuentwickeln.
  • Diese Aufgabe wird erfindungsgemäß gelöst durch ein Verfahren mit den Merkmalen des Anspruchs 1 sowie durch ein Datenverarbeitungssystem mit den Merkmalen des Anspruchs 9. Im Folgenden im Zusammenhang mit dem Verfahren erläuterte Ausgestaltungen und Vorteile der Erfindung gelten sinngemäß auch für das Datenverarbeitungssystem und umgekehrt.
  • Das Verfahren geht aus von einer in einem Datenverarbeitungssystem, insbesondere in einer medizintechnischen Umgebung, bereitgestellten, mehrschichtig aufgebauten Applikation. Einzelne Schichten der Applikation sind beispielsweise eine Darstellung-, eine Geschäfts- und eine Dienstleistungsschicht. Ebenso kann es im Einzelfall praktikabel sein, Infrastruktur, Datenmanagement, und Bildverarbeitung verschiedenen Schichten zuzuordnen. Jeder Schicht der Applikation ist mindestens ein Modul zugeordnet. Insgesamt weist die Applikation damit mindestens zwei Module auf.
  • Um die Software, das heißt die Applikation, aktualisieren zu können, ohne sie komplett auszutauschen, werden aktualisierte Module bereitgestellt, die jeweils zum Ersatz eines existierenden Moduls vorgesehen sind. Im Rahmen des Verfahrens erfolgt eine automatische Kontrolle der existierenden Module daraufhin, ob ein zugehöriges aktualisiertes Modul bereitgestellt ist. Basierend auf dieser Information werden schließlich diejenigen Module erneuert, zu welchen aktualisierte Module vorliegen, wobei die übrigen Module unverändert bleiben oder lediglich insoweit modifiziert werden, als dies zur Zusammenwirkung mit den aktualisierten Modulen erforderlich ist.
  • Von der Aktualisierung können in einem einfachen Fall lediglich Module einer einzigen Schicht, auch als Hierarchieebene bezeichnet, betroffen sein. Bei minimalem Umfang der Aktualisierung wird nur ein einziges Modul einer bestimmten Schicht der Applikation ausgetauscht, während gegebenenfalls vorhandene weitere Module derselben Schicht sowie die allen übrigen Schichten zugeordneten Module nicht verändert werden. In komplexeren Fällen sind dagegen verschiedene aktualisierte Module unterschiedlichen Hierarchieebenen zugeordnet. Dies kann sowohl in Fällen zutreffen, in denen lediglich zwei Hierarchieebenen existieren und damit die Mindestzahl an Schichten vorhanden ist. Bevorzugt wird das Verfahren zur Aktualisierung jedoch bei Applikationen eingesetzt, die mehr als zwei Hierarchieebenen umfassen.
  • In vorteilhafter Ausgestaltung ist das Verfahren zur Aktualisierung einer Applikation geeignet, welche mindestens ein Modul aufweist, das direkt mit mehreren weiteren Modulen unterschiedlicher Hierarchieebenen verknüpft ist.
  • Gemäß einer bevorzugten Weiterbildung wird ein aktualisiertes Modul zusätzlich zu einem existierenden, weiterhin nutzbaren Modul installiert, wobei das aktualisierte Modul direkt mit einem ersten bestehenden Modul und das existierende Modul direkt mit einem zweiten bestehenden Modul verknüpft wird.
  • Durch die Aktualisierung erhöht sich damit die Anzahl der nutzbaren Module. Hierbei kann vorgesehen sein, das erste bestehende Modul im Zuge der Installation des aktualisierten Moduls automatisch zu modifizieren, um es innerhalb der geänderten Struktur der Applikation nutzbar zu machen, während das zweite bestehende Modul unverändert bleibt. Die verschiedenen bestehenden Module, welche im Zuge der Aktualisierung der Applikation nur zum Teil einer Modifikation bedürfen, können unterschiedlichen Hierarchieebenen angehören.
  • Unabhängig von der genauen Ausführungsform ist das erfindungsgemäße Verfahren mittels eines Computerprogrammprodukts ausführbar, wobei ein von einem Computer lesbares Medium den Computer zur Durchführung des Verfahrens veranlasst. Das Programm ist hierbei nicht notwendigerweise auf einem einzigen Medium gespeichert, sondern kann beispielsweise, in Funktionsblöcke unterteilt, in mehreren örtlich voneinander getrennten Speichern abgelegt sein.
  • Der Vorteil der Erfindung liegt insbesondere darin, dass ein äußert komfortabel handhabbarer Software Verwaltungsdienst bereitgestellt wird, der eine weitestgehend automatisierte Aktualisierung von Applikationen auf Anwendungsklienten ermöglicht. Hierbei kann eine Applikation, auch als Anwendung bezeichnet, aus logisch und physikalisch getrennten Bausteinen, so genannten Modulen, aufgebaut sein. Der Anwender, welcher das erfindungsgemäße Verfahren nutzt, braucht über keine Information zu verfügen, welche Module welcher Schichten der Applikation im Einzelfall zu aktualisieren sind. Vielmehr trägt die Anwendung selbst diese Information. In allen Fällen ist sichergestellt, dass die Aktualisierung nur die tatsächlich zu ändernden Module umfasst. Dies hat über den hohen Benutzungskomfort hinaus zur Folge, dass die Aktualisierung sehr zeitsparend durchgeführt wird. Die Interaktion des Benutzers bei der Aktualisierung beschränkt sich in der Regel auf eine simple Bestätigung. Gleichzeitig wird dem Benutzer die Möglichkeit gegeben, sich Detailinformationen über die Aktualisierung anzeigen zu lassen, so dass stets die gewünschte Transparenz gegeben ist.
  • Besonders vorteilhaft ist die für den Benutzer gegebene Möglichkeit, den Umfang der Aktualisierung selbst zu bestimmen. Beispielsweise kann durch den Benutzer festgelegt werden, dass lediglich ein Teil der Module der Applikation auf den neuesten Stand gebracht werden soll, während die übrigen Module in älteren Versionen Weiterbetrieben werden. In einer Gesamtbetrachtung bedeutet dies, dass verschiedene Module der Anwendung unterschiedliche Lebenszyklen aufweisen können, was angesichts der verschiedenen Funktionen der einzelnen Module sachgerecht sein kann und maßgeblich zu einer besonders rationellen Wartbarkeit der Applikation beiträgt.
  • Nachfolgend werden mehrere Varianten des erfindungsgemäßen Verfahrens sowie ein zur Durchführung des Verfahrens geeignetes Datenverarbeitungssystem anhand einer Zeichnung näher erläutert. Hierin zeigen:
  • 1 In symbolisierter Darstellung ein Datenverarbeitungssystem,
  • 2 die prinzipielle Struktur einer ersten innerhalb des Datenverarbeitungssystems nach 1 nutzbaren mehrschichtigen Applikation,
  • 3 in einer Darstellung analog 2 ein zweites Ausführungsbeispiel einer mehrschichtigen Applikation,
  • 4 eine erste Variante einer Aktualisierung der Applikation nach 2,
  • 5 eine zweite Variante einer Aktualisierung der Applikation nach 2, und
  • 6 in Diagrammform verschiedene Möglichkeiten von Aktualisierungen einer Applikation.
  • Ein in 1 in grober Schematisierung dargestelltes Datenverarbeitungssystem 1 umfasst ein Datenaufnahmesystem 2, welches mehrere Datenaufnahmeeinheiten 3 aufweist, sowie eine datentechnisch, insbesondere über ein Netzwerk, mit dem Datenaufnahmesystem 2 verbundene Datenverarbeitungseinheit 4. Bei den Datenaufnahmeeinheiten 3 kann es sich beispielsweise um so genannte Modalitäten in der Medizintechnik, insbesondere um bildgebende diagnostische Geräte wie Computertomographie- oder Magnetresonanzgeräte, handeln.
  • Die Datenverarbeitungseinheit 4, welche nicht notwendigerweise, wie in 1 vereinfacht dargestellt, in Form eines einzigen Rechners zur Verfügung steht, sondern beispielsweise auch als komplexeres, mehrere Einzelgeräte umfassendes Datenverarbeitungsnetzwerk realisiert sein kann, ist zur Durchführung einer Applikation ausgebildet, welche direkt oder indirekt mit dem Datenaufnahmesystem 2 gewonnene Daten, das heißt medizintechnische Daten, verarbeitet.
  • Die grundsätzliche Struktur eines ersten Ausführungsbeispiels einer Applikation ist in 2 veranschaulicht. Es handelt sich hierbei um eine auch als Anwendung bezeichnete Applikation A1, die mehrschichtig, mit drei Ebenen E1, E2, E3, in welchen sich Module M1, M2, M3, M4 befinden, sowie mit einer Anwendungsebene AE, aufgebaut ist. Insgesamt weist die Applikation damit vier Hierarchiestufen AE, E1, E2, E3 auf. Der Ebene E1 sind die Module M3 und M4 zugeordnet, während das Modul M2 der Ebene E2 und das Modul M1 der Ebene E3 zugeordnet ist. Das Modul M1 ist direkt mit verschiedenen Modulen unterschiedlicher Hierarchieebenen verknüpft, nämlich einerseits mit dem Modul M2 in Ebene E2 und andererseits mit dem Modul M4 in Ebene E1. Die der Ebene E1, welche direkt der Anwendungsebene AE unterlagert ist, zugeordneten Module M3, M4 werden als direkt benötigte Module bezeichnet, während die Module M1, M2, welche lediglich mittelbar mit der Anwendungsebene AE verknüpft sind, als indirekt benötigte Module bezeichnet werden.
  • Nach dem Stand der Technik würde eine isolierte Aktualisierung der indirekt benötigten Module M1, M2 voraussetzen, dass zunächst ein direkter Bezug zwischen diesen Modulen M1, M2 und der Anwendungsebene AE hergestellt wird. Dies bedeutet, dass zum Zweck der Aktualisierung die vierstufige modulare Anwendung A1 zunächst in eine zweistufige Anwendung umgewandelt werden müsste, welche lediglich die Anwendungsebene AE sowie eine einzige weitere Ebene, in der alle Module M1, M2, M3, M4 angeordnet sind, umfasst. Die Erfindung dient dazu, den damit verbundenen Aufwand zu vermeiden, wie untenstehend anhand der 4 und 5 noch näher erläutert wird.
  • Eine im Vergleich zum Ausführungsbeispiel nach 2 komplexere Applikation, welche ebenfalls für eine Aktualisierung nach dem erfindungsgemäßen Verfahren prädestiniert ist, ist in 3 dargestellt. In diesem Fall sind zwei Anwendungen A1, A2 in der Anwendungsebene AE hierarchisch gleichwertig nebeneinander gestellt. Die beiden Anwendungen A1, A2 greifen zumindest teilweise auf dieselben Module zu, nämlich auf die Module M3, M4, M5 in der Ebene E1, auf das Modul M2 in der Ebene E2, sowie auf das Modul M1 in der Ebene E3. Ähnlich wie im Ausführungsbeispiel nach 2 handelt es sich bei den Modulen M1, M2 um indirekt benötigte Module, während im vorliegenden Fall insgesamt drei direkt benötigte Module M3, M4, M5 existieren.
  • Sowohl im Ausführungsbeispiel nach 2 als auch im Ausführungsbeispiel nach 3 kann es sich bei allen Modulen M1, M2, M3, M4 (sowie ggf. M5) um zu verschiedenen Zeitpunkten fertig gestellte Softwareanwendungen handeln, so dass jede Applikation A1, A2 insgesamt als evolutionäres Softwaresystem zu bezeichnen ist, welches im Einzelfall wesentlich mehr als drei Ebenen E1, E2, E3 aufweisen kann. Beispielsweise sind Infrastruktur, Datenmanagement und Bildverarbeitung, das heißt die Verarbeitung von mittels der Datenaufnahmeeinheiten 3 aufgenommenen medizintechnischen Bilddaten, insbesondere Schichtaufnahmen, unterschiedlichen Hierarchieebenen E1, E2, E3 zugeordnet. Die verschiedenen Modulen M1, M2, M3, M4, M5 der Applikationen A1, A2 können nicht nur logisch, sondern auch physikalisch voneinander getrennt sein, beispielsweise auf verschiedenen Rechnern, etwa zum Teil auf Applikationsrechnern und zum Teil auf Anwendungs- oder Dienstleitungsservern, gespeichert sein.
  • Zur selektiven Aktualisierung einzelner Module M1, M2, M3, M4, M5 einer Anwendung A1, A2 stehen zwei unterschiedliche Varianten des erfindungsgemäßen Verfahrens, nämlich einerseits ein so genannter Patch sowie andererseits ein sogenanntes Upgrade, zur Verfügung, welche im Folgenden anhand 4 beziehungsweise anhand 5 erörtert werden. Hierbei zeigt sowohl in 4 als auch in 5 die linke Hälfte der jeweiligen Darstellung die Struktur der Anwendung vor der Aktualisierung, während in der rechten Hälfte der Darstellung die Struktur nach der Aktualisierung, das heißt nach dem Patch beziehungsweise nach dem Upgrade, visualisiert ist.
  • Im Fall des Patches (4) wird ein Modul, im vorliegenden Fall das Modul M1, aktualisiert, wobei die Auswirkungen der Aktualisierung auf das aktualisierte Modul beschränkt sind. Das das ursprüngliche Modul M1 ersetzende Modul ist als aktualisiertes Modul M1' bezeichnet. Ebenso wie die Module M2, M4 das ursprüngliche Modul M1 verwenden, wird auch das aktualisierte Modul M1' von den Modulen M2, M4 verwendet, ohne dass diese irgendeiner Änderung bedürfen.
  • Im Ausführungsbeispiel nach 5, welches ein Upgrade veranschaulicht, ist die Ausgangssituation mit der Ausgangssituation im Ausführungsbeispiel nach 4 identisch. Im Unterschied hierzu sind jedoch von der Aktualisierung mehrere Module betroffen:
    Zunächst wird das der Ebene E3, also der niedrigsten Hierarchieebene, zugeordnete Modul M1 aktualisiert, so dass als Ergebnis der Aktualisierung das aktualisierte Modul M1' nutzbar ist. Anders als im Ausführungsbeispiel nach 4 habe die primär das Modul M1 betreffende Aktualisierung jedoch Auswirkungen auf das der nächsthöheren Hierarchieebene E2 zugeordnete Modul M2, welches auf das Modul M1 zugreift. Somit ist die Notwendigkeit gegeben, auch das Modul M2 zu aktualisieren, nämlich durch ein aktualisiertes Modul M2' zu ersetzen. Diese Aktualisierung wird innerhalb des Upgrades in Form eines Patches durchgeführt, was sich darin ausdrückt, dass die der Ebene E1 zugeordneten Module M3, M4, welche auf das Modul M2 zugreifen, trotz dessen Aktualisierung nicht geändert werden zu brauchen.
  • Eine Besonderheit der Verfahrensvariante nach 5 liegt ferner darin, dass neben dem aktualisierten Modul M1' auch die ursprüngliche Version des entsprechenden Moduls, das heißt das Modul M1, aktiv bleibt. Wie aus 5 hervorgeht, greift nicht nur das Modul M2, sondern auch das Modul M4 direkt auf das Modul M1 zu. Was den direkten Zugriff des Moduls M4 betrifft, sei jedoch im Unterschied zum Zugriff des Moduls M2 keine Aktualisierung erwünscht. Vielmehr ist beabsichtigt, dass das Modul M4, soweit eine direkte Kopplung mit dem Modul M1 gegeben ist, seine Funktionen vor und nach der Aktualisierung in identischer Weise ausführt. Dies wird dadurch erreicht, dass das ursprüngliche Modul M1 hierarchisch gleichwertig neben dem aktualisierten Modul M1' beibehalten wird und eine weitere Verknüpfung erzeugt wird. Somit ist je nach Anforderungen eine Koexistenz verschiedener Softwarestände innerhalb eines komplexen Softwaresystems möglich, was insbesondere Vorteile hinsichtlich des Aufwands für die Wartung des Softwaresystems impliziert.
  • Die einfache Möglichkeit, Softwaremodule verschiedener Entwicklungsstände parallel im Rahmen eines komplexen Softwaresystems zu nutzen, wird im Folgenden anhand eines in 6 wiedergegebenen Diagramms erläutert.
  • Zunächst stehe eine Applikation A1 mit den Modulen M1, M2, M3 zur Verfügung. Zum Zeitpunkt t1 wird für jedes Modul M1, M2, M3 eine aktualisierte Version M1', M2', M3' angeboten. Der Wechsel zu einer neuen Entwicklungsstufe, das heißt einer aktualisierten Version M1', M2', M3' ist im unteren Teil von 6 durch eine Stufe in der entsprechenden Kurve symbolisch angedeutet. Eine weitere Aktualisierung führt zum Zeitpunkt t2 von den Versionen M1', M2', M3' zu den Modulen M1', M2'', M3''. Der untere Teil der Darstellung in 6 zeigt somit die sukzessive Aktualisierung der Anwendung A1 im jeweils größtmöglichen Umfang.
  • In der Praxis kann es zweckmäßig sein, vom größtmöglichen Aktualisierungsumfang im Einzelfall abzusehen und nur diejenigen Softwarekomponenten zu aktualisieren, bei denen eine solche Änderung einen Nutzen verspricht, der in einem günstigen Verhältnis zum Aufwand sowie zum Risiko der Aktualisierung steht. Ein derartiges Szenario ist im oberen Teil des in 6 wiedergegebenen Diagramms veranschaulicht. Das erste Modul M1 wird sowohl zum Zeitpunkt t1 als auch zum Zeitpunkt t2 aktualisiert und damit stets auf dem neuesten Stand gehalten. Beim zweiten Modul M2 wird dagegen lediglich die Aktualisierung zum Zeitpunkt t1 durchgeführt, während von der möglichen Aktualisierung zum Zeitpunkt t2 abgesehen wird. Die prinzipiell mögliche, jedoch nicht durchgeführte Aktualisierung ist durch eine gestrichelte Linie angedeutet. Analoges gilt für das dritte Modul M3, welches ohne jegliche Aktualisierung weiter verwendet wird. Ab dem Zeitpunkt t2 werden somit Module M1'', M2', M3 dreier verschiedener Entwicklungsstände parallel benutzt.
  • Im Folgenden sind Auszüge aus einem Programm zur Durchführung des erfindungsgemäßen Verfahrens wiedergegeben.
  • Zunächst wird durch eine „DeploymentService" genannte Softwarekomponente die Verfügbarkeit von aktualisierten Anwendungsteilen am Server geprüft, wobei die verfügbaren Aktualisierungen als Graph von „DeploymentTasks" zurückgeliefert werden:
    Figure 00110001
    Figure 00120001
  • Um die gefundenen Aktualisierungen für den Anwender benutzbar zu machen, werden diese zunächst asynchron heruntergeladen und anschließend asynchron aktiviert, das heißt installiert:
    Figure 00120002
    Figure 00130001
    Figure 00140001
    Figure 00150001
    Figure 00160001
    Figure 00170001
    Figure 00180001
  • 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 10351351 A1 [0002]

Claims (10)

  1. Verfahren zur Aktualisierung einer Applikation in einem Datenverarbeitungssystem (1), mit folgenden Schritten: – Bereitstellen einer mehrschichtig aufgebauten Applikation (A1, A2) in dem Datenverarbeitungssystem (1), wobei die Applikation (A1, A2) eine Mehrzahl an Modulen (M1,... M5) aufweist, die jeweils einer von mehreren Hierarchieebenen (E1, E1, E3) zugeordnet sind, – bereitstellen aktualisierter Module (M1', M2'), die jeweils zum Ersatz eines existierenden Moduls (M1, M2) vorgesehen sind, – automatische Kontrolle der existierenden Module (M1, M2) daraufhin, ob ein zugehöriges aktualisiertes Modul (M1', M2') bereitgestellt ist, – Erneuerung derjenigen Module (M1, M2), zu welchen aktualisierte Module (M1', M2') vorliegen, unter unveränderter Beibehaltung der übrigen Module (M3, M4, M5).
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die aktualisierten Module (M1', M2') unterschiedlichen Hierarchieebenen (E1, E1, E3) zugeordnet sind.
  3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Applikation (A1, A2) mehr als zwei Hierarchieebenen (E1, E1, E3) umfasst.
  4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass die Applikation (A1, A2) eine Darstellung-, eine Geschäfts- und eine Dienstleistungsschicht umfasst.
  5. Verfahren nach Anspruch 3 oder 4, dadurch gekennzeichnet, dass die Applikation (A1, A2) ein Modul (M1) aufweist, welches direkt mit mehreren Modulen (M2, M4, M5) unterschiedlicher Hierarchieebenen (E1, E2) verknüpft ist.
  6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass ein aktualisiertes Modul (M1') zusätzlich zu einem existierenden, weiterhin nutzbaren Modul (M1) installiert wird, wobei das aktualisierte Modul (M1') direkt mit einem ersten bestehenden Modul (M2) und das existierende Modul (M1) direkt mit einem zweiten bestehenden Modul (M4) verknüpft wird.
  7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass das erste bestehende Modul (M2, M2') im Zuge der Installation des aktualisierten Moduls (M1') modifiziert wird, während das zweite bestehende Modul (M4) unverändert bleibt.
  8. Verfahren nach Anspruch 6 oder 7, dadurch gekennzeichnet, dass die verschiedenen bestehenden Module (M2, M4) unterschiedlichen Hierarchieebenen (E1, E2) angehören.
  9. System zur Verwaltung mehrschichtiger Datenverarbeitungsprozesse, umfassend ein Datenaufmahmesystem (2) sowie eine zur Verarbeitung von mit dem Datenaufmahmesystem (2) akquirierten Daten vorgesehene Datenverarbeitungseinheit (4), welche datentechnisch zur Durchführung des Verfahrens nach Anspruch 1 eingerichtet ist.
  10. System nach Anspruch 9, dadurch gekennzeichnet, dass es sich bei dem Datenaufmahmesystem (2) um ein medizintechisches Datenaufmahmesystem handelt.
DE102007049958A 2007-10-18 2007-10-18 Verfahren und System zur Aktualisierung einer mehrschichtigen Applikation Withdrawn DE102007049958A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102007049958A DE102007049958A1 (de) 2007-10-18 2007-10-18 Verfahren und System zur Aktualisierung einer mehrschichtigen Applikation
US12/285,922 US20090106750A1 (en) 2007-10-18 2008-10-16 Method and system for updating a multilayer application

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102007049958A DE102007049958A1 (de) 2007-10-18 2007-10-18 Verfahren und System zur Aktualisierung einer mehrschichtigen Applikation

Publications (1)

Publication Number Publication Date
DE102007049958A1 true DE102007049958A1 (de) 2009-05-07

Family

ID=40514142

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102007049958A Withdrawn DE102007049958A1 (de) 2007-10-18 2007-10-18 Verfahren und System zur Aktualisierung einer mehrschichtigen Applikation

Country Status (2)

Country Link
US (1) US20090106750A1 (de)
DE (1) DE102007049958A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9483755B2 (en) 2008-03-04 2016-11-01 Apple Inc. Portable multifunction device, method, and graphical user interface for an email client
KR20100050098A (ko) * 2008-11-05 2010-05-13 삼성전자주식회사 영상처리장치 및 그 제어 방법

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030208569A1 (en) * 2000-04-14 2003-11-06 O'brien Michael D System and method for upgrading networked devices
DE10351351A1 (de) 2003-11-04 2005-06-16 Siemens Ag Verfahren und System zur dynamischen Generierung von User Interfaces
US20050262453A1 (en) * 2004-05-21 2005-11-24 Luca Massasso Modular data management system

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6880086B2 (en) * 2000-05-20 2005-04-12 Ciena Corporation Signatures for facilitating hot upgrades of modular software components
US20020078262A1 (en) * 2000-12-14 2002-06-20 Curl Corporation System and methods for providing compatibility across multiple versions of a software system
US20020144256A1 (en) * 2001-03-30 2002-10-03 Navin Budhiraja Method of deployment for concurrent execution of multiple versions of an integration model on an integration server
DE10254285A1 (de) * 2002-11-20 2004-06-03 Robert Bosch Gmbh Gateway-Einheit zur Verbindung von Subnetzen, insbesondere in Fahrzeugen
US9298513B2 (en) * 2004-10-07 2016-03-29 International Business Machines Corporation Method and structure for autonomic application differentiation/specialization
US7770164B2 (en) * 2005-05-31 2010-08-03 Siemens Aktiengesellschaft Software upgrades with centralized preparation
US8521736B2 (en) * 2005-10-26 2013-08-27 Dassault Systemes Enovia Corp. Managing hierarchies of components
US7827528B2 (en) * 2006-08-29 2010-11-02 Sap Ag Delta layering
US8522208B2 (en) * 2006-09-29 2013-08-27 Siemens Aktiengesellschaft System for creating and running a software application for medical imaging

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030208569A1 (en) * 2000-04-14 2003-11-06 O'brien Michael D System and method for upgrading networked devices
DE10351351A1 (de) 2003-11-04 2005-06-16 Siemens Ag Verfahren und System zur dynamischen Generierung von User Interfaces
US20050262453A1 (en) * 2004-05-21 2005-11-24 Luca Massasso Modular data management system

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
RAKIC, M.; MEDVIDOVIC, N.: Increasing the confiden ce in off-the shelf components: a software connect or-based approach, ACM SIGSOFT Software Engineerin g Notes, Volume 26, Issue 3, May 2001
RAKIC, M.; MEDVIDOVIC, N.: Increasing the confidence in off-the shelf components: a software connector-based approach, ACM SIGSOFT Software Engineering Notes, Volume 26, Issue 3, May 2001 *

Also Published As

Publication number Publication date
US20090106750A1 (en) 2009-04-23

Similar Documents

Publication Publication Date Title
DE102007062986B4 (de) Verfahren und Einrichtung zur Client-Server-Kommunikation gemäß dem Standardprotokoll OPC UA
DE102004062434A1 (de) System und Verfahren zum automatischen Aktualisieren von Funktionalitäten in einem verteilten Netzwerk
EP1430369B1 (de) Dynamischer zugriff auf automatisierungsressourcen
DE102010011658A1 (de) Applikationsplattform und Verfahren zum Betrieb einer Datenverarbeitungseinrichtung mit einer solchen
DE10309246B4 (de) Verfahren für das Event Management
EP1638028A2 (de) Rechnergestützte Erzeugung und Änderungsmanagement für Bedienoberflächen
DE102006035890A1 (de) System und Verfahren zur automatischen Installation und Wartung von Hard- und Software in einem verteilten Computersystem
DE102006035889A1 (de) System und Verfahren zur automatischen Installation und Wartung von Hard- und Software in einem verteilten Computersystem
DE102011107646A1 (de) Verfahren und System zur dynamischen Verteilung von Programmfunktionen in verteilten Steuerungssystemen
DE112013003240B4 (de) Verfahren zur Steuerung eines Kraftfahrzeuggetriebes
DE102007049958A1 (de) Verfahren und System zur Aktualisierung einer mehrschichtigen Applikation
EP3028182B1 (de) Verfahren und system zur synchronisation von daten
EP3441919A1 (de) Verfahren zum austausch von daten zwischen engineering-tools eines engineering-systems sowie engineering-system zur durchführung des verfahrens
DE102006024233B4 (de) Verfahren und Vorrichtung für ein Fehlertoleranzmanagement einer Softwarekomponente
DE102004017698A1 (de) SCADA-System
DE102021200190A1 (de) Verfahren zum Bereitstellen eines Konfigurations-Datensatzes einer Entität
EP4315088A1 (de) Verfahren und system zum bereitstellen von daten
DE102022125524A1 (de) Verfahren zum Entwerfen von Maschinensystemen
WO2022242921A1 (de) Verfahren, vorrichtung, computerprogramm und computerlesbares speichermedium zur ermittlung von fehlerbehafteten fahrzeugen
DE102006037968B4 (de) Universelle und erweiterbare Datenverwaltung mit Beobachtungs- und Interprozesskommunikations-Mechanismen
EP3028144A1 (de) Verfahren zum konnektieren von objekten in einer softwareanwendung
EP2927811B1 (de) Verfahren zur Steuerung eines automatisierten Ablaufs
DE202016104397U1 (de) Anordnung mit einem Werkzeug zum Konfigurieren einer technischen Anlage
DE102013216420A1 (de) Steueranlage zum Steuern von zumindest einem Schweißprozess
DE102012020760A1 (de) Einstellungsabhängige Releasenote

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
R016 Response to examination communication
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee

Effective date: 20130501