Der
Erfindung liegt damit die Aufgabe zugrunde, eine Softwaresystemanordnung
bereitzustellen, die dem Applikationsingenieur eine strukturierte
Führung
bei der Entwicklung gibt.
Diese
Aufgabe wird durch ein System zur automatisierten Benutzerführung bei
der Applikationsentwicklung gemäß den unabhängigen Patentansprüchen. 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.
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 an bieten 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 unterstü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 Bu siness-Forms hierarchisch angeordnet, so dass die Abfolge
des Umschaltens innerhalb einer Hierarchiestufe erfolgt, wenn die
Abfolge des Umschaltens in der nächsttieferen
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
kann in der Systemanordnung ein Zustands-Manager (State Manager)
vorgesehen sein, 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 4 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.