DE112005002887T5

DE112005002887T5 - Modell-getriebenes Benutzerinterview

Info

Publication number: DE112005002887T5
Application number: DE112005002887T
Authority: DE
Inventors: Jay JieBing San Diego Yu; Kenichi Carlsbad Mori
Original assignee: Intuit Inc
Current assignee: Intuit Inc
Priority date: 2004-11-23
Filing date: 2005-11-23
Publication date: 2008-01-03
Also published as: AU2005309461A1; WO2006058207A3; US7805349B2; US20070094207A1; US20070094205A1; WO2006058207A9; CN101194252A; AU2005309461B2; US20070094206A1; GB0709662D0; US20060112114A1; GB2435172A; WO2006058207A2; US20070016607A1

Abstract

Computerimplementiertes System zum Modifizieren eines instanziierten Datenmodells, wobei das instanziierte Datenmodell eine oder mehr instanziierte spezialisierte Elemente enthält, wobei das System enthält:
ein Datenmodell, welches ein nicht-instanziiertes spezialisiertes Element enthält; und
einen Interviewtreiber, der so konfiguriert ist, einem Nutzer eine Aufforderung zu präsentieren, wobei die Aufforderung auf der Basis einer Position auf einem Graphen bestimmt wird und wobei der Graph das eine oder die mehreren instanziierten spezialisierten Elemente des instanziierten Datenmodells enthält.

Description

Hintergrund
Diese Patentanmeldung beansprucht die Priorität aus der folgenden Patentanmeldung, welche durch Referenz hiermit miteinbezogen wird: Vorläufige US-Patentanmeldung mit der laufenden Nummer 60/630,812, angemeldet am 23. November 2004, mit dem Titel "Modell-getriebene Steueranwendungsgerüst".
Die vorliegende Erfindung bezieht sich auf eine Software, die ein Benutzerinterview enthält.
Das Ausfüllen von Formularen ist eine allgemeine Tätigkeit in heutigen Zeiten. Einige Formulare sind einfach und gradlinig, während andere komplex und schwierig zu verstehen sind. Über die Jahre hinweg wurde Software hergestellt, um den Menschen zu helfen, Formulare auszufüllen. Ein Softwaretyp erhält von einem Benutzer Informationen, die zum Ausfüllen eines Formulars benötigt werden. Zum Beispiel kann eine Software einen Nutzer "interviewen", indem sie den Nutzer auffordert, die Information einzugeben. Diese Information kann dann verarbeitet werden, um zu bestimmen, wie das Formular ausgefüllt werden sollte. Eine solche Software wurde geschaffen, um bei der Fertigstellung von Formularen, die in Bereichen wie des Finanzwesens und des Gesetzes benutzt werden, zu helfen.
Zusammenfassung
Ein Gerüst bzw. Rahmen wird bereitgestellt, das verwendet werden kann, Software, die ein Benutzerinterview enthält, zu erzeugen und auszuführen. Bei einer Ausführungsform ist die Software als Finanzsoftware ausgebildet und kann z. B. für die Steuer, das Rechnungswesen oder das Finanzmanagement verwendet werden. Das Interview sammelt Informationen, die z. B. verwendet werden können, um ein Formular auszufüllen oder ein Dokument zu erzeugen. Das Interview ist dynamisch in der Weise, dass es von Nutzer zu Nutzer und von einem Moment zu dem anderen abhängig von Informationen, die bis dahin gesammelt wurden, verändert werden kann.
Das Gerüst enthält verschiedene Ablaufmaschinen und Datenspeicher. Zusammen führen die Ablaufmaschinen eine Softwareanwendung, die ein Benutzerinterview enthält, auf der Basis der Inhalte der Datenspeicher aus.
Der Datenspeicher enthält Modellinformationen und Interviewinstruktionen. Das Modell ist so konfiguriert, um beliebige Informationstypen, die einen finanziellen Zusammenhang, wie z. B. persönliche Informationen (z. B. Geburtsdatum, Ehestand), Beschäftigungsinformationen (z. B. Gehalt, Zusatzleistungen), Kontenniederschriften für beliebige Arten von Finanzkonten und Finanzbewegungen aufweisen, zu speichern. Bei einem Ausführungsbeispiel enthalten die Modellinformation ein Meta-Modell, ein Datenmodell und ein instanziiertes Modell. Das Meta-Modell definiert vier Elementtypen: Entitäten (Personen, Plätze oder Dinge), Beziehungen (Verbindungen zwischen den Entitäten), Regeln (Einschränkungen, die auf Entitäten und Beziehungen gelegt werden) und Ereignisse (Zustandsänderungen der Entitäten und Beziehungen). Das Datenmodell enthält spezialisierte Versionen dieser Elemente, wie spezialisierte Entitäten (z. B. eine Person oder ein Geschäft), spezialisierte Beziehungen (z. B. Heirat oder Beschäftigung), spezialisierte Regeln (z. B. bezüglich, ob ei ne Person legal arbeiten kann) und spezialisierte Ereignisse (z. B. Heirat oder der Arbeitsstart).
Das Meta-Modell und das Datenmodell sind abstrakt in der Weise, dass sie keine Daten enthalten, die spezifisch für eine besondere Entität (z. B. einen Nutzer) sind. Für eine vorgegebene Finanzanwendung wird ein instanziiertes Modell aus dem Datenmodell, welches eine oder mehrere instanziierte Elemente (Elemente, die einen Wert für einen oder mehrere Attribute aufweisen) enthält, gebildet. Ein instanziiertes Element stellt ein Phänomen „aus dem realen Leben" dar, obwohl das Phänomen real oder hypothetisch sein kann.
Die InterviewAufforderungen spezifizieren, wie man die Informationen von einem Nutzer gewinnt, um das instanziierte Datenmodell zu erzeugen oder zu modifizieren. In einer Ausführungsform enthalten die InterviewAufforderungen Steuerflussinformationen, Anforderungen und Benutzerschnittstellen-(UI = user interface) Informationen. Die Steuerflussinformationen steuern den Fluss eines Interviews. In einer Ausführungsform basiert der Fluss auf dem Datenmodell. Wenn eine spezialisierte Entität als ein Knoten angesehen wird und eine spezialisierte Beziehung als ein Rand angesehen wird, kann ein Satz untereinander verbundener Entitäten und Beziehungen als ein Graph interpretiert werden. In einer Ausführungsform entspricht der Interviewfluss dem, wie dieser Graph verläuft, von Knoten zum Rand und umgekehrt.
Die enthalten Anforderungen (z. B. Fragen), die an einen Benutzer während des Interviewvorganges gestellt werden. Eine Aufforderung eruiert Informationen, die dazu verwendet werden können, ein Element des Datenmodells, wie z. B. eine spezialisierte Entität oder Beziehung, zu erkennen oder zu untersuchen. In einer Ausführungsform weist jedes Element in dem Datenmodell drei Aufforderungstypen auf, die mit ihr verbunden sind: AskExit, AskDetail und AskChange.
Die UI-Informationen bestimmten die Benutzerschnittstelle für die Anwendung. In einer Ausführungsform bestimmten die UI-Informationen, wie eine Aufforderung dargestellt wird und/oder wie ein Benutzer auf eine Aufforderung antwortet. In einer Ausführungsform weist jedes Element in dem Datenmodell eine oder mehrere zugehörige UIs auf, die der Benutzer verwendet, um die angeforderten Informationen einzugeben.
Die Ablaufmaschinen enthalten einen Interviewtreiber. Der Interviewtreiber führt eine Anwendung, welche ein Benutzerinterview enthält, auf der Basis der Inhalte des Datenspeichers aus. Der Interviewtreiber erzeugt oder modifiziert ein instanziiertes Modell durch Verwendung der InterviewAufforderungen, um von einem Nutzer Informationen zu erhalten. Insbesondere führt der Interviewtreiber eine Interviewsequenz basierend auf dem instanziierten Modell und der Steuerflussinformationen aus. Der Interviewtreiber verwendet die Aufforderung und die UI-Informationen, um eine Aufforderung für den Nutzer zur Verfügung zu stellen und um eine Eingabe von dem Nutzer zu erhalten. Der Interviewtreiber verwendet die Eingabeinformationen, um das instanziierte Modell (z. B. durch Erzeugen eines neuen Elementes oder durch Modifizieren oder Entfernen eines bestehenden Elementes) zu erzeugen oder zu modifizieren.
Wurde erst einmal ein instanziiertes Modell erzeugt, kann es verwendet werden, ein instanziiertes anwendungsspezifisches Modell, wie z. B. für eine persönliche Einkommenssteuer, zu erzeugen. Das instanziierte anwendungsspezifische Modell kann dann verwendet werden, ein anwendungsspezifisches Dokument, wie z. B. ein Steuerformular, zu erzeugen. Da die Anwendung auf der Basis der Inhalte des Speichers ausgeführt wird, kann die Anwendung durch Verändern der Inhalte des Speichers modifiziert werden.
Kurze Beschreibung der Zeichnungen
1 zeigt ein Blockdiagramm eines Gerüsts, welches verwendet werden kann, um Software, die ein Benutzerinterview gemäß einer erfindungsgemäßes Ausführungsform enthält, zu erzeugen und auszuführen.
2 zeigt ein Ablaufdiagramm eines Verfahrens zum Erzeugen eines instanziierten Modells gemäß einer erfindungsgemäßen Ausführungsform.
3A und 3B zeigen ein Ablaufdiagramm für ein Verfahren zum Überprüfen eines instanziierten Modells gemäß einer erfindungsgemäßen Ausführungsform.
4 zeigt ein Ablaufdiagramm, wie einige der Komponenten in 1 gemäß einer erfindungsgemäßen Ausführungsform verwendet werden können.
5 zeigt eine Benutzerschnittstelle eines visuellen Modellierers gemäß einer erfindungsgemäßen Ausführungsform.
6 zeigt eine Benutzerschnittstelle eines Interviewfluss-Designers gemäß einer erfindungsgemäßen Ausführungsform.
7 zeigt eine Benutzerschnittstelle eines UI-Komponenten-Designers gemäß einer erfindungsgemäßen Ausführungsform.
8 zeigt eine Benutzerschnittstelle eines Modellkatographs gemäß einer erfindungsgemäßen Ausführungsform.
9 zeigt eine Tabelle spezialisierter Entitäten und deren Charakteristiken gemäß einer erfindungsgemäßen Ausführungsform.
10 zeigt eine Tabelle spezialisierter Verhältnisse und deren Charakteristika gemäß einer erfindungsgemäßen Ausführungsform.
11 zeigt ein Entitäts-Verhältnis-Diagramm, welches ein Datenmodell gemäß einer erfindungsgemäßen Ausführungsform darstellt.
12 zeigt eine Tabelle spezialisierter Ereignisse und deren Charakteristika gemäß einer erfindungsgemäßen Ausführungsform.
13 zeigt ein Blockdiagramm einer Information bezüglich einer "Ehepartner"-Beziehung gemäß einer erfindungsgemäßen Ausführungsform.
14 zeigt ein Blockdiagramm mit Informationen bezüglich einer "arbeitet für"-Beziehung gemäß einer erfindungsgemäßen Ausführungsform.
15 zeigt ein Diagramm für eine einheitliche Modellierungssprache (UML = Unified modelling language), welche ein Datenmodell gemäß einer erfindungsgemäßen Ausführungsform darstellt.
Ein Fachmann wird aus der nachfolgenden Diskussion leicht erkennen, dass alternative Ausführungsformen der Strukturen und Methoden, die hier gezeigt werden, angewendet werden können, ohne von dem Prinzip der hier beschriebenen Erfindung abzuweichen.
Detaillierte Beschreibung
Die nachfolgend beschriebenen Ausführungsformen widmen sich einer Finanzsoftware, die einen Nutzer "interviewt" (d. h. einen Nutzer für Informationen auffordern). Jedoch kann die Erfindung in Verbindung mit jeglichen Softwaretypen, die ein Benutzerinterview enthalten, verwendet werden. Diese Software kann in solch verschiedenen Bereichen wie z. B. im Rechtsbereich (z. B. Gerichtsdokumente) und für rechtliche Erfüllungen (z. B. lokale, staatliche und föderale Regierungseingaben) verwendet werden.
Ferner, während die Erfindung in Verbindung mit jeglicher Art von Finanzsoftware (z. B. Steuer-, Buchhaltungs- und Finanzmanagement) verwendet werden kann, widmen sich die nachfolgend beschriebenen Ausführungsformen im Speziellen der Steuersoftware. Insbesondere werden Systeme und Verfahren für Steuersoftware, die ein Benutzerinterview enthalten, beschrieben.
Gerüst zur Erzeugung einer Software, die ein Benutzerinterview enthält
Gemäß einer erfindungsgemäßen Ausführungsform wird ein Gerüst verwendet, um eine Software, die ein Benutzerinterview enthält, zu erzeugen und auszuführen. Das Interview sammelt Informationen, die z. B. verwendet werden können, ein Formular auszufüllen oder ein Dokument zu erzeugen. Das Interview ist dynamisch in der Weise, dass es von Nutzer zu Nnutzer und von einem Moment auf den nächsten abhängig von Informationen, die bis dahin gesammelt wurden, variieren kann.
Ein variabler Aspekt des Interviews ist sein "Fluss" (Sequenz oder Logik), welcher darstellt, welche Informationen gesucht werden und in welcher Reihenfolge. Ein weiterer variabler Aspekt des Interviews besteht darin, wie der Nutzer zur Eingabe von Informationen angewiesen wird (z. B. welche Fragen gefragt werden).
1 zeigt ein Blockdiagramm eines Gerüsts, das verwendet werden kann, Software, die ein Benutzerinterview gemäß einer erfindungsgemäßen Ausführungsform enthält, zu erzeugen oder auszuführen. Hier enthält das Gerüst 100 einen Datenspeicher 105 und Ablaufmaschinen 110. Der Datenspeicher 105 enthält Modellinformationen 120 und InterviewAufforderungen 125.
Die Modellinformationen 120 enthalten ein Meta-Modell 121, ein Datenmodell 122 und ein instanziiertes Modell 123. Das Meta-Modell 121 enthält vier Elementtypen (Entitäten, Beziehungen, Regeln und Ereignisse), die Informationen mit finanziellen Verflechtungen speichern können. Eine Entität stellt eine Person, ein Platz oder ein Ding dar; eine Beziehung stellt einen Zusammenhang zwischen Entitäten dar; eine Regel stellt eine Einschränkung, die auf eine Entität oder Beziehung platziert ist, dar; und ein Ereignis signalisiert einen Wechsel in einem Element. Das Datenmodell 122 enthält spezi alisierte Versionen dieser Elemente, wobei jedes spezialisierte Element verschiedene Attribute aufweist, von denen jedem ein besonderer Wert zugeordnet werden kann. Das instanziierte Modell 123 enthält eine oder mehrere Instanziierungen der Elemente des Datenmodells 122, wobei eine Instanziierung ein Element ist, welches für einen oder mehrere seiner Attribute einen Wert enthält. In einer Ausführungsform werden die Modelinformationen 120, die das Meta-Modell 121, das Datenmodell 122 und das instanziierte Modell 123 enthalten, unter Verwendung einer XML-Sprache (XML = eXtensible Markup Language) ausgedrückt. Die Modellinformationen 120 werden in dem nachfolgendem Abschnitt mit dem Titel "Beispiel: Finanzsoftware" gemäß einer erfindungsgemäßen Ausführungsform weiter beschrieben.
Die InterviewAufforderungen 125 spezifizieren, wie man Informationen von einem Benutzer erhält. Bei einer Ausführungsform enthalten die InterviewAufforderungen 125 Steuerflussinformationen 126, Aufforderungen 127 und Benutzerschnittstelleninformationen 128 (UI-Informationen).
Die Steuerflussinformationen 126 steuern den Fluss eines Interviews. Bei einer Ausführungsform basiert der Fluss auf dem Datenmodell 122. Wird eine (spezialisierte) Entität als ein Knoten angesehen und wird eine (spezialisierte) Beziehung als ein Kante angesehen, kann ein Satz miteinander verbundener Entitäten und Beziehungen als ein Graph interpretiert werden. In einer Ausführungsform entspricht der Fluss, wie dieser Graph von Knoten zu Kante und umgekehrt durchlaufen wird.
Der Interviewverlauf kann z. B. zwei Phasen für jedes spezialisierte Element in dem Graphen enthalten. Die erste Phase, das Erkennen, enthält das Bestimmen, ob das Element existiert. Die zweite Phase, das Untersuchen, enthält das Bestimmen der Information über dieses Element. Jede dieser Bestimmungen kann z. B. auf der Basis von Informationen, die von einem Nutzer erhalten wurden, oder von Informationen, die von anderen Informationen abgeleitet wurden, gemacht werden, wie unten erläutert wird.
In einer Ausführungsform spezifizierten die Steuerflussinformationen 126 die Reihenfolge, in welcher die spezialisierten Elemente erkannt und/oder untersucht werden sollten. In einer Ausführungsform kann die Reihenfolge des Erkennens und/oder des Untersuchens auf drei verschiedene Weisen gesteuert werden. Eine erste Möglichkeit ist mittels einer vorher definierten Sequenz. Ein Beispiel für eine vorher definierte Sequenz besteht darin, bei der Hauptentität Person zu starten, dann seine Wohnort-Entität (sofern vorhanden) zu enrkennen, dann seine Ehepartner-Beziehung (sofern vorhanden), dann seine „Arbeit für"-Beziehung (sofern vorhanden), etc. Ein anderes Beispiel einer vorher definierten Sequenz besteht darin, bei der Hauptentität Person zu starten, dann seine „Arbeit für"-Beziehung zu erkennen, dann die damit verbundene Geschäfts-Entität, etc.
Eine zweite Möglichkeit, den Fluss zu steuern, ist über ein Satz Regeln oder Heuristiken. Ein Beispiel für ein Heuristik besteht darin, eine Ehepartnerbeziehung vor der Feststellung einer "arbeitet für"-Beziehung zu erkennen. Ein weiteres Beispiel für eine Heuristik besteht darin, eine Entität vor einer Beziehung zu erkennen. Noch ein weiteres Beispiel besteht darin, sämtliche Beziehungen, die mit einer besonderen Entität verbunden sind, vor dem Untersuchen irgendeiner Beziehung genauer zu erkennen. Eine Heuristik kann als ein teilweises Anordnen dieser Elemente des Datenmodells angesehen werden. Zum Beispiel adressiert eine Heuristik, die die Reihenfolge zwischen Entitäten spezifiziert, nicht die Reihenfolge zwischen Beziehungen oder zwischen einer Beziehung und einer Entität.
In einer Ausführungsform sind Elemente eines Datenmodells in Gruppen organisiert und eine Heuristik ordnet Elemente auf der Basis deren Gruppen an. Zum Beispiel enthält die Gruppe "persönliche Informationen" Personen-Entitäten, Geschäfts-Entitäten und Wohnorts-Entitäten. Die Gruppe "Dinge, die man besitzt" enthält Entitäten, die von der Vermögens-Entität, so wie die Gebäudevermögensentitäten und Fahrzeugvermögensentitäten, abgeleitet sind, enthält. Die Gruppe "Dinge, die man schuldet" enthält Entitäten, die von der Haftungsentität (liability entity, so wie die Hypothekenhaftungsentitäten und der Eigenkapitaldarlehenshaftungsentitäten (Equity Loan Liability) abgeleitet sind. Die Gruppe "Andere" enthält die verbleibenden Entitäten des Datenmodells.
Mögliche Heuristiken können z. B. enthalten: Erkennen der Entitäten "Persönliche Informationen" vor den Entitäten "Dinge, die man besitzt"; Erkennen der Entitäten "Persönliche Informationen" vor den Entitäten "Dinge, die man schuldet"; Erkennen der Entitäten "Dinge, die man besitzt" vor den Entitäten "Andere"; und Erkennen der Entitäten "Dinge, die man schuldet" vor den Entitäten "Andere". Diese vier Heuristiken fungieren als ein partielles in der Reieenfolge Anordnen aller Entitäten in dem Datenmodell. (Die Reihenfolge ist nicht vollständig, da keine Heuristik sowohl die Entitäten "Dinge, die man besitzt" als auch die Entitäten "Dinge, die man schuldet" adressiert.) Während die obigen Heuristiken das Erkennen adressieren, kann eine Heuristik auch zum Untersuchen (z. B. zum Bestimmen, ob ein Element sofort untersucht werden soll oder auf später verschoben werden soll) verwendet werden kann.
In einer Ausführungsform spezifizierten die Steuerflussinformationen 126, ob ein spezialisiertes Element, das erkannt wurde, sofort untersucht wird oder auf später verschoben wird. Zum Beispiel verläuft eine Anwendung entlang eines Graphes eines instanziierten Modells 123 und erkennt ein Element, wie z. B. eine spezialisierte Entität oder Beziehung. Die Anwendung kann das Element entweder sofort oder zu einer späteren Zeit untersuchen (Informationen darüber bestimmen). Ein Flusstyp erkennt z. B. alle Beziehungen, die mit einer besonderen Entität verbunden sind, bevor irgendwelche Beziehungen genauer untersucht werden. In dieser Ausführungsform wird die Untersuchung einer Beziehung verschoben, bis alle Beziehungen (die mit der besonderen Entität verbunden sind) erkannt wurden.
Noch allgemeiner verläuft z. B. eine Anwendung entlang des Graphes eines instanziierten Modells 123 und stößt auf ein Element, wie z. B. eine Entität (Knoten) oder eine Beziehung (Kante). Die Anwendung überprüft, welche Elemente (sofern vorhanden) sie erkannt aber nicht untersucht hat. Sofern eine Heuristik existiert, die einem vorher erkannten, jedoch bis jetzt noch nicht untersuchten Element (z. B. basierend auf deren Gruppen) eine höhere Priorität zuordnet, dann wird die Untersuchung des derzeitigen Elements verschoben.
Eine dritte Möglichkeit, den Fluss zu steuern, ist über einen generischen Graph-Such-Algorithmus, wie z. B. "depth-first" (Tiefe zuerst), "breadth-first" (Breite zuerst), "branch-and-bound", "beam", oder "random" (zufällig). Ein Beispiel des "breadth-first"-Algorithmus besteht darin, bei der Hauptentität Person zu beginnen und dann alle seine verbundenen Beziehungen zu erkennen, bevor irgendeine der Entitäten, die mit den Beziehungen verknüpft ist, erkennt wird. (Erkennen einer mit einer Beziehung verknüpften Entität bevor alle Beziehungen erkannt wurden, stellt ein Beispiel der Suche der Tiefe des Graphes dar.)
Zu beachten ist, dass, da die vorherdefinierten Sequenzen besondere spezialisierte Elemente diskutieren, deren Betrieb auf eine Anwendung, die ein besonderes Datenmodell 122 verwenden, begrenzt ist. Da ein generischer Graph-Such-Algorithmus unabhängig von dem Datenmodell 122 arbeitet, kann er verwendet werden, den Fluss jeder Anwendung, die irgendein Datenmodell verwendet, zu steuern. Zu beachten ist auch, dass die obigen Verfahren zur Steuerung des Flusses in Kombination verwendet werden können. Zum Beispiel kann eine Entscheidung bei einem Erkennen auf einer Heuristik basieren. Wenn jedoch keine Heuristik sich auf die besondere Situation bezieht, kann eine vorher definierte Sequenz oder ein generischer Graph-Such-Algorithmus statt dessen verwendet werden.
In einer anderen Ausführungsform enthalten die Steuerflussinformationen 126, welche Aufforderungstypen bei jedem Knoten (Entität) oder bei jeder Kante (Beziehung), wenn sie durchlaufen wird (z. B. erkannt oder untersucht wird) präsentiert werden sollte. In einer Ausführungsform weist jedes Element in dem Datenmodell drei Aufforderungstypen auf, die mit ihm verknüpft sind. Der erste Typ ("AskExist") eruiert Informationen, die verwendet werden können, das spezialisierte Element "zu erkennen" (i.e. festzustellen, ob das spezialisierte Element existiert). Der zweite Typ ("AskDe tail") eruiert Informationen, die verwendet werden können, um das spezialisierte Element "zu untersuchen" (z. B. es zu instanziieren durch Zuordnen eines Wertes zu einem oder mehrerer seiner Attribute). Der dritte Typ ("AskChange") eruiert Informationen bezüglich eines möglichen Wechsels in dem spezialisierten Element. Da ein Ereignis ein spezialisiertes Element ändern kann, eruiert eine AskChange-Aufforderung manchmal Informationen, die verwendet werden können, ein spezialisiertes Ereignis zu erkennen oder zu untersuchen.
Nehmen wir eine Ehepartnerbeziehung an, die mit zwei Personenentitäten verknüpft sind. Eine AskExist-Aufforderung könnte "Sind Sie verheiratet?" oder "Sind sie Single?" sein. Eine AskDetail-Aufforderung könnte "Teilen Sie uns mehr über Ihre Ehe mit" oder "Beschreiben Sie Ihre Hochzeit." sein. Eine AskChange-Aufforderung könnte "Gibt es irgendeine Veränderung in Ihrem Ehestatus seit 1/1/2005?" oder "Haben Sie in 2005 geheiratet?" sein.
In einer Ausführungsform könnten für eine bestehende Entität oder Beziehung eine oder zwei Aufforderungen präsentiert werden: 1) eine AskChange-Aufforderung über die Entität oder Beziehung oder 2) eine AskExist-Aufforderung über ein spezialisiertes Ereignis, welches diese Entität oder Beziehung ändern (oder beseitigen) würde. Für eine nicht existierende Entität oder Beziehung könnten eine oder zwei Aufforderungen präsentiert werden: 1) eine AskExist-Aufforderung über die Entität oder Beziehung oder 2) eine AskExist-Aufforderung über ein spezialisiertes Ereignis, welches diese Entität oder Beziehung erzeugen würde.
Während der Laufzeit kann der Interviewtreiber 135 die Steuerflussinformationen 126 abrufen, um z. B. zu bestimmen, welches Element als nächstes zu erkennen oder zu untersuchen ist und/oder welcher Aufforderungstyp zu präsentieren ist. Die Steuerflussinformationen 126 können auf der Basis davon abweichen, welcher Flusstyp gewünscht ist. Wenn z. B. eine vorher definierte Sequenz gewünscht ist, können die Steuerflussinformationen 126 eine spezifische Reihenfolge der Elemente des Datenmodells beinhalten, wie z. B. Entitäten und Beziehungen. Wenn ein auf Regeln oder Heuristik basierender Fluss gewünscht ist, können die Steuerflussinformationen 126 eine oder mehrere Regeln oder Heuristiken und deren Rangfolgen im Hinblick darauf beinhalten, welche dieser sollen im Falle eines Konfliktes angewendet werden. Falls ein Graph-Such-Algorithmus gewünscht ist, können die Steuerflussinformationen 126 einen oder mehrere Algorithmen, wie z. B. "breadth-first"-Suche, "depth-first"-Suche, "branch-and-bound", und "beam"-Suche, beinhalten.
In einer Ausführungsform sind die Steuerflussinformationen in einer Datenbank unter Verwendung von XML gespeichert. Anhang A beinhaltet einen XML-Code zum Definieren der Heuristiken zum Erkennen und zum Untersuchen basierend auf Gruppen (wie oben beschrieben) gemäß einer erfindungsgemäßen Ausführungsform.
Die Aufforderungen 127 beinhalten Aufforderungen (z. B. Fragen), um diese einem Nutzer während eines Interviewvorgangs zu präsentieren. Wie oben diskutiert eruiert eine Aufforderung Informationen, die verwendet werden können, um ein Element (z. B. eine spezialisierte Entität oder Beziehung) eines Datenmodells 122 zu erkennen oder zu untersuchen.
In einer Ausführungsform weist jedes Element in dem Datenmodell 122 drei Aufforderungstypen auf, die mit ihm verknüpft sind: AskExist-Aufforderungen, AskDetail-Aufforderungen und AskChange-Aufforderungen. Sofern mehr als eine Aufforderung für einen besonderen Typ (z. B. wenn zwei AskExist-Aufforderungen existieren) existieren, wird in einer Ausführungsform eine Aufforderung während der Laufzeit auf der Basis einer oder mehrerer Benutzercharakteristiken gewählt. Diese Charakteristiken können in dem instanziierten Modell 123 durch verschiedene spezialisierte Elemente beschrieben werden. Zum Beispiel könnte das Alter oder das Geschlecht des Nutzers durch die Personen-Entität, die den Nutzer darstellt, beschrieben werden. Die Charakteristiken würden dann verwendet werden, um die angemessene Aufforderung zu bestimmen. Falls z. B. der Nutzer jünger als 25 ist, könnte die gewählte AskExist-Aufforderung eher "Sind Sie Single?" als "Sind Sie verheiratet?" sein.
Informationen in Bezug auf das in Frage stehende spezialisierte Element (z. B. dem Element, über welches Informationen eruiert wurden) könnten auch durch ein anderes spezialisiertes Element beschrieben werden. Insbesondere können AskChange-Aufforderungen gut Gebrauch von diesem Informationstyp machen. Da eine AskChange-Aufforderung Informationen bezüglich eines möglichen Wechsels in dem spezialisierten Element eruiert, wird ein anfänglicher Zustand des spezialisierten Elementes miteinbezogen. Wenn z. B. das besagte spezialisierte Element die Ehepartnerbeziehung ist und das instanziierte Modell 123 gerade den Nutzer als Single beschreibt, könnte die gewählte AskChange-Aufforderung eher "Hatten Sie 2005 geheiratet?" sein als "Gab es irgendeinen Wechsel in Ihrem Ehestand seit 1/1/2005?".
Nutzercharakteristiken könnten ebenfalls Informationen enthalten, die außerhalb derer sind, die in dem instanziierten Modell 123 beschrieben sind. Zum Beispiel könnten Nutzercharakteristiken das Erfahrungsniveau des Nutzers mit der Anwendung (z. B. ob der Nutzer ein Experte oder ein Neuling ist) beinhalten. Das Erfahrungsniveau könnte auf Statistiken basieren, die durch die Software während der Verwendung der Anwendung gesammelt werden.
In einer Ausführungsform wird eine Aufforderung individuell geschrieben. In einer anderen Ausführungsform wird eine Aufforderung unter Verwendung der Software erzeugt. Zum Beispiel kann eine "Template"-Aufforderung verwendet werden, die bestimmte Variablen kennzeichnet, deren Werte während der Laufzeit bestimmt werden. Ein Beispiel einer Template-Aufforderung ist "Wie ist der Name Ihres <Ehepartners>?", wobei der Wert der Variablen <Ehepartner> abhängig von dem Geschlecht des Nutzers "Ehefrau" oder "Ehemann" sein kann. Somit kann diese Template-Aufforderung statt der zwei "normalen" Aufforderungen "Wie ist der Name Ihrer Ehefrau?" und "Wie ist der Name Ihres Ehemanns?" geschrieben werden. Als ein anderes Beispiel kann eine Verarbeitung der natürlichen Sprache verwendet werden, um eine Aufforderung (z. B. basierend auf der Substitution des Namens, der Substitution der Rolle und einer Umformulierung) zu erzeugen.
In einer Ausführungsform wird eine Aufforderung (sei es eine normale Aufforderung oder eine Template-Aufforderung) in einer Datenbank unter Verwendung von XML gespeichert. Anhang B beinhaltet einen XML-Code für eine Template-Aufforderung gemäß einer Ausführungsform der Erfindung. Während der Laufzeit kann der Interviewtreiber 135 auf diese Informationen zugreifen, um zu bestimmen, welche Aufforderung dem Nutzer zu präsentieren ist. In einer anderen Ausführungsform ist die Aufforderung verknüpft mit 1) dem Element des Datenmo dells 122, über welches es Informationen eruiert und/oder 2) dem Typ der Aufforderung (z. B. AskExist, AskDetail oder AskChange).
Die UI-Informationen 128 spezifizieren die Nutzerschnittstelle für die Anwendung. In einer Ausführungsform spezifizieren die UI-Informationen 128, wie eine Aufforderung präsentiert wird und/oder wie ein Nutzer auf eine Aufforderung antwortet. In einer Ausführungsform weist jede spezialisierte Entität, Beziehung und Ereignis eine oder mehrere verknüpfte UIs auf, welche der Nutzer benutzt, um angeforderte Informationen einzugeben. Zum Beispiel kann ein spezialisiertes Element verschiedene UIs aufweisen, die verschiedenen Zwecken dienen. Eine "Add View" (füge Ansicht hinzu) UI kann einem Nutzer ermöglichen, ein neues Element durch Eingeben neuer Informationen zu erzeugen. Eine "Edit View" (gib eine Ansicht aus) UI kann einem Nutzer ermöglichen, ein bestehendes Element durch Modifizieren oder Aktualisieren bestehender Informationen auszugeben. Eine "Summary View" (Übersichtsansicht) UI kann ausgewählte Informationen über das Element präsentieren, während eine "Detail View" (Detailansicht) UI alle Informationen über das Element präsentieren kann.
UIs können in deren äußeren Erscheinungsbild (z. B. durch Verwendung verschiedener Layouts, Schriftsätze und Farbschemata) basierend auf deren verknüpften spezialisierten Elementen und/oder deren Verwendung (z. B. Add View, Edit View, Summary View and Detail View) voneinander abweichen. In einer Ausführungsform wird ein Satz von UI-Informationen 128 für ein Datenmodell 122 als ein "Thema" bezeichnet. Durch Spezifizieren eines unterschiedlichen Themas kann die UI einer Anwendung geändert werden. In einer Ausführungsform be inhaltet eine UI eine Dialogbox mit Feldern, in welche Informationen eingegeben werden können.
In einer Ausführungsform werden die UI-Informationen 128 in einer Datenbank unter Verwendung von XML gespeichert. Während der Laufzeit kann der Interviewtreiber 135 auf diese Informationen zugreifen, um zu bestimmen, 1) wie Aufforderungen zu präsentieren sind und/oder 2) wie eine Eingabe zu akzeptieren ist. Zum Beispiel können die UI-Informationen 128 unter Verwendung einer XML-Nutzerschnittstellensprache (XUL = XML User Interface Language) oder einer XAML-Sprache (XAML = eXtensible Application Markup Language) ausgedrückt werden. XUL ist ferner beschrieben bei
http://www.mozilla.org/projects/xul/, und seine Spezifikation ist erhältlich bei
http://www.mozilla.org/projects/xul/xul.html. XAML ist ferner beschrieben bei
http://winfx.msdn.microsoft.com/library/default.asp?url=/lib rary/en-us/wcp_conceptual/html/a80db4cd-dd0f-479f-a45f-3740017c22e4.asp.
Die Laufzeitmaschinen 110 enthalten einen Interviewtreiber 135. Der Interviewtreiber 135 führt eine Anwendung (die ein Benutzerinterview enthält) basierend auf den Inhalten des Datenspeichers 105 aus. In einer (nicht gezeigten) Ausführungsform enthalten die Laufzeitmaschinen 110 Helferanwendungen, wie z. B. eine Regelmaschine und eine Datenbankmaschine. Die Regelmaschine führt auf der Basis eines Satzes an Regeln eine Regelverkettung aus. Diese Regelverkettung kann z. B. verwendet werden, eher Informationen abzuleiten als diese von einem Nutzer während des Interviewvorgangs zu gewinnen. Sie kann auch verwendet werden, den Verlauf des Graphes eines instanziierten Modells 123, wie oben erläu tert, zu steuern. In einer Ausführungsform ist die Regelmaschine die Open-Source-("Drools"-)Regelmaschine (erhältlich bei http://drools.codehaus.org), und Steuerflussinformationen 126 enthalten Regeln, die in die Regelmaschine eingegeben werden. Die Datenbankmaschine koppelt den Datenspeicher 105, um auf Informationen zuzugreifen und Informationen zu speichern.
Der Interviewtreiber 135 erzeugt und modifiziert ein instanziiertes Modell 123. Ungeachtet seines Typs fokussiert sich eine Anwendung auf das Sammeln von Informationen, die für eine oder mehrere spezialisierte Entitäten relevant sind. Falls die Anwendung beginnt, wird bei einer Ausführungsform ein instanziiertes Modell 123 erzeugt, welches diese Entität (die "Anker"-Entität) enthält. Der Interviewtreiber 135 instanziiert diese Entität und "erkennt" (bestimmt die Existenz von) anderen spezialisierten Elementen und instanziiert diese. Schließlich wird ein vollständiges instanziiertes Modell 123 aufgebaut.
Man betrachtet z. B. eine Anwendung einer Steuerdarstellung, die verwendet wird, um die Steuerhaftbarkeit (tax liability) einer Person zu bestimmen. Die Anwendung würde ein instanziiertes Modell 123 erzeugen, welches ein Ankerelement – eine Personenentität, die den besagten Steuerzahler repräsentiert – enthalten würde. Der Interviewtreiber 135 würde die Personenentität instanziieren und andere Elemente des Datenmodells, welche die Steuerhaftbarkeit des Steuerzahlers betreffen, erkennen.
Man beachtet, dass die obigen Schritte in verschiedener Reihenfolge aufgeführt werden können. Zum Beispiel könnte ein Interviewtreiber 135 zunächst die Steuerzahlerentität in stanziieren und dann andere Elemente erkennen oder umgekehrt. Auch könnte der Interviewtreiber 135 eine dieser anderen Elemente, sobald sie identifiziert wurden, instanziieren oder der Interviewtreiber 135 könnte damit fortfahren, zusätzliche Elemente vor dem Instanziieren von irgendeinem davon zu identifizieren. Diese Auswahl steuert die Laufzeit der Bearbeitung des Interviewtreibers und wurde oben mit Bezug auf die Interviewanweisungen 125 diskutiert.
In einer Ausführungsform wird ein Element des Datenmodells erkannt und/oder instanziiert basierend auf Informationen, die von dem Nutzer der Anwendung erhalten werden. Zum Beispiel kann die Anwendung den Nutzer "interviewen" (Aufforderungen präsentieren). Um dem DateOfBirth (Geburtsdatums)-Attribut einer Personenentität einen Wert zuzuweisen, könnte die Anwendung den Nutzer nach seinem Geburtsdatum fragen. Um zu bestimmen, ob eine "arbeitet für"-Beziehung existiert, könnte die Anwendung den Benutzer fragen, ob er einen Job hat. In einer Ausführungsform wird die Aufforderung visuell (z. B. durch Verwendung einer Anzeigeeinrichtung) präsentiert. In einer anderen Ausführungsform wird eine Aufforderung akustisch (z. B. durch Verwendung eines Lautsprechers) präsentiert.
Die Antwort des Nutzers würde dann verwendet werden, um die Existenz eines Elementes zu bestimmen oder einem Attribut eines Elementes einen Wert zuzuweisen. In einer Ausführungsform wird eine Antwort durch Verwendung eines Zeigegeräts oder einer Tastatur (z. B. um einen Wert in ein Feld eines Formulars einzugeben) eingegeben. In einer anderen Ausführungsform wird eine Antwort durch Sprechen (z. B. unter Verwendung eines Mikrophons und eines Spracherkennungsprogramms) eingegeben.
In einer anderen Ausführungsform wird ein Element des Datenmodells erkannt und/oder instanziiert auf der Basis von Informationen, die durch die Anwendung abgeleitet wurden (z. B. unter Verwendung einer Regel/Ableitemaschine). Man nehme z. B. ein Datenmodell an, welches eine Personenentität enthält, die als Wert eines Geschlechtsattributs "männlich" aufweist. Die Anwendung bestimmt dann, dass die Person, die durch die Personenentität repräsentiert wird, verheiratet ist (und somit Teil einer Ehepartnerbeziehung ist). Als Ergebnis dieser Bestimmung kann die Anwendung ableiten, dass 1) eine andere Personenentität existiert (der Ehepartner der ersten Person) und 2) der Wert des Geschlechtsattributs dieser Personenentität "weiblich" ist. Die Anwendung kann diese Tatsache deshalb ableiten, da 1) eine Ehepartnerbeziehung als zwischen zwei Personenentitäten existierend definiert wird und 2) eine Regel existiert, die angibt, dass in einer Ehepartnerbeziehung die zwei Personenentitäten unterschiedliche Werte deren Geschlechtsattribute aufweisen müssen. Auf diese Art und Weise kann ein Interviewtreiber 135 die Elemente eines Datenmodells erkennen und/oder diese instaziieren, ohne eine zusätzliche Eingabe von dem Nutzer zu benötigen. Das Ableiten wird mit Bezug auf Regeln, die mit Elementen des Datenmodells 122 verknüpft sind, beschrieben.
Der Interviewtreiber 135 verwendet die InterviewAufforderungen 125, um Informationen von dem Nutzer zu erhalten. Speziell führt der Interviewtreiber 135 eine Interviewsequenz basierend auf dem instanziierten Modell 123 und den Steuerflussinformationen 126 aus. Der Interviewtreiber 135 verwendet die Aufforderungen 126 und die UI-Informationen 128, um eine Aufforderung zu präsentieren und um eine Eingabe von dem Nutzer aufzunehmen. Der Interviewtreiber 135 verwendet die Interviewinformationen, um das instanziierte Modell 123 zu erzeugen oder zu modifizieren (z. B. durch Erzeugen eines neuen Elementes oder durch Modifizieren oder Entfernen eines bestehenden Elementes).
Erzeugen und Überprüfen eines instanziierten Modells
Software, die gemäß dem in 1 dargestellten Gerüst 100 erzeugt wurde, kann verwendet werden, ein instanziiertes Modell 123 zu erzeugen und/oder ein existierendes instanziierendes Modell 123 zu überprüfen. Das Erzeugen eines Modells ist sinnvoll, wenn die Software z. B. zum ersten Mal für eine bestimmte Person verwendet wird. Das Überprüfen eines Modells ist sinnvoll, wenn z. B. die Software bereits für eine bestimmte Person verwendet wurde, die gespeicherten Informationen in dem Modell aber nicht mehr aktuell sind. 2 adressiert das Erzeugen eines Modells, während die 3A und 3B das Überprüfen eines existierenden Modells adressieren.
2 zeigt ein Ablaufdiagramm eines Verfahrens zum Erzeugen eines instanziierten Modells gemäß einer erfindungsgemäßen Ausführungsform. In einer Ausführungsform führt der Interviewtreiber 135 die Schritte des Ablaufdiagramms 200 aus. Man erinnere sich, dass eine Anwendung Informationen, die für eine oder mehrere spezialisierte Entitäten, so genannte "Anker"-Entitäten, relevant sind, sammelt. Eine Ankerentität kann z. B. eine Personenentität oder eine Geschäftsentität sein. In einer Ausführungsform wird, wenn das Datenmodell 122 erzeugt wird, eine oder mehrere Entitäten als Ankerentität bezeichnet.
In der in 2 dargestellten Ausführungsform existiert nur eine einzige Ankerentität. Das Ablaufdiagramm beginnt, wenn die Ankerentität (eine spezialisierte Entität) einer als neue Entitätsschlange (NEQ = New Entity Queue) 110 bezeichneten Reihe hinzugefügt wird. Als nächstes werden verschiedene Schritte für jede Entität (die "aktuelle Entität") in der NEQ ausgeführt. Anfangs enthält die NEQ nur die Ankerentität. Jedoch können andere Entitäten zu der NEQ während anderer Schritte des Ablaufdiagramms 200, wie unten beschrieben wird, hinzugefügt werden.
Die aktuelle Entität wird instanziiert und zu einem instanziierten Modell 220 hinzugefügt. (Das instanziierte Modell 123 ist anfangs, leer bis die instanziierte Ankerentität während der ersten Iteration des Schritts 220 zu ihm hinzugefügt wird.) Wie oben diskutiert enthält das Instanziieren eines spezialisierten Elementes das Zuweisen eines Wertes zu einem oder mehreren Attributen des Elementes. Dieser Wert kann auf der Basis von Informationen bestimmt werden, die von dem Nutzer aufgenommen werden, oder auf der Basis von Informationen, die von anderen Informationen, wie oben diskutiert, abgeleitet werden. Diese Bestimmung ist ähnlich zu der oben beschriebenen "Untersuchungsphase". In einer Ausführungsform wird, während ein Wert bestimmt wird, zunächst ein Rückschluss basierend auf Informationen versucht, die bereits gesammelt wurden (z. B. in dem instanziierten Modell 123 gespeicherte Informationen).
Falls der Wert nicht durch Rückschluss bestimmt werden kann, dann werden die Informationen von dem Nutzer abgefragt. In einer Ausführungsform werden dem Nutzer eine oder mehrere Aufforderungen präsentiert. In einer Ausführungsform wird eine "AskDetail"-Aufforderungen, die mit der aktuellen Enti tät (Teil der Aufforderung 127) verknüpft ist, präsentiert. Zum Beispiel enthält die Aufforderung für eine Personenentität die Frage "Was ist Ihr Geburtsdatum?". Als Antwort auf die Aufforderung gibt der Nutzer Informationen ein, die benutzt werden, einen Wert für ein Attribut der Entität zu bestimmen. In einer Ausführungsform werden die Informationen unter Verwendung einer "Add View" UI eingegeben. Dieser Vorgang wird für alle Attribute der Entität wiederholt.
Als nächstes werden verschiedene Schritte für jede spezialisierte Beziehung (die "derzeit mögliche Beziehung") durchgeführt, welche existieren können und welche die aktuelle Entität einbinden. Falls die Entität z. B. eine Personenentität ist, könnte sie in eine Ehepartnerbeziehung, eine Eltern/Kind-Beziehung und/oder eine "arbeitet-für"-Beziehung eingebunden werden. Diese Beziehungen können auf der Basis des Datenmodells 122 identifiziert werden. Man beachte, dass einige Beziehungen zwei spezialisierte Entitäten desselben Typs (z. B. zwei Personenentitäten) einbinden. Um die doppelte Betrachtung jeder dieser Beziehungen (einmal, wenn die derzeitige Entität die erste Entität bildet und wiederum, wenn die aktuelle Entität die zweite Entität bildet) zu vermeiden, werden in einer Ausführungsform nur solche Beziehungen, die berücksichtigt werden, herangezogen, bei denen die derzeitige Entität die erste ("Quell-")Entität ist, und nicht bei der die derzeitige Entität die zweite ("Ziel")Entität ist.
Eine Bestimmung wird in Bezug darauf gemacht, ob die derzeitige mögliche Beziehung, die die derzeitige Entität einbindet, existiert und die derzeitige Entität mit der Antwort 230 vermerkt ist. Diese Bestimmung ist ähnlich zu der oben beschriebenen "Erkennungs"-Phase. In einer Ausführungsform sind drei Antworten möglich: 1) existiert (die aktuelle mögliche Beziehung existiert), 2) existiert nicht (die aktuelle mögliche Beziehung existiert nicht) und 3) unbekannt (es ist unklar, ob die aktuelle mögliche Beziehung existiert). Falls die derzeit mögliche Beziehung existiert, wird sie zu einer als neue Beziehungsschlange (NRQ = New Relation Queue) 240 bezeichneten Reihe hinzugefügt.
Die Bestimmung kann auf Informationen, die von dem Nutzer empfangen wurden, oder auf Informationen, die von anderen Informationen abgeleitet wurden, basieren. In einer Ausführungsform, wenn diese Bestimmung durchgeführt wird, wird zunächst ein Rückschluss auf der Basis von Informationen, die bereits gesammelt wurden (z. B. in dem instanziierten Modell 123 gespeicherte Informationen), versucht.
Falls das Bestimmen durch Rückschluss nicht durchgeführt werden kann, dann werden die Informationen von dem Nutzer abgefragt. In einer Ausführungsform werden dem Nutzer eine oder mehrere Aufforderungen präsentiert. In einer Ausführungsform wird eine "AskExist"-Aufforderung, die mit der derzeit möglichen Beziehung (Teil der Aufforderungen 127) verknüpft ist, präsentiert. Für eine Ehepartnerbeziehung enthält die Aufforderung z. B. die Frage "Sind Sie verheiratet?". In einer anderen Ausführungsform wird eine "AskExist"-Aufforderung, die mit einem Ereignis (Teil der Aufforderungen 127) verknüpft ist, präsentiert. Dieses Ereignis könnte eines sein, welches, falls es auftritt, die derzeit mögliche Beziehung erzeugen würde. Für z. B. eine Ehepartnerbeziehung könnte das Ereignis eine Heirat sein und die Aufforderung könnte die Frage "Haben Sie kürzlich geheiratet?" enthalten. Als Antwort auf diese Aufforderung gibt der Nutzer Informationen ein, welche genutzt werden, um zu bestimmen, ob die derzeit mögliche Beziehung, welche die derzeitige Entität einbindet, existiert.
Als nächstes werden verschiedene Schritte für jede spezialisierte Beziehung (die "derzeit aktuelle Beziehung") in der NRQ durchgeführt. Anfänglich enthält die NRQ nur Beziehungen, die die Ankerentität einbinden. Jedoch können andere Beziehungen zu der NRQ in anderen Schritten des Ablaufdiagramms 200, wie unten erläutert wird, hinzugefügt werden.
Die derzeit aktuelle Beziehung wird instanziiert und zu dem instanziierten Modell 250 hinzugefügt. Ein Wert eines Attributs der spezialisierten Beziehung kann auf der Basis von Informationen, die von dem Benutzer aufgenommen wurden, oder auf der Basis von Informationen, die von anderen Informationen abgeleitet wurden, bestimmt werden. Diese Bestimmung ist ähnlich zu der oben beschriebenen "Untersuchungs"-Phase. Während des Bestimmens eines Wertes wird in einer Ausführungsform zunächst ein Rückschluss basierend auf Informationen, die bereits gesammelt wurden (z. B. in dem instanziierten Modell 123 gespeicherte Informationen), versucht.
Falls der Wert nicht durch Rückschluss bestimmt werden kann, dann werden die Informationen von dem Nutzer abgefragt. In einer Ausführungsform werden dem Nutzer eine oder mehrere Aufforderungen präsentiert. In einer Ausführungsform wird eine "AskDetail"-Aufforderung, die mit der derzeit aktuellen Beziehung (Teil der Aufforderungen 127) verknüpft ist, präsentiert. Für z. B. eine Ehepartnerbeziehung enthält die Aufforderung die Frage "Wann haben Sie geheiratet?". Als Antwort auf diese Aufforderung gibt der Nutzer Informationen ein, welche verwendet werden, einen Wert für ein Attribut der derzeit aktuellen Beziehung zu bestimmen. In einer Aus führungsform werden die Informationen unter Verwendung der "Add View" UI eingegeben. Dieser Vorgang wird für alle Attribute der Beziehung wiederholt.
Man erinnere sich, dass eine Beziehung mehrfache Entitäten einbindet. Da eine Bestimmung durchgeführt wurde, dass die Beziehung existiert, müssen andere Entitäten in der Beziehung (z. B. solche, die anders sind wie die derzeitige Entität) auch existieren. Diese anderen (spezialisierten) Entitäten werden zu der NEQ 260 hinzugefügt und werden, wie oben beschrieben, entsprechend bearbeitet. In einer Ausführungsform können die Schritte 250 und 260 in beliebiger Reihenfolge durchgeführt werden.
Man beachte, dass die obige Beschreibung des Ablaufdiagramms 200 nicht die Reihenfolge adressiert, in welcher 1) die spezialisierten Entitäten in der NEQ untersucht werden (z. B. beginnend mit dem Schritt 220), 2) die spezialisierten Beziehungen erkannt werden (z. B. beginnend mit Schritt 230) und 3) die spezialisierten Beziehungen in der NRQ untersucht werden (z. B. beginnend mit dem Schritt 250). Diese Reihenfolge basiert auf den oben beschriebenen Steuerflussinformationen 126. Bezüglich der Entitäten können z. B. die Steuerflussinformationen 126 spezifizieren, dass Personenentitäten vor Geschäftentitäten untersucht werden sollten. Bezüglich Beziehungen können die Steuerflussinformationen 126 spezifizieren, dass Ehepartnerbeziehungen vor "arbeitet-für"-Beziehungen erkannt werden sollten, jedoch dass Ehepartnerbeziehungen nach "arbeitet-für"-Beziehungen untersucht werden sollten.
Andere Ausführungsformen des Ablaufsdiagramms 200 basierend auf den Steuerflussinformationen 126 sind ebenfalls möglich.
Zum Beispiel können die Iterationszyklen zum Untersuchen der Entitäten, zum Erkennen der Beziehungen und zum Untersuchen der Beziehungen unterschiedlich definiert werden und dadurch den Fluss des Interviews beeinflusst. Wurde für eine (nicht gezeigte) Ausführungsform einmal eine Bestimmung durchgeführt, dass eine derzeit mögliche Beziehung existiert (Schritt 230), wird diese Beziehung eher sofort untersucht (Schritte 250 und 260), als dass für die Bestimmungen, die bezüglich der Existenz anderer möglicher Beziehungen gemacht werden, gewartet wird. In dieser Ausführungsform wird jede mögliche Beziehung sowohl für das Erkennen als auch das Untersuchen (falls diese Beziehung existiert) durchgeführt, bevor andere Beziehungen in Betracht gezogen werden.
Wurde für eine andere (nicht gezeigte) Ausführungsform eine Zielentität zu der NEQ (Schritt 260) hinzugefügt, dann wird diese Entität eher sofort untersucht (Schritt 220), als dass für die Untersuchung anderer aktueller Beziehungen gewartet wird (Schritt 250 und 260). In dieser Ausführungsform wird jede Entität sobald sie erkannt wurde untersucht.
Die 3A bis 3B veranschaulichen ein Ablaufdiagramm eines Verfahrens zum Überprüfen eines instanziierten Modells gemäß einer erfindungsgemäßen Ausführungsform. Bei dieser Ausführungsform führt der Interviewtreiber 135 die Schritte des Ablaufdiagramms 300 aus. Während das Ablaufdiagramm 300 beginnt, existiert bereits ein instanziiertes Modell 123.
In der in den 3A und 3b veranschaulichten Ausführungsform enthält das instanziierte Modell 123 nur eine Ankerentität. Das Ablaufdiagramm 300 beginnt, wenn die Ankerentität (eine instanziierte spezialisierte Entität) zu einer als ak tualisierte Entitätsschlange (UEQ = Update Entity Queue) 305 bezeichneten Reihe hinzugefügt wird.
Als nächstes werden verschiedene Schritte für jede instanziierte Entität (die "aktuelle Entität") in der UEQ ausgeführt. Anfänglich enthält die UEQ nur die Ankerentität. Jedoch können andere Entitäten zu der UEQ in anderen Schritten des Ablaufdiagramms 300, wie unten beschrieben, hinzugefügt werden.
Die derzeitige Entität wird aktualisiert 310. In einer Ausführungsform enthält das aktualisieren einer Entität 310 das Aktualisieren des Wertes (sofern erforderlich) eines der Attribute der Entität. Während des Bestimmens des aktualisierten Wertes wird in einer Ausführungsform zunächst ein Rückschluss basierend auf Informationen, die bereits gesammelt wurden (z. B. in dem instanziierten Modell 123 gespeicherte Informationen), versucht. Falls der aktualisierte Wert nicht durch Rückschluss bestimmt werden kann, dann werden die Informationen von dem Nutzer durch Präsentieren eines oder mehrerer Aufforderungen nachgefragt. In einer Ausführungsform wird eine "AskChange"-Aufforderung, die mit der derzeitigen Entität (Teil der Aufforderungen 127) verknüpft ist, präsentiert. Zum Beispiel enthält die Aufforderung für eine Personenentität die Frage "Haben Sie Ihren Namen gewechselt". In einer anderen Ausführungsform wird eine "AskExist"-Aufforderung, die mit einem Ereignis (Teil der Aufforderungen 127) verknüpft ist, präsentiert. Dieses Ereignis könnte z. B. eines sein, sofern es auftritt, welches ein Attribut der derzeitigen Entität ändern könnte. Zum Beispiel könnte für eine Personenentität das Ereignis eine Hochzeit (die zur Folge hat, dass das "Name"-Attribut wechselt) sein und die Aufforderung könnte die Frage enthalten "Haben Sie kürzlich geheiratet?". Als Antwort auf diese Aufforderung gibt der Benutzer Informationen ein, die verwendet werden, einen Wert eines Attributes der derzeitigen Entität zu aktualisieren. In einer Ausführungsform werden die Informationen unter Verwendung des "Edit View" UI eingegeben. Dieser Vorgang kann für mehrfache AskChange-Aufforderungen, AskExist-Aufforderungen und Attribute der Entität wiederholt werden.
In der eben beschriebenen Ausführungsform existiert jeweils nur eine Version von jeder instanziierten Entität (z. B. in dem Datenspeicher 105). In einer anderen Ausführungsform können gleichzeitig mehrfache Versionen derselben instanziierten Entität existieren. Diese Versionen können die instanziierte Entität während verschiedener Zeitperioden repräsentieren. In einer Ausführungsform enthält ein Element "Beginn"- und "Ende"-Attribute, die das Startdatum bzw. das Endedatum repräsentieren, zwischen welchen das durch die Entität modellierte Phänomen existiert. Die Entität enthält auch ein "Vergangenheit"-Attribut, welches die entsprechende Entität (sofern vorhanden) referenziert, die vor dem Beginndatum und einem "Zukunfts"-Attribut existierte, und welche die entsprechende Entität (sofern vorhanden) referenziert, die nach dem Endedatum existierte. Auf diese Art und Weise wird eine Entität mit anderen Versionen von ihr "verbunden".
In einer Ausführungsform, bei der mehrere Versionen derselben instanziierten Entität gleichzeitig existieren können, enthält das Aktualisieren einer Entität 310 Folgendes: Eine Bestimmung wird in Bezug darauf gemacht, ob ein Wert eines der Attribute der Entität geändert werden sollte. Falls der Wert geändert werden sollte, wird die Entität kopiert. Die nichtkopierte Entität wird dann aktualisiert mit einem neuen Wert für das Attribut. Die Kopie repräsentiert die Entität vor der Änderung, während die nichtkopierte Entität die Entität nach der Änderung repräsentiert. Die Werte des "Ende"-Attributes der Kopie und des "Beginn"-Attributes der Nichtkopie werden dann auf eine Zeitmarke gesetzt, die deren Gültigkeitsperioden widerspiegelt. Zusätzlich referenziert das "Zukunft"-Attribut der Kopie auf die Nichtkopie, während das "Vergangenheits"-Attribut der Nichtkopie auf die Kopie referenziert.
Als nächstes werden verschiedene Schritte für jede spezialisierte Beziehung, die in der derzeitigen Entität (der "derzeitigen Beziehung") vermerkt ist, durchgeführt. Man erinnere sich, dass, wenn das instanziierte Modell 123 erzeugt wurde (2), mögliche Beziehungen berücksichtigt wurden und die Entität mit ihren Existenzzuständen (Schritt 230) vermerkt wurde. Für jede Beziehung, die als "existiert nicht" oder "unbekannt" vermerkt wurde, wird eine Bestimmung in Bezug darauf gemacht, ob die Beziehung existiert (einschließlich der derzeitigen Entität), und die derzeitige Entität wird mit der Antwort 315 vermerkt. Falls die derzeitige Beziehung existiert, wird sie zu einer als NRQ (New Relation Queue) 320 bezeichneten Reihe hinzugefügt.
In einer Ausführungsform wird, um diese Bestimmung zu machen, zunächst ein Rückschluss basierend auf Informationen, die bereits gesammelt wurden (z. B. in dem instanziierten Modell 123 gespeicherten Informationen), versucht. Falls die Bestimmung nicht durch Rückschluss gemacht werden kann, dann werden die Informationen von dem Nutzer durch Präsentieren einer oder mehrerer Aufforderungen erfragt. In einer Ausführungsform wird eine "AskExist"-Aufforderung, die mit der derzeitigen Beziehung verknüpft ist (Teil der Aufforderungen 127), präsentiert. Für eine Ehepartnerbeziehung enthält die Aufforderung z. B. die Frage "Sind Sie verheiratet?". In einer anderen Ausführungsform wird eine "AskExist"-Aufforderung, die mit einem Ereignis (Teil der Aufforderungen 127) verknüpft ist, präsentiert. Dieses Ereignis könnte z. B. eines sein, welches, falls es auftritt, die derzeitige Beziehung erzeugen könnte. Für z. B. eine Ehepartnerbeziehung könnte das Ereignis eine Hochzeit sein und die Aufforderung könnte die Frage "Haben Sie kürzlich geheiratet?" enthalten. Als Antwort auf die Aufforderung gibt der Nutzer Informationen ein, welche benutzt werden, um zu bestimmen, ob die Beziehung existiert. In einer Ausführungsform werden die Informationen unter Verwendung einer "Edit View" UI eingegeben. Dieser Vorgang kann für mehrere AskExist-Aufforderung wiederholt werden.
Für jede Beziehung, die als "existiert" vermerkt ist, wird eine Bestimmung in Bezug darauf gemacht, ob eine Aktualisierung benötigt wird 325. In einer Ausführungsform, falls bestimmt wird, ob eine Aktualisierung erforderlich ist, wird zunächst ein Rückschluss basierend auf Informationen, die bereits gesammelt wurden (z. B. in dem instanziierten Modell 123 gespeicherte Informationen), versucht. Falls die Bestimmung nicht durch Rückschluss gemacht werden kann, dann werden die Informationen von dem Nutzer durch Präsentieren einer oder mehrerer Aufforderung erfragt. In einer Ausführungsform wird eine "ASkChange"-Aufforderung, die mit der derzeitigen Beziehung (Teil der Aufforderungen 127) verknüpft ist, präsentiert. Für z. B. eine Ehepartnerbeziehung enthält die Aufforderung die Frage "Gab es einen Wechsel in Ihrem Ehestand?". In einer anderen Ausführungsform wird eine "AskExist"-Aufforderung, die mit einem Ereignis (Teil der Aufforderungen 127) verknüpft ist, präsentiert. Dieses Ereignis könnte z. B. eines sein, dass, sofern es auftritt, ein Attribut der derzeitigen Beziehung ändern könnte. Für z. B. eine Ehepartnerbeziehung könnte das Ereignis eine gesetzliche Trennung sein und die Aufforderung könnte die Frage "Haben Sie eine gesetzliche Trennung durchgeführt?" enthalten. Als Antwort auf die Aufforderung gibt der Nutzer Informationen ein, welche verwendet werden, um zu bestimmen, ob eine Aktualisierung benötigt wird. In einer Ausführungsform werden die Informationen unter Verwendung einer "Edit View" UI eingegeben. Dieser Vorgang kann für mehrere AskChange-Aufforderungen und AskExist-Aufforderungen wiederholt werden.
Falls die Informationen der derzeitigen Beziehung (z. B. seine Attributswerte) aktualisiert werden sollten, wird die derzeitige Beziehung aktualisiert 330. In einer Ausführungsform enthält das Aktualisieren einer Beziehung 330 das Aktualisieren eines Wertes von einem der Attribute der Beziehung. In dieser Ausführungsform existiert jeweils nur eine Version jeder instanziierten Beziehung (z. B. in dem Datenspeicher 105). In einer anderen Ausführungsform können mehrere Versionen derselben instanziierten Beziehung gleichzeitig existieren. Diese Versionen können die instanziierte Beziehung während verschiedener Zeitperioden repräsentieren. In einer Ausführungsform enthält ein Element "Beginn"- und "Ende"-Attribute, die das Startdatum bzw. Endedatum repräsentieren, zwischen welchen das durch die Beziehung modellierte Phänomen existiert. Diese Beziehung enthält auch ein "Vergangenheit"-Attribut, welches die entsprechende Beziehung (sofern vorhanden), die vor dem Beginndatum existierte, referenziert, und ein "Zunkunfts"-Attribut, welches die entsprechende Beziehung (sofern vorhanden), die nach dem Endedatum existierte, referenziert. Auf diese Art und Weise wird eine Beziehung mit anderen Versionen von ihr "verbunden".
In einer Ausführungsform, bei der mehrere Versionen der selben instanziierten Beziehung gleichzeitig existieren können, enthält das Aktualisieren einer Beziehung 330 das Folgende: Eine Beziehung wird kopiert. Die nichtkopierte Beziehung wird dann mit einem neuen Wert für dieses Attribut aktualisiert. Die Kopie repräsentiert die Beziehung vor der Änderung, während die Nichtkopie die Beziehung nach der Änderung repräsentiert. Die Werte des "Ende"-Attributs der Kopie und des "Beginn"-Attributs der Nichtkopie werden auf eine Zeitmarke, die deren Gültigkeitsperioden reflektiert, gesetzt. Zusätzlich referenziert das "Zukunfts"-Attribut der Kopie auf die Nichtkopie, während das "Vergangenheit"-Attribut der Nichtkopie auf die Kopie referenziert.
Falls eine derzeitige Beziehung beendet wurde (z. B. eine Ehepartnerbeziehung wurde aufgrund einer Scheidung beendet), wird die derzeitige Beziehung entfernt 335. In einer Ausführungsform enthält das Entfernen der Beziehung 335 das Vermerken der derzeitigen Entität (und der Zielentität der Beziehung), um wiederzugeben, dass die Beziehung nicht länger existiert. Zusätzlich werden die "Beginn"- und "Ende"-Attribute der Entität auf eine Zeitmarke gesetzt, die deren Gültigkeitsperioden reflektiert.
In einer Ausführungsform wird die derzeitige Beziehung aus dem Datenspeicher 105 gelöscht. In dieser Ausführungsform werden Informationen in Bezug auf vergangene Beziehungen, die nicht mehr länger existieren, nicht beibehalten. In einer anderen Ausführungsform werden Informationen dieser Art beibehalten. Die "Beginn"- und "Ende"-Attribute der derzeitigen Beziehung werden auf eine Zeitmarke gesetzt, die die Gültigkeitsperiode der Beziehung reflektiert.
Falls keine Aktualisierung benötigt wird (z. B. die derzeitige Beziehung wurde nicht geändert), wird die instanziierte Zielentität der derzeitigen Beziehung zu der UEQ hinzugefügt. Auf diese Weise wird die Zielentität, wie oben beschrieben, ebenfalls aktualisiert 310.
Als nächstes werden verschiedene Schritte für jede spezialisierte Beziehung (die "derzeitige Beziehung") in der NRQ durchgeführt. Beziehungen werden zu der NRQ während des Schrittes 320 hinzugefügt. Diese Beziehungen wurden vorher als "existiert nicht" oder "unbekannt" vermerkt, wurden jedoch nun als existierend bestimmt (Schritt 315). Die derzeitige Beziehung wird instanziiert ("untersucht") und zu dem instanziierten Modell 345 hinzugefügt (siehe 3B). Zusätzlich wird seine spezialisierte Zielentität zu der NEQ 350 hinzugefügt. Die Schritte 345 und 350 (von 3B) sind vergleichbar zu den Schritten 250 und 260 (von 2), so dass deren Details hier nicht wiederholt werden sollen.
Als nächstes werden verschiedene Schritte für jede spezialisierte Entität (die "derzeitige Entität") in der NEQ durchgeführt. Entitäten wurden zu der NEQ während des Schrittes 350 hinzugefügt. Diese Entitäten waren Zielentitäten von neuen Beziehungen. Die derzeitige Entität wird instanziiert und zu dem instanziierten Modell 345 hinzugefügt. Für jede spezialisierte Beziehung, die einschließlich der derzeitigen Entität ("die derzeitige mögliche Beziehung") existieren könnte, wird eine Bestimmung in Bezug darauf gemacht, ob diese existiert, und die derzeitige Entität wird mit der Antwort 360 vermerkt. Falls die derzeitige Beziehung existiert, wird sie zu der NRQ 365 hinzugefügt. Jede spezialisierte Beziehung in der NRQ ("die derzeitig aktuelle Bezie hung") wird instanziiert und zu dem instanziierten Modell 370 hinzugefügt. Zusätzlich wird die spezialisierte Zielentität der derzeitigen aktuellen Beziehung zu der NEQ 375 hinzugefügt. Die Schritte 355, 360, 365, 370 und 375 (von 3B) sind ähnlich zu den Schritten 220, 230, 240, 250 und 260 (von 2), so dass deren Details hier nicht wiederholt werden sollen.
Nachdem jede spezialisierte Entität in der NEQ durchgeführt wurden (Schritte 355, 360, 365, 370 und 375), wird bestimmt, ob irgendwelche Beziehungen in der NRQ existieren, die noch nicht bearbeitet wurden. (Eine Beziehung hätte zu der NRQ während des Schrittes 365 hinzugefügt werden können). Falls dies so ist, kehrt das Ablaufdiagramm 300 zu den Schritten 345 und 350 zurück, um die unbearbeiteten Beziehungen zu bearbeiten. Dann werden beliebige Entitäten in der NEQ, die noch nicht bearbeitet wurden, bearbeitet. Diese Schritte (345, 350, 355, 360, 365, 370 und 375) wiederholen sich, bis alle Beziehungen in der NRQ und alle Entitäten in der NEQ bearbeitet wurden.
Man beachte, dass die obige Beschreibung des Ablaufdiagramms 300 nicht die Reihenfolge adressiert, in welcher 1) die instanziierten Entitäten in der UEQ aktualisiert werden (z. B. Schritt 310), 2) die als "existiert nicht" oder "unbekannt" vermerkten Beziehungen aktualisiert werden (z. B. Schritte 315 und 320), 3) die als "existiert" vermerkten Beziehungen aktualisiert werden (z. B. Schritte 325, 330, 335 und 340), 4) die spezialisierten Beziehungen in der NRQ untersucht werden (Schritte 345 und 350), 5) die spezialisierten Entitäten in der NEQ untersucht werden (z. B. beginnend mit Schritt 355), 6) die spezialisierten möglichen Beziehungen erkannt werden (z. B. beginnend mit Schritt 360) und 7) die spezialisierten aktuellen Beziehungen untersucht werden (z. B. beginnend mit Schritt 370). Diese Reihenfolge basiert auf den oben beschriebenen Steuerflussinformationen 126.
Andere Ausführungsformen des Ablaufdiagramms 300 sind ebenfalls möglich basierend auf den Steuerflussinformationen 126. Zum Beispiel können die Iterationszyklen zum Erkennen, Untersuchen und Aktualisieren der Entitäten und Beziehungen verschieden definiert werden und dadurch den Interviewfluss beeinflussen. In einer (nicht gezeigten) Ausführungsform, sobald eine Bestimmung gemacht wurde, dass eine derzeit mögliche Beziehung existiert (Schritt 360), dass diese aktuelle Beziehung eher sofort untersucht wird (Schritte 370 und 375), als dass für die Bestimmung, die mit Bezug auf die Existenz von anderen Beziehungen zu machen wird, gewartet wird. In dieser Ausführungsform wird jede mögliche Beziehung für sowohl das Erkennen und das Untersuchen (sofern die Beziehung existiert) bearbeitet wird, bevor eine andere Beziehung berücksichtigt wird.
In einer anderen (nicht gezeigten) Ausführungsform, sofern eine Zielentität einmal zu der NEQ (Schritt 375) hinzugefügt wurde, wird diese Entität eher sofort untersucht (Schritt 355), als dass für das Untersuchen von anderen aktuellen Beziehungen (Schritte 370 und 375) gewartet wird. In dieser Ausführungsform wird jede Entität, sobald sie erkannt wurde, untersucht.
4 zeigt ein Ablaufdiagramm beziehungsweise ein Flussdiagramm, welches darstellt, wie einige der in 1 dargestellten Komponenten gemäß einer Ausführungsform der Erfindung verwendet werden können. Bei einer Ausführungsform wird deren Anwendungsprogramm wie folgt ausgeführt: Ein Inter viewtreiber 135 erhält Informationen von dem Nutzer und erzeugt ein instanziiertes Modell 123. Ein Transformer 410 verwendet das instanziierte Modell 123 und die Applikationslogik 400 zur Erzeugung eines instanziierten applikationsspezifischen Modells 420. Schließilch erzeugt ein Dokumentenersteller 430 ein applikationsspezifisches Dokument 440 basierend auf dem instanziierten applikationsspezifischen Models 420. Dieser Prozess wird im Folgenden im Detail beschrieben.
Sobald der Interviewtreiber 135 ein instanziiertes Modell 123 erzeugt hat, kann die Information von dieser Domaine zu einer anderen Domaine (beispielsweise einem Finanzmodell, etwa einem Steuer- oder Buchhaltungsmodell) transformiert werden. Beispielsweise wird eine Vorbereitungsanwendung für eine Steuererklärung benutzt, um eine Steuererklärung vorzubereiten und bei einer bestimmten Anwendung wird eine Erklärung für einen bestimmten Steuerpflichtigen vorbereitet. Um dies durchzuführen muss die Anwendung alle Einkommensquellen und anwendbaren Abschreibungsmöglichkeiten des Steuerzahlers identifizieren.
Bezüglich des Datenmodells handelt es sich bei dem bestimmten Steuerzahler um eine Personenentität oder eine Geschäftsentität, wobei die Einkommensquellen und Abschreibungen Entitäten darstellen, (beispielsweise Vermögenswerte oder Verbindlichkeiten), die mit der Personenentität oder der Unternehmensentität über verschiedene Beziehungen (wie beispielsweise Besitzen oder Schulden) in Verbindung stehen. Die Verbindungen können "direkt" (beispielsweise entlang eines Pfades, welcher lediglich eine Beziehungskante enthält) oder "indirekt" sein (beispielsweise entlang eines Pfades, welcher einen oder mehrere Zwischenentitätsknoten und mehre re Beziehungskanten aufweist). Ein Beispiel für eine direkte Verbindung ist eine Vermögensentität, die mit einer Steuerzahlerentität über einen Pfad verbunden ist, welcher eine "Besitzen"-Beziehung aufweist. Ein Beispiel für eine indirekte Verbindung ist eine Vermögensentität, die mit einem Steuerzahler über einen Pfad verbunden ist, welcher eine "Besitzen"-Beziehung, eine Personenentität und eine Ehepartnerbeziehung aufweist.
Jede Finanzsoftware-Applikation hat ihr eigenes Mapping von dem Datenmodell zu dem geeigneten Finanzmodell, gleichgültig, ob die Applikation bzw. Anwendung auf dem Gebiet der Steuer, Buchhaltungs- oder Finanzmanagements liegt. Dieses Mapping korreliert ein Finanzkonzept (wie beispielsweise "Löhne" oder "Zinseinkommen") mit einem oder mehreren Datenmodellelementen und zeigt an, wie der Wert eines Konzepts nötigenfalls zu berechnen ist.
Der Transformer 410 erzeugt ein instanziiertes applikationsspezifisches Modell 420 basierend auf dem instanziierten Modell 123 und der Applikationslogik 400. Applikationslogik 400 bezieht ein instanziiertes Modell 123 auf ein spezifisches Modell der Zielanwendung, indem die Daten von dem instanziierten Modell 123 auf das Zielmodell gemapped bzw. abbildet werden. Es handelt sich bei dem Zielmodell um ein Finanzmodell, wie beispielsweise ein Steuer- oder Buchhaltungsmodell. Beim Mapping bzw. beim Abbilden werden Finanzregeln (beispielsweise Buchhaltungsregeln oder Steuergesetze) eingesetzt, um ein Konzept in dem Zielmodell mit einem oder mehreren Elementen des instanziierten Modells 123 zu korrelieren und um anzuzeigen, wie dieses Konzept nötigenfalls zu berechnen ist.
Beispiele für Finanzmodelle auf dem Gebiet des Steuerwesens umfassen staatliche und bundesstaatliche bzw. föderale Einkommenssteuern für Privatpersonen oder Unternehmen. Bei einer Ausführungsform umfasst das föderale persönliche Einkommenssteuer-Finanzmodell, Konzepte wie Steuerzahlungsentitäten (beispielsweise für Privatpersonen oder ein verheiratetes Paar), Einkommenstypen (beispielsweise Gehalt oder Zinsen) und Abschreibungs- bzw. Abziehungstypen (beispielsweise lokale Steuern oder Zinsen auf eine Hypothek). Bei einer persönliche Einkommenssteuervorbereitungsapplikation korreliert die Applikationslogik 400 diese Konzepte mit einem oder mit mehreren Elementen des instanziierten Modells 123 und gibt an, wie die Werte dieser Konzepte nötigenfalls zu berechnen sind.
Beispielsweise entspricht die Steuerzahlungsentität der Personenentität, die den Steuerzahler repräsentiert (in diesem Falle einen individuellen Steuerzahler) oder zwei Personenentitäten, die eine Ehepartner-Relation "Spouse" gemeinsam haben bzw. teilen (in diesem Falle ein verheiratetes Paar, welches gemeinsam ihre Steuererklärung abgibt). Die soziale Versicherungsnummer der steuerzahlenden- bzw. steuerpflichtigen Entität (die üblicherweise für eine Steuererklärung benötigt wird) entspricht dann dem Wert des Attributes eine Personenentität SSN (im Falle eines individuellen Steuerzahlers).
Eine Einkommensquelle entspricht beispielsweise einem Arbeitslohn (dargestellt als ein Lohnattribut oder eine Arbeitsbeziehung "WorkFor") oder Zinsen für ein Bankguthaben (repräsentiert durch eine Finanzvermögenswertentität, beispielsweise einer Sparguthabenvermögensentität). Falls die steuerzahlende Entität Einkommen von verschiedenen Quellen bezieht, ist das verdiente Gesamteinkommen die Summe dieser Beträge. In diesem Falle spezifiziert die Applikationslogik 400 sowohl 1) die entsprechenden instanziierten Elemente als auch 2) wie das finanzielle Konzept (hier das Gesamteinkommen) basierend auf diesen Elementen zu berechnen ist. (Bei dem oben stehenden Sozialversicherungsnummer-Beispiel ist die Sozialversicherungsnummer der steuerpflichtigen Entität bei dem instanziierten Modell 123 vorhanden, so dass keine Berechnung notwendig ist, um die Bestimmung vorzunehmen.) Wie oben bereits diskutiert, kann das instanziierte Modell 123 in einer beliebigen Form oder Datenstruktur ausgedrückt werden. In ähnlicher Weise kann das spezifische Modell in einer Zielapplikation in einer beliebigen Form oder Datenstruktur ausgedrückt werden, wobei es nicht notwendig ist, dass es in der gleichen Weise ausgedrückt wird wie das instanziierte Modell 123. Bei einer Ausführungsform können sowohl das instanziierte Modell 123 als auch das Zielmodell in XML ausgedrückt bzw. erstellt werden. XML beschreibt die Struktur des Modells einschließlich der dieses Modell bildenden Teile. Bei einer Ausführungsform wird XML spezifiziert unter Verwendung eines XML-Schemas gemäß der XML-Schema-Definitions-Sprache (XSD).
Anlage C1 enthält eine XSD-Sprache, die ein instanziiertes Modell 123 gemäß einer Ausführungsform der Erfindung spezifiziert. Hierbei enthält die XSD-Sprache verschiedene Elemente, beispielsweise Nachname "LastName", Geschlecht "Gender", Arbeitgeber "Employer" und Gehalt "Salary". Die XSD-Sprache enthält ferner verschiedene zusammengesetzte Typen, wir beispielsweise Personentyp "PersonTyp", Namenstyp "Name-Type" und Wohnorttyp "ResidenceType".
Anlage C2 enthält eine XSD-Sprache, die ein Zielfinanzmodell gemäß einer Ausführungsform der Erfindung spezifiziert. Diese Ausführungsform des Finanzmodells enthält eine föderale persönliche Einkommenssteuer und insbesondere ein IRS (Internal Revenue Service) Formblatt 1040. XSD enthält hier verschiedene Elemente, beispielsweise Nachname "LastName", Adresszeile "AddressLine" und Sozialversicherungsnummer "SSN". Die XSD enthält ferner verschiedene zusammengesetzte Typen, beispielsweise Einkommenstyp "IncomeType", "Line7Type" und Steuerzahlertyp "TaxPayerType".
Die Applikationslogik 400 spezifiziert wie ein instanziiertes applikationsspezifisches Modell 420 bei einem vorgegebenen instanziierten Modell 123 und einem applikationsspezifischen Ziel-Modell (beispielsweise einer föderalen persönlichen Einkommenssteuer) zu erzeugen ist. Bei einer Ausführungsform, handelt es sich bei der Applikationslogik 400 um ein XML-Dokument. Beispielsweise kann die Applikationslogik 400 ein XSL-Transformations(XSLT)-Dokument sein, das bei Ausführung (siehe auch unten bezüglich des Transformers 410) die Mapping-Funktion ausführt und ein instanziiertes applikationsspezifisches Modell 420 erzeugt.
Falls es sich bei der Applikationslogik 400 um ein XSLT-Dokument handelt, kann der Transformer 410 beispielsweise eine XSLT-Maschine sein. Bei einer alternativen Ausführungsform können die Applikationslogik 400 und der Transformer 410 zu einem einzigen Programm kombiniert werden, das das instanziierte applikationsspezifische Modell 420 basierend auf dem instanziierten Modell 123 erzeugt. Bei einer Ausführungsform verwendet der Transformer 410 eine XSLT-Transformation zur Durchführung des Mappings bzw. der Abbildung und der Berechnung. Die Transformationsregeln und/oder Berechnungen werden bei dem Mapping spezifiziert. Der Transformer 410 kann eine XSLT-Maschine enthalten, beispielsweise eine Xalan-Maschine (die einen Teil des ApacheXML-Projekts bildet) oder die Altova-XSLT-Maschine (die bei Altova^® Beverly, Messachusetts erhältlich ist).
Sobald ein instanziiertes applikationsspezifisches Modell 420 existiert, kann ein Finanzdokument (beispielsweise eine Steuererklärung oder eine Bilanz) erzeugt werden. Der Dokumentenersteller 430 erzeugt ein applikationsspezifisches Dokument 440 (beispielsweise ein Steuerformblatt oder einen Buchhaltungsbericht) basierend auf dem instanziierten applikationsspezifischen Modell 420, welches durch den Transformer 410 generiert bzw. erzeugt wird. Bei einer Ausführungsform ist das instanziierte applikationsspezifische Dokument 440 in einem Web-Format beschrieben (beispielsweise einschließlich verschiedener User-interface-Elemente) unter Verwendung des X-Form Standards. HTML (HyperText Markup Language) oder XHTML (eXtensible HyperText Markup Language) wird aus der X-Form Definition unter Verwendung der XSLT-Transformation erzeugt. Das HTML oder XHTML kann von einem Web-Browser geliefert werden.
Es sei angemerkt, dass eine Applikation nicht alle in 4 dargestellten Komponenten bei jeder Ausführung ausführen muss. Beispielsweise, falls ein Nutzer ein applikationsspezifisches Dokument 440 erzeugt hat und nunmehr ein anderes erzeugen möchte, muss die Anwendung nicht den Interviewtreiber 135 nochmals ausführen. Dies liegt daran, dass der Interviewtreiber 135 zur Erzeugung eines instanziierten Modells 123 vorgesehen ist und ein instanziiertes Modell 123 bereits existiert (es wurde benutzt, um ein erstes applikationsspezifisches Dokument 440 zu erzeugen). Der Interview treiber 135 muss lediglich dann ausgeführt werden, wenn kein instanziiertes Modell 123 existiert (beispielsweise zum ersten Mal wenn die Applikation abläuft) oder wenn ein instanziiertes Modell 123 existiert, jedoch modifiziert werden muss (beispielsweise wenn ein Phänomen, welches durch das instanziierte Modell 123 dargestellt wird, sich ändert).
Bei einer Ausführungsform (nicht gezeigt) enthält die Applikation auch eine Ablaufmaschine und/oder eine Dokumentenmanagermaschine. Die Ablaufmaschine beziehungsweise Ablaufplattform verwaltet den Fortschritt des Nutzers während des Interviews und des Dokumentenvorbereitungsprozesses und ermöglicht dem Nutzer zwischen verschiedenen Fragen (entweder vorwärts oder rückwärts) zu navigieren, eine aktuelle Sitzung zu speichern oder eine bereits gespeicherte Sitzung zu laden. Die Dokumentenverwaltungsmaschine speichert Nutzerinformationen (beispielsweise applikationsspezifische Dokumente 440 die bereits erzeugt wurden) und stellt Features bereit, wie beispielsweise Zugriffskontrolle, Versionsverwaltung und Editierung.
Design-Time-Tools
Wie bereits erwähnt, führt die Zeitablaufmaschine 110 eine Applikation bwz. Anwendung auf Grundlage der den in dem Datenspeicher bzw. der Datenbank 105 enthaltenen Inhalte durch. Daher können verschiedene Applikationen erzeugt werden, indem man die Inhalte der Datenbank 105 ändert.
Die Inhalte der Datenbank 105 können in verschiedenen Formen oder Datenstrukturen ausgedrückt werden. Falls die Inhalte in für Menschen leserlicher Form (beispielsweise als Source-Code oder XML) gespeichert sind, können sie direkt editiert werden, um eine bestehende Applikation zu modifizieren oder eine neue Modifikation zu erzeugen.
Sofern die Inhalte in für Menschen nicht leserlicher Form vorliegen (oder sofern eine direkte Editierung nicht erwünscht ist) kann ein Design-Tool erzeugt werden, um den Nutzer in die Lage zu versetzen (beispielsweise einen Applikationsdesigner oder Programmierer) Inhalte der Datenbank 105 zu erzeugen und/oder zu modifizieren. Bei einer Ausführungsform weist jeder Informationstyp, der in der Datenbank 105 gespeichert ist ein eigenes Design-Tool auf, welches es ermöglicht, die Information zu erzeugen und/oder zu modifizieren.
Beispielsweise wird bei einer Ausführungsform das Datenmodell 122 erzeugt und/oder modifiziert indem ein visueller Modellierer eingesetzt wird. Bei einer Ausführungsform liefert der visuelle Modellierer ein Drag-and-Drop Interface, so dass ein Nutzer spezifische Elemente definieren und/oder modifizieren kann (beispielsweise basierend auf den Elementen des Metamodells 121). Die spezialisierten bzw. spezifischen Elemente können dann für eine bestimmte Applikation bzw. Anwendung verwendet werden. Bei einer weiteren Ausführungsform enthält der visuelle Modellierer eine Bibliothek von spezialisierten bzw. spezifischen Elementen, die bereits definiert worden sind (durch den gleichen oder einen anderen Nutzer). Diese Bibliothek kann die spezifischen Elemente derart organisieren und unterteilen, dass sie einfacher aufzufinden sind, während der visuelle Modellierer benutzt wird. Beispielsweise kann die Organisation auf einem Finanzmodel (beispielsweise Steuer gegenüber Buchhaltung) und innerhalb des Modells auf verschiedenen Typen von Anwendungen basieren (beispielsweise Staat gegenüber Bundesstaat oder Persönlich gegenüber Geschäft). 5 zeigt eine Nutzerschnittstelle eines visuellen Modellierers gemäß einer Ausführungsform der Erfindung.
Bei einer Ausführungsform werden die Interview-Anweisungen 125 unter Verwendung eines Interview-Aufforderungs-Designers "interview prompt designer" und eines Interview-Ablauf-Designers "interview-flow-designer" erzeugt und/oder modifiziert. Bei einer Ausführungsform weist der Interview-Designer eine Bibliothek von Interview-Aufforderungsanweisungen (prompts) (einschließlich Dokumentenvorlagen und Variablen) auf, die definiert worden sind (durch den gleichen oder andere Nutzer). Die Bibliothek kann die Aufforderungsanweisungen (prompts) derart organisieren und aufteilen, dass sie während des Einsatzes des Interview-Promt-Designers leichter auffindbar sind. Beispielsweise kann das Organisieren basierend auf einem spezialisierten bzw. spezifischen Element (beispielsweise einer Personenentität) erfolgen und innerhalb dieses spezifischen Elements basierend auf unterschiedlichen Typen von Aufforderungsanweisungen (beispielsweise "AskExist", "AskDetail" und "AskChange"). Der Interviewablaufdesigner versetzt den Nutzer beispielsweise in die Lage, Entdeckungs- bzw. einen Bestimmungs- oder einen Untersuchungsablauf grafisch zu spezifizieren und Vorwärts- und Rückwärtsdurchlaufaktionen basierend auf Regeln und Bedingungen zu definieren. 6 zeigt eine Benutzerschnittstelle für einen Interview-Ablauf-Designer gemäß einer Ausführungsform der Erfindung.
Eine Nutzer-Interface-Information 128 wird erzeugt und/oder modifiziert unter Verwendung eines UI (user Interface) Komponentendesigners. Bei einer Ausführungsform stellt der UI-Komponentendesigner ein "what-you-see-is-what-you-get" (WY- SIWYG)-Interface bereit, so dass die zu designende Nutzer-Interface-Komponente dem Entwerfer bzw. Designer oder Nutzer derart präsentiert wird, als ob sie dem Endnutzer präsentiert wird. Bei einer weiteren Ausführungsform erhält der Nutzer-Interface-Komponentendesigner eine Bibliothek von UI (user interface)-Komponenten, die bereits definiert worden sind (durch den selben oder durch einen anderen Nutzer). Diese Bibliothek kann die Komponenten derart organisieren und aufteilen, dass sie leichter auffindbar sind, wenn der UI-Komponentendesigner benutzt wird. Beispielsweise kann die Organisation basierend auf einem spezifischen bzw. spezialisierten Element (beispielsweise einer Personenentität) erfolgen und innerhalb des spezifischen Elements basierend auf unterschiedlichen Funktionstypen (beispielsweise "Add View", "Edit View", "Detail View" und "Summary View"). 7 zeigt ein Benutzerinterface eines UI(user interface)-Komponentendesigners gemäß einer Ausführungsform der Erfindung.
Die Applikationslogik 400 wird erzeugt und/oder modifiziert unter Verwendung eines Modell-Mappers. Bei einer Ausführungsform stellt der Modell-Mapper ein grafisches Interface zur Verfügung, das den Nutzer in die Lage versetzt, einen Wert in einem Modell (beispielsweise dem Datenmodel 122) mit einem anderen Wert in einem anderen Modell (beispielsweise einem applikationsspezifischen Modell) zu korrelieren (bzw. zu mappen) und eine Berechnung zu spezifizieren. 8 zeigt ein Nutzerinterface eines Modell-Mappers gemäß einer Ausführungsform der Erfindung. Bei einer Ausführungsform nutzt der Modell-Mapper eine MapForce^TM Software-Applikation (die beispielsweise bei Altova^® Beverly Massachusetts erhältlich ist). Anlage D enthält einen XSLT-Code, der in einem Modell-Mapper erzeugt worden ist.
Die linke Seite des Userinterfaces zeigt ein Ursprungsmodell. Bei dem Ursprungsmodell handelt es sich hier um ein Datenmodell 122, welches eine Person darstellt, die einen Namen, ein Geburtsdatum, einen Wohnort und einen Beruf besitzt. Die rechte Seite des Nutzerinterfaces zeigt ein Zielmodell. Bei diesem Zielmodell handelt es sich um ein Finanzmodell (um das IRS-Format 1040), welches einen Steuerzahler darstellt, der einen Ehegatten und ein Einkommen hat.
Die Mitte der Nutzerschnittstelle zeigt die Korrelation zwischen dem Modell auf der linken und dem Modell auf der rechten Seite. Die Linie, welche die zwei Elemente verbindet (eins von jedem Modell) gibt an, dass die beiden Elemente miteinander in Beziehung stehen. Falls die Berechnung für ein Ursprungselement durchgeführt wird bevor dessen Wert zu einem Zielelement zugewiesen wird, wird die Berechnung in der Mitte der Nutzerschnittstelle dargestellt. Beispielsweise weist das ADDRLINE-Element des Ursprungmodells bzw. Entstehungs- oder Veranlassungsmodell (origination model) zwei Zeichenketten bzw. Strings (string1 und string2) auf. Diese Zeichenketten werden verknüpft und jede Zeichenkette dem Adressline-Element in dem Zielmodell zugewiesen. Es sei angemerkt, dass die Berechnungsvorgänge miteinander verkettet sein können. Beispielsweise das CITY- und STATEPROVN-Element in dem Ursprungsmodell werden verknüpft bzw. zusammengefügt, um die resultierende Zeichenkette zu bilden, wobei die Zeichenkette bzw. der String mit dem POSTALCODE-Element in dem Ursprungsmodell zusammengesetzt wird. Die letztendliche Zeichenkette wird dann dem CityStateZip-Element in dem Zielmodell zugewiesen.
Die Design-Zeit-Hilfsprogramme (Design-time tools) können auch eine Ablaufmaschine und/oder eine Finanzverwaltungsma schine aufweisen. Die Ablaufmaschine verwaltet den Fortschritt des Softwareteams während des Designs und der Implementierung der Software-Applikation und ermöglicht es Teile der Applikation zu prüfen, abzunehmen und auszuliefern. Die Inhaltsverwaltungsmaschine (content management engine) speichert Daten, welche der Softwareapplikation zugrunde liegen, beispielsweise einen Source-Code, Bilder und Modelle und stellt Features wie beispielsweise Zugriffskontrolle, Versionen-Verwaltung und Editierung zur Verfügung.
Beispiel: Finanzsoftware
Finanzsoftwareapplikationen, beispielsweise die Vorbereitung einer Steuererklärung, Buchhaltungs- und Finanzmanagement-Applikationen unterscheiden sich voneinander auf verschiedene Weisen. All diese Unterschiede haben ihre Ursache in der Tatsache, dass die Applikationen bzw. Anwendungen verschieden Primärfunktionen oder Zwecke haben. Während eine Applikation zur Vorbereitung einer Steuererklärung dazu benutzt werden kann, die Steuerschuld einer Person oder eines Unernehmens zu bestimmen, kann eine Buchhaltungsapplikation oder Finanzverwaltungsapplikation dazu eingesetzt werden, Vermögenswerte bzw. Aktiva und Verbindlichkeiten bzw. Passiva einer Person oder eines Unternehmens aufzufinden und zu analysieren. Die unterschiedlichen Zweckvorgaben führen dazu, dass die Applikationen verschiedene Typen von Finanzinformationen benötigen. Beispielsweise benötigt eine Steuererklärung Informationen über eine Person sowie über den Beruf und Arbeitgeber der Person während eine Buchhaltungsapplikation Informationen über ein Unternehmen sowie über die Kunden und Verkaufszahlen des Unternehmens benötigt.
Die verschiedenen Applikationen bzw. Anwendungen unterscheiden sich auch darin, wie sie Informationen im Zusammenhang des primären Zwecks der Applikation manipulieren bzw. aufbereiten. Beispielsweise kann eine Applikation zur Vorbereitung einer Steuererklärung einen Einkommensbetrag gegenüber Abschreibungsmöglichkeit klassifizieren, während eine Buchhaltungsapplikation einen Betrag eines Vermögenswertes gegenüber einer Verbindlichkeit klassifiziert. Applikationen bzw. Anwendungen unterscheiden sich darüber hinaus in dem Typ des erzeugten Finanzdokuments. Beispielsweise erzeugt eine Steuerapplikation eine Steuererklärung während eine Buchhaltungsapplikation eine Bilanz erzeugt.
Trotz all dieser Unterschiede weisen Finanzsoftwareapplikationen gemeinsame Eigenschaften auf. Sie erhalten Finanzinformationen, bereiten diese entsprechend einem Satz von Regeln auf und erzeugen Finanzdokumente. Falls diese Unterschiede der einzelnen Teile berücksichtigt werden, dann kann ein gemeinsamer Rahmen bzw. eine gemeinsame Plattform verwendet werden, um unterschiedliche Typen von Finanzsoftwareapplikationen zu erzeugen. Beispielsweise kann eine Datenmodellierungstechnik verwendet werden, um Informationen darzustellen, welche für Finanzsoftwareapplikationen benötigt werden. Informationen in dem Datenmodell können dann auf verschiedene Weise in Abhängigkeit von dem Zweck der Softwareapplikation (Steuer, Buchhaltung) aufbereitet werden. Schließlich können unterschiedliche Finanzdokumente erzeugt werden. Der oben beschriebene Rahmen kann eingesetzt werden, um unterschiedliche Typen von Finanzsoftwareapplikationen zu erzeugen, wobei das Datenmodell eines zugrundeliegenden Phänomens eingesetzt wird, welches für die jeweilige Applikation von Bedeutung ist.
Bei einer Ausführungsform wird die Information, welche durch eine Finanzsoftwareapplikation benötigt wird, durch eine Modellinformation 120 definiert, welche ein Metamodell 121, ein Datenmodell 122 und ein instanziiertes Model 123 aufweist. Das Metamodell 121 weist vier Elementtypen auf: Entitäten, Beziehungen, Regeln und Ereignisse. Das Datenmodell 122 weist spezialisierte bzw. spezifische oder applikationsspezifische Versionen dieser Elemente auf, wie im Weiteren noch ausgeführt wird.
Eine Entität stellt eine Person, einen Ort oder einen Gegenstand dar. Bei einer Ausführungsform weist das Datenmodell 122 folgende spezifische Entitäten auf nämlich, Person, Unternehmen, Wohnwort, Ort, Verbindlichkeit, Vermögenswert, Schule, Wohlfahrt, Regierung und medizinisches Institut. Andere spezifische Entitäten können basierend auf der Finanzsoftwareapplikation, die erzeugt wird, als geeignet definiert werden. Verschiedene Softwareapplikationen können verschiedene Entitäten des gleichen spezifischen Typs betreffen. Beispielsweise kann eine Steuererklärungsvorbereitungsapplikation eine Personenentität betreffen, welche einen individuellen Steuerzahler darstellt, und eine Unternehmensentität, welche einen Arbeitgeber darstellt, während eine Buchhaltungsapplikation eine Personenentität betreffen kann, welche einen Kunden darstellt, und eine Unternehmensentität, die einen Anbieter bzw. Verkäufer darstellt.
Unterschiedliche spezifizierte Entitäten können unterschiedliche Typen von Eigenschaften oder Attributen aufweisen. Bei einer Ausführungsform weist eine Personenentität die folgenden Attribute auf: Name, Geburtstag, Geschlecht, Familienstand, Staatsbürgerschaft und Sozialversicherungsnummer (SSN = social security number). Eine Geschäfts- bzw. Unterneh mensidentität weist folgende Attribute auf nämlich, Name, Gründungsdatum, Ort, Bundes-ID und Staats-ID.
Der Wert eines Attributs kann ein einfacher Datentyp (beispielsweise eine Zahl oder eine Zeichenkette) oder ein zusammengesetzter Datentyp sein, welcher mehrere Unterteile aufweist. Beispielsweise kann ein Adresswert (ein zusammengesetzter Datentyp) verschiedene Zeichenketten (beispielsweise eine Stadt oder Staat) und Zahlen (beispielsweise Postleitzahl) aufweisen. Ein Attributwert kann durch einen Nutzer angegeben werden, oder kann basierend auf anderen Informationen innerhalb des instanziierten Datenmodells 123 ermittelt oder abgeleitet werden. Beispielsweise kann der Familienstandwert (MarriageStatusValue) auf Grundlage der (Nicht-)Existenz einer Ehegattenrelation (siehe unten) ermittelt werden. Der Wert, welcher die abhängigen Familienmitglieder darstellt, kann aus der Anzahl von Abhängigkeitsbeziehungen (siehe unten) abgeleitet werden. Ein Nutzer kann einen abgeleiteten bzw. gefolgerten Wert überschreiben, indem er einen unterschiedlichen Wert eingibt. Falls dieser unterschiedliche Wert mit dem Rest des instanziierten Datenmodells 123 im Konflikt steht kann dem Nutzer eine Warnung mitgeteilt werden.
9 zeigt eine Tabelle spezifischer Entitäten und deren Charakteristika gemäß einer Ausführungsform der Erfindung. Eine „abgeleitete Entität" stellt einen Subtyp bzw. einen Untertyp einer spezifischen Entität dar. Beispielsweise kann eine Wohnortentität eine primäre Wohnortentität bzw. Hauptwohnortentität oder eine sekundäre bzw. Zweitwohnortentität sein. Die Verbindlichkeitsentität kann beispielsweise eine Hypothekenverbindlichkeitsentität, eine Autokreditverbind lichkeitsentität, eine Anleihenverbindlichkeitsentität oder ein persönlicher Kleinkredit sein.
Eine Beziehung stellt eine Verknüpfung zwischen verschiedenen Entitäten dar. Bei einer Ausführungsform weist das Datenmodell 122 die folgenden spezifischen Relationen auf, nämlich Ehepartner, Eltern/Kind, abhängige Person, Arbeitsverhältnis, Beziehung, Ausbildung, LiveIn, Station, Freiwilliger, Besitzen, Schulden, und Zahlen/Empfangen. Weitere spezifische Beziehungen bzw. Relationen können als geeignet definiert werden basierend auf der Finanzsoftwareapplikation, welche erzeugt wird, (beispielsweise Produkt, Anbieter und Lieferant). Verschiedene spezifische Relationen können unterschiedliche Eigenschaftstypen oder Attribute aufweisen. Beispielsweise besteht eine Ehegattenbeziehung zwischen zwei Personenentitäten und weist zwei Attribute (eine für jede Personenentität) auf. Der Wert für die Rolle der männlichen Person ist dabei „Ehegatte" und der Wert für die Rolle der weiblichen Person ist „Ehefrau". Eine Arbeitsbeziehung bzw. eine WorkFor-Relation besteht zwischen einer Personenentität und einer Unternehmensentität und hat die Attribute Berufstitel, Gehalt, Benefits, Ausgaben und Rolle (für jede Entität). Der Wert für die Rolle einer Personenentität ist „Angestellter" und der Wert für die Rolle der Unternehmensentität ist „Arbeitgeber". Ähnlich wie ein Entitätsattribut kann der Wert eines Beziehungsattributs ein einfacher Datentyp oder ein zusammengesetzter Datentyp sein. 10 zeigt eine Tabelle von spezifischen Beziehungen und deren Charakteristika bzw. Eigenschaften gemäß einer Ausführungsform der vorliegenden Erfindung.
Bei einer Ausführungsform wird das Datenmodell 122 als ein Entitäts-Beziehungs-Modell dargestellt und unter Verwendung eines ER (Entity-Relation) Diagramms visualisiert. 11 zeigt ein Entitäts-Beziehungs-Diagramm, welches ein Datenmodell gemäß einer Ausführungsform der Erfindung darstellt. Bei der dargestellten Ausführungsform wird eine Entität als ein Rechteck dargestellt und eine Beziehung als ein Oval gezeigt. Die dargestellte Ausführungsform weist vier Entitäten (zwei Personenentitäten 1110A, 1110B und zwei Unternehmensentitäten 1120A, 1120B) sowie drei Beziehungen (eine Ehegattenbeziehung 1130 und zwei Arbeitsbeziehungen 1140A, 1140B) auf.
Jede spezifische Beziehung hat eine spezifische Bedeutung. Diese Bedeutung kann in Abhängigkeit von relativen „Positionen" der Entitäten zu denen die Relation gehört unterschiedlich sein. Beispielsweise besteht eine Abhängigkeitsbezie hung zwischen zwei Personenentitäten 1110. Allerdings besteht keine Möglichkeit allein auf der Grundlage der Personentitäten 1110 festzustellen bzw. zu identifizieren welche Personenentität 1110 die Abhängige ist. Um Fälle wie diesen zu berücksichtigen kann eine Linie in einem ER-Diagramm bidirektional sein, wobei die Richtung die Bedeutung der Beziehung angibt.
Bei einer Ausführungsform wird ein bestimmtes Phänomen durch ein Element des Datenmodells 122, welches instanziiert worden ist, dargestellt (d. h. ein Element, welches einen Wert für eines oder mehrerer seiner Attribute enthält). Beispielsweise wird ein Steuerzahler durch eine instanziierte Personenentität repräsentiert. Die instanziierte Personenentität kann Attributwerte aufweisen, die dem Status des Steuerzahlers entsprechen, nämlich den Namen des Steuerzahlers, dessen Geburtsdatum und dessen Geschlecht. In ähnlicher Weise wird ein Beruf durch eine instanziierte Relation bzw. Ar beitsbeziehung dargestellt. Die instanziierte Arbeitsbeziehung kann Attributwerte aufweisen, die dem Status des Berufs entsprechen, beispielsweise den Berufstitel und das Gehalt.
Im Folgenden wird eine Applikation bzw. Anwendung zur Vorbereitung einer Steuererklärung betrachtet. Informationen, die relevant für eine Steuerverbindlichkeit einer Person oder eines Unternehmens sind, werden in instanziierten Entitäten und Beziehungen bzw. Relationen gespeichert. Falls die Entitäten als Knoten betrachtet werden und die Relationen als Kanten können diese instanziierten Entitäten und Relationen mit derjenigen Entität „verbunden" (im graphischen Sinne) werden, welche die Steuerverbindlichkeit der betreffenden Person oder des Unternehmens repräsentiert. Bei einer Ausführungsform kann die Steuerverbindlicheit einer Entität bestimmt werden, indem man lediglich die Informationen analysiert, welche in den Entitäten und Relationen gespeichert sind, welche mit der Zinsentität verbunden sind. Bei einer Ausführungsform betrifft die Ausführung der Finanzsoftwareapplikation das Durchlaufen eines Datenmodells bzw. „Graphs" (wie bereits oben ausgeführt).
Falls beispielsweise die Datenmodellelemente, wie sie in 11 dargestellt sind, instanziiert werden, kann das instanziierte Datenmodell 123 eine erste Person (Personenentität 1110A), eine zweite Person (Personenentität 1110B) Tatsachen über deren Eheverhältnis (Ehegattenverhältnis 1130) und Tatsachen über deren Berufe (Arbeitsrelation 1140A, 1140B) darstellen. Dieses instanziierte Datenmodell 123 kann beispielsweise dazu verwendet werden die Steuererklärung für die erste Person (Personenentität 1110A) vorzubereiten (selbstverständlich unter der Annahme, dass keine weiteren Einkommensquellen oder Abzugsmöglichkeiten bestehen). Die Informationen in dem instanziierten Datenmodell 123 können in Datenstrukturen abgespeichert werden. Beispielsweise können die Attributwerte für jedes Element beispielsweise einer Entität oder Beziehung bzw. Relation) in einer separaten Datenstruktur abgespeichert werden. Die Steuererklärungsvorbereitungssoftware kann auf die Datenstrukturen zugreifen (siehe oben), um die Steuerverbindlichkeit zu bestimmen und die Steuererklärung zu erzeugen.
Bei einer Ausführungsform besteht ein Phänomen bzw. eine Erscheinung, welche durch ein instanziiertes Element modelliert wird, im realen Leben und die Attributwerte des instanziierten Elements spiegeln hier den Zustand des im realen Leben bestehenden Phänomens wieder. Bei dieser Ausführungsform reflektiert das instanziierte Element die Realität. Es ist allerdings auch sinnvoll für ein instanziiertes Element nicht die Realität wiederzuspiegeln (beispielsweise als Teil einer hypothetischen Situation die für eine finanzielle Vorhersage ermittelt wird). Bei dieser Ausführungsform existiert das durch das instanziierte Element modellierte Phänomen nicht in der realen Welt (oder, falls das Phänomen doch existiert, können die Attributwerte des instanziierten Elements nicht den Zustand eines realen Phänomens wiedergeben).
Eine Regel stellt eine Restriktion für eine Entität oder eine Relation dar. Falls eine Entität oder eine Relation nicht seinen Regeln gehorcht ist sie nicht gültig. Bei einer Ausführungsform spezifisiert eine Regel für eine Entität wie der Wert eines bestimmten Attributs gewonnen werden kann. Beispielsweise, falls eine Personenentität 1110 ein Alter-Attribut aufweist, kann eine Regel spezifizieren bzw. angeben, dass der Wert dieses Attributs der Differenz zwischen dem „aktuellen" Zeitstempel (beispielsweise dem Datum an dem die Modellinformation gültig ist) und dem Attributwert des Geburtstages der Person entspricht. Bei einer weiteren Ausführungsform wird eine Regel dieser Entität angegeben, ob ein Wert eines bestimmten Attributs gültig ist. Beispielsweise kann eine Regel spezifizieren bzw. angeben, dass der wert des Altersattribut einer Personenentität den Wert 120 nicht überschreiten darf.
Eine Regel kann auch eine Verbindung zwischen einer Entität (beispielsweise ein Attribut) und einer Relation ausdrücken. Beispielsweise, falls eine Personenentität 1110 ein Familienstandattribut aufweist, kann eine Regel angeben, dass der Wert des Attributs „verheiratet" ist, falls eine Ehegattenbeziehung 1130 vorliegt und „unverheiratet" ist, falls die Ehegattenbeziehung 1130 nicht besteht. Bei einer weiteren beispielhaften Ausführungsform enthält das Datenmodell 122 folgende spezifische Regeln für die Ehegattenbeziehung 1130: Falls der Wert des Geschlechtsattributs einer zugehörigen Personenentität 1110 männlich ist dann ist der Wert des Geschlechtattributs der anderen zughörigen Personenentität 1110 weiblich (und umgekehrt). Falls bei dieser Ausführungsform eine Ehegattenbeziehung 1130 gerade festgestellt worden ist, kann daraus geschlossen werden, dass 1) eine zusätzliche Personenentität 1110 besteht (d. h. ein Ehegatte) und 2), dass die zusätzliche Personenentität 1110 einen Geschlechtsattributswert aufweist, der entweder weiblich (falls das Geschlechtsattribut der anderen Person männlich ist) oder männlich (falls der Wert der des Geschlechtsattributs der anderen Person weiblich ist). Weitere spezifische Regeln können basierend auf der Finanzsoftwareapplikation, welche erzeugt wird, als geeignet definiert werden.
Ereignisse im echten Leben können Auswirkungen auf Menschen, Orte und Dinge sowie auf Beziehungen zwischen diesen haben. Da diese Phänomene bzw. Ereignisse in einem instanziierten Datenmodell 123 dargestellt werden hat dies zur Folge, dass reale Ereignisse das instanziierte Datenmodell 123 beeinflussen. Bei einer Ausführungsform umfassen die Auswirkungen auf ein instanziiertes Datenmodell 123 auf Grund realer Ereignisse, Änderungen von Attributwerten von bestehenden Entitäten und Relationen, die Erzeugung von neuen Entitäten und Relationen sowie das Entfernen von bestehenden Entitäten und Relationen. Heiratet beispielsweise eine Person (ein Heiratsereignis) wird sich der Wert des Heiratsstatusattributs der zugehörigen Personenentität ändern und eine Ehegattenbeziehung 1130 wird erzeugt. Falls eine Person eine Gehaltserhöhung erhält (ein Leistungsänderungsereignis) kann sich der Wert des Gehaltsattributs der zugehörigen Arbeitsrelation ändern. Falls eine Person geboren wird (Geburtsereignis) wird eine Personenentität 1110 erzeugt und falls eine Person stirbt (ein Todesfallereignis) wird eine Personenentität 1110 entfernt. In ähnlicher Weise wird, falls ein Unternehmen eine Geschäftstätigkeit aufnimmt, eine Unternehmensentität 120 erzeugt, und falls ein Unternehmen seine Tätigkeiten einstellt, eine Unternehmensentität 1120 entfernt.
12 zeigt eine Tabelle von spezifischen Ereignissen und deren Eigenschaften gemäß einer Ausführungsform der vorliegenden Erfindung. Bei der dargestellten Ausführungsform gibt die Frequenzspalte an, wie oft ein Ereignis für die gleiche Personenentität auftreten kann. Beispielsweise kann ein Todesfallereignis oder ein Geburtsereignis nur einmal auftreten, weil eine Person nur einmal geboren und sterben kann. Ein Frequenzwert von „0..x" zeigt an, dass das Ereignis zwischen einmal und x-mal auftreten kann, wobei x eine positive ganze Zahl ist. Falls x * ist (beispielsweise ein Frequenzwert von 0..*) dann weist x keine Grenze auf und das Ereignis kann mehrmals oder unendlich oft auftreten.
Da sich die Welt bzw. die Umwelt über die Zeit verändert, kann sich ein instanziiertes Datenmodell 123, welches die Umgebung bzw. die Welt (und das zugehörige Diagramm) darstellt über die Zeit verändern. Auf diese Weise ist ein instanziiertes Datenmodell 123 für eine spezifische Zeitdauer gültig. Falls ein Ereignis eine Auswirkung auf ein instanziiertes Datenmodell 123 hat, wirkt das Ereignis als Verbindung zwischen zwei instanziierten Datenmodellen 123 nämlich jenes, welches die Umgebung bzw. die Welt vor dem Ereignis darstellt, und einem, welches die Welt bzw. die Umgebung nach dem Ereignis darstellt. Der Zeitpunkt an dem das Ereignis aufgetreten ist signalisiert das Ende der Gültigkeit des ersten Modells und den Beginn der Gültigkeit des zweiten Modells. Bei einer Ausführungsform weist jedes Ereignis einen zugehörigen Zeitstempel auf, welcher angibt, wann das Ereignis aufgetreten ist. Dieser Zeitstempel wird dazu benutzt beispielsweise anzuzeigen, wann die Gültigkeitsdauer eines vor dem Ereignis liegenden Modells endet oder eine Gültigkeitsdauer eines nach dem Ereignis liegenden Modells beginnt.
Im Folgenden betrachten wir nochmals das in 11 dargestellte instanziierte Datenmodell 123. Man nimmt ferner an, dass eine Steuervorbereitungsapplikation benutzt worden ist, um die Steuerverbindlichkeit einer ersten Person (Personenentität 1110A) zu bestimmen. Falls diese Person geschieden wird, wird die Ehegattenbeziehung 1130 entfernt, wodurch die Personenentität 1110B, die Arbeitsbeziehung 1140B und das Unternehmen 1120B von dem Datenmodellgraph für die Personen entität 1110A „getrennt" wird. Diese Trennung ist sinnvoll, da Informationen bezüglich der zweiten Person bezüglich des Berufs und des Arbeitgebers dieser Person im Weiteren keine Auswirkungen auf die Steuerverbindlichkeit der ersten Person haben.
Bezüglich der Ereignisse wäre das instanziierte Datenmodell 123, wie es in 11 dargestellt ist, bis zur Scheidung gültig und das oben beschriebene „getrennte" instanziierte Datenmodell 123 wäre ab der Scheidung gültig. Das Scheidungsereignis „verbindet" diese zwei instanziierten Datenmodelle 123 und signalisiert das Ende der Gültigkeit des ersten Modells sowie den Beginn der Gültigkeit des zweiten Modells.
13 zeigt ein Blockdiagramm mit Informationen bezüglich einer Ehegattenbeziehung bei einer Ausführungsform der vorliegenden Erfindung. In der dargestellten Ausführungsform wird eine Regel durch ein Oktagon dargestellt und ein Ereignis wird als Pfeil dargestellt. Wie oben beschrieben besteht die Ehegattenbeziehung 1130 zwischen zwei Personenentitäten 1110A, 1110B. Sie wird durch eine Heirat (ein Heiratsereignis 1300) erzeugt und durch eine Scheidung (ein Scheidungsereignis 1310) entfernt. Bei der dargestellten Ausführungsform weist die Ehegattenbeziehung 1130 zwei Rollenattribute und eine zugehörige Regel 1320 auf.
14 zeigt ein Blockdiagramm mit Informationen bezüglich einer Arbeitsbeziehung gemäß einer Ausführungsform der vorliegenden Erfindung. Wie oben beschrieben besteht eine Arbeitsbeziehung 1140 zwischen einer Personenentität 1110 und einer Unternehmensentität 1120. Sie wird generiert bzw. erzeugt, wenn eine Person eine Arbeit aufnimmt (StartJob- Ereignis 1400) und wird entfernt, wenn eine Person kündigt, gefeuert oder entlassen wird (EndJob-Ereignis 1410). Bei der dargestellten Ausführungsform weist die Arbeitsbeziehung 1140 zwei Attribute (Titel und Gehalt) auf. Wenngleich keine Regeln dargestellt sind besteht eine mögliche Regel darin, dass eine Person, die eine Arbeit hat, ein rechtlich zulässiges Arbeitsalter aufweisen muss (wobei das Alter der Person basierend auf dem Datenbereich des instanziierten Datenmodells 123 und dem Wert des Geburtsdatumsattributs der Personenentität bestimmt wird).
Bei einer Ausführungsform wird das Datenmodell 122 in einer ein Unified Modeling Language (UML) dargestellt und unter Verwendung eines UML-Diagramms visualisiert. 15 zeigt ein UML-Diagramm, welches ein Datenmodell bei einer Ausführungsform der vorliegenden Erfindung darstellt. Das UML-Diagramm kann man sich als Graph vorstellen, wobei Entitäten Knoten bilden und Relationen Kanten. Das Datenmodell enthält verschiedene spezifische Entitäten wobei einige von diesen zusammen in verschiedene Abstraktionsebenen unter Verwendung von Untertypen („abgeleitete Entitäten") gruppiert werden. Beispielsweise kann die Vermögenswertentität 1500 („besitzt" durch Personenentität 1110) eine Immobilienvermögenswertentität 1505 (beispielsweise ein Haus), ein Fahrzeugvermögenswertentität 1510 (beispielsweise ein Auto oder ein Boot) oder eine Finanzvermögenswertentität 1515 sein. Die Finanzvermögenswertentität 1515 kann beispielsweise ein Barguthabenvermögenswertentität 1525, eine Girokontovermögenswertentität 1520, eine Kapitalmarktgutenhabenvermögenswertentität 1530, eine CD-Guthabenvermögenswertentität 1535, eine Anlagefondvermögenswertentität 1540, eine Aktienvermögenswertentität 1545 oder eine Anleihenvermögenswertentität 1550 sein. In ähnlicher Weise kann eine Verbindlichkeitsentität 1555 („geschuldet" durch eine Personenentität 1110) eine Hypothekenverbindlichkeitsentität 1560, eine Anleihenverbindlichkeitsentität 1565, ein Fahrzeugkreditverbindlichkeitsentität 1570 oder eine persönliche Verbindlichkeitsentität 1575 sein. Weitere spezifische Entitäten, die in der Ausführungsform dargestellt sind, umfassen finanzielle Institutionen, Guthaben, Wohlfahrt, Regierungen, Erziehungsinstitutionen und Wohnorte.
Das Datenmodell 122 enthält viele spezifische Relationen, (die mit gestrichelten Linien dargestellt sind), wobei einige von diesen zusammen auf verschiedenen Abstraktionsebenen unter Verwendung von Untertypen ("abgeleitete Relationen") zusammengruppiert sind. Beispielsweise besteht eine Beziehungsrelation 1580 zwischen zwei Personenentitäten 1110, beispielsweise eine Eltern-Kind 1585, eine Ehegattenbeziehung 1130, eine Partnerschaft 1590 (beispielsweise eine Unternehemenspartnerschaft) und eine Abhängigkeitsbeziehung 1595. Eine Arbeitsbeziehung 1140 besteht zwischen einer Personenentität 1110 und einer Unternehmensentität 1120.
Falls eines oder mehrere Elemente des Datenmodells 122 instanziiert werden stellt das instanziierte Datenmodell 123 einen Zustand der Umgebung bzw. der Welt dar. Beispielsweise beschreibt es verschiedene Entitäten und Beziehungen zwischen zwei Relationen in graphischer Form. Der dargestellte Umgebungszustand kann über eine bestimmte Zeitperiode tatsächlich existieren oder hypothetisch sein.
15 zeigt ein UML-Diagramm einer Ausführungsform eines Datenmodells 122. Andere Ausführungsformen des Datenmodells sind ebenfalls möglich. Diese Ausführungsformen können unterschiedlich spezifische Entitäten und Relationen und/oder spezifische Entitäten und Relationen mit unterschiedlichen Attributen, Bedeutungen oder Regeln aufweisen. Möglicherweise können diese Ausführungsformen unterschiedlich spezifische Ereignisse und/oder spezifische Ereignisse mit unterschiedlichen Ausführungsformen und Bedeutungen aufweisen.
Bei einer Ausführungsform werden die Elemente des Meta-Modells 121 unter Verwendung der eXtensible Markup Language (XML) ausgedrückt. Beispielsweise kann der folgende XML-Code die Entität darstellen:
Zum Beispiel stellen die Eigenschaften "begin" und "end", das Startdatum und das Endedatum dar zwischen denen die Entität existiert. Die entsprechende Entität (sofern vorhanden), welche vor dem Startdatum existiert hat, wird als "vergangene" Eigenschaft bezeichnet während die entsprechende Entität (sofern vorhanden), welche nach dem Endedatum existierte als "zukünftige" Eigenschaft bezeichnet wird. Die vergangenen und zukünftigen Eigenschaften stellen eine Möglichkeit dar, um ein Element mit anderen Versionen des gleichen Elements zu "verbinden", wie bereits oben beispielsweise bezüglich der Schritte 310 und 330 in 3A erwähnt.
Wie bereits diskutiert, besitzt ein spezifisches Element eines Datenmodells 122 ein oder mehrere Attribute. Bei einer Ausführungsform wird ein spezifisches Element durch seine Attribute und Informationen bezüglich dieser Attribute definiert. Eine Information über ein Attribut kann beispielsweise einen Vorgabewert für das Attribut und die Validierungslogik aufweisen, welche bestimmt, ob ein Attribut korrekt ist und/oder ob es das richtige Format aufweist.
Wie ein Element des Meta-Modells 121 kann ein Element des Datenmodells 122 unter Verwendung von XML ausgedrückt werden. Während der Ablaufzeit kann die Finanzsoftwareapplikation auf diese Information zugreifen, um ein benötigtes Element eines Datenmodells 122 zu erzeugen und zu instanziieren. Bei einer Ausführungsform wird ein spezifisches Element als eine Erweiterung eines "generischen" Elements in dem Meta-Modell 122 ausgedrückt. Beispielsweise kann eine Personentität in dem Datenmodell 122 eine Erweiterung eines Entitätselements in dem Meta-Modell 122 ausgedrückt werden. Im Folgenden ist ein Beispiel für ein XML-Code angegeben, welcher eine Personentität darstellt:
Man betrachte eine weitere instanziierte Personenentität mit den folgenden Attributwerten: Name (Dr. John Jay Doe), Geburtsdatum (02/01/1950), Todesfalldatum (keines), Sozialversicherungsnummer SSN (123456789), Staatsangehörigkeit (USA). Die Entität kann folgenden XML-Code ausgedrückt werden:
Anlage E1 enthält einen XML-Code, welcher eine Entität aus dem Meta-Modell 121 darstellt oder eine spezifische Entität eines Datenmodells 122. Anlage E2 enthält einen XML-Code, welcher eine instanziierte spezifische Entität ausdrückt. Anlage F1 enthält einen XML-Code für Beziehungen und spezifische Relationen, während Anlage F2 einen XML-Code für in stanziierte spezifische Relationen aufweist. Anlage G1 enthält einen XML-Code für Ereignisse und spezifische Ereignisse, während Anlage G2 einen XML-Code für instanziierte spezifische Ereignisse aufweist.
Schließlich enthält die Anlage H1 einen XML-Code für Regeln während Anlage H2 einen XML-Code für instanziierte spezifische Regeln enthält. Bei einer Ausführungsform wird eine Regel unter Verwendung einer Rule Markup Language (RuleML) ausgedrückt. RuleML wird auch unter http://www.ruleml.org beschrieben und seine Spezifikation ist erhältlich unter http://www.ruleml.org/spec/.
Falls eine Softwareapplikation ein spezifisches Element benötigt, das nicht in dem Datenmodell 122 existiert, kann das spezifische Element erzeugt werden. In oben beschriebenen Ausführungsformen wird ein spezifisches Element des Datenmodells 122 unter Verwendung einer XML-Definition spezifiziert. Somit kann ein neues spezifisches Element definiert werden indem man eine andere XML-Definition generiert. Bei einer Ausführungsform ist das neue spezifische Element eine Erweiterung von einem der generischen Elemente des Meta-Modells 121.
Die vorliegende Erfindung wurde detailliert unter Bezugnahme auf verschiedene mögliche Ausführungsformen beschrieben. Fachleute erkennen ohne Weiteres, dass weitere Ausführungsformen der Erfindung möglich sind. Für die besondere Bezeichnung von Komponenten ist die Groß- oder Kleinschrift von Bezeichnungen, Attributen, Datenstrukturen oder sonstigen Programmier- oder strukturellen Aspekten nicht zwingend oder signifikant und die Mechanismen, welche die Erfindung mit deren Merkmalen implementieren, können unterschiedliche Namen, Formate oder Protokolle aufweisen. Ferner, kann ein System durch die Kombination von Hardware und Software oder ausschließlich durch Hardwareelemente implementiert werden. Die besondere Aufteilung der Funktionalität zwischen verschiedenen hier beschriebenen Systemkomponenten ist lediglich beispielhaft und nicht zwingend. Funktionen, die durch eine Einzelsystemkomponente ausgeführt werden, können auch durch verschiedene Komponenten ausgeführt werden. Funktionen, die durch verschiedene Komponenten ausgeführt werden können stattdessen auch durch eine Einzelkomponente ausgeführt werden.
Einige Abschnitte der obigen Beschreibung stellen die Merkmale der vorliegenden Erfindung anhand von Algorithmen und symbolischen Darstellungen von Informationsverarbeitungsschritten dar. Diese algorithmischen Beschreibungen und Darstellungen dienen dazu, Fachleuten auf dem Gebiet der Datenverarbeitung den Arbeitsinhalt anderen Fachleuten zu übermitteln. Diese Operationen wenn gleich funktionell und logisch beschrieben werden durch Computerprogramme implementiert. Darüber hinaus hat es sich manchmal angeboten diese Anordnungen und Operationen, Module oder durch ihre funktionalen Namen ohne Verlust der Allgemeinheit zu beschreiben.
Sofern nicht anders ausgeführt wird angemerkt, dass in der Beschreibung durchgehend Diskussionen, die Begriffe wie "Bestimmen" oder "Anzeigen" oder dergleichen, verwenden, sich auf Aktionen und Prozesse eines Computersystems oder ähnlicher elektronischer Vorrichtungen beziehen, welche Daten als physische (elektronische) Einheiten innerhalb eines Computersystemspeichers oder Registers oder sonstigen Informationsspeichern, Übertragungs- und Anzeigevorrichtungen, auswerten und transformieren.
Einige Aspekte der vorliegenden Erfindung enthalten Prozessschritte und darin enthaltene Befehle in Form eines Algorithmus. Es sei angemerkt, dass die Prozessschritte und Befehle der vorliegenden Erfindung in Software, Firmware oder Hardware ausgeführt werden können, wobei bei einer Ausführungsform in Software dieses Schrittes heruntergeladen werden können, um auch von verschiedenen Plattformen unter Verwendung eines Echtzeitnetzwerkbetriebssystems betrieben werden zu können.
Die vorliegende Erfindung betrifft auch eine Vorrichtung zur Durchführung der Operationen. Diese Vorrichtung kann spezifisch für den erforderlichen Zweck konstruiert sein oder einen Universalcomputer aufweisen, der selektiv aktiviert oder von einem Computerprogramm erneut konfiguriert wird, welches auf einem computerlesbaren Medium gespeichert ist, auf das der Computer Zugriff hat. Ein solches Computerprogramm kann auf einem computerlesbaren Speichermedium, beispielsweise (jedoch nicht darauf beschränkt) auf irgendeinem Träger, beispielsweise einer Floppy Disk, einer optischen Disk, einer CD-ROM, einer magnetisch-optischen Disk, einem ROM, einem RAM, EPROMs, EEPROMs, einer magnetischen oder optischen Speicherkarte, auf applikationsspezifischen integrierten Schaltkreisen (ASICs) oder auf jeglichem Medientyp gespeichert werden, der zur Speicherung elektronischer Befehle geeignet ist und mit einem Computersystembus verbunden ist. Darüber hinaus können Computer auf die die Beschreibung Bezug nimmt, einen Einzelprozessor oder Architekturen aufweisen die verschiedene Prozessordesigns für Erhöhung der Rechenfähigkeit verwenden.
Die hier beschriebenen Algorithmen und Operationen beziehen sich nicht auf einen bestimmten Computer oder sonstigen Apparat. Verschiedene Mehrzwecksysteme können Programmen entsprechend der hierin angegebenen technischen Lehre verwenden oder es kann sich anbieten, erfinderisch spezialisierte Apparate zur Durchführung der erforderlichen Verfahrensschritte zu konstruieren. Die erforderliche Struktur für eine Vielzahl dieser Systeme und entsprechende äquivalente Variationen sind für den Fachmann deutlich. Darüber hinaus ist die vorliegende Erfindung nicht bezüglich einer bestimmten Programmiersprache beschrieben. Es sei angemerkt, dass verschiedene Programmiersprachen zur Implementierung der technischen Lehre der vorliegenden Erfindung verwendet werden können und unter Bezugnahmen auf spezifische Sprachen zur Darstellung einer besten Ausführungsform der vorliegenden Erfindung gemacht sind.
Die vorliegende Erfindung ist geeignet für eine Vielzahl von Computernetzwerksystemen über unterschiedliche Topologien. Auf diesem Gebiet weist die Konfiguration und die Verwaltung solcher Netzwerke Vorrichtungen und Computer auf, die mit unterschiedlichen Computern und Speichervorrichtungen, ein Netzwerk, wie beispielsweise dem Internet, gekoppelt sind.
Schließlich wird darauf hingewiesen, dass die in der Beschreibung benutzte Sprache häufig zur besseren Lesbarkeit gewählt ist und nicht zur Abgrenzung und Umschreibung des erfindungsgemäßen Gegenstandes. Entsprechend ist die Offenbarung der vorliegenden Erfindung erläuternd und nicht einschränkend für den Schutzbereich der vorliegenden Erfindung, welcher in den beigefügten Patentansprüchen festgelegt ist. App. A
App. B
App. C1

App. C2

App. D

App. E1
App. E2

App. F1
App. F2

App. G1
App. G2
App. H1
App. H2
Zusammenfassung
Die vorliegende Erfindung betrifft ein computerimplementiertes System zum Modifizieren eines instanziierten Datenmodells, wobei das instanziierte Datenmodell eine oder mehr instanziierte spezialisierte Elemente enthält, wobei das System enthält: ein Datenmodell, welches ein nicht-instanziiertes spezialisiertes Element enthält; und einen Interviewtreiber, der so konfiguriert ist, einem Nutzer eine Aufforderung zu präsentieren, wobei die Aufforderung auf der Basis einer Position auf einem Graphen bestimmt wird und wobei der Graph das eine oder die mehreren instanziierten spezialisierten Elemente des instanziierten Datenmodells enthält.

Claims

Computerimplementiertes System zum Modifizieren eines instanziierten Datenmodells, wobei das instanziierte Datenmodell eine oder mehr instanziierte spezialisierte Elemente enthält, wobei das System enthält: ein Datenmodell, welches ein nicht-instanziiertes spezialisiertes Element enthält; und einen Interviewtreiber, der so konfiguriert ist, einem Nutzer eine Aufforderung zu präsentieren, wobei die Aufforderung auf der Basis einer Position auf einem Graphen bestimmt wird und wobei der Graph das eine oder die mehreren instanziierten spezialisierten Elemente des instanziierten Datenmodells enthält.
System nach Anspruch 1, bei dem ein Element eine Entität oder eine Beziehung enthält.
System nach Anspruch 1, mit einem Meta-Modell, welches ein generisches Element enthält, wobei das instanziierte spezialisierte Element vom Typ her dem generischen Elementes entspricht.
System nach Anspruch 1, bei dem der Interviewtreiber ferner so konfiguriert ist, ein instanziiertes spezialisiertes Element aus dem instanziierten Datenmodell zu löschen.
System nach Anspruch 1, wobei der Interviewtreiber ferner so konfiguriert ist, das nicht-instanziierte spezialisierte Element zu instanziieren und das instanziierte spezialisierte Element zu dem instanziierten Datenmodell hinzuzufügen.
System nach Anspruch 5, bei dem das nicht-instanziierte spezialisierte Element mit einer Elementenregel verknüpft ist und bei dem der Interviewtreiber ferner so konfiguriert ist, das nicht-instanziierte spezialisierte Elemente entsprechend der Elementenregel zu instanziieren.
System nach Anspruch 1, bei dem der Interviewtreiber ferner so konfiguriert ist, ein instanziiertes spezialisiertes Element zu modifizieren.
System nach Anspruch 7, bei dem das instanziierte spezialisierte Element mit einer Elementenregel verknüpft ist und bei dem der Interviewtreiber ferner so konfiguriert ist, das instanziierte spezialisierte Element entsprechend der Elementenregel zu modifizieren.
System nach Anspruch 7, bei dem der Interviewtreiber ferner so konfiguriert ist, einen Wert eines Attributes des instanziierten spezialisierten Elementes zum modifizieren.
System nach Anspruch 1, mit einer Regelmaschine und einem Regelset, wobei die Regelmaschine so konfiguriert ist, eine Regelverkettung auf der Basis des Regelsets auszuführen, und bei dem der Interviewtreiber ferner so konfiguriert ist, das instanziierte Datenmodell auf der Basis der Regelverkettung zu modifizieren.
System nach Anspruch 1, bei der der Interviewtreiber ferner so konfiguriert ist, das instanziierte Datenmodell auf der Basis von dem Nutzer empfangenen Informationen zu modifizieren.
System nach Anspruch 11, bei dem der Satz von Interviewanweisungen eine Aufforderung enthält und bei dem der Interviewtreiber ferner so konfiguriert ist, dem Nutzer die Aufforderung zu präsentieren.
System nach Anspruch 12, bei dem die Aufforderung mit dem nicht-instanziierten spezialisierten Element verknüpft ist.
System nach Anspruch 13, bei dem die von dem Nutzer aufgenommenen Informationen verwendet werden, um zu bestimmen, ob das nicht-instanziierte spezialisierte Element zu instanziieren ist.
System nach Anspruch 13, bei dem die von dem Nutzer empfangenen Informationen verwendet werden, die nicht-uninstanziierten spezialisierten Elemente zu instanziieren.
System nach Anspruch 13, bei dem der Satz von Interviewanweisungen Flussinformationen enthält und bei dem die Aufforderung auf der Basis ihres verknüpften nicht-instanziierten spezialisierten Elementes ausgewählt wird, wobei das nicht-instanziierte spezialisier te Element auf der Basis des instanziierten Datenmodells und der Flussinformationen ausgewählt wird.
System nach Anspruch 12, bei dem die Aufforderung mit einem instanziierten spezialisierten Element verknüpft wird.
System nach Anspruch 17, bei dem die von dem Nutzer empfangenen Informationen genutzt werden, das instanziierte spezialisierte Element zu modifizieren.
System nach Anspruch 17, bei dem der Satz von Interviewanweisungen Flussinformationen enthält und bei dem die Aufforderung auf der Basis seines assoziierten instanziierten spezialisierten Elementes ausgewählt wird, wobei das instanziierte spezialisierte Element auf der Basis des instanziierten Datenmodells und der Flussinformationen ausgewählt wird.
Computerimplementiertes Verfahren zum Modifizieren eines instanziierten Datenmodells, wobei das instanziierte Datenmodell eine oder mehrere instanziierte spezialisierte Elemente enthält, wobei das Verfahren enthält: Präsentieren einer Aufforderung an einen Nutzer, wobei die Aufforderung auf der Basis einer Position auf einem Graph bestimmt wird, wobei der Graph das eine oder die mehreren instanziierten spezialisierten Elemente des instanziierten Datenmodells enthält; Beschaffen von Informationen von dem Nutzer; und Modifizieren des instanziierten Datenmodells.
Computerimplementiertes Verfahren zum Erzeugen eines anwenderspezifischen Dokuments, enthaltend: Beschaffen von Informationen von einem Nutzer; Modifizieren eines instanziierten Datenmodells, wobei das instanziierte Datenmodell eine oder mehrere instanziierte spezialisierte Elemente enthält; Entwerfen eines instanziierten anwenderspezifischen Datenmodells auf der Basis des modifizierten instanziierten Datenmodells; und Erzeugen des anwenderspezifischen Dokumentes auf der Basis des instanziierten anwenderspezifischen Datenmodells.