(57)【特許請求の範囲】
【請求項１】
ビジネス・アプリケーションのソフトウェア・システムを開発するために使用される、財務統合フレームワークを有するフレームワークを含むコンピュータ・システムであって、前記フレームワークは、サーバをして、
製品クラス、倉庫クラス、顧客クラス、在庫タイプ・クラスを含むベース・クラスのセットと、
少なくとも１つの汎用分析コードのクラスのインスタンスを含む汎用台帳インタフェースと、
使用される非財務コンポーネントを使用して定義される領域固有クラスのインスタンスを、領域汎用統合キーを参照して前記汎用台帳インタフェースへとインタフェースし、領域汎用統合キーが配置される汎用キーを含む汎用データ変換エンジンとを構成させ、
前記ベース・クラスは、領域固有クラスを識別させるためのアカウント・コントロール・タイプ・クラスおよび汎用統合キー・クラスを生成させ、
前記汎用データ変換エンジンは、汎用台帳インタフェースに対して前記汎用データ変換エンジンの前記汎用キーを参照することにより、領域固有クラスの内容の明示的な知識の使用を回避させながら領域固有クラスのマッピングを実行させる、
フレームワークを含むコンピュータ・システム。
【請求項２】
ベース・クラスは、さらに汎用ジャーナル・クラス、汎用解析クラス、汎用記入組合わせクラス、汎用分析グループ・クラス、別々の汎用分析グループに伴われる汎用分析コード・クラスを含む、
請求項１記載のコンピュータ・システム。
【請求項３】
請求項１または２に記載のフレームワークを記憶するコンピュータ可読な記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、オブジェクト指向技術を使用してソフトウェア・システムを開発する方法およびビジネス・アプリケーションを開発するためのフレームワークに関する。
【０００２】
本出願は、同じ出願人によって同じ出願日に出願された以下の同時係属出願に関連する。
【０００３】
「A  method  of  developing  a  software  system  using  Object  Oriented  Technology」（出願人ドケット番号ＧＥ９９７０３４）
「A  method  for  using  decoupled  chain  of  responsibility」（出願人ドケット番号ＧＥ９９７０３５）
「Framework  for  business  applications  using  cached  aggregate  and  specification  key」（出願人ドケット番号ＧＥ９９７０３９）
「Software  business  objects  in  a  multi-level  organizational  structure」（出願人ドケット番号ＧＥ９９７０４０）
「Method  of  error  handling  in  a  framework」（出願人ドケット番号ＧＥ９９７０４１）
「A  method  of  locating  software  objects  in  different  containers」（出願人ドケット番号ＧＥ９９７０４２）
【０００４】
【従来の技術】
競争力を維持または拡大するため、世界中のほぼあらゆる業種の企業が、自社の情報技術を手直しおよび更新して、顧客の要求を満たし、ひいては市場で成功を収めなければならない。しかし、従来的に開発されたソフトウェアに基づく情報システムを最新に維持することは、費用のかかる試みであり、多くの場合、解決不可能な問題である。オブジェクト指向技術または単にオブジェクト技術（略して「ＯＯＴ」または単に「ＯＴ」ともいう）は、会社の情報システム内でソフトウェア・アプリケーションの開発、維持および拡張に伴う問題を解消し、多数のアプリケーションおよびハードウェア・プラットフォームにまたがる相互運用性および適応性を提供する技術的可能性を有している。
【０００５】
オブジェクト指向技術は、コンピュータ・システムのオペレーティング・ソフトウェアおよびアプリケーション・ソフトウェアの開発方法を記述する。従来的な非オブジェクト指向のソフトウェア開発方法とは逆に、オブジェクト指向技術は、自動車開発の場合の工具および部品にたとえられる、ソフトウェアの開発のためにあらかじめ設計された「メソッド」および「オブジェクト」を含み、使用する。
【０００６】
必要なねじそれぞれを個々に開発するのではなく、標準化されたねじを使用し、それを所要の長さに切り詰めることによって個々に適合させることができる自動車開発の場合と同様に、ソフトウェアの開発でも、オブジェクト指向技術は、ソフトウェア・テンプレートの１種として「クラス」を提供し、このクラスから個々の「オブジェクト」をインスタンス生成することができる。これらのクラスは普通、ソフトウェア・ライブラリまたはいわゆる「クラス・ライブラリ」に格納される。クラス・ライブラリとは、単に、ライブラリと呼ばれる特殊なファイリング・フォーマットでいっしょに格納されるいくつかのクラスの集合体である。
【０００７】
オブジェクト指向技術において、「オブジェクト」とは、関連のデータおよび手続きを有するソフトウェアの独立部分である。データとは、コンピュータ・プログラム中の情報、たとえば名前または在庫部品番号を格納することができる情報または空間をいう。手続きとは、コンピュータに実際に何かをやらせるプログラムの部分、たとえば、計算を実行させるプログラムの部分または何かをコンピュータ・ディスク上に記憶させるプログラムの部分である。オブジェクト指向技術において、オブジェクトの手続きが「メソッド」と呼ばれる。
【０００８】
オブジェクトがそれ自体の中にデータおよび手続きを有するソフトウェアの独立部分であるという概念が、ソフトウェアを開発する新たな方法である。非オブジェクト指向ソフトウェアでは、しばしばプログラム全体のデータの大部分がプログラムの始まり近くでいっしょにグループ分けされ、手続きがこの共通のデータのプールにしたがう。この従来の方法は小さめのプログラムにはうまく働くが、ソフトウェアが大きくなり、いくぶん複雑になり始めるとすぐ、どの手続きがどのデータを使用しているのかを理解することがますます困難になる。これが、従来のソフトウェア・プログラムをデバッグまたは変更することをきわめて困難で費用のかかるものにする。
【０００９】
オブジェクト指向技術において、一般に、オブジェクト指向ソフトウェアをデバッグし、維持し、機能強化することはより易しい。もっとも一般的な３種のオブジェクト指向プログラミング言語は、おそらく「Ｃ＋＋」、「ＪＡＶＡ」および「Smalltalk」である。データおよびメソッドの両方がオブジェクトの中に含まれるという概念は「カプセル化」と呼ばれる。カプセル化の概念の一部は、オブジェクトが他のオブジェクトと通信する予測可能な方法、いわゆる予測可能な「インタフェース」またはメソッド契約とも呼ばれるものを有することである。
【００１０】
インタフェースが変更されないならば、オブジェクトの中のコードまたはメソッドは、そのオブジェクトと相互作用する他のオブジェクトの能力を損なうことなく、変更することができる。たとえば、TAX  CALCULATION（税金算出）オブジェクトは、PAYCHECK（給与チェック）オブジェクトが使用するための予測可能なインタフェースを有するであろう。インタフェースが変更されないならば、税法が変わるたびにTAX  CALCULATION（税金算出）オブジェクトの中の詳細なプログラム・コードを変更することができ、給与支払いシステム中の他のオブジェクトはそのような変更に関して何も知らなくてもよい。
【００１１】
オブジェクト指向技術において、一つのオブジェクトが別のオブジェクトからその行動およびデータの一部を受け継ぐことができるという概念を伝えるのに「継承」という語が使用される。たとえば、従業員とは人のタイプであるため、EMPLOYEE（従業員）オブジェクトは、PERSON（人物）オブジェクトの特性、たとえば名前、生年月日および住所データを継承するかもしれず、そのようなデータを更新し、表示するためのメソッドを継承するかもしれない。
【００１２】
オブジェクトが他のオブジェクトからその特性のいくつかを継承するとしても、そのオブジェクトは、それ自体の非継承特性をも有することができ、通常は有するであろう。たとえば、PERSON（人物）オブジェクトは、人物の住所を表示するための継承可能なメソッドを有するが、すべての人物が給与をもらうわけではないため、PERSON（人物）オブジェクトは、おそらく、給与履歴を表示するためのメソッドを有しないであろう。EMPLOYEE（従業員）オブジェクトはPERSON（人物）オブジェクトからこのメソッドを継承することができないため、EMPLOYEE（従業員）オブジェクトは、給与履歴を表示するためにそれ自体のメソッドを定義しなければならない。
【００１３】
オブジェクト指向技術は明らかに、ソフトウェア・アプリケーションの開発、維持および拡張にとってもっとも進んだ方法であると思われるが、ソフトウェア・アプリケーションを開発する多くの会社が、既存のアプリケーションの手直しおよびオブジェクト指向技術を使用する新たなアプリケーションの作成に伴う費用および危険性を懸念している。そのようなソフトウェア・アプリケーション開発者にとって、ソフトウェア・アプリケーションの技術的基礎が、オブジェクト指向技術を基礎として使用するツールとして構築されて、各開発者が高度にオリジナルのソフトウェア製品を開発できるようでなければならない。この技術的基礎は、以前にはソフトウェア・アプリケーション開発者が自ら開発しなければならなかった基本的アプリケーション構造を構成するフレームワークによって形成される。
【００１４】
オブジェクト指向技術において、「フレームワーク」とは、フレームの中の個々のクラスのいずれによっても提供されない機能の共通に必要な部分を提供するために共働する再使用可能なクラスのセットまたは集合体を記述するために使用される。したがって、フレームワークは、多数のオブジェクトをいっしょに使用して、一つ一つのオブジェクトでは実行できない一つ以上のタスクを実行する具体的な方法を定義する。言い換えるならば、フレームワークとは、繰り返し起こるプログラミング問題に対処するいくつかのオブジェクトの、再使用可能で、あらかじめ定義され、あらかじめ設計された束である。
【００１５】
フレームワークは、オブジェクトどうしの再使用可能な関係を把握して、それらのオブジェクトが必要とされるたびにそれらをその同じ関係で再びアセンブルする必要がないようにする方法を提供する。フレームワークは、多数のオブジェクトをいっしょにグループ分けして、必要とされるたびに下層のオブジェクト・レベルで判断するべきではない機能を実行する方法を提供する。たとえば、PRINT（印刷）フレームワークは、プログラマがいずれかのプリンタで何かを容易に印刷するために必要であるすべてのオブジェクトを有しおそらくは、プリンタ選択、ディスクへのスプールまたはエラー検出、たとえば「用紙切れ」のオブジェクトを含む。フレームワークは、たとえば、金融、物流管理または製造の業種で、ソフトウェア・アプリケーションのための技術的基礎を含むソフトウェア・オブジェクトのグループとみなすことができる。フレームワークはソフトウェア・アプリケーションの骨組みを表すが、通常、フレームワークは実行可能なソフトウェア・プログラムではない。
【００１６】
E.  GAMMAらの「Design  Patterns:  elements  of  reusable  object-oriented  software」、Addison-Wesley、1995、ISBN  0-201-63361-2は、特に本発明に関し、一般的にはオブジェクト指向技術への、より具体的には設計パターンへの有用な手引きを提供する。
【００１７】
ソフトウェア・アプリケーションを開発するための技術的基礎としてフレームワークを提供することにより、以下の問題に対処しなければならない。
【００１８】
アプリケーションは、市販されているすべてのハードウェア・プラットフォームおよび関連のソフトウェア・オペレーティング・システムをサポートしなければならない。アプリケーションはまた、グラフィカル・ユーザ・インタフェースおよびウィンドウ処理技術をはじめとする、クライアント／サーバ機器構成に関する要件を満たさなければならない。また、アプリケーションは、インターネット互換性およびアクセス・オン・デマンドを提供しなければならない。さらに、アプリケーションは、インストールされるソフトウェアに関して統合された解決方法を提供しなければならない。
【００１９】
特に、大部分のビジネス・アプリケーションの核心は台帳である。ビジネス・アプリケーションによって解消しなければならない比較的困難な問題の一つは、多くの場合、異なる開発組織によって開発される多数の様々なビジネス・アプリケーション・コンポーネント、たとえば給与／人事、倉庫管理、製造が、各コンポーネントに固有の要件にあつらえられた方法でいかにして台帳に入力を提供することができるかである。このタスクは、同じく異なる開発組織によって開発される多数の台帳コンポーネントがフレームワークと相互運用することを可能にするのと同時に、達成されなければならない。フレームワークはまた、残りのアプリケーション・コンポーネントをいかなる方法でも変更することなく、台帳コンポーネントを提供しないことを選択するアプリケーションをサポートしなければならない。
【００２０】
加えて、フレームワークは、均一ではない項目のセットのフレキシブルな表現をサポートできなければならない。
【００２１】
添付図面において、クラス、オブジェクト、関係などの表現の標準は、少なくとも部分的に、Grady  Boochの「Object-Oriented  Analysis  and  Design  with  Applications」第二版（The  Benjamin/Cummings  Publishing  Company,  Ind.,  Redwood  City,  CA,  USA）に準じて使用する。
【００２２】
【発明が解決しようとする課題】
本発明の目的は、上記に論じた課題を解消する、オブジェクト指向技術を使用してソフトウェア・アプリケーションを開発するための技術的基礎を提供することである。
【００２３】
本発明のさらなる目的は、多数の様々なビジネス・アプリケーション・コンポーネントが、各コンポーネントに固有の要件にあつらえられた方法で台帳コンポーネントに入力を提供できるようにすることである。
【００２４】
【課題を解決するための手段】
本発明は、これらの目的を、独立請求項に記載の装置およびコンピュータ可読な記憶媒体によって解決する。本発明の具体的な実施態様は、従属請求項に提示する。
【００２５】
特に、本発明は、たとえばビジネス・アプリケーションのソフトウェア・システムを開発するために使用される、財務統合フレームワークであるフレームワークであって、三つの主要なコンポーネント、すなわち、使用される非財務コンポーネント統合ベース・クラス、ターゲット財務または台帳コンポーネント統合ベース・クラスおよび汎用データ変換エンジンを有することを特徴とするフレームワークを提供する。
【００２６】
本発明は、いかなる特定のビジネス・アプリケーション・コンポーネントにカスタマイズすることも容易である。さらには、開発組織によって望まれるいかなるレベルの複雑さでもコンポーネント間のデータ・マッピングを可能にして、開発組織による修正なしでも完全に機能する機構を有する汎用データ変換エンジンを提供する。このエンジンは、フレームワーク中の他のコンポーネントによって領域固有のクラス・インスタンス、たとえば、倉庫管理コンポーネントの場合には製品、倉庫、顧客および在庫タイプの形態で提供される様々なデータを受け入れ、そのデータを、汎用台帳(General Ledger)フレームワーク・インタフェース、すなわち、それぞれが別々の汎用分析グループに対応する汎用分析コードの一つ以上のインスタンスで構成される汎用記入組み合わせを含む汎用解析とで互換性のある形態に変換する。それは、基本レベルではいかなる台帳アプリケーションからも独立して作動しながらも、フレームワークのために開発された台帳アプリケーション・コンポーネントが、基本レベル機能を、それ自体のより進んだ機能によって容易に置換することを可能にする。
【００２７】
【発明の実施の形態】
本発明の主体を開発ツールとして使用するソフトウェア・アプリケーションの開発は、図１に示す四つの層の構成とみなすことができる。
【００２８】
一番下の層がベース層１０１である。ベース層１０１は、異なるオペレーティング・システム、たとえばＯＳ／２、ＯＳ／４００、ＡＩＸおよびＮＴの下で潜在的に作動するサーバ・ハードウェア１１１とのインタフェースを提供し、管理する。サーバ・ハードウェア１１１は、通信ネットワーク１１３を介してクライアント・ハードウェア１１２に接続されている。クライアント・ハードウェア１１２もまた、異なるオペレーティング・システム、たとえばＯＳ／２、ＮＴおよびＡＩＸの下で潜在的に作動することができる。図１に示す実施態様は、クライアント／サーバ・アプリケーションのサーバ部のみの開発を示す。
【００２９】
ベース層１０１は、オペレーティング・システムに近い多くの機能、たとえばオブジェクトの発見、それらの名前の追跡、それらに対するアクセスの制御、競合解消、セキュリティ管理およびインストールを含む、より上位のオブジェクトための技術的基礎を表す。ベース層１０１はまた、下層構造の複雑さをソフトウェア・アプリケーション開発者から隠しながら、オブジェクトを構築するための一貫したモデルを提供する、いわゆるオブジェクト・モデル・クラスを含む。ベース層１０１は、ベース層１０１によって提供されるインタフェース機能を使用する、その上のオブジェクト技術のアプリケーションに必要な、下位ミドルウェアの１種とみなすことができる。
【００３０】
ベース層１０１の上には、共通ビジネス・オブジェクト１０２を含む層がある。この共通ビジネス・オブジェクト層１０２は、ビジネス・アプリケーションの中で共通に必要な機能、たとえば日時、通貨、住所、単位および暦を実行する多数のオブジェクトを提供する。これらの共通ビジネス・オブジェクトは、ソフトウェア・アプリケーション開発者が選択し、ビジネス・アプリケーションを生成するのに使用することができる構成単位を表す。たとえば、これらの共通ビジネス・オブジェクトをコピーし、拡張して、新たな機能を実行することができる。たとえば、日時オブジェクトを拡張して、旧暦を扱うこともできる。
【００３１】
共通ビジネス・オブジェクト層１０２の上の層１０３は、コア・ビジネス・プロセスをすでに含み、コア・ビジネス・プロセス層１０３とみなすことができる。この層１０３は通常、実行可能なコードを提供しないが、この層１０３の中で、本発明を使用して開発されるビジネス・ソフトウェア・アプリケーションが形成し始める。各コア・ビジネス・プロセス層は、一つの特定のタイプのアプリケーション、たとえば台帳または倉庫管理のために構築される。
【００３２】
このコア・ビジネス・プロセス層１０３は、完全なソフトウェア・アプリケーション・プログラムではないが、このタイプのアプリケーション・プログラムのすべてが必要とする基本機能をすべて含む上位ミドルウェアとみなすことができる。このコア・ビジネス・プロセス層１０３こそが、共通ビジネス・オブジェクトのいくつかが、構築されるフレームワークのタイプ、たとえば倉庫管理に固有な多数のオブジェクトに連結されるアプリケーション・フレームワークを生成する。得られるフレームワークは、共通に使用される機能を含み、かつ拡張しやすいような方法で構成される。
【００３３】
上述の３層モデルの上に、ソフトウェア・アプリケーション開発者によって生成され、実行可能なコードを表すアプリケーション・ソフトウェアが位置する。ベース層１０１だけを使用するのか、ベース層１０１および共通ビジネス・オブジェクト層１０２を使用するのか、３層１０１、１０２および１０３すべてを使用するのかは、ソフトウェア・アプリケーション開発者が自らのソフトウェア・アプリケーションの開発に関して選択する。いずれの場合にも、開発者は、アプリケーションの残り部分を自ら開発しなければならず、したがって、得られるソフトウェア・アプリケーション・プログラムそれぞれが完全なオリジナル製品になる。
【００３４】
本発明の主体は、３層モデル１０１、１０２および１０３の中で表現されるのであり、本発明を使用して開発されるソフトウェア・アプリケーション１２１の実行可能なコードによって表現されるのではないことに留意すること。
【００３５】
図２に示すように、財務統合フレームワークは、三つの主要セクション２０１、２０２および２０３を含む。第一のセクション２０１は、財務処理の特定のソースによって使用されるベース・クラスのセットである。第二のセクション２０２は、第一のセクション２０１における特殊化をそれらの抽象ベース・クラスとして使用して、対象の特定のソースの特定項目から台帳のインタフェースにおける関連項目にマッピングする汎用データ変換エンジンである。第三のセクション２０３は、情報を台帳に汎用的にパスすることができる台帳（ＧＬ）に対するインタフェースからなる。
【００３６】
財務統合フレームワークを使用することを望むビジネス・アプリケーション・コンポーネントは、まず、フレームワークによって提供されるベース・クラスからサブクラス化される具象クラスのセットを定義しなければならない。これらの具象クラスの機能は、主として、フレームワーク・ベース・クラスから導出される。領域固有の具象クラスは、ビジネス・アプリケーション・コンポーネントとフレームワークとの間をさらに隔離させ、コンポーネント開発者が、コンポーネントの残りの部分に対して有意義な領域固有インタフェースを定義することを可能とさせる。これにより、アプリケーションを開発する際に、フレームワークの使いやすさを大幅に改善することができる。
【００３７】
本発明の実施態様では、フレームワークによって定義される以下のベース・クラスがビジネス・アプリケーション・コンポーネント開発者によってサブクラス化されなければならない。
・AccountControlType
・DomainGenericIntegrationKey
・GenericGLDissectionCreateTemplate
・GnenericGLJournal
・GenericDissection
・GenericPostingCombination
・GenericAnalysisGroup
・GenericAnalysisCode
これらのベース・クラスについて、以下に説明する。
【００３８】
AccountControlType
AccountControlTypeベース・クラスは、フレームワークが汎用データ変換エンジン中のいかなる領域固有クラスをも使用することを許す。アプリケーション・コンポーネント開発者は、エンジンによって使用される領域固有クラスごとにこのクラスのサブクラスを定義しなければならない。そして、コンポーネント定義サブクラスそれぞれのインタンスが汎用データ変換エンジンに与えられる。エンジンは、このセットの順序を維持し、汎用マッピング・プロセスでそれを使用する。
【００３９】
DomainGenericIntegrationKey
アプリケーション・コンポーネント開発者は、DomainGenericIntegrationKeyベース・クラスの一つのサブクラスを生成させる。このサブクラスが汎用統合キー・インタフェースを、領域固有語、たとえばsetProduct、setWarehouseに適合するように変換する。サブクラス上の各領域固有インタフェースは、一つ以上の領域固有AccountControlTypeサブクラスに結合される。AccountControlTypeサブクラスは、汎用マッピング・プロセスによって使用される汎用統合キー（Generic Key）を構築する場合のインデックスとなる。
【００４０】
GenericGLDissectionCreateTemplate
GenericGLDissectionCreateTemplateクラスのサブクラスは、財務統合フレームワークがGenericDissectionを生成するために必要なすべての情報をカプセル化するために使用される。各テンプレート・サブクラスはDomainGenericDissectionTypeインスタンスと対応し、このインスタンスは、汎用データ変換エンジンにより、テンプレートを処理するとき、適切なマッピング・サブセットを選択するために使用される。各テンプレート・サブクラスは、サブクラスのインスタンスを生成するとき、アプリケーション・コンポーネント開発者が、解析に必要なすべての領域固有情報をパスすることを許す。すると、サブクラスは、この情報を、汎用データ変換エンジンとで互換性である形態にパッケージングする。この処理の一部は、先に記載した領域固有サブクラスを使用して統合キーを構築することを含む。
【００４１】
ビジネス・アプリケーション・コンポーネントはまた、DomainGenericDissectionTypeクラスの一つ以上のインスタンスを生成して、各インスタンスを一つ以上のAccountControlTypeサブクラスに対応させなければならない。この対応が、特定の解析タイプの対象である領域固有クラスを定義する。ビジネス・アプリケーション・コンポーネントによって定義されるGenericGLDissectionCreateTemplateサブクラスごとに一つのDomainGenericDissectionTypeクラス・インスタンスが生成される。
【００４２】
財務統合フレームワークはさらに、汎用データ変換エンジンによって使用されるインタフェースをサポートするベース・クラスのセットを含む。これは、財務統合フレームワークが台帳アプリケーション・コンポーネントの非存在で作動することを許す。フレームワークによって提供されるベース・クラスには次のものがある。
【００４３】
GnenericGLJournal
このクラスは、台帳（ＧＬ）に対して同時に記入される分析のセットを表す。通常、仕訳帳を正しく記入するためには、その借り方解析の合計がその貸し方解析の合計に等しくなければならない。
【００４４】
GenericDissection
このクラスは、仕訳帳の一部として台帳に記入される特定の財務エントリ（借り方または貸し方）を表す。これは、GenericPostingCombinationを量および値の情報とともに含む。
【００４５】
GenericPostingCombination
このクラスは、解析が記入されなければならない台帳勘定を識別する。これは、一つ以上のGenericAnalysisCodeからなる。
【００４６】
GenericAnalysisGroup
このクラスは、台帳アプリケーションのユーザにとって興味のある類似したビジネス実体、たとえば部門、仕事の機能、費用センタのグループを表す。グループの各インスタンスはGenericAnalysisCodeによって表現される。
【００４７】
GenericAnalysisCode
このクラスは、GenericAnalysisGroupに含まれる特定のビジネス群を表す。このクラスのインスタンスはユーザによって定義される。財務統合フレームワークのセットアップ中に、ユーザは、GenericAnalysisCodeインスタンスを領域固有オブジェクト・インスタンスのセットと連係（リンク）させる。これらの領域固有オブジェクト・インスタンスは、DomainGenericDissectionTypeおよびGenericAnalysisGroupの組み合わせにとって意味のあるようにユーザによって指定されるAccountControlTypeを選択して生成される。これらのマッピング対が、財務処理を処理するために財務統合フレームワークによって使用される情報の核心を形成する。
【００４８】
財務統合フレームワークは、台帳アプリケーション・コンポーネントの非存在でも作動するが、意味のある財務処理を完了するためには、そのようなコンポーネントがアプリケーションによって提供されなければならない。台帳コンポーネントは、上述のクラスの汎用バージョンを台帳コンポーネントの置換クラスで置換してフレームワークのオブジェクト工場（ファクトリ）を構築するだけで、フレームワークの中に容易に統合される。財務統合フレームワークを使用する他のコンポーネントや、それどころか、フレームワークそのものは、財務統合タスクのそれらの部分を完了するのに必要な機能が汎用ベース・クラス・レベルで定義されるため、このクラス置換に気づかない。
【００４９】
旧式であってオブジェクト指向ではない台帳アプリケーションもまた、同様にしてこのフレームワークに容易に統合することができる。このような統合に使用されるサブクラスは、汎用オブジェクト指向フレームワーク・インタフェースと、旧式のアプリケーションによって提供される手続きインタフェースとの間でマッピングするように定義される。
【００５０】
本発明によって定義される汎用データ変換エンジンは、その核心で、フレームワークの使用コンポーネントによって定義される領域固有クラスのインスタンスと、フレームワークによって定義される台帳固有ベース・クラスのインスタンスとの間でマッピングすることができる汎用マッピング・プロセスを提供する。このマッピング機構は、使用コンポーネントごとに別個のインスタンスを提供して、各コンポーネントが、アプリケーションの他のコンポーネントからの干渉を受けるおそれなしに、そのマッピング規則を独立して定義する自由を有し、いかなる数の解析タイプ（それぞれがマッピング・エンジンによって使用されるいかなる数の領域固有クラスと対応していてもよい）をも使用コンポーネントによって汎用に定義することを許し、使用コンポーネントによって定義される領域固有クラスを、ユーザによってあらかじめ定義された汎用分析グループ・クラス・インスタンスに結合し、領域固有クラス・インスタンスの特定の組み合わせを、各汎用分析グループごとにユーザによって定義される汎用分析コード・クラス・インスタンスに対応させることにより、アプリケーション・ユーザが、使用コンポーネントによって定義される領域固有クラスのいずれかまたはすべてを選択的に使用することを許す。
【００５１】
このエンジンはまた、アプリケーション・コンポーネントによって供給される汎用処理を、財務統合フレームワークに対応する台帳アプリケーション・コンポーネントとで互換性のある合併形態に束ねる汎用仕訳帳構築プロセスを提供する。
【００５２】
汎用マッピング・プロセスは、領域固有クラスのタイプまたは内容の明示的な知識なしで、領域固有クラスと共働できなければならない。そのような知識は回避しなければならない。理由は、回避しないならば、フレームワークが不都合にも特定の領域具現態様に結合され、新たな領域区域へのフレームワークの拡張が厄介になるからである。
【００５３】
これはフレームワークの主要な問題であり、この問題に対し、本発明が解決方法を提供する。本発明のフレームワークによって定義されるAccessKey/Keyables機構は、財務統合フレームワークがいかなる領域固有クラスとでも汎用的に共働することを許す（AccessKeyに関しては、１９９７年１月１６日に欧州特許庁に出願された関連の特許出願第９７１００５６６．６号「Access  Key  Objects」を参照すること）。アプリケーション・コンポーネントの対象になる各領域固有クラスには、財務統合フレームワークにとって既知である、フレームワーク・クラスAccountControlTypeのサブクラスとして汎用的に保持されるＩＤと、マッピング・エンジンによって使用される汎用キーの中の位置とが割り当てられる。領域定義解析がフレームワークによって処理されるとき、各領域固有クラス・インスタンスは、Generic  Keyableによってラップされ、汎用キーの中の先に指定された位置に配置される。すると、このキーを、解析のためのマッピング・プロセスの際に使用することができる。ひとたびこのようにして含まれると、領域固有のマッピング・データを、この解析の記入組み合わせを構成する分析コードのユーザ指定セットの探索中に汎用的に操作することができる。
【００５４】
使用アプリケーション・コンポーネントによって定義される各解析タイプは、汎用マッピング・プロセスによって使用することができるAccountControlTypeサブクラス・インスタンスのリストを介して領域固有の属性のセットを指定する。アプリケーションの設計の際、アプリケーションのユーザは、利用可能な属性タイプのうち、どれがマッピング・プロセスで使用されるのか、また、このインストールにとって有効である特定のマッピングを示さなければならない。
【００５５】
図３に示すように、マッピングは、解析タイプ３１２およびAnalysisGroup３１１について定義することができる。すなわち、これらのマッピングは、特殊化されたマッピング３０１、またはAnalysisGroupだけ、すなわち、解析タイプ／AnalysisGroup固有マッピングに対して適切な対照が存在しない場合にすべての解析タイプに対して適用されるデフォルト・マッピング３０２として定義することができる。ユーザによって指定される特定のマッピングそれぞれは、アプリケーションの正常な作動の間に領域固有解析からの入力がカプセル化されるように、AccessKeysにカプセル化される。したがって、ひとたびフレームワークがこの方法で構成されると、変換プロセスは自動的であり、GenericKeyインスタンスどうしを比較することにより、フレームワークの中で汎用に実施することができる。
【００５６】
図４に示すように、汎用マッピング・プロセスは、変換エンジンによってサポートされる汎用仕訳帳構築プロセスの一部である。領域固有アプリケーション・コンポーネントが解析テンプレート・インスタンス４０１を生成する時点では、マッピング・プロセスまたは変換プロセスのいずれも完了しない。代わりに、これらのインスタンスは、財務統合フレームワークによって収集され、アプリケーションが汎用仕訳帳構築プロセス４０２を開始するまで保持される。このプロセスの第一段階は、構成可能な手法、たとえば解析テンプレートを生成したときアプリケーション・コンポーネントによって提供される、特定のJournalCreationIDに基づいて解析テンプレートのサブセットを選択することを含む。セットのそれぞれのテンプレートは、まず、汎用マッピングを完了してGenericPostingCombinationを生成し、GenericPostingCombinationおよびテンプレートに保持された残りの情報からGenericDissectionを構築することにより処理される。ひとたびGenericDissectionが構築されると、GenericDissectionは、解析テンプレートのこのサブセットについて生成したGenericJournal４０３に組み込むことが可能となる。このようにしてすべての解析テンプレートを処理したのち、GenericJournalを記入し、財務統合処理が完了する。
【００５７】
図５は、特定の汎用解析タイプについて、一つの分析グループをマッピングする例を示す。この場合、汎用解析タイプはSTOCK  VALUE５０１であり、これは、アプリケーションの財務部分に対し、手持ち在庫の価値の変化を示すために使用される。ターゲット財務アプリケーションは、細分化されたその勘定を表している。各断片は、分析グループと呼ばれ、ユーザが関心を示したいくつかの側面を有している。典型的な分析グループは部門５０２である。分析グループの中で、指定の値が分析コード５０３と呼ばれる。たとえば、分析グループ部門は、SALES（販売）、ENGINEERING（製造）などのような分析コードを含むかもしれない。したがって、勘定は、分析グループごとの分析コードのセットで構成される。
【００５８】
この特定の実施例では、分析グループ２−部門５０２だけを示す。分析グループ２については、倉庫５０６の勘定管理タイプだけが使用される。図５は、倉庫「ＢＢ００１」５０７が分析コード「ＢＢ」５０４にマッピングされていることを示す。したがって、在庫タイプのような汎用解析タイプを使用する場合には、倉庫勘定管理タイプに与えられた「ＢＢ００１」が、分析グループ２に使用される勘定管理タイプを示す「ＢＢ」分析コードを与えることになる。
【００５９】
図６は、二つの汎用解析タイプ（在庫管理６０７および在庫価値６０８）と、三つの分析グループ（１＝主勘定６０９、２＝部門６１０、３＝製品６１１）と、三つの勘定管理タイプ（製品６１２、倉庫６１３、コストタイプ６１４）とを含む、より複雑な例を示す。マップ６０１は、どのような勘定管理タイプが使用されるかにかかわらず、特定の分析コードが分析グループに使用されるべき、特殊な場合のマッピングを示す。この特定の場合、分析コード「４５５０」が常に使用される。マップ６０２、マップ６０３およびマップ６０５は、上述した図５に類似するマッピングを示すものである。マップ６０６は、すべての可能な分析グループを使用する必要がないことを示すのに使用され、マップ６０６には、この特定の汎用解析タイプの分析グループ３（使用されず）には、望ましい分析コードはない。マップ６０４は、二つ以上の勘定管理タイプを使用する場合を示す。この特定の場合には、コスト・タイプ６１４および製品６１２が使用される。したがって、「ＣＮＳ０１」（正常）６１５のコスト・タイプおよび製品「ＢＦＴＲ０１」（三輪車）６１６の場合、分析コード「１５１２」６１７を使用するようにマッピングされることになる。
【００６０】
図７は、図６で定義したマップを使用する例を示す。この例では、指定された勘定管理タイプの値を各汎用解析タイプに使用して、財務アプリケーションに情報を与えるために勘定を構築するのに適切な分析コードを決定させている。
【００６１】
まとめとして、本発明の構成に対して以下の事項を開示する。
（１）  ビジネス・アプリケーションのソフトウェア・システムを開発するために使用される、財務統合フレームワークを有するフレームワークを含むコンピュータ・システムであって、前記フレームワークは、サーバをして、
製品クラス、倉庫クラス、顧客クラス、在庫タイプ・クラスを含むベース・クラスのセットと、
少なくとも１つの汎用分析コードのクラスのインスタンスを含む汎用台帳インタフェースと、
使用される非財務コンポーネントを使用して定義される領域固有クラスのインスタンスを、領域汎用統合キーを参照して前記汎用台帳インタフェースへとインタフェースし、領域汎用統合キーが配置される汎用キーを含む汎用データ変換エンジンとを構成させ、
前記ベース・クラスは、領域固有クラスを識別させるためのアカウント・コントロール・タイプ・クラスおよび汎用統合キー・クラスを生成させ、
前記汎用データ変換エンジンは、汎用台帳インタフェースに対して前記汎用データ変換エンジンの前記汎用キーを参照することにより、領域固有クラスの内容の明示的な知識の使用を回避させながら領域固有クラスのマッピングを実行させる、
フレームワークを含むコンピュータ・システム。
（２）ベース・クラスは、さらに汎用ジャーナル・クラス、汎用解析クラス、汎用記入組合わせクラス、汎用分析グループ・クラス、別々の汎用分析グループに伴われる汎用分析コード・クラスを含む、
上記（１）記載のコンピュータ・システム。
（３）上記１または２に記載のフレームワークを記憶するコンピュータ可読な記憶媒体。
【図面の簡単な説明】
【図１】本発明を使用してソフトウェア・アプリケーションを開発することができる４層スキーマ図である。
【図２】財務統合フレームワークによって構成される三つの主要セクションを示す図である。
【図３】特殊化マッピングおよびデフォルト・マッピングを示す図である。
【図４】汎用仕訳帳構築プロセスを示す図である。
【図５】特定の汎用解析タイプの一つの分析グループのマッピングの例を示す図である。
【図６】二つの汎用解析タイプ、三つの分析グループおよび三つの勘定管理タイプを有するより複雑な例を示す図である。
【図７】図６で定義されたマップを使用する例を示す図である。
【符号の説明】
１０１  ベース層
１０２  共通ビジネス・オブジェクト層
１０３  コア・ビジネス・プロセス層
１１１  サーバ・ハードウェア
１１２  クライアント・ハードウェア
１１３  通信ネットワーク
１２０  ソフトウェア・アプリケーション
【図１】
0003566550.tif 000002
【図２】
0003566550.tif 000003
【図３】
0003566550.tif 000004
【図４】
0003566550.tif 000005
【図５】
0003566550.tif 000006
【図６】
0003566550.tif 000007
【図７】
0003566550.tif 000008