-
GEBIET DER
ERFINDUNG
-
Die
vorliegende Erfindung betrifft ein Verfahren zum Entwickeln eines
Softwaresystems mittels der objektorientierten Technologie und Frameworks (Rahmenprogramme)
zum Entwickeln einer Geschäftsanwendung.
-
Die
vorliegende Patentanmeldung bezieht sich auf die folgenden gleichzeitig
anhängigen
Patentanmeldungen, die vom selben Anmelder am selben Tag eingereicht
wurden:
- – „A method
of developing a software system using Object Oriented Technology" (US-Patentschrift
6 106 569 von Kathryn Bohrer et al.)
- – „A method
for using decoupled chain of responsibility" (US-Patentschrift 6 499 064 von Brent
Carlson et al.)
- – „Framework
for business applications using cached aggregate and specification
key" (US-Patentschrift
6 134 706 von James Carey et al.)
- – „Software
business objects in a multi-level organizational structure" (US-Patentschrift
6 134 706 von James Carey et al.)
- – „Method
of error handling in a framework" (US-Patentschrift 6 052
525 von Brent Carlson et al.)
- – „A method
of locating software objects in different containers" (US-Patentanmeldung
US20020002632 von Anders Nilsson et al.)
-
BESCHREIBUNG DES STANDES
DER TECHNIK
-
Zur
Erhaltung oder Verbesserung ihrer Wettbewerbsfähigkeit müssen in der ganzen Welt Unternehmen
fast aller Geschäftsbereiche
ihre Datenverarbeitungstechnik erneuern und auf den neuesten Stand
bringen, um den Kundenanforderungen gerecht zu werden und dadurch
auf dem Markt erfolgreich tätig
zu sein. Ein mit herkömmlicher
Software ausgestattetes Datenverarbeitungssystem auf dem neuesten
Stand zu halten, ist zumindest ein aufwändiges Unterfangen und stellt
oft sogar ein unlösbares Problem
dar. Die objektorientierte Technologie oder einfach Objekttechnologie,
die oft als „OOT" oder einfach als „OT" abgekürzt wird,
verfügt über das
technische Potenzial zur Lösung
der mit der Entwicklung, der Pflege und Erweiterung von Softwareanwendungen
im Datennetz eines Unternehmens verbundenen Probleme und zur Gewährleistung
des Zusammenwirkens und der Anpassungsfähigkeit verschiedener Anwendungen
und Hardwareplattformen.
-
Als
objektorientierte Technologie wird ein Verfahren zur Entwicklung
von Betriebssystemsoftware wie auch Anwendungssoftware für ein Computersystem
beschrieben. Im Gegensatz zur herkömmlichen, nichtobjektorientierten
Softwareentwicklung zeichnet sich die objektorientierte Technologie
dadurch aus, dass sie zur Softwareentwicklung vorgefertigte „Methoden" und „Objekte" umfasst und verwendet,
welche mit Werkzeugen und Bauteilen zur Entwicklung eines Autos
verglichen werden können.
-
Ähnlich wie
bei der Entwicklung eines Autos, bei dem auch nicht jede benötigte Schraube
einzeln entwickelt wird, sondern Standardschrauben verwendet werden,
die jeweils durch Einkürzen
auf die nötige
Länge gebracht
werden, stellt die objektorientierte Technologie bei der Softwareentwicklung
eine „Klasse" als eine Art Softwarevorlage
zur Verfügung,
von der einzelne „Objekte" abgeleitet werden
können. Diese
Klassen werden normalerweise in einer Softwarebibliothek gespeichert,
die auch als „Klassenbibliothek" bezeichnet wird.
Eine Klassenbibliothek stellt einfach eine Sammlung verschiedener
Klassen dar, die zusammen mit einem speziellen Dateiformat gespeichert
werden; diese Sammlung wird als Bibliothek bezeichnet.
-
Bei
der objektorientierten Technologie ist unter einem „Objekt" eine in sich geschlossene
Softwareeinheit zu verstehen, die aus zugehörigen Daten und Prozeduren
besteht. Daten sind Informationen oder Speicherplätze in einem
Computerprogramm zur Speicherung von Informationen, z.B. ein Name oder
eine Inventarnummer. Prozeduren sind Teile eines Programms, welche
den Computer zu bestimmten Aktionen veranlassen, z.B. die Teile
eines Programms zum Ausführen
von Berechnungen oder der Teil eines Programms zum Speichern von
Daten auf einer Speicherplatte. Bei der objektorientierten Technologie
werden die Prozeduren eines Objekts als „Methode" bezeichnet.
-
Die
Idee von einem Objekt als in sich geschlossene Softwareeinheit mit
den dazugehörigen Daten
und Prozeduren stellt einen neuartigen Weg in der Softwareentwicklung
dar. Bei der nichtobjektorientierten Software ist der größte Teil der
Daten für
ein gesamtes Programm am Programmanfang zusammen aufgeführt, und
die Prozeduren bedienen sich aus dieser gemeinsamen Datensammlung.
Dieses herkömmliche
Verfahren funktionierte zwar ganz gut bei kleineren Programmen,
sobald jedoch eine Softwareeinheit größer und etwas komplexer wurde, konnte
man kaum noch erkennen, welche Prozedur welche Daten verwendet.
Dadurch wurden die Fehlersuche und Änderungen von herkömmlichen
Softwareprogrammen ziemlich schwierig und aufwändig.
-
Bei
der objektorientierten Technologie ist es im Allgemeinen einfacher,
Fehler in objektorientierter Software zu suchen sowie die Software
zu pflegen und zu erweitern. Die verbreitetsten objektorientierten
Programmiersprachen sind wahrscheinlich „C++", „JAVA" und „Smalltalk". Die Idee, sowohl
Daten als auch Methoden in einem Objekt unterzubringen, wird als „Kapselung" bezeichnet. Ein
Teil der Idee der Kapselung besteht darin, dass ein Objekt auf vorhersagbare
Weise mit anderen Objekten kommuniziert, also eine vorhersagbare „Schnittstelle", die mitunter auch
als Methodenvereinbarung bezeichnet wird.
-
Geht
man von einer unveränderten
Schnittstelle aus, können
der Code oder die Methoden im Objekt geändert werden, ohne dass die
Wechselwirkung anderer Objekte mit diesem Objekt beeinträchtigt wird.
Zum Beispiel hat ein Objekt STEUERBERECHNUNG eine vorhersagbare
Schnittstelle zur Verwendung durch GEHALTSZAHLUNG-Objekte. Bleibt
diese Schnittstelle unverändert,
kann der Programmcode im Objekt STEUERBERECHNUNG bei Änderungen
in der Steuergesetzgebung im Einzelnen verändert werden, wobei die anderen
Objekte im Lohnsystem keine Kenntnis von diesen Änderungen haben müssen.
-
Bei
der objektorientierten Technologie soll der Begriff „Vererbung" ausdrücken, dass
ein Objekt einen Teil seiner Verhaltensweisen und Daten von einem
anderen Objekt erben kann, wenn z.B. ein Arbeitnehmer ein Personentyp
ist, kann ein Objekt MITARBEITER sowohl Eigenschaften von einem
Objekt PERSON erben, zum Beispiel, dass es einen Namen, ein Geburtsdatum
und Adressdaten enthält,
als auch Methoden zum Aktualisieren und Anzeigen dieser Daten.
-
Obwohl
ein Objekt einige seiner Eigenschaften von anderen Objekten erbt,
kann und wird dieses Objekt normalerweise auch seine eigenen, nicht
vererbten Eigenschaften haben, z.B. kann ein Objekt PERSON zwar
eine vererbbare Methode zum Anzeigen der Adresse der Person enthalten,
höchstwahrscheinlich
aber keine Methode zum Anzeigen der bisher erhaltenen Gehaltszahlungen,
da nicht alle Personen Gehalt erhalten. Da ein Objekt MITARBEITER diese
Methode nicht von einem Objekt PERSON erben kann, muss es zum Anzeigen
der bisher erhaltenen Gehaltszahlungen eine eigene Methode definieren.
-
Obwohl
die objektorientierte Technologie das am weitesten entwickelte Verfahren
zur Entwicklung, Pflege und Erweiterung von Softwareanwendungen sein
dürfte,
scheuen viele mit der Softwareentwicklung befasste Unternehmen die
mit der Umstellung vorhandener Anwendungen und der Entwicklung neuer
Anwendungen mit Hilfe der objektorientierten Technologie verbundenen
Kosten und Risiken. Für diese
Entwickler von Softwareanwendungen muss eine technische Grundlage
für Softwareanwendungen
geschaffen werden, die als Werkzeug der objektorientierten Technologie
alle Entwickler bei der Entwicklung ganz neuer Softwareprodukte
unterstützt. Diese technische
Grundlage besteht aus Frameworks (Rahmenprogrammen), welche die
Grundstruktur der Anwendung umfassen, die bisher von den Entwicklern
der Softwareanwendung selbst entwickelt werden musste.
-
Bei
der objektorientierten Technologie dient der Begriff „Framework" zur Beschreibung
einer mehrfach verwendbaren Gruppe oder Sammlung von Klassen, die
zusammengenommen eine allgemein benötigte Funktionalität ergeben,
die von keiner der einzelnen Klassen im Framework bereitgestellt wird.
Somit definiert ein Framework eine spezielle Verfahrensweise zur
gemeinsamen Verwendung mehrerer Objekte bei der Bearbeitung einer
oder mehrerer Tasks, die von keinem der einzelnen Objekte geleistet
wird. Mit anderen Worten, ein Framework stellt ein mehrfach verwendbares,
vordefiniertes und vorgefertigtes Bündel mehrerer Objekte zur Bearbeitung
eines mehrfach auftretenden Programmierungsproblems dar.
-
Frameworks
gestatten eine mehrfach verwendbare Beziehung zwischen Objekten
festzuschreiben, sodass diese Objekte nicht immer wieder von Neuem
für dieselben
Beziehungen zusammengestellt werden müssen, wenn sie benötigt werden. Frameworks
ermöglichen
das Zusammenstellen mehrerer Objekte zu einer Gruppe, die eine Funktion ausführen kann,
die auf der Ebene der vorhandenen Einzelobjekte auf keinen Fall
möglich
wäre. Zum
Beispiel würde
ein Framework DRUCKEN aus allen Objekten bestehen, die ein Programmierer
benötigt,
um einfach etwas auf einem Drucker auszudrucken, und möglicherweise
Objekte zur Auswahl von Druckern, zum Hintergrunddrucken von der
Festplatte oder zur Fehlererkennung wie beispielsweise „Papier
alle". Ein Framework
kann als Gruppe von Softwareobjekten angesehen werden, die als technische Grundlage für eine Softwareanwendung
dienen können.
Dies kann Geschäftsbereiche
wie die Finanzbuchhaltung, die Logistik und den Vertrieb oder die
Produktion betreffen. Ein Framework stellt zwar das Grundgerüst einer
Softwareanwendung dar, ist normalerweise jedoch kein ausführbares
Softwareprogramm.
-
E.
GAMMA et al. geben in „Design
Patterns: elements of reusable object-oriented software", Addison-Wesley,
1995, ISBN 0-201-63361-2, eine brauchbare Einführung in die objektorientierte
Technologie im Allgemeinen sowie in die Entwicklung von Softwareelementen
im Besonderen, insbesondere in Bezug auf die vorliegende Erfindung.
-
Mit
Hilfe von Frameworks als technische Grundlage zur Entwicklung von
Softwareanwendungen sollen die folgenden Probleme gelöst werden:
Die
Anwendungen sollen alle wesentlichen Hardwareplattformen und entsprechende
Betriebssystemsoftware unterstützen,
die auf dem Markt verfügbar sind.
Die Anwendungen sollen den von Client-Server-Konfigurationen gestellten
Anforderungen einschließlich
den Anforderungen von grafischen Benutzeroberflächen und Fenstertechniken genügen. Ferner
sollen die Anwendungen kompatibel mit dem Internet sein und Direktzugriff
ermöglichen.
Außerdem sollen
die Anwendungen integrierte Lösungen
für die installierte
Software bieten.
-
Das
Kernstück
der meisten Geschäftsanwendungen
ist insbesondere das Hauptbuch (General Ledger). Eines der von einer
Geschäftsanwendung
schwieriger zu lösenden
Probleme besteht darin, wie mehreren unterschiedlichen Komponenten einer
Geschäftsanwendung,
z.B. Personal, Lagerverwaltung und Fertigung, die vielfach von verschiedenen
Entwicklern entwickelt worden sein können, der Zugang zum Hauptbuch
auf eine Weise ermöglicht wird,
die auf die speziellen Anforderungen jeder Komponente zugeschnitten
ist. Diese Aufgabe muss gelöst
werden, während
gleichzeitig mehrere Komponenten des Hauptbuchs, die ebenfalls von
verschiedenen Entwicklern entwickelt worden sein können, mit
dem Framework Hand in Hand arbeiten sollen. Das Framework muss auch
solche Anwendungen unterstützen,
die keine Komponente für
das Hauptbuch zur Verfügung
stellen, ohne dass die übrigen
Komponenten der Anwendung überhaupt
geändert
werden müssen.
-
Außerdem muss
ein Framework in der Lage sein, flexible Darstellungen einer Gruppe
von verschiedenartigen Artikeln zu unterstützen.
-
Zwischen
den zugehörigen
Zahlen werden zumindest teilweise Darstellungsstandards für Klassen,
Objekte, Beziehungen usw. verwendet, wie sie in „Object-Oriented Analysis
and Design with Applications" von
Grady Booch, zweite Auflage, The Bnejamin/Cummings Publishing Company,
Ind., Redwood City, CA, USA, beschrieben werden.
-
In
der Publikation „The
Promise of Distributed Business Components" von T.D. Kythe, AT&T Technical Journal, Bd. 75, Nr.
2, 1. April 1996, S. 20 bis 28, werden die Vorteile des Ersetzens
von individualisierter Software durch mehrfach verwendbare Komponenten
erörtert,
die einen Ausweg aus der Softwarekrise bedeuten können. Die
objektorientierte Programmierung liefert Erkenntnisse darüber, wie Komponenten
erstellt werden müssen.
Da Komponenten in verteilten Umgebungen und mit wohldefinierten
Schnittstellen eingesetzt werden müssen, werden als verteilte
Objektarchitekturen die Architekturmodelle Object Management Group
(Objektverwaltungsgruppe, OMG) und Common Object Request Broker
(Vermittlung für
allgemeine Objektanforderungen, CORBA) beschrieben, die mehrfach verwendbare
Komponenten unterstützen.
Für den Zugriff
auf Geschäftssoftware
und die in relationalen Datenbanken enthaltenen Daten ist ferner
noch eine Überwachungseinheit
für die
Transaktionsbearbeitung erforderlich. Die Komponenten bestehen aus objektorientierten
Frameworks, die auf Modelle des jeweiligen Problemkreises oder Geschäftsbereichs aufbauen.
-
AUFGABE DER
ERFINDUNG
-
Eine
Aufgabe der vorliegenden Erfindung besteht darin, eine technische
Grundlage für
die Entwicklung von Softwareanwendungen mittels der objektorientierten
Technologie bereitzustellen, durch welche die oben erörterten
Probleme beseitigt werden können.
-
Eine
weitere Aufgabe der vorliegenden Erfindung besteht darin, dass mehreren
unterschiedlichen Komponenten einer Geschäftsanwendung der Zugang zur
Komponente „Hauptbuch" auf eine Weise ermöglicht wird,
die auf die speziellen Anforderungen jeder Komponente zugeschnitten
ist.
-
ÜBERBLICK ÜBER DIE
ERFINDUNG
-
Die
vorliegende Erfindung löst
diese Aufgabe mit den Verfahren und der Vorrichtung, die in den beiliegenden
Hauptansprüchen
dargelegt sind. In den Unteransprüchen sind spezielle Ausführungsarten
der vorliegenden Erfindung beschrieben.
-
Insbesondere
stellt die vorliegende Erfindung ein Framework bereit, das zur Entwicklung
eines Softwaresystems, z.B. einer Geschäftsanwendung, verwendet wird,
wobei dieses Framework die Finanzbuchhaltung integriert und aus
den drei folgenden Hauptkomponenten besteht: Verwendung von Basisklassen
zur Integration von nicht finanzrelevanten Komponenten, von Basisklassen
zur Integration von finanzrelevanten oder Hauptbuchkomponenten und
einer allgemeinen Datenumwandlungseinheit.
-
Die
vorliegende Erfindung kann leicht an jede Komponente einer speziellen
Geschäftsanwendung
angepasst werden. Darüber
hinaus ermöglicht die
Erfindung den Datenabgleich zwischen den Komponenten auf jeder vom
Entwickler geforderten Komplexitätsstufe
und stellt eine allgemeine Datenumwandlungseinheit bereit, deren
Mechanismus voll funktionstüchtig
ist, ohne dass der Entwickler eingreifen muss. Diese Datenumwandlungseinheit
empfängt
die unterschiedlichen Daten, die von den anderen Komponenten des
Framework in Form von Exemplaren einer domänenspezifischen Klasse, zum Beispiel
der Typen „Artikel", „Kunde" oder „Lager" für eine Komponente
der Lagerverwaltung, geliefert wurden, und wandelt diese Daten in
eine Form um, die mit der Schnittstelle des Framework „Hauptbuch" kompatibel ist,
d.h. in Kategoriegruppen (Generic Dissection), die Kategorien von
Buchungssätzen (Generic
Posting Combination) enthalten, welche aus einem oder mehreren Exemplaren
von allgemeinen Analysecodes (Generic Analysis Code) bestehen, die
wiederum jeweils einer anderen allgemeinen Analysegruppe (Generic
Analysis Group) zugeordnet sind. Die Datenumwandlungseinheit arbeitet
auf unterster Ebene unabhängig
von allen Komponenten der Hauptbuchanwendung und ermöglicht so,
dass bei allen für
das Framework entwickelten Komponenten der Hauptbuchanwendung die
Basisfunktion einfach durch die höher entwickelte Funktion ersetzt werden
kann.
-
KURZBESCHREIBUNG
DER ZEICHNUNGEN
-
1 zeigt
ein Vierebenenschema, aus welchem mittels der vorliegenden Erfindung
eine Softwareanwendung entwickelt werden kann.
-
2 zeigt
die drei Hauptbereiche, aus denen das Framework „Finanzintegration" besteht.
-
3 zeigt
spezielle und standardmäßige Zuordnungsarten.
-
4 zeigt
den allgemeinen (generischen) Prozess der Journalerstellung.
-
5 zeigt
ein Beispiel für
die Zuordnung einer Analysegruppe zu einem bestimmten allgemeinen
Kategorietyp.
-
6 zeigt
ein komplexeres Beispiel mit zwei Typen von Kategoriegruppen, drei
Analysegruppen und drei Kontenarten.
-
7 zeigt
ein Beispiel, bei dem die in 6 definierten
Tabellen verwendet werden.
-
DETAILLIERTE BESCHREIBUNG
-
Die
unter Zuhilfenahme des Gegenstands der vorliegenden Erfindung als
Entwicklungswerkzeug entwickelten Softwareanwendungen lassen sich
in vier Schichten gemäß 1 darstellen.
-
Die
unterste Schicht ist die Basisschicht 101. Die Basisschicht 101 liefert
und verwaltet die Schnittstelle zur Server-Hardware 111,
auf der möglicherweise
unterschiedliche Betriebssysteme wie beispielsweise OS/2, OS/400,
AIX oder NT laufen können.
Die Server-Hardware ist über
ein Kommunikationsnetz 113 mit der Client-Hardware 112 verbunden. Auch
auf der Client-Hardware 112 können möglicherweise unterschiedliche
Betriebssysteme wie beispielsweise OS/2, NT oder AIX laufen. Die
in 1 dargestellte Ausführungsart zeigt nur den Serverteil einer
Client-Server-Anwendung.
-
Die
Basisschicht 101 stellt die technische Grundlage für die Objekte
der höheren
Ebenen dar, wozu viele dem Betriebssystem nahe stehende Funktionen
wie beispielsweise die Suche nach Objekten, das Verfolgen von Objektnamen,
die Zugangskontrolle zu Objekten, das Lösen von Konflikten, das Sicherheitsmanagement
und die Installation gehören.
Die Basisschicht 101 beinhaltet auch die so genannten Objektmodellklassen
(Object Model Class), die dem Softwareentwickler als einheitliches Modell
zum Erstellen von Objekten zur Verfügung stehen, ohne dass dieser
mit der Komplexität
der zugrunde liegenden Infrastruktur konfrontiert wird. Die Basisschicht 101 kann
als eine Art einfache Middleware angesehen werden, welche sich der
von der Basisschicht 101 zur Verfügung gestellten Schnittstellenfunktionalität bedient
und für
die Anwendung der über
dieser Basisschicht angesiedelten Objekttechnologie erforderlich
ist.
-
Oberhalb
der Basisschicht 101 liegt eine Schicht, welche allgemeine
Geschäftsobjekte 102 umfasst.
Diese Schicht der allgemeinen Geschäftsobjekte 102 liefert
eine große
Anzahl von Objekten, die in einer Geschäftsanwendung allgemein benötigte Funktionen
ausführen,
z.B. Datum und Uhrzeit, Währung,
Adresse, Maßeinheit
und Kalender. Diese allgemeinen Geschäftsobjekte stellen Bausteine
dar, aus denen der Softwareentwickler bei der Erstellung von Geschäftsanwendungen
auswählen
kann, wobei diese allgemeinen Geschäftsobjekte kopiert und erweitert
werden können,
um neue Funktionen auszuführen;
so kann zum Beispiel das Objekt „Datum und Uhrzeit" so erweitert werden,
dass es den chinesischen Kalender anwendet.
-
Die
oberhalb der Schicht 102 der allgemeinen Geschäftsobjekte
(Common Business Object) gelegene Schicht 103 umfasst bereits
die Kerngeschäftsprozesse
(Core Business Process) und kann als Schicht 103 der Kerngeschäftsprozesse
bezeichnet werden. Obwohl die Schicht 103 normalerweise noch
keinen ausführbaren
Code zur Verfügung
stellt, zeichnen sich die mit Hilfe der vorliegenden Erfindung entwickelten
Geschäftssoftwareanwendungen bereits
ab. Jede Schicht der Kerngeschäftsprozesse wird
für einen
bestimmten Anwendungstyp erstellt, zum Beispiel für das Hauptbuch
oder die Lagerverwaltung.
-
Diese
Schicht 103 der Kerngeschäftsprozesse kann als eine Art
höhere
Middleware angesehen werden, die zwar noch kein komplettes Programm
einer Softwareanwendung darstellt, aber bereits die Grundfunktionen
enthält,
welche von allen Anwendungsprogrammen dieses Typs benötigt werden. Aus
dieser Schicht 103 der Kerngeschäftsprozesse heraus entstehen
dann die Frameworks der Anwendungen, wobei einige der allgemeinen
Geschäftsobjekte
mit einer großen
Anzahl von Objekten verknüpft werden,
die für
den Typ des entstehenden Framework typisch sind, z.B. für die Lagerverwaltung.
Das entstehende Framework ist so aufgebaut, dass es Funktionen enthält, die
nicht nur allgemein genutzt werden, sondern auch einfach erweitert
werden können.
-
Ganz
oben auf dem oben beschriebenen Dreischichtenmodell befindet sich
die vom Entwickler geschaffene Softwareanwendung, die durch einen ausführbaren
Code gekennzeichnet ist. Ein Entwickler der Softwareanwendung kann
wählen,
ob er zur Entwicklung seiner Softwareanwendung nur die Basisschicht 101,
die Basisschicht 101 in Verbindung mit der Schicht 102 der
allgemeinen Geschäftsobjekte
oder alle drei Schichten 101, 102 und 103 zusammen
zur Entwicklung seiner Softwareanwendung nutzt. Auf jeden Fall muss
er einen Rest der Anwendung noch selbst entwickeln, sodass jedes
derart entstandene Programm einer Softwareanwendung ein ganz eigenes
Produkt ist.
-
Hierzu
ist zu bemerken, dass nicht der ausführbare Code der mit Hilfe der
vorliegenden Erfindung entwickelten Softwareanwendung 121 den
Gegenstand der vorliegenden Erfindung ausmacht, sondern das Dreischichtenmodell
mit den Schichten 101, 102 und 103.
-
2 zeigt
das Framework „Finanzintegration", welches die drei
Hauptabschnitte 201, 202 und 203 umfasst.
Der erste Abschnitt 201 ist eine Anzahl von Basisklassen,
die von der jeweiligen Quelle der Finanztransaktionen verwendet
werden. Der zweite Abschnitt 202 ist eine allgemeine Datenumwandlungseinheit,
welche die Spezialklassen im ersten Abschnitt 201 als eigene
abstrakte Basisklassen nutzt, um die entsprechenden interessierenden
Posten der jeweiligen Quelle den Posten in der Schnittstelle des
Hauptbuchs zuzuordnen. Der dritte Abschnitt 203 besteht
aus der Schnittstelle für
das Hauptbuch (General Ledger, GL), welche dafür sorgt, dass die Daten grundsätzlich zum
Hauptbuch durchgelassen werden.
-
Eine
Komponente einer Geschäftsanwendung,
welche das Framework „Finanzintegration" nutzen möchte, muss
zuvor eine Gruppe konkreter Klassen definieren, die von den Basisklassen
des Framework in Unterklassen eingeteilt werden. Die Funktion dieser
konkreten Klassen leitet sich vor allem von den Basisklassen des
Framework ab. Die domänenspezifischen
konkreten Klassen sorgen für eine
zusätzliche
Abgrenzung zwischen der Komponente der Geschäftsanwendung und dem Framework
und gestatten dem Entwickler, eine domänenspezifische Schnittstelle
zu definieren, die für
den Rest der Komponente von Bedeutung ist. Dadurch wird die Anwendung
des Framework während
der Entwicklung der Anwendung beträchtlich erleichtert.
-
Bei
einer Ausführungsart
der Erfindung können
die folgenden durch das Framework definierten Basisklassen vom Entwickler
der Komponente der Geschäftsanwendung
in Unterklassen eingeteilt werden:
-
AccountControlType:
-
Die
Basisklasse AccountControlType (Kontensteuerungstyp) gestattet dem
Framework, in der allgemeinen Datenumwandlungseinheit jede domänenspezifische
Klasse zu verwenden. Der Entwickler der Komponente der Anwendung
muss für
jede von der Datenumwandlungseinheit verwendete domänenspezifische
Klasse eine Unterklasse definieren. Dann wird der allgemeinen Datenumwandlungseinheit
ein Exemplar jeder der für
die Komponente definierten Unterklassen übermittelt. Die Datenumwandlungseinheit
behält
die Reihenfolge dieser Gruppe von Unterklassen bei und nutzt sie
während
des allgemeinen Zuordnungsprozesses.
-
DomainGenericIntegrationKey:
-
Der
Entwickler der Komponente der Anwendung erzeugt aus der Basisklasse
DomainGenericIntegrationKey (Domänenspezifischer
allgemeiner Integrationsschlüssel)
eine einzige Unterklasse. Diese Unterklasse wandelt die allgemeine
(generische) Schnittstelle „Integrationsschlüssel" (Integration Key) in
eine Schnittstelle um, die der domänenspezifischen Bezeichnungsweise
entspricht, z.B. setProduct, setWarehouse. Jede domänenspezifische Schnittstelle
der Unterklasse ist mit einer oder mehreren domänenspezifischen Unterklassen
der Basisklasse AccountControlType verbunden. Die Unterklassen der
Basisklasse AccountControlType dienen bei der Erstellung des während des
allgemeinen Zuordnungsprozesses verwendeten GenericKey (Allgemeiner
Schlüssel)
als Index.
-
GenericGLDissectionCreateTemplate:
-
Die
Unterklassen der Basisklasse GenericGLDissectionCreateTemplate (Vorlage
zum Erstellen einer allgemeinen Hauptbuchkategorie) dienen zum Abkapseln
aller vom Framework „Finanzintegration" zum Erzeugen einer
Klasse GenericDissection (Allgemeine Kategorie) benötigten Informationen. Jede
Unterklasse der Vorlage ist einem Exemplar von DomainGenericDissectionType
(Domänenspezifischer
allgemeiner Kategorietyp) zugeordnet, das die allgemeine Datenumwandlungseinheit
beim Verarbeiten der Vorlage benötigt,
um die richtige Untergruppe zum Zuordnen auszuwählen. Jede Unterklasse der
Vorlage gestattet dem Entwickler der Komponente der Anwendung, alle
zum Kategorisieren erforderlichen domänenspezifischen Informationen
zur Verfügung
zu stellen, wenn ein Exemplar der Unterklasse erzeugt wird. Die
Unterklasse führt
diese Informationen dann in einer Form zusammen, die mit der allgemeinen
Datenumwandlungseinheit kompatibel ist. Die Erstellung eines Schlüssels „Integration
Key" (Integrationsschlüssel) mit
Hilfe der oben beschriebenen domänenspezifischen
Unterklasse stellt einen Teil dieser Verarbeitung dar.
-
Die
Komponente der Geschäftsanwendung muss
ferner ein oder mehrere Exemplare der Klasse DomainGenericDissectionType
erzeugen und jedes Exemplar einer oder mehreren Unterklassen AccountControlType
zuordnen. Durch diese Zuordnung werden die domänenspezifischen Klassen definiert, die
für einen
bestimmten Kategorietyp von Interesse sind. Für jede durch die Komponente
der Geschäftsanwendung
definierte Unterklasse GenericGLDissectionCreateTemplate wird ein
Exemplar der Klasse DomainGenericDissectionType erzeugt.
-
Das
Framework „Finanzintegration" beinhaltet ferner
eine Gruppe von Basisklassen, welche die von der allgemeinen Datenumwandlungseinheit
verwendeten Schnittstellen unterstützt. Dies ermöglicht dem
Framework „Finanzintegration", auch ohne eine Komponente
der Anwendung „Hauptbuch" (General Ledger)
weiterzuarbeiten. Folgende Basisklassen werden vom Framework bereitgestellt:
-
GenericGLJournal
-
Die
Klasse GenericGLJournal (Allgemeines Hauptbuchjournal) stellt eine
Gruppe von Kategorien dar, die gleichzeitig im Hauptbuch gebucht
werden sollen. Damit ein Journal richtig gebucht werden kann, muss
die Summe der Debitorenkategorien gleich der Summe der Kreditorenkategorien
sein.
-
GenericDissection
-
Die
Klasse GenericDissection (Allgemeine Kategorie) stellt einen bestimmten
Geldbetrag dar (entweder Soll oder Haben), der als Teil eines Journals
im Hauptbuch verbucht werden soll. Sie enthält eine Klasse GenericPostingCombination
(Allgemeiner Buchungssatz) zusammen mit Mengen- und Wertangaben.
-
GenericPostingCombination
-
Diese
Klasse zeigt dem Hauptbuch an, dass in ihm eine Kategorie verbucht
werden soll, und besteht aus einem oder mehreren GenericAnalysisCodes
(Allgemeiner Analysecode).
-
GenericAnalysisGroup
-
Die
Klasse GenericAnalysisGroup (Allgemeine Analysegruppe) stellt eine
Gruppe ähnlicher
Unternehmenskategorien dar, z.B. Abteilung, Dienststellung, Kostenstelle,
die für
den Benutzer einer Anwendung „Hauptbuch" von Interesse sind.
Jedes Exemplar einer Gruppe wird durch einen GenericAnalysisCode
dargestellt.
-
GenericAnalysisCode
-
Diese
Klasse stellt eine bestimmte Unternehmenseinheit innerhalb einer
GenericAnalysisGroup dar. Exemplare dieser Klasse werden vom Benutzer definiert.
Während
der Installation des Framework „Finanzintegration" ordnet der Benutzer
ein Exemplar der Klasse GenericAnalysisCode einer Gruppe von Exemplaren
des domänenspezifischen
Objekts zu. Diese Exemplare des domänenspezifischen Objekts werden
aus den Klassen AccountControlType ausgewählt, die vom Benutzer als für die Kombination
der Klasse DomainGenericDissectionType und der Klasse GenericAnalysisGroup
wichtig angesehen wurden. Diese Zuordnungspaare bilden den Kern
der Informationen, welche das Framework „Finanzintegration" bei der Bearbeitung
von Finanztransaktionen nutzt.
-
Das
Framework „Finanzintegration" kann zwar auch ohne
eine Komponente der Anwendung „Hauptbuch" arbeiten, dennoch
muss die Anwendung eine solche Komponente bereitstellen, damit eine
sinnvolle Bearbeitung der Finanztransaktion ausgeführt werden
kann. Eine Komponente des Hauptbuchs kann leicht in das Framework
integriert werden, indem einfach die Objekterstellungseinheit des
Framework so konfiguriert wird, dass die oben aufgeführten allgemeinen
Klassenversionen durch die von der Komponente „Hauptbuch" bereitgestellten Klassen ersetzt werden.
Andere das Framework „Finanzintegration" nutzende Komponenten
und sogar das Framework selbst bekommen diesen Austausch der Klassen
nicht mit, da alle zur Ausführung ihres
Anteils in der Task „Finanzintegration" erforderlichen Funktionen
auf der allgemeinen Ebene der Basisklasse definiert sind.
-
Auch
vererbte nichtobjektorientierte Hauptbuchanwendungen können so
in dieses Framework integriert werden. Die für eine solche Integration verwendeten
Unterklassen werden so definiert, dass sie eine Zuordnung zwischen
den allgemeinen (generischen) Schnittstellen des objektorientierten
Framework und den von der vererbten Anwendung mitgebrachten Prozedurschnittstellen
herstellen.
-
Die
von der vorliegenden Erfindung definierte allgemeine Datenumwandlungseinheit
bietet in ihrem Kern einen allgemeinen Zuordnungsprozess, der die
Exemplare der von den Komponenten des Framework definierten domänenspezifischen
Klassen den Exemplaren der von den nutzenden Komponenten des Framework
definierten, für
das Hauptbuch spezifischen Basisklassen zuordnen kann. Dieser Zuordnungsmechanismus
liefert für
jede nutzende Komponente extra Exemplare, sodass jede Komponente
die Freiheit hat, unabhängig
ihre eigenen Zuordnungsregeln zu definieren, ohne Störungen durch
andere Komponenten der Anwendung befürchten zu müssen; ferner ermöglicht der
Zuordnungsmechanismus der nutzenden Komponente das Definieren einer
beliebigen Anzahl von Kategorietypen, die jeweils einer beliebigen
Anzahl von der Zuordnungseinheit verwendeter domänenspezifischer Klassen zugeordnet
werden können,
und außerdem ermöglicht der
Zuordnungsmechanismus dem Benutzer der Anwendung, die Verwendung
beliebig vieler durch die nutzende Komponente definierter domänenspezifischer
Klassen zuzulassen, indem der Benutzer diese Klassen mit den Exemplaren
der zuvor vom ihm definierten Klasse GenericAnalysisGroup koppelt
und bestimmte Kombinationen der Exemplare der domänenspezifischen
Klassen den vom Benutzer für
die Klasse GenericAnalysisGroup definierten Exemplaren der Klasse
GenericAnalysisCode zuordnet.
-
Die
Zuordnungseinheit stellt auch einen allgemeinen Journalerstellungsprozess
zur Verfügung, der
die von der Komponente der Anwendung gelieferten allgemeinen Transaktionen in
einer kompakten Form zusammenfasst, die mit der Komponente der Hauptbuchanwendung
kompatibel ist, welche dem Framework „Finanzintegration" zugeordnet ist.
-
Der
allgemeine Zuordnungsprozess muss in der Lage sein, mit domänenspezifischen
Klassen zu arbeiten, ohne deren Typ oder Inhalt zu kennen, weil das
Framework sonst unzulässig
mit einer speziellen Ausführungsform
der Domäne
gekoppelt und die Erweiterung des Framework auf neue Domänenbereiche
umständlich
würde.
-
Dies
ist ein vorrangiges Problem des Framework, für welches die vorliegende Erfindung
eine Lösung
bereitstellt. Ein von den Frameworks der vorliegenden Erfindung
definierter Mechanismus „AccessKey/Keyables" (Zugangsschlüssel/domänenunspezifischer
Schlüssel)
gestattet dem Framework „Finanzintegration", ohne Unterschied
mit jeder domänenspezifischen
Klasse zu arbeiten.
-
Bezüglich AccessKey
siehe die verwandte Patentanmeldung „Access Key Objects", eingereicht im
Europäischen
Patentamt, Anmeldungsnummer 97 119 950.0, Anmeldedatum 14. November
1997. Eine Klasse „Zugangsschlüssel" betrifft einen Zugangsschlüssel zum
Zugreifen auf einen Posten in einer Tabelle, und eine Klasse der
Komponente „Zugangsschlüssel" betrifft spezielle
Komponenten des Zugangsschlüssels.
Jede dieser speziellen Komponenten weist eine Anzahl von Einträgen auf,
wobei jedes Objekt „Zugangsschlüssel" genau einen aus
der Gesamtzahl von Einträgen
jeder der speziellen Komponenten in einer bestimmten Folge enthält.
-
Eine
Kategorie „Keyable" (domänenunspezifischer
Schlüssel)
stellt eine Klasse „Zugangsschlüssel" und eine Klasse
der Komponente „Zugangsschlüssel" dar, welch Letztere
diese Klasse „Zugangsschlüssel" von den Exemplaren
der domänenspezifischen
Klasse abgrenzt.
-
Jeder
für eine
Anwendungskomponente interessanten domänenspezifischen Klasse ist
eine Kennung (ID) zugewiesen, die stets als Unterklasse der Frameworkklasse
AccountControlType geführt
wird und dem Framework „Finanzintegration" bekannt ist, sowie
eine Position innerhalb des von der Zuordnungseinheit verwendeten „Allgemeinen
Schlüssels" (Generic Key). Wenn
das Framework eine domänendefinierte
Kategorie verarbeitet, wird jedes Exemplar einer domänenspezifischen
Klasse in einen allgemeinen domänenunspezifischen
Schlüssel
(Generic Keyable) aufgenommen und an die zuvor definierte Position
im allgemeinen Schlüssel
gesetzt. Dieser Schlüssel
kann während
des Zuordnungsprozesses dieser Kategorie verwendet werden. Sobald
das Exemplar auf diese Weise untergebracht worden ist, können die
domänenspezifischen
Zuordnungsdaten unterschiedslos verarbeitet werden, während nach der
Gruppe der benutzerdefinierten Analysecodes (Analysis Codes) gesucht
wird, welche den Buchungssatz für
diese Kategorie bilden.
-
Jeder
von einer nutzenden Anwendungskomponente definierte Kategorietyp
beschreibt die domänenspezifischen
Attribute durch eine Liste von Exemplaren der Unterklasse AccountControlType, welche
vom allgemeinen Zuordnungsprozess verwendet werden können. Während der
Konfigurierung der Anwendung muss der Benutzer der Anwendung angeben,
welche der vorhandenen Attributtypen beim Zuordnungsprozess Verwendung finden
werden, sowie die für
diese Installation gültigen
besonderen Zuordnungen.
-
Gemäß 3 können Zuordnungen
entweder für
einen bestimmten Kategorietyp 312 und die AnalysisGroup 311 definiert
werden, also als spezielle Zuordnung 301, oder einfach
nur für
eine AnalysisGroup 311, also als eine für alle Kategorietypen geltende
Standardzuordnung 302, wenn ein erfolgreicher Vergleich
mit einer speziellen Zuordnung Kategorietyp/AnalysisGroup fehlt.
Jede dieser vom Benutzer angegebenen speziellen Zuordnungen wird genau
so in AccessKeys eingeschlossen wie die Eingabewerte der domänenspezifischen
Kategorien während
des normalen Betriebs der Anwendung. Wenn also das Framework auf
diese Weise konfiguriert wird, läuft
der Umwandlungsprozess automatisch ab und kann im Framework unterschiedslos durchgeführt werden,
indem Exemplare von GenericKey verglichen werden.
-
4 zeigt
den allgemeinen Zuordnungsprozess als Teil des allgemeinen Prozesses
zur Journalerstellung, der von der Datenumwandlungseinheit unterstützt wird.
Zu dem Zeitpunkt, da die domänenspezifische
Anwendungskomponente ein Exemplar 401 der Kategorievorlage
erzeugt, sind weder der Zuordnungsprozess noch der Umwandlungsprozess abgeschlossen.
Diese Exemplare werden vielmehr vom Framework „Finanzintegration" aufgenommen und
so lange aufbewahrt, bis die Anwendung den allgemeinen Prozess 402 zur
Journalerstellung startet. Beim ersten Schritt dieses Prozesses
wird ausgehend von einer konfigurierbaren Bearbeitungsstrategie
eine Untergruppe von Kategorievorlagen ausgewählt, beispielsweise ausgehend
von einer durch die Anwendungskomponente während der Erzeugung der Kategorievorlage
bereitgestellten speziellen Kennung JournalCreationId. Dann wird
jede Vorlage in dieser Untergruppe bearbeitet, indem zuerst der
allgemeine Zuordnungsprozess abgeschlossen wird, was zur Entstehung
von GenericPostingCombination führt,
und anschließend
aus GenericPostingCombination und den restlichen in der Vorlage
verbliebenen Informationen ein GenericDissection erzeugt wird. Nach
dem Erstellen von GenericDissection kann dieses in GenericJournal 403 eingefügt werden,
das für diese
Untergruppe von Kategorievorlagen erzeugt worden ist. Nachdem alle
Kategorievorlagen auf diese Weise bearbeitet worden sind, wird GenericJournal
gebucht und somit die Bearbeitung des Framework Finanzintegration
abgeschlossen.
-
5 zeigt
ein Beispiel einer Zuordnung einer Analysegruppe zu einem bestimmten
allgemeinen Kategorietyp. In diesem Fall steht für den allgemeinen Kategorietyp
der LAGERBESTAND 501, der dem Finanzteil der Anwendung
eine Änderung
des aktuellen Lagerbestands anzeigt. Die Zielfinanzanwendung stellt
ihre Konten in kleineren Untereinheiten dar. Jede dieser Untereinheiten
wird als Analysegruppe (Analysis Group) bezeichnet und widerspiegelt
einen für
den Benutzer interessanten Aspekt. Eine typische Analysegruppe wäre die Abteilung 502. Die
einzelnen Werte innerhalb einer Analysegruppe werden als Analysecodes 503 bezeichnet.
Die Analysegruppe „Abteilung" beispielsweise kann
solche Analysecodes wie beispielsweise UMSATZ (SALES), KONSTRUKTION
(ENGINEERING) usw. enthalten. Somit besteht ein Konto aus einer
Gruppe von Analysecodes, wobei jeweils ein Code zu einer Analysegruppe
gehört.
-
Bei
diesem speziellen Beispiel ist nur die Analysegruppe 2 – ABTEILUNG 502 dargestellt.
Für die
Analysegruppe 2 wird nur die Kontenart für Lager 506 verwendet. 5 zeigt,
dass das Lager „BB001" 507 dem
Analysecode „BB" 504 zugeordnet
ist. Wenn also die allgemeine Kategorie für die Warenart verwendet und
als Kontenart des Lagers „BB001" angegeben wird,
erhält
man den für
die Analysegruppe 2 verwendeten Analysecode „BB".
-
6 zeigt
ein komplexeres Beispiel mit zwei Kategoriearten (Bestandsänderung 607 und
Lagerbestand 608), drei Analysegruppen (1 = Hauptkonto 609,
2 = Abteilung 610 und 3 = Ware 611) sowie drei
Kontenarten (Ware 612, Lager 613 und Kostenart 614).
Die Tabelle 601 zeigt einen Sonderfall, bei dem unabhängig davon,
welche Kontenart verwendet wird, für die Analysegruppe ein bestimmter Analysecode
zu verwenden ist. In diesem speziellen Fall wird immer der Analysecode „4550" verwendet. Die Tabellen 602, 603 und 605 entsprechen
der oben beschriebenen 5. Die Tabelle 606 zeigt,
dass nicht alle möglichen
Analysegruppen verwendet werden müssen und in der Tabelle 606 für die (nicht
verwendete) Analysegruppe 3 für
diesen Kategorietyp kein Analysecode wünschenswert ist. Die Tabelle 604 zeigt
einen Fall, bei dem mehr als nur eine Kontenart verwendet wird.
In diesem speziellen Fall werden die Kontenarten „Kostenart" 614 und „Ware" 612 verwendet.
Somit wird für
eine Kostenart „CNS01" (normal) 615 und
eine Ware „BFTR01" (DREIRAD) 616 der
Analysecode „1512" 617 verwendet.
-
7 zeigt
ein Beispiel für
die Verwendung der in 6 definierten Tabellen. Bei
diesem Beispiel werden für
jeden Kategorietyp die Werte für
die angegebenen Kontenarten dazu verwendet, die entsprechenden zum
Erstellen des Kontos erforderlichen Analysecodes zu ermitteln, um
Informationen zur Finanzanwendung zu liefern.