DE102005010405B4

DE102005010405B4 - Systemanordnung und Verfahren zur automatisierten Applikationsentwicklung mit Benutzerführung

Info

Publication number: DE102005010405B4
Application number: DE102005010405A
Authority: DE
Inventors: Detlef Becker; Karlheinz Dorn; Christian Scharf; Vladyslav Ukis; Hans-Martin von Dr. Stockhausen
Original assignee: Siemens AG
Current assignee: Siemens Healthcare GmbH
Priority date: 2005-03-07
Filing date: 2005-03-07
Publication date: 2009-05-20
Anticipated expiration: 2025-03-08
Also published as: CN1831767A; DE102005010405A1; CN100541429C

Abstract

Systemanordnung zur Applikationsentwicklung mit Benutzerführung, umfassend:
– zumindest eine View-Komponente (5–8) mit einer Mehrzahl von Presentation-Forms (7, 8), von denen zu einem bestimmten Zeitpunkt jeweils eine zur Ansicht von Daten und zur Eingabe durch einen Benutzer bestimmt ist,
– zumindest eine Model-Komponente (9–12) zum Speichern, Verarbeiten und/oder Abrufen von Daten,
– eine Controller-Komponente (1) zur Weiterleitung von Benutzereingaben und/oder Verarbeiten von Daten an die Model-Komponente (9–12) und zur Weiterleitung von abgefragten/verarbeiteten Daten an eine Presentation-Form (5–8),
wobei die Controller-Komponente (1) des Weiteren zum Umschalten zwischen den Ansichten (7, 8) bestimmt ist,
und wobei eine Prozessablaufkomponente (4) vorgesehen ist, die zumindest eine konfigurierbare Abfolge des Umschaltens zwischen den Ansichten (7, 8) anbietet,
gekennzeichnet durch
eine Zustandsmanager-Komponente (13) zum Speichern von Zuständen der anderen Teile der Systemanordnung bei deren Suspendierung und zum Wiederherstellen der Zustände beim Resumieren der Systemanordnung.

Description

Heutige Softwarearchitekturen bieten in der Regel die Möglichkeit an, Frontend- und Backendlogik nach bestimmten Vorschriften zu gestalten, um eine Homogenisierung der Software zu erreichen und die Software zu strukturieren. Damit wird eine Applikationssoftware-Entwicklung ermöglicht, die Softwareapplikationen erzeugt. Unter einer Frontendlogik wird dabei eine vorbereitende Programmlogik verstanden, während eine Backendlogik nach geordnete Verarbeitungsschritte, z. B. die Speicherung und Wiedergewinnung von Informationen in einer Datenbank, zum Ziel hat. Übliche Applikationen besitzen die Eigenschaft, monolithisch zu sein, was bei einem längeren Einsatz der Applikation dazu führt, dass es äußerst schwierig wird, veränderte bzw. neue Anforderungen an die Applikation in dieser umzusetzen. Dies liegt vor allem daran, dass die heutigen Softwarearchitekturen so gut wie keine Unterstützung für Interapplikationsprobleme anbieten.
Es existiert heute kein Subapplikationskonzept. Außerdem bieten die heutigen Softwarearchitekturen keine Unterstützung für den Datenfluss innerhalb einer Applikation. Der Anwender ist vielmehr bei der Bearbeitung von Anfragen, der Eingabe von neuen Informationen, dem Gewinnen von Informationen aus Datenbanken etc. insbesondere bei komplexen, über mehrere logische Einzelabschnitte gehenden Vorgängen auf sich selbst gestellt.
Weiterhin zeichnen sich die heutigen Softwarearchitekturen dadurch aus, dass die Programmiermodelle im Front- und Backend grundsätzlich verschieden sind, was sogar spezifische Teams von Softwareentwicklern geprägt hat, nämlich Frontend- und Backendentwickler. Eine solche Spezialisierung kann sich jedoch nachteilig auf den gesamten Entwicklungsprozess, insbesondere die Kosten, auswirken.
Außerdem bieten die heutigen Softwarearchitekturen keine Unterstützung für den Datenfluss innerhalb einer Applikation, was teilweise zu einem unübersichtlichen und unkontrollierten Datenaustausch in der Applikation führen kann und fehleranfällig ist. Fehler können auch vom Benutzer gemacht werden, wenn er bei seiner Arbeit nicht durch eine bestimmte Anordnung einzelner Arbeitsschritte vom Softwaresystem unterstützt wird, sondern darauf angewiesen ist, sich selbst einen Ablaufplan zu erstellen.
Des Weiteren ist das bisherige Vorgehen nach dem Stand der Technik mit einem Sicherheitsrisiko verbunden, da bei einer (ungewollten) Systemunterbrechung der Entwicklungszustand nicht gesichert ist. So zeigt das Oracle White Paper, datiert von April 2004 mit der Bezeichnung „Oracle Application Developement Framework Overview" ebenfalls ein Framework bei der Erstellung von Softwarearchitekturen. Es beinhaltet aber nachteiligerweise keine Sicherheitslogik, die es insbesondere ermöglicht, vom System eingenommene Zustände so abzuspeichern, dass bei einer Störung eine fehlerfreie Wiederaufnahme des Betriebs sichergestellt ist.
Der Erfindung liegt damit die Aufgabe zugrunde, eine Softwaresystemanordnung und ein entsprechendes Verfahren bereitzustellen, die/das das bisherige Vorgehen verbessert und dem Applikationsingenieur eine strukturierte Führung bei der Entwicklung gibt, während gleichzeitig die Sicherheit des Systems erhöht wird.
Diese Aufgabe wird durch ein System zur automatisierten Benutzerführung bei der Applikationsentwicklung gemäß den unabhängigen Patentansprüchen gelöst. Weitere vorteilhafte Aspekte, Details und Ausgestaltungen der vorliegenden Erfindung ergeben sich aus den abhängigen Patentansprüchen, der Beschreibung und den beigefügten Zeichnungen.
Ein klassisches System besteht aus einer View-Komponente, die für die Anzeige der Daten zuständig ist und diese Daten in verschiedenen Formen, wie z. B. Tabellen, Listen usw. anzeigen kann. Das klassische System besteht weiterhin aus einer Model-Komponente als Backend, die für die Datenspeicherung verantwortlich ist und Kenntnisse über die Art der Datenspeicherung besitzt. Der dritte Teil in einem vorbekannten System ist eine Controller-Komponente oder ein Controller, der sich logisch zwischen View-Komponente und Model-Komponente einordnet. Die Controller-Komponente verarbeitet die Benutzerinteraktionen (Tastatur, Mausereignisse usw.), wandelt sie in Datenanforderungen an die Model-Komponente um und schickt sie an die Model-Komponente. Wenn die Model-Komponente die Daten zurückgegeben hat, werden sie von der Controller-Komponente an die View-Komponente weitergeleitet und dort in der vom Benutzer gewünschten Art zur Anzeige gebracht. Der Vorteil dieses Ablaufs liegt darin, dass sowohl die Art der Datenspeicherung als auch die der Datenanzeige verändert werden können, ohne das gesamte Softwaresystem umbauen zu müssen. Die Controller-Komponente fungiert als Vermittler zwischen "View" und "Model". Deswegen ist der View von Änderungen im Model unbetroffen und genau so ist das Model gegen Änderungen im View immun.
Dementsprechend weist die erfindungsgemäße Systemanordnung zur automatischen Benutzerführung bei der Applikationsentwicklung die folgenden Komponenten auf:

– zumindest eine View-Komponente (Frontend) mit einer Mehrzahl von Presentation-Forms, von denen zu einem bestimmten Zeitpunkt jeweils eine zur Ansicht von Daten und zur Eingabe durch einen Benutzer bestimmt ist,
– zumindest eine Model-Komponente (Backend) zum Speichern und Abrufen von Daten,
– eine Controller-Komponente zur Weiterleitung von Benutzereingaben und/oder Abfragen von Daten an die Model-Komponente und zur Weiterleitung von abgefragten Daten an eine View-Komponente, wobei die Controller-Komponente des Weiteren zum Umschalten zwischen den Presentation-Forms bestimmt ist, und
– eine Prozesslaufkomponente zur Festlegung einer Abfolge des Umschaltens zwischen den Presentation-Forms und
– einen Zustands-Manager (State Manager, der zum Speichern von Zustanden der anderen Teile des Systems bei dessen Unterbrechung und zum Wiederherstellen der Zustände bei Wiederaufnahme des Systems bestimmt ist.

In der bevorzugten Ausführungsform ist die Prozessablaufkomponente dazu bestimmt, einen konfigurierbaren Ablauf anzubieten. Konfigurierbar soll in diesem Zusammenhang bedeuten, dass der Ablauf für jeden Entwicklungsprozess spezifisch anpassbar und vom Anwender einstellbar ist.
Die Prozessablaufkomponente ist vorgesehen, um eine konfigurierbare Abfolge des Umschaltens zwischen den Ansichten anbieten zu können. Darüber hinaus kann sie vorgesehen sein, um eine konfigurierbare Abfolge von Verarbeitungsschritten bei der Applikationsentwicklung anzubieten.
Die neuartige Architektur führt eine neue Dimension namens Prozessablaufkomponente oder "Process" ein. Diese Dimension adressiert die oben angesprochenen Probleme, die damit zusammenhängen, dass der Datenfluss innerhalb einer Applikation chaotisch werden kann, wenn die Softwarearchitektur, auf der die Applikation bzw. dessen Entwicklung aufsetzt, keine Unterstützung dafür bietet, den Datenfluss zu ordnen und zu lenken. Mit der Prozessablaufkomponente kann das Ziel erreicht werden, eine Workflow-Automatisierung vorzunehmen, so dass der Softwarebenutzer in seinen Entscheidungen durch eine konfigurierbare Abfolge von Datenbearbeitungsschritten unter stützt wird. Dies bringt den Vorteil, dass weniger Fehler produziert werden können.
Genauso wie eine View-Komponente gemäß der Erfindung eine Mehrzahl von Presentation-Forms aufweist, kann auch die Model-Komponente strukturiert sein, so dass sie eine Mehrzahl von Business-Forms der Datenspeicherung aufweist, die jeweils mit zumindest einer Presentation-Form logisch verbunden sind, wobei das Umschalten zwischen Presentation-Forms mit einem entsprechenden Umschalten zwischen Business-Forms gekoppelt ist.
Unter einer Business-Form ist hier eine bestimmte programmtechnische Art und Weise zu verstehen, in der die Daten aus einer Datenbank oder einem ähnlichen Datenreservoir gespeichert, abgefragt und aufbereitet werden. Auf diese Weise lässt sich eine Optimierung des Datenflusses erzielen, wenn für jede Presentation-Form oder eine Gruppe von Presentation-Forms eine passend gemachte Business-Form vorhanden ist.
In einer weiteren bevorzugten Ausführungsform sind die Presentation-Forms und gegebenenfalls, falls vorhanden, die Business-Forms hierarchisch angeordnet, so dass die Abfolge des Umschaltens innerhalb einer Hierarchiestufe erfolgt, wenn die Abfolge des Umschaltens in der nächst tieferen Hierarchiestufe durchlaufen worden ist. In der Praxis kann beispielsweise jede Presentation-Form und jede Business-Form noch aus Aufgaben ("Tasks") bestehen, die nacheinander aktiviert, aufgerufen bzw. abgearbeitet werden.
Auf diese Weise ist eine strukturierte Steuerung der Benutzerführung möglich, bis hinunter zu einer Ebene, bei der ein Entwickler gezwungen wird, ein bestimmtes Feld eines Formblatts oder eine bestimmt formatierte Eingabe auf der Kommandozeile einzugeben. Bevorzugterweise kann die Prozessablaufkomponente aufgrund von vorgegebenen Ereignissen bei der Benutzereingabe in einer Ansicht die Controller-Komponente dazu anweisen, anhand der festgelegten Abfolge zwischen zwei Presentation-Forms und gegebenenfalls zwischen zwei Business-Forms umzuschalten. Hierbei erfolgt eine Auswertung der jeweils getätigten Benutzereingaben und nach Komplettierung bestimmter Anforderungen an die Benutzereingaben kann die Prozessablaufkomponente die Fertigstellung bestimmter Bedingungen erfüllen, um dann die Presentation-Form für die Benutzereingabe zu wechseln. Es versteht sich, dass auch andere "Trigger" zum Umschalten möglich sind, so der Ablauf einer bestimmten Zeit seit Darstellung der Presentation-Form oder eine explizite Benutzeraktion, mit der dieser klar macht, dass er die aktuelle Presentation-Form vollständig bearbeitet hat (beispielsweise das Drücken einer Return-Taste).
Vorteilhafterweise wird die Abfolge von Presentation-Forms durch eine Konfigurationsdatei für die Prozessablaufkomponente bestimmt, die ausgelesen wird und festlegt, welche Presentation-Form als nächste geschaltet werden soll.
Ein Umschalten zwischen zwei Presentation-Forms erfolgt auf folgende Weise: Wenn der Benutzer mit der letzten Task des Subdatenflusses fertig ist, wird zum nächsten Schritt des Hauptdatenflusses übergegangen. Die Schritte des Hauptdatenflusses sind im Navigation Graph konfiguriert. D. h. durch den Navigation Graph wird festgelegt, in welcher Reihenfolge die Views geschaltet werden.
Die View-Komponente kann wiederum in mehrere Teilkomponenten unterteilt sein, um eine strukturierte Programmierung zu gestatten. So ist es beispielsweise möglich, die View-Komponente in eine generische "Frontend"-Komponente und eine eigentliche Presentation Form zu unterteilen, wobei der ersteren die Bereitstellung der grundlegenden Funktionalitäten zur Anzeige von Daten zukommt und die letztere die konkrete Ausgestaltung der Präsentation dieser Daten definiert.
Entsprechend kann das erfindungsgemäße System weiterhin einen View-Manager zur Erzeugung von generischen Frontend-Programmkomponenten für die zumindest eine View-Komponente aufweisen. Zudem kann es ebenfalls einen Model-Manager zur Erzeugung von generischen Backend-Programmkomponenten für die zumindest eine Model-Komponente aufweisen. Die Erzeugung der Frontend-Programmkomponenten und Backend-Programmkomponenten durch ihre jeweiligen Manager kann dabei ebenfalls von der Prozessablaufkomponente gesteuert oder zumindest gestartet werden. Während zur Erzeugung der generischen Backend- und Frontend-Komponenten eigene Manager verwendet werden, kann die Erzeugung der eigentlichen Presentation-Forms und Business-Forms durch die Controller-Komponente erfolgen. Entsprechend kann die Controller-Komponente Programmcode zur Erzeugung der Presentation-Forms der View-Komponente enthalten oder verarbeiten.
Die Controller-Komponente kann ebenfalls Programmcode zur Erzeugung der Modelle der View-Komponente enthalten oder verarbeiten.
Der Programmcode kann beispielsweise eine Konfigurationsdatei sein, insbesondere auf XML basieren.
Weiterhin ist in der Systemanordnung ein Zustands-Manager (State Manager) vorgesehen, der zum Speichern von Zuständen der anderen Teile des Systems bei dessen Unterbrechung (bzw. Suspense) und zum Wiederherstellen der Zustände bei Wiederaufnahme (bzw. Resume) des Systems bestimmt ist. Auf diese Weise ist es möglich, die erfindungsgemäße Systemanordnung zu unterbrechen bzw. in einen Ruhezustand zu versetzen und in exakt demselben Zustand wieder zu reaktivieren, ohne dass der Verarbeitungsvorgang vollständig neu gestartet werden muss.
Die erfindungsgemäße Systemanordnung kann lokal auf einem Computer oder auch auf einem Netzwerk ausgeführt werden, wobei zumindest die Model-Komponente und die View-Komponenten auf unterschiedlichen Rechnern, die über ein Netzwerk miteinander verbunden sind, ablaufen können. Dementsprechend wird es bevorzugt, dass die Systemanordnung zumindest eine View-Komponente für einen lokalen Einsatz auf Betriebssystemebene, d. h. auf einem einzelnen Computer, und zumindest eine View-Komponente für einen Netzwerkeinsatz über Netzwerkprotokolle aufweist. Aufgrund der völlig unterschiedlichen Art der Aufbereitung bei lokaler Anzeige, z. B. über X-Windows, PDF, Postscript oder GDI, im Vergleich zu einer Darstellung über ein Netzwerk, wie beispielsweise mittels HTML, XML oder speziellen Protokollen, erfolgt, sind auch spezifische View-Komponenten notwendig (es sei angemerkt, dass X-Windows und Display-Postscript-Varianten sowohl lokal als auch über ein Netzwerk verwendet werden können, so dass hier keine unterschiedlichen View-Komponenten notwendig sein müssten). Es stehen grundsätzlich verschiedene Möglichkeiten bereit, um den notwendigen Programmcode, wenn schon nicht für die einzelnen Komponenten der erfindungsgemäßen Systemanordnung, so doch für deren Interaktion und Ablauf zu implementieren.
Die erfindungsgemäße Systemanordnung kann weiterhin Mittel zur Datenzwischenspeicherung bei einem Umschalten der Presen tation-Forms vorsehen, um die in einer Presentation-Form gewonnenen Daten in weiteren Presentation-Forms weiterverwenden zu können. Die Datenzwischenspeicherung kann durch die Prozessablaufkomponente erfolgen und in einem Speicherbereich der Controller-Komponente vorgenommen werden, der beispielsweise über "Ports" zugänglich ist.
In einer bevorzugten Ausführungsform ist der Programmcode zur Erzeugung und Konfiguration der Komponenten der Systemanordnung ein in einer Scriptsprache geschriebener Code. Auf diese Weise ist auch nach Einrichtung der Systemanordnung eine Änderung durch einfache Änderung des Scriptcodes jederzeit noch möglich und damit eine Wartung der Systemanordnung einfach.
Die vorstehend beschriebenen, erfindungsgemäßen Ausführungsformen des Verfahrens können auch als Computerprogrammprodukt ausgebildet sein, wobei der Computer zur Durchführung des oben beschriebenen, erfindungsgemäßen Verfahrens veranlasst wird und dessen Programmcode durch einen Prozessor ausgeführt wird.
Eine alternative Aufgabenlösung sieht ein Speichermedium vor, das zur Speicherung des vorstehend beschriebenen, computerimplementierten Verfahrens bestimmt ist und von einem Computer lesbar ist.
Darüber hinaus ist es möglich, dass einzelne Komponenten des vorstehend beschriebenen Verfahrens in einer verkaufsfähigen Einheit und die restlichen Komponenten in einer anderen verkaufsfähigen Einheit ausgeführt werden können. Eine erfindungsgemäße weitere Lösung der Aufgabe liegt deshalb in einem Produkt, umfassend:
zumindest eine View-Komponente, eine Model-Komponente, eine Controller-Komponente und eine Prozessablaufkomponente eines verteilten Systems, welches Mittel umfasst, die zur Durchführung derjenigen Schritte eines Verfahrens nach zumindest einem der vorstehend beschriebenen Verfahrensaspekte eingerichtet sind, die von dem Produkt bewirkt werden, wobei zumindest ein weiteres Produkt zur Durchführung der restlichen Schritte des Verfahrens eingerichtet ist und durch Zusammenwirkung der zumindest zwei Produkte alle Schritte des Verfahrens durchgeführt werden.
Weitere vorteilhafte Ausführungsformen ergeben sich aus den Unteransprüchen.
In der folgenden detaillierten Figurenbeschreibung werden nicht einschränkend zu verstehende Ausführungsbeispiele mit deren Merkmalen und weiteren Vorteilen anhand der Zeichnung besprochen. In dieser zeigen:
1 eine Architektur der erfindungsgemäßen Systemanordnung;
2 einzelne Komponenten, die die erfindungsgemäße Systemanordnung bilden; und
3 beispielhaft einen hierarchischen Ablaufplan der einzelnen Presentation-Forms.
Wenn dem vorbekannten Softwaremuster MVC (Model·View·Controller) eine Prozessablaufkomponente hinzugefügt wird, kann bei der Benutzerinteraktion mit dem Softwaresystem ein konfigurierbares Muster von ausführbaren Schritten angeboten werden, das das Softwaresystem dem Applikationsentwickler bzw. Benutzer als Abfolge anbieten sollte. Durch eine Spezifikation der Schritte in einer bestimmten Reihenfolge wird die View-Komponente die Daten von der Model-Komponente über die Controller-Komponente in genau dieser Reihenfolge anfordern, so dass die Software den Entwickler bei seinen Entscheidungen mittels einer Führung durch die Schritte unterstützt.
1 gibt eine Übersicht über die erfindungsgemäß vorgesehene Architektur der Systemanordnung zur Benutzerführung. Der View kommuniziert mit dem Model über den Controller. Der erfindungsgemäße Process ist dabei für die Anordnung bzw. An folge dieser Interaktionen zuständig und legt fest, in welcher Reihenfolge die Interaktionen stattfinden sollen. Dieser Vorgang wird vom so genannten Navigation Graph, einer Konfigurationsdatei, durchgeführt. Der Navigation Graph hält die Informationen darüber bereit, welcher Schritt nach einem erfolgten Bearbeitungsschritt als nächstes auszuführen ist. Bei einer hierarchischen Anordnung treten zum Navigation Graph weitere Sub-Navigation Graphs, beispielsweise für Abfolgen bestimmter "Tasks", hinzu. Nachfolgend sollen die Strukturen der Komponenten des erfindungsgemäßen Systems näher beleuchtet werden. Bei der Entwicklung der Architektur wurde viel Wert auf die Symmetrie der Applikationsbestandteile gelegt. Der View wird vom sogenannten Generic Frontend (GenFE) und das Model vom Generic Backend (GenBE) repräsentiert. Beide beherbergen generische Implementierungen von Behältern (Containern). Das GenFe ist der generische Container für visuelle Frontanteile der Applikation und das GenBE ist der generische Container für Backendanteile der Applikation. Die Kommunikation zwischen diesen Komponenten des Frontends und Backends ist über die Controller-Komponente gesteuert.
Wie aus 1 ersichtlich, beinhaltet sowohl das GenFE als auch das GenBE jeweils eine so genannte Form, also eine Darstellung zur Präsentation von Daten und zur Eingabe derselben, bzw. zur formatierten Bearbeitung. Im Frontend ist eine vom GenFE gehostete Presentation-Form vorhanden und im Backend eine vom GenBE gehostete Business-Form.
Beide Forms beruhen auf der Idee, dass es sinnvoll ist, die Komponenten einer Softwareschicht (Frontend- oder Backend-Komponenten) und ihre Interaktionsmöglichkeiten in einer Konfigurationsdatei zu spezifizieren und von der so genannten Form erzeugen zu lassen. Die eigentlichen Interaktionen werden lokalisiert und in einer oder mehrerer Dateien vorzugsweise in einer Scriptsprache programmiert, so dass der Schichtbenutzer sowohl den aus konfigurierten Komponenten bestehenden Forminhalt als auch die Komponenteninteraktionen flexibel anpassen kann, ohne die ganze Schicht umbauen zu müssen. Die 2 zeigt, dass der Scriptcode der beiden Forms in der bevorzugten Ausführungsform im Controller angesiedelt ist, was man als Script Code Behind bezeichnet. Dies bringt auch dann Vorteile, wenn die Anzeigenprogrammkomponente die Darstellung von Daten in verschiedenen Technologien wie beispielsweise lokal oder über ein Netz, z. B. mit Win- oder WebForms, vornehmen muss. Wenn der Scriptcode der Presentation Form im Controller läuft, müssen die Komponenteninteraktionen nicht unbedingt verändert werden, wenn sich die Darstellungsart der Frontendkomponenten ändert. Diese "Forms" sind bereits zu einem früheren Zeitpunkt definiert worden.
Die heutige Softwarearchitekturen zeichnen sich dadurch aus, dass die Programmiermodelle im Front- und Backend grundsätzlich verschieden sind. Die Asymmetrien in Front- und Backendentwicklung können allerdings durch den Einsatz von Form-Konzepten in der hier vorgestellten erfindungsgemäßen Architektur merkbar reduziert werden.
Ein verfeinertes Modell des erfindungsgemäßen Systems zeigt 2 in einem schematischen Aufbau. Die vier Kernelemente der erfindungsgemäßen Architektur sind in der 2 deutlich zu erkennen. Die vier aktiven Hauptkomponenten sind ein Controller 1, ein View-Manager 2, ein Model-Manager 3, sowie der erfindungsgemäße Process, d. h. die Prozessablaufprogrammkomponente 4. Der View-Manager 2 erzeugt generische Frontendkomponenten 5, 6, welche wiederum jeweils eine Presentation-Form 7, 8, die die Frontendlogik der Applikation beschreibt und verarbeitet, anhand von Scriptcode erzeugen Das bemerkenswerte Merkmal bei dieser Ausgestaltung der Erfindung ist, dass der View-Manager 2 konfigurierbar ist und es im vorgestellten Beispiel der 2 zwei View-Manager 2 für verschiedene Technologien Web- und Winform existieren. Durch die Konfiguration von außen wird ein bestimmter View-Manager 2 gewählt, erzeugt und verwendet. Die WinForm-Frontendkomponenten 5, 7 können im Desktopeinsatz unter Win dows verwendet werden und die WebForm Frontends 6, 8 werden beim Webeinsatz des erfindungsgemäßen Systems eingesetzt. Beim Webeinsatz läuft der Container bzw. Gesamtbehälter in einem WebServer. Typischerweise entscheidet man sich unter Windows für Microsoft Internet Information Server (IIS).
Im Backend des erfindungsgemäßen Systems gibt es einen Model-Manager 3, der generische Backendkomponenten 9, 10 erzeugen kann. Die generischen Backendkomponenten 9, 10 erzeugen wiederum Business-Forms 11, 12, welche die Anwendungslogik der Applikation beschreibt und verarbeitet, mittels Scriptcode 17.
In 2 ist auf der rechten Seite der Zustands-Manager 13 zu sehen, bei dem der View- und Model-Manager 2, 3 ihren Zustand ablegen können. Der Zugriff auf den Zustandsmanager 13 wird bis in die Forms 7, 8, 11, 12 propagiert, damit die auf der jeweiligen Form befindlichen Komponenten ihren Zustand speichern und wieder auslesen können. Mit diesem Merkmal kann das ganze erfindungsgemäße System seinen Zustand über den Zustands-Manager 13 speichern, bevor es suspendiert wird, und den Zustand wieder auslesen, unmittelbar nachdem es resumiert werden soll. Es ist daher möglich, die Verarbeitung zu unterbrechen und wieder zu beginnen, ohne den Verarbeitungsvorgang vollständig neu starten zu müssen.
Links in der 2 ist die Controller-Komponente 1 zu finden, welche die Kommunikation zwischen Frontend und Backend steuert. Das Front- und Backend müssen nicht im gleichen Prozess innerhalb des Betriebssystems laufen. Es ist genauso möglich, zwei Container mit jeweils nur Front- oder Backendanteilen zu starten und die im Controller 1 angesiedelte Kommunikationsschicht sorgt dafür, dass die beiden Kommunikationspartner sich auch über ein Netzwerk finden. Außerdem beherbergt der Controller 1 ein Ereignissystem 14, das dafür sorgt, dass Front- und Backend der Applikation Ereignisse erzeugen können.
In der Mitte der 2 ist die vierte Basiskomponente der erfindungsgemäßen Systemarchitektur die Prozessablaufprogrammkomponente 4 (Process), vertreten durch den Navigation Graph, mit einer Datenflussmaschine sichtbar. Der Navigation Graph enthält die Informationen darüber, in welcher Reihenfolge der Benutzer bestimmte Arbeitsschritte ausführen soll, um eine bestimmte Applikation zu entwickeln bzw. um eine bestimmte Arbeit durchzuführen. Die nachfolgende Programmauflistung zeigt eine Konfiguration des Navigationsgraphen. Dort werden drei Ansichten hintereinander geschaltet: View_2D, View_3D und View_Filming. Wenn also der Benutzer eine Interaktion mit View_2D abgeschlossen hat, wird zum View_3D geschaltet. Weiterhin wird, wenn der Benutzer mit dem View_3D fertig ist, zum View_Filming geschaltet usw.
Die zugehörigen Models 11, 12 werden dabei von den Views bzw. Presentation-Forms 7, 8 getrieben, d. h. beim Umschalten einer View auf eine andere wird automatisch das zugehörige Model 11, 12 mit umgeschaltet. Die Datenflussmaschine kann beim Umschalten von Views auch die Daten zwischen den Views transportieren. Dafür existieren die in der 2 am Controller 1 vorhandenen Ports 15. Ein View 7, 8 kann seine fertigen Daten in einen Port von der Datenflussmaschine ablegen lassen und der nächste View kann diese Daten aus den Port von der Datenflussmaschine holen lassen, um sie zu verarbeiten.
Das Konzept der hierarchischen Ablaufsteuerung und des zugehörigen Unterdatenflusses gehört ebenfalls zum Prozessaspekt der erfindungsgemäßen Systemanordnung. Der äußere Datenfluss wird durch den zuvor gezeigten Navigationsgraphen beschrieben und legt fest, wie die einzelnen so genannten Activities (Views + Models) zu verschalten sind. Der "innere" Datenfluss bzw. die nächst tiefere Hierarchiestufe wird durch den in der nachfolgenden Programmauflistung referenzierten Datenfluss "Subdatenfluss1" beschrieben und liegt fest, wie der Datenfluss innerhalb der Aktivität aussehen kann.
3 zeigt in schematischer, nicht auf das oben stehende konkrete Beispiel bezogener Darstellung den Gesamtdatenfluss der Systemanordnung. Hierbei verschaltet sich Datenfluss1 (DF1) als Koordinator zu Subdatenflüssen 1, 2, 3 (SDF1, SDF2, SDF3), deren Ausgangsdaten wiederum zum Datenfluss1 zurückgeführt werden und nach einer weiteren Verarbeitung zum Datenfluss2 (DF2) gereicht werden, der im Subdatenfluss 4, 5 und 6 (SDF4, SDF5, SDF6) ebenfalls eine Weiterreichung der Daten vornimmt.
Die oben stehende Programmauflistung zeigt, dass jeder Task aus einem Modell- und einem Viewanteil besteht. Die jeweiligen Konfigurationen sind ganz normale Konfigurationen für die Business und Presentation Form, wie beschrieben. Der Navigation Graph zur Verschaltung von Tasks ist in der unten stehenden Programmauflistung dargestellt:
Die verschiedenen vorhandenen Komponenten der erfindungsgemäßen Systemanordnung müssen gestartet und miteinander verbunden werden. Auch dies geschieht logisch über ein Script, das in der nachfolgenden Programmauflistung dargestellt ist.
Die oben stehende Programmauflistung zeigt die Konfiguration der referenzierten Objekttypen, auf die im weiteren Verlauf der Konfiguration Bezug genommen wird. Hier werden der View-Manager 2, der Model-Manager 3, der Zustands-Manager 13 und der Controller 1 definiert.
Die nachfolgende Programmauflistung zeigt die Konfiguration einer so genannten Aktivität, die die gesamte erfindungsgemäße Systemanordnung widerspiegelt. Hier werden ein Model, ein View und ein Controller definiert. Der Controller wird über den Activity Work Flow Controller referenziert. Die eigentliche Definition erfolgte bereits bei der Konfiguration der Objekttypen in der unterhalb oberhalb stehenden Programmauflistung.
Die im Folgenden wiedergegebene Programmauflistung veranschaulicht eine komplette Konfiguration einer Applikation mit Daten und Subdatenfluss.
Durch den Einsatz des favorisierten und auf der erfindungsgemäßen Systemanordnung basierenden Containers wird es möglich, Applikationen zu schreiben, deren Business- und Präsentations-Logik nach dem gleichen Muster aufgebaut sind.
Weiterhin wird es möglich, eine Applikation in autarke Sub-Applikationen aufzuteilen und die Sub-Applikation von der konfigurierbaren Datenflussmaschine ablaufen zu lassen, um dem Benutzer flexibel bei seinem Entscheidungen zu unterstützen.
Vorteilhafterweise erfordert eine Umsetzung der Erfindung keine prinzipiellen Änderungen des bisherigen Standes der Technik, sondern lässt sich grundsätzlich nachträglich als Baustein – insbesondere als modifiziertes oder zusätzliches Computerprogrammprodukt – einfügen.
Abschließend sei darauf hingewiesen, dass die Beschreibung der Erfindung und die Ausführungsbeispiele grundsätzlich nicht einschränkend in Hinblick auf eine bestimmte physikalische Realisierung der Erfindung zu verstehen ist. Für einen einschlägigen Fachmann ist insbesondere offensichtlich, dass die Erfindung teilweise oder vollständig in Software und auf mehrere physikalische Produkte – dabei insbesondere auch Computerprogrammprodukte – verteilt realisiert werden kann.

Claims

Systemanordnung zur Applikationsentwicklung mit Benutzerführung, umfassend: – zumindest eine View-Komponente (5–8) mit einer Mehrzahl von Presentation-Forms (7, 8), von denen zu einem bestimmten Zeitpunkt jeweils eine zur Ansicht von Daten und zur Eingabe durch einen Benutzer bestimmt ist, – zumindest eine Model-Komponente (9–12) zum Speichern, Verarbeiten und/oder Abrufen von Daten, – eine Controller-Komponente (1) zur Weiterleitung von Benutzereingaben und/oder Verarbeiten von Daten an die Model-Komponente (9–12) und zur Weiterleitung von abgefragten/verarbeiteten Daten an eine Presentation-Form (5–8), wobei die Controller-Komponente (1) des Weiteren zum Umschalten zwischen den Ansichten (7, 8) bestimmt ist, und wobei eine Prozessablaufkomponente (4) vorgesehen ist, die zumindest eine konfigurierbare Abfolge des Umschaltens zwischen den Ansichten (7, 8) anbietet, gekennzeichnet durch eine Zustandsmanager-Komponente (13) zum Speichern von Zuständen der anderen Teile der Systemanordnung bei deren Suspendierung und zum Wiederherstellen der Zustände beim Resumieren der Systemanordnung.
Systemanordnung nach Anspruch 1, dadurch gekennzeichnet, dass die Model-Komponente (9–12) eine Mehrzahl von Business-Forms (11, 12) aufweist, die jeweils mit zumindest einer Presentation-Form (7, 8) logisch verbunden sind, wobei das Umschalten zwischen Presentation-Forms (7, 8) mit einem entsprechenden Umschalten zwischen Business-Forms (11, 12) gekoppelt ist.
Systemanordnung nach zumindest Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Presentations-Forms (7, 8) und gegebenenfalls die Business-Forms (11, 12) hierarchisch angeordnet sind, so dass die Abfolge des Umschaltens innerhalb einer Hierarchiestufe erfolgt, wenn die Abfolge des Umschaltens in der nächst tieferen Hierarchiestufe durchlaufen worden ist.
Systemanordnung nach zumindest einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Prozessablaufkomponente (4) aufgrund von vorgegebenen Ereignissen bei der Benutzereingabe in einer Presentation-Form (7, 8) die Controller-Komponente (1) dazu anweisen kann, anhand der festgelegten Abfolge zwischen zwei Presentation-Forms (7, 8) und gegebenenfalls zwischen zwei Business-Forms (11, 12) umzuschalten.
Systemanordnung nach zumindest einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Abfolge von Presentation-Forms (7, 8) durch zumindest eine Konfigurationsdatei für die Prozessablaufkomponente (4) bestimmt ist.
Systemanordnung nach zumindest einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass das Umschalten durch zumindest ein vorkonfigurierbares Ereignis triggerbar ist.
Systemanordnung nach zumindest einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass diese weiterhin einen View-Manager (2) zur Erzeugung von generischen Frontendprogrammkomponenten (5, 6) für zumindest eine View-Komponente (5–8) aufweist.
Systemanordnung nach zumindest einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass diese weiterhin einen Model-Manager (3) zur Erzeugung von generischen Backendprogrammkomponenten (9, 10) für zumindest eine Model-Komponente (9–12) aufweist.
Systemanordnung nach zumindest einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass die Controller-Komponente (1) Vorrichtungen zur Weiterleitung von Ereignissen von den und an die Model-Komponenten (9–12) und View-Komponenten (5–8) aufweist.
Systemanordnung nach zumindest einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass die Controller-Komponente (1) Programmcode (16) zur Erzeugung der Presentation-Forms (7, 8) zumindest einer View-Komponente (5–8) enthält oder verarbeiten kann.
Systemanordnung nach zumindest einem der Ansprüche 2 bis 10, dadurch gekennzeichnet, dass die Controller-Komponente (1) Programmcode (17) zur Erzeugung der Business-Forms (11, 12) der Model-Komponente (9–12) enthält oder verarbeiten kann.
Systemanordnung nach zumindest einem der Ansprüche 10 oder 11, dadurch gekennzeichnet, dass der Programmcode auf einem Script basiert.
Systemanordnung nach zumindest einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, dass die Systemanordnung zumindest eine View-Komponente (5, 7) für einen lokalen Einsatz auf Betriebssystemebene und zumindest eine weitere View-Komponente (6, 8) für einen Netzwerkeinsatz über Netzwerkprotokolle aufweist.
Systemanordnung nach zumindest einem der Ansprüche 1 bis 13, dadurch gekennzeichnet, dass Mittel zur Datenzwischenspeicherung bei einem Umschalten der Ansichten vorgesehen sind.
Systemanordnung nach Anspruch 14, dadurch gekennzeichnet, dass die Datenzwischenspeicherung durch die Prozessablaufkomponente (4) erfolgt und in einem Speicherbereich der Controller-Komponente (1) vorgenommen wird.
Systemanordnung nach zumindest einem der Ansprüche 1 bis 15, dadurch gekennzeichnet, dass der Programmcode zur Erzeugung und Konfiguration der Komponenten der System in einer Script-Sprache geschriebener Code ist.
Verfahren zur Applikationsentwicklung mit einer automatisierten Benutzerführung, umfassend die folgenden Verfahrensschritte: – Bereitstellen einer View-Komponente (5–8) mit einer Mehrzahl von Presentation-Forms (7, 8), von denen zu einem bestimmten Zeitpunkt jeweils eine zur Ansicht von Daten und zur Eingabe durch einen Benutzer bestimmt ist, – Bereitstellen zumindest einer Model-Komponente (9–12) zum Speichern, Verarbeiten und/oder Abrufen von Daten, – Weiterleiten von Benutzereingaben und/oder Verarbeiten von Daten an die Model-Komponente (9–12) und Weiterleiten von abgefragten/verarbeiteten Daten an eine Presentation-Form (5–8) durch eine Controller-Komponente (1), – Umschalten von einer Presentation-Form (7, 8) auf eine andere, vorgegebene Presentation-Form durch die Controller-Komponente (1), nachdem vorgegebene Benutzereingaben festgestellt worden sind; – Festlegen einer Abfolge des Umschaltens unter anderem zwischen den Ansichten (7, 8) mittels einer Prozessablaufkomponente (4), – Speichern von Zuständen der anderen Teile der Systemanordnung bei deren Suspendierung und zum Wiederherstellen der Zustände beim Resumieren der Systemanordnung durch eine Zustandsmanager-Komponente (13).
Verfahren nach Anspruch 17, dadurch gekennzeichnet, dass die Model-Komponente (9–12) eine Mehrzahl von Business-Forms (11, 12) umfasst, die jeweils mit zumindest einer Presentation-Form (7, 8) logisch verbunden sind, und dass es den weiteren Schritt aufweist: – Koppeln des Umschaltens zwischen Presentation-Forms (7, 8) mit dem Umschalten zwischen Business-Forms (11, 12).
Verfahren nach zumindest einem der Ansprüche 17 oder 18, dadurch gekennzeichnet, dass es mittels der Systemanordnung gemäß einem der Ansprüche 1 bis 16 durchgeführt wird.