JP2004280814A - ソフトウェアシステム内での処理ロジックのカスタマイズ方法 - Google Patents

Abstract

【課題】 処理ソースコードを修正することなく、ソフトウェアシステム内で処理のカスタマイズを容易に行えるようにする。
【解決手段】 処理についてのメタデータ記述をカスタマイズすることによって、カスタマイズされたサービス識別子を処理エージェントに受け渡すことによって、あるいは処理エージェントまたはサービスファクトリによって伝達されたイベントを処理することによって、処理をカスタマイズすることができる。
【選択図】 図６Ｂ

Description

本発明は、ユーザが所望するアプリケーションおよびプログラムを実装するのにソースコードが使用されるコンピューティング環境に関する。より詳細には、本発明は、ソースコードを修正せずにコンピュータプログラムおよびアプリケーションのカスタマイズを可能とするフレームワークに関する。

コンピュータソフトウェア関連製品を設計および販売する手法の１つに、その製品が様々な産業分野や多くの異なる国など広範囲に適用可能なように、水平方向の機能に焦点を絞る手法がある。そのようなシステムは、望ましくは、特定の垂直ターゲット市場や特定の企業に固有のニーズに応えることで、アフターサービス市場を活性化させることもできる。同様に、それらの製品は、望ましくは、製品を顧客個々のニーズに合わせて変更またはカスタマイズすることで、顧客の能力を増進させることもできる。

顧客固有のニーズを満たすようにそれらの製品を拡張できないとすると、顧客は必然的に、購入したソフトウェアに合うように業務を変更しなければならない。業務活動の変更にはコストと時間を費やさなければならないので、当然、こうしたタイプのソフトウェアは顧客の支持を得ることができない。

システムのカスタマイズを可能とするために従来より使用されてきた、多くの異なる技法が存在する。こうした従来技法には、例えば、ソースコード修正（ｓｏｕｒｃｅ ｃｏｄｅ ｍｏｄｉｆｉｃａｔｉｏｎ）がある。この技法は、顧客に製品のソースコードのコピーを提供することを必要とする。したがって、この技法は、熟練した専門家に相当な量の内容の変更を許し、変更内容は実質上修正ソースコード製品の一部となるので、そのような変更は、変更内容があたかも製品の一部のように見えるよう行われる。

しかし、ソースコード修正には大きな難点が伴う。例えば、ソースコード修正は、製品を使用し始めるまでに多額の費用を要する。ユーザまたは顧客はしばしば、製品がどのように構築されているかその微妙な詳細について特別な教育を受けているコンサルタントおよびディベロッパを高額で雇わなければならないからである。ユーザは次に、非常に困難で漠然とした作業である問題予測の作業をやり抜かなければならない。これらの問題を克服し、目的を貫徹できたとしても、その結果は修正ソースコードである。オリジナルのソースコードの製造元が、バグフィックス、アップデート、および新バージョンなど追加のソフトウェアを出荷した場合、顧客は、有能なエンジニアまたはディベロッパ（望ましくは、最初の修正を行ったのと同じ者たち）を再び雇い、製造元が出荷した新しいソースコードにすでに行った修正を組み込み、新しい修正ソースコードに不具合が生じた場合、それを１つ１つ解決するよう強いられる。あるいは、ユーザは、バグフィックスやユーザの業務に便益をもたらすかもしれない新機能を単に組み込まずにおくこともできる。

さらに、ソースコード修正は、複数の異なるベンダから、「既成品」のアドオンモジュールを単に購入することを極めて困難にする。そうした各ベンダは、その特定の既製品モジュールを組み込めるように、おそらくソースコードに同じように修正を加えなければならないからである。その結果、基本製品のソースコードを出荷する製造元ばかりか、各アドオンベンダも同様にそのソースを出荷するであろう。その場合、ユーザは、何らかのその場限りの組み込み作業を行わなければならず、またはソースコードのこれらの乱雑な集合から単一の製品を合成しなければならない。当然、その結果として、アップグレードが行われた場合やどこか１つのベンダがバグフィックスを出荷した場合にほぼ問題を抱える、脆弱な１組のコードが得られる。

ソースコード修正はまた、世の中で唯一の企業（ソースコードを修正した特定のディベロッパまたはエンジニア）しか、修正ソースコードがどのように構築されているかを知らないという問題をもつ。したがって、規模の経済を実現すること、また顧客サイトで動作する製品のどのような製品でもサポートが受けられるようにすることが、不可能ではないにしても困難となる。

ソースコード修正に伴う問題は、たとえ単一顧客の範囲内であっても、異なる１組のニーズおよび好みをもった異なる１組のユーザが存在する場合、著しく増大する。そうしたユーザの１人が、自分たちに特有なニーズを組み込むため、ソースコード修正戦略によって製品を変更する毎に、そうしたユーザを雇用する顧客は実質的に、結局新しいソースコード基盤（base）をもつに至る。言い換えると、顧客は単一のカスタムコード基盤をもつとは限らず、顧客内のどれだけの特定ユーザまたは部署がコード基盤を修正したか次第で、実質的に多くのカスタムコード基盤をもつこともある。繰り返すと、バグフィックスが公表される毎に、またはすべてのユーザに適用されるカスタマイズに変更が加えられる毎に、顧客は、作成されたソースのすべての他のコピーに何らかの組み込み作業を実施しなければならない。

上述の問題は、ソースコード修正技法に関連する多くの問題のうちのほんの一部に過ぎない。これらの問題は、顧客および従業員自身の管理作業にとって非常に大きな障害となり得る。

オブジェクトに基づくコンピュータプログラムの限定的修正を可能にする別の技法に、ユーザが定義できるユーザフィールドを追加する技法がある。言い換えると、「カスタマイズ可能」である各オブジェクトが最初に、ユーザが好きなように定義または使用できる１つまたは複数のユーザフィールドをもつように定義される。この技法によって、ある種のタイプのカスタマイズが可能になるが、上述のすべての問題が解決されるわけではない。この技法にも、この技法特有の非常に多くの問題が伴う。例えば、ユーザフィールドに関連するネーミング規約は、それらのユーザフィールドの具体的な使用目的を直観的に連想することを困難にする。例えば、追加のユーザフィールドには一般に、「ＵＳＥＲＦＩＥＬＤ．１」から「ＵＳＥＲＦＩＥＬＤ．Ｎ」など、非常に汎用的な名前が付けられる。各ユーザフィールドが何のために使用されているのか、ユーザが覚えているのは、不可能ではないにしても困難である。さらに、ユーザフィールドを追加しても、マルチベンダに関連する問題、または異なる組織による複数修正に関連する問題は解決されない。例えば、あるベンダまたはユーザが、あるユーザフィールドを第１の仕方で割り当て、別のベンダまたはユーザが、同じユーザフィールドを別の仕方で割り当てた場合、そのユーザフィールドの定義の仕方に不一致が生じ、２つのベンダまたはユーザに関連する２つの製品は、さらに修正を加えなければ、一緒に動作させることはできない。

カスタマイズに関するその他の技法も、さらに試みられた。例えば、カスタムイベントコードを記述することによって、カスタマイズを行うことができる。その他、ソースコード中でオリジナルのオブジェクトへの１対１マッピングを使用することによって、あるイベントがオリジナルのオブジェクト上で発生した場合に、「カスタマイズされた」オブジェクトを操作することができる。これまでに使用されたことのある別の技法として、「プロパティバッグ（ｐｒｏｐｅｒｔｙ ｂａｇ）」や名前−値ペア（ｎａｍｅ−ｖａｌｕｅ ｐａｉｒ）を挙げることができる。これらの技法はやはり共に、深刻な難点を抱えており、ソースコード修正に関連する不完全は取り除かれない。

従来のシステムには上述したような種々の問題があり、さらなる改善が望まれている。

本発明は、このような状況に鑑みてなされたもので、その目的とするところは、処理ソースコードを修正することなく、ソフトウェアシステム内で処理のカスタマイズを容易に行えるようにすることができる、ソフトウェアシステム内での処理ロジックのカスタマイズ方法を提供することにある。

本発明は、処理ソースコードを修正することなく、ソフトウェアシステム内で処理のカスタマイズを容易に行えるようにする。処理についてのメタデータ記述をカスタマイズすることによって、カスタマイズされたサービス識別子を処理エージェント（ｐｒｏｃｅｓｓ ａｇｅｎｔ）に受け渡すことによって、あるいは処理エージェントまたはサービスファクトリ（ｓｅｒｖｉｃｅ ｆａｃｔｏｒｙ）によって伝達されたイベントを処理することによって、処理をカスタマイズすることができる。

以下、図面を参照して本発明を適用できる実施形態を詳細に説明する。本発明は、コンピュータソフトウェアのカスタマイズに関する。しかし、本発明をより詳細に説明する前に、本発明を使用することができる例示的な環境の一実施形態について説明する。

図１には、本発明を実施することができる、適切なコンピューティングシステム環境１００の一例が示されている。コンピューティングシステム環境１００は、適切なコンピューティング環境の単なる一例に過ぎず、本発明の使用または機能の範囲に何らかの限定を課すことを意図したものではない。コンピューティングシステム環境１００は、例示的な動作環境のコンピューティングシステム環境１００に示された、どれか１つのコンポーネントまたはコンポーネントの組合せに関して、どのような依存または要求ももたないものと解釈される。

本発明は、数々の他の汎用または専用コンピューティングシステム環境または構成で動作可能である。本発明に係る使用に適した、周知のコンピューティングシステム、環境、および／または構成の例として、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能家庭用電化製品、ネットワークＰＣ（personal・computer）、ミニコンピュータ、メインフレームコンピュータ、上記システムまたは装置の任意のものを含む分散コンピューティング環境、その他を挙げることができるが、これらに限定されるものではない。

コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令という一般的状況において、本発明を説明することができる。一般に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データ型を実施する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明はまた、通信ネットワークを介して結合されたリモート処理装置によってタスクを実行する、分散コンピューティング環境でも実施することができる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を始めとする、ローカルおよびリモートのコンピュータ記憶媒体に配置することができる。

図１を参照すると、本発明を実施するための例示的なシステムは、コンピュータ１１０の形態をした汎用コンピューティング装置を含む。コンピュータ１１０のコンポーネントとして、プロセッサ１２０、システムメモリ１３０、およびシステムメモリなど様々なシステムコンポーネントをプロセッサ１２０に結合するシステムバス１２１を挙げることができるが、これらに限定されるものではない。システムバス１２１は、様々なバスアーキテクチャのいずれかを使用する、メモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを始めとする複数のタイプのバス構造のうちの、任意のバス構造とすることができる。例えば、こうしたアーキテクチャとして、ＩＳＡ（Industry Standard Architecture）バス、ＭＣＡ（Micro Channel Architecture）バス、ＥＩＳＡ（Extended Industry Standard Architecture）バス、ＶＥＳＡ（Video Electronics Standards Association）ローカルバス、およびメザニンバス（Ｍｅｚｚａｎｉｎｅ ｂｕｓ）としても知られるＰＣＩ（Peripheral Component Interconnect）バスを挙げることができるが、これらに限定されるものではない。

コンピュータ１１０は一般に、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０によってアクセス可能な任意の利用可能媒体とすることができ、揮発性および不揮発性媒体、リムーバブルおよびノンリムーバブル媒体を含む。例えば、コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含むが、これらに限定されるものではない。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータといった情報を記憶するための任意の方法または技法によって実施される、揮発性および不揮発性媒体、リムーバブルおよびノンリムーバブル媒体を含む。コンピュータ記憶媒体として、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（Electronically Erasable and Programmable Read Only Memory）、フラッシュメモリ、またはその他のメモリ技術、ＣＤ（compact disc）−ＲＯＭ、ＤＶＤ（Digital Versatile Disc）、またはその他の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶、またはその他の磁気記憶装置、あるいは所望の情報を記憶するのに使用でき、コンピュータ１１０によってアクセス可能なその他の任意の媒体を挙げることができるが、これらに限定されるものではない。通信媒体は一般に、搬送波やその他の移送機構などの変調データ信号中に、コンピュータ可読命令、プログラムモジュール、またはデータ構造を包含し、任意の情報送達媒体を含む。「変調データ信号」という語は、信号中に情報を符号化できるような方式で設定または変更される１つまたは複数の信号特性をもつ信号を意味する。例えば、通信媒体として、有線ネットワークまたは直接配線接続などの有線媒体、および音響、ＲＦ（radio frequency）、赤外線、またはその他の無線媒体などの無線媒体が挙げられるが、これらに限定されるものではない。上記の媒体の任意の組合せも、コンピュータ可読媒体の範囲に含まれるものとする。

システムメモリ１３０は、ＲＯＭ（読み取り専用メモリ）１３１やＲＡＭ（ランダムアクセスメモリ）１３２などの、揮発性および／または不揮発性メモリの形態をしたコンピュータ記憶媒体を含む。ＲＯＭ１３１には一般に、起動処理中などにコンピュータ１１０内の要素間の情報伝送を助ける基本ルーチンを含む、ＢＩＯＳ（Basic Input/Output System）１３３が記憶される。ＲＡＭ１３２は一般に、プロセッサ１２０が直ちにアクセス可能な、かつ／またはやがてそれに基づいて動作するデータおよび／またはプログラムモジュールを含む。例えば、図１には、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７が示されているが、これらに限定されるものではない。

コンピュータ１１０はまた、その他のリムーバブル／ノンリムーバブル、揮発性／不揮発性コンピュータ記憶媒体を含む。図１には、ノンリムーバブルな不揮発性磁気媒体に対して読み書きを行うハードディスクドライブ１４１、リムーバブルな不揮発性磁気ディスク１５２に対して読み書きを行う磁気ディスクドライブ１５１、ＣＤ−ＲＯＭやその他の光媒体などリムーバブルな不揮発性光ディスク１５６に対して読み書きを行う光ディスクドライブ１５５が、例としてのみ示されている。例示的な動作環境で使用することができるその他のリムーバブル／ノンリムーバブル、揮発性／不揮発性コンピュータ記憶媒体として、磁気テープカセット、フラッシュメモリカード、ＤＶＤ、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ、その他を挙げることができるが、これらに限定されるものではない。ハードディスクドライブ１４１は一般に、インタフェース１４０などのノンリムーバブルメモリインタフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は一般に、インタフェース１５０などのリムーバブルメモリインタフェースを介してシステムバス１２１に接続される。

上で説明し、図１に示すドライブおよびそれに関連するコンピュータ記憶媒体は、コンピュータ１１０のためのコンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの記憶を可能とする。図１には、例えば、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７を記憶するものとして、ハードディスクドライブ１４１が示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７と同じであることもでき、異なることもできる。ここでは、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７には、少なくともそれらが異なるコピーであることを示すために、異なる番号が振られている。

ユーザは、キーボード１６２、マイクロホン１６３、およびポインティングデバイス１６１（例えば、マウス、トラックボール、またはタッチパッド）などの入力装置を介して、コマンドおよび情報をコンピュータ１１０に入力することができる。その他の入力装置（図示せず）として、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナ、その他を挙げることができる。上記およびその他の入力装置はしばしば、システムバスに結合されたユーザ入力インタフェース１６０を介してプロセッサ１２０に接続されるが、パラレルポート、ゲームポート、またはＵＳＢ（universal serial bus）など、その他のインタフェースおよびバス構造によって接続することもできる。モニタ１９１またはその他のタイプのディスプレイ装置も、ビデオインタフェース１９０などのインタフェースを介してシステムバス１２１に接続される。モニタの他に、コンピュータは、出力周辺インタフェース１９５を介して接続できる、スピーカ１９７やプリンタ１９６などのその他の周辺出力装置も含むことができる。

コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理コネクションを使用して、ネットワーク環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、ハンドヘルド装置、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、またはその他の共通ネットワークノードとすることができ、一般にコンピュータ１１０に関連して上で説明した、多くのまたはすべての要素を含むことができる。図１に示す論理コネクションは、ＬＡＮ（ローカルエリアネットワーク）１７１およびＷＡＮ（ワイドエリアネットワーク）１７３を含むが、その他のネットワークを含むこともできる。こうしたネットワーク環境は、オフィスで、また企業規模のコンピュータネットワーク、イントラネット、インターネットで一般的である。

ＬＡＮネットワーク環境で使用される場合、コンピュータ１１０は、ネットワークインタフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーク環境で使用される場合、コンピュータ１１０は一般に、インターネットなどのＷＡＮ１７３を介して通信を確立するための、モデム１７２またはその他の手段を含む。内蔵とも外付けともすることのできるモデム１７２は、ユーザ入力インタフェース１６０またはその他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク環境では、コンピュータ１１０との関連で示したプログラムモジュールまたはその部分は、リモートのメモリ記憶装置に記憶することができる。例えば、図１には、リモートコンピュータ１８０上に存在するものとして、リモートアプリケーションプログラム１８５が示されているが、それに限定されるものではない。図示のネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立するその他の手段も使用できることは理解されよう。

図２は、オブジェクトリレーショナル（またはエンティティリレーショナル）データ記憶システムのブロック図である。本明細書の説明では、エンティティは、「オブジェクト」という語と交換可能なものとして解釈される。Ｅ−Ｒシステム２００は、リレーショナルデータベース２０４に保存されたデータに対応する、１組のエンティティ（またはオブジェクト）２０２を含む。エンティティは、エンティティ−リレーショナル（ＥＲ）マップ（ｅｎｔｉｔｙ−ｒｅｌａｔｉｏｎａｌ（ＥＲ）ｍａｐ）２０８を利用するデータアクセスシステム（ｄａｔａ ａｃｃｅｓｓｉｎｇ ｓｙｓｔｅｍ）２０６を介して、リレーショナルデータベースにアクセスする。ＥＲマップ２０８は、エンティティ２０２とリレーショナルデータベース２０４内のテーブルエントリとの間のマッピングを含む。本発明をＥ−Ｒシステム以外の他のシステムで使用できること、図２に示すシステムは本発明を使用できるシステムの単なる一例に過ぎないことに留意されたい。

図３は、本発明の一実施形態によるカスタマイズサブシステム（ｃｕｓｔｏｍｉｚａｔｉｏｎ ｓｕｂｓｙｓｔｅｍ）２２２のカスタマイズフレームワーク（ｃｕｓｔｏｍｉｚａｔｉｏｎ ｆｒａｍｅｗｏｒｋ）２２０を表すＵＭＬ（統一モデリング言語）クラス図である。カスタマイズサブシステム２２２は、カスタマイザ（ディベロッパ、ユーザ、またはマネージャなどの仲介カスタマイザ）とカスタマイズサブシステム２２２との間で対話を可能にするカスタマイザユーザインタフェース（ｃｕｓｔｏｍｉｚｅｒ ｕｓｅｒ ｉｎｔｅｒｆａｃｅ）２２４に接続されて示されている。サブシステム２２２はまた、カスタマイズイネーブルサブシステム（ｃｕｓｔｏｍｉｚａｔｉｏｎ−ｅｎａｂｌｅｄ ｓｕｂｓｙｓｔｅｍ）２２６にも接続されて示されており、カスタマイズイネーブルサブシステムは、本発明のカスタマイズ機能の外部に位置するコンポーネント２２８に接続される。

以下でより詳細に説明するように、カスタマイザインタフェース２２４によって、カスタマイザは、コンピュータソフトウェアをカスタマイズするために、システム２２２にアクセス可能となる。外部のコンポーネント２２８は、カスタマイズされたソフトウェアの何らかの部分にアクセスすることを望む、ユーザなどの任意のコンポーネントとすることができる。カスタマイズイネーブルサブシステム２２６は、ユーザによって使用されるコンピューティング環境の任意のサブシステムとし、カスタマイズサブシステム２２２と相互作用を行って、カスタマイズされることが可能なように構成される。

カスタマイズサブシステム２２２は、アダプタシステム（ａｄａｐｔｅｒ ｓｙｓｔｅｍ）２３０およびターゲットシステム（ｔａｒｇｅｔ ｓｙｓｔｅｍ）２３２を含む。アダプタシステム２３０は、基底クラスのＳｕｂｓｙｓｔｅｍＡｄａｐｔｅｒ２３４と複数のデータ型のアダプタ２３６、２３８、２４０、２４２とで実装される。ターゲットシステム２３２は、基底クラスのＴａｒｇｅｔ２４４と複数のデータ型のターゲット２４６、２４８、２５０、２５２とで実装される。ターゲットシステム２３２はまた、ＧｅｎｅｒａｔｅｄＡｓｓｅｔエンティティ２５４と合成関係（ｃｏｍｐｏｓｉｔｉｏｎ ｒｅｌａｔｉｏｎｓｈｉｐ）にもある。システム２３０および２３２は共に、Ｃｏｎｔｅｘｔエンティティ２５６にアクセスすることができる。

アダプタシステム２３０は、カスタマイズイネーブルサブシステム２２６とフレームワーク２２０の間の一次接続ポイントとして動作する。アダプタシステム２３０は、全体としてサブシステム２２６に適用されるカスタマイズロジックを実施する。一方、ターゲットシステム２３２は、カスタマイズしたいデータ型の特定のインスタンスをカスタマイズするのに使用されるロジックを含む。

Ｃｏｎｔｅｘｔエンティティ２５６は、現在のコンテキストを識別するコンテキスト情報を含む。例えば、組織でそれぞれ異なる役割を果たしている人々に異なった仕方でカスタマイズを適用したほうが望ましい場合がある。同様に、組織内の異なる部署に異なった仕方でカスタマイズを適用したほうが望ましい場合がある。Ｃｏｎｔｅｘｔエンティティ２５６は、現在のコンテキストに関連した、それに適したカスタマイズを行うことができるように、現在のコンテキストを識別するコンテキスト情報を含む。これについても、以下で図４と関連させてより詳細に説明する。

以下で説明するように、フレームワーク２２０は拡張可能である。カスタマイズ可能となったサブシステムにとって、それが行わなければならないことはフレームワーク２２０へのインタフェースをサポートすることだけである。サブシステムがカスタマイズ対象の追加のデータ型をもつ場合、行わなければならないステップは、カスタマイズしたいデータ型のための（アダプタ２４２などの）アダプタを提供することだけである。同様に、サブシステムの作成者は、（ターゲットエンティティ２５２などの）ターゲットを作成しなければならない。アダプタエンティティとターゲットエンティティは一緒に、サブシステムの作成者が望むようにサブシステムをカスタマイズするためのカスタマイズロジックを保有する。そのようなサブシステムが追加のカスタマイザインタフェース２２４を作成でき、それを介してユーザがそのサブシステムのタイプのカスタマイズを行えることも理解されよう。

本発明の一実施形態によれば、カスタマイズを必要とするソフトウェアは、ユーザインタフェース内容、データ、および処理内容を始めとする内容の複数の基底クラスを含む。ユーザインタフェース内容は、ユーザが画面または報告書上で目にする内容を含む。ユーザインタフェース内容は、レイアウト情報、メッセージ、フィールドラベルといったものを含む。データは、システムが記憶する情報を表す。例えば、データは、顧客、在庫品、注文などを含む。処理内容は、定義された１組のステップに従って作業の順を決めるワークフロー仕様と、各データについて明確に定義されたアクションを実行する低レベルの処理ロジックを含む。処理内容の一例として、例えば、注文を元帳に記入したり、在庫品を確保したりする、ワークフローおよび低レベルの処理ロジックを挙げることができる。これらならびにその他のタイプの内容は、本発明の様々な実施形態に従って、カスタマイズすることができる。

カスタマイズされる内容のタイプに関わりなく、カスタマイズは、望ましくは、対象とするコンテキストに関連させることができる。どのコンテキストであるかによって、適用されるカスタマイズが異なる。すなわち、コンテキストの概念を導入することによって、あるカスタマイズはある特定のユーザだけに適用され、別のカスタマイズはある特定のグループに所属するすべてのユーザに適用され、さらに別のカスタマイズはユーザが誰であれ全社に適用されることが可能になる。これらは、コンテキストの３つの異なる例に過ぎず、この他にも多くのコンテキストを使用することができる。

Ｃｏｎｔｅｘｔエンティティ２５６は、現在のコンテキストを取得するために、アダプタシステム２３０またはターゲットシステム２３２によって呼び出される。図４には、Ｃｏｎｔｅｘｔエンティティ２５６によって表されるデータ構造の一実施形態が示されている。もちろん、Ｃｏｎｔｅｘｔエンティティ２５６は、リレーショナルデータベース２０４にマップされるデータを表す。図４には、どのカスタマイズをどのコンテキストに適用するかを判別するのに使用されるテーブルの一実施形態が示されている。

例示の実施形態では、Ｃｏｎｔｅｘｔエンティティ２５６は、コンテキストテーブル２５７、カスタマイズテーブル２５９、およびカスタマイズ−コンテキストテーブル２６１を含むリレーショナルデータベース２０４内のテーブルにマップされる。図４に示す実施形態では、コンテキストテーブル２５７は、コンテキスト識別番号によってコンテキストを識別するフィールドを含む。コンテキストテーブル２５７には、ある特定のユーザを識別するユーザＩＤと、マネージャ、販売員、副社長など組織内の役割を識別する職務と、発送部、販売部など企業の業務単位を識別する組織と、地理的所在を表す所在地とを含む、４つのコンテキスト項目が示されている。この他にも、多種多様な追加のコンテキスト要素を使用することができる。

コンテキストテーブル２５７の第１のコンテキストエントリは、第１のコンテキストＩＤがヨーロッパにいるすべてのマネージャに関連づけられていることを示している。第２のコンテキストＩＤは、ユーザＩＤが１２３４５のある特定のユーザに関連づけられており、第３のコンテキストＩＤは、発送部のマネージャに関連づけられている。カスタマイズテーブル２５９は、システムに入力された異なるカスタマイズに関連づけられた識別子と、そのカスタマイズＩＤに関連づけられた特定のカスタマイズの仕様を定めるカスタマイズデータを含む。カスタマイズ−コンテキストテーブル２６１は、コンテキストＩＤとカスタマイズＩＤの間の対応関係を定義する。したがって、指定されたＩＤをもつカスタマイズは、それと関連するコンテキストＩＤフィールドで識別される様々なコンテキストに適用される。もちろん、所与のどのカスタマイズにも複数のコンテキストをマップすることができ、所与のどのコンテキストにも複数のカスタマイズをマップすることができる。

他のテーブル構成を使用することもでき、図４に示すテーブル構成は単なる一例に過ぎない。例えば、テーブル２６１を削除して、コンテキストテーブル２５７に同様のカスタマイズＩＤフィールドを設けることもできる。コンテキストテーブルに複数の行をもたせることによって、１つのカスタマイズにさらに多くのコンテキストをもたせることができる。

どの場合でも、システム２３０および２３２は、Ｃｏｎｔｅｘｔエンティティ２５６に現在のコンテキストをリクエストすることができ、Ｃｏｎｔｅｘｔエンティティはまた、一実施形態では、現在のコンテキスト内で適用する必要のある特定のカスタマイズの識別情報を返すことができる。

エンティティ拡張
カスタマイズフレームワーク２２０の動作をより良く説明するために、図３に関連する説明を、図５〜図６Ｂを併せ参照しながら進める。これらの図は、エンティティのカスタマイズをより良く説明する。本明細書では、エンティティのカスタマイズを「エンティティ拡張（ｅｎｔｉｔｙ ｅｘｔｅｎｓｉｏｎ）」とも呼ぶ。

図５には、カスタマイズイネーブルサブシステム２２６内のエンティティが生成された時に生成されるデータ構造が示されている。図６Ａには、図５に示すデータ構造が示されているが、生成されたデータ構造に加え、エンティティがカスタマイズされた時に修正されたデータ構造も示されている。図６Ｂは、図６Ａのエンティティがどのように生成または修正されるかを示したフローチャートである。

図５には、業務アプリケーション内の基底の（base）エンティティ２８０が示されている。業務アプリケーション内で顧客を識別する「Ｃｕｓｔｏｍｅｒ」エンティティを、例示的な業務エンティティ（business entity；符号２８０）とする。説明される特定の例は単なる例に過ぎず、その他のエンティティにも本発明の概念が同様に適用されることは、当然理解されよう。基底のエンティティ２８０は、拡張（またはカスタマイズ）されるエンティティを表す。図５には、（図２に示す）ＥＲマップ２０８内の顧客ＥＲマップ（ｃｕｓｔｏｍｅｒ ＥＲ ｍａｐ）エントリ２８２によって、基底のエンティティ２８０がリレーショナルデータベース２０４にマップされることも示されている。基底のエンティティ２８０とその他のエンティティの間の関係は、顧客ＥＡマップ（ｃｕｓｔｏｍｅｒ ＥＡ（ｅｎｔｉｔｙ ａｓｓｏｃｉａｔｉｏｎ）ｍａｐ）２８４で識別される。図５にはさらに、リレーショナルデータベース２０４が、Ｃｕｓｔｏｍｅｒエンティティ２８０に関連づけられた顧客テーブル２８６を例示的に含み、顧客テーブルが、顧客ＩＤフィールド、名前フィールド、住所フィールド、および顧客を識別するのに望ましいその他の任意のフィールドを含むことが示されている。

本発明は、エンティティをカスタマイズするのにソースコード修正を必要としないので、基底のエンティティ２８０を再コンパイルせずに新しいエンティティ関係を基底のエンティティに動的に追加できるようにするために、基底のＥｘｔｅｎｓｉｏｎエンティティ（ｂａｓｅ ｅｘｔｅｎｓｉｏｎ ｅｎｔｉｔｙ）２８８も提供される。基底のＥｘｔｅｎｓｉｏｎエンティティ２８８は、生成された各基底のエンティティ２８０毎に生成される。基底のＥｘｔｅｎｓｉｏｎエンティティ２８８は、基底のエンティティ２８０の名前を例示的に含み、そのため、この例では、基底のＥｘｔｅｎｓｉｏｎエンティティ２８８は「ＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎ」と命名される。基底のＥｘｔｅｎｓｉｏｎエンティティ２８８は最初は空であるが、やはり空である顧客拡張ＥＲマップ２９０および顧客拡張ＥＡマップ２９２を含むことができる。基底のエンティティ２８０は、基底のＥｘｔｅｎｓｉｏｎエンティティを識別する合成フィールド（ｃｏｍｐｏｓｉｔｉｏｎ ｆｉｅｌｄ）を含む。例えば、基底のエンティティ２８０は、「Ｅｘｔｅｎｓｉｏｎ」という名前の「ＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎ」型の合成フィールドを含むことができる。Ｃｕｓｔｏｍｅｒエンティティ２８０のエンティティ関連メタデータ（ｅｎｔｉｔｙ ａｓｓｏｃｉａｔｉｏｎ ｍｅｔａｄａｔａ）は、ＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎエンティティ２８８との関係を反映している。エンティティ２８０および２８８は共に、例示的には、本発明による製品をインストールする時に、ＤＬＬ（Dynamic Link Library）として出荷され、配布される。これらのエンティティおよびそれに関連するマップを生成するステップが、図６Ｂのブロック４００および４０２に示されている。その時点で、カスタマイザは、図３に示すインタフェース２２４などのカスタマイザユーザインタフェースを介して、Ｃｕｓｔｏｍｅｒエンティティ２８０への拡張プロパティの追加を開始することができる。

図６Ａには、拡張プロパティがどのように追加されるかが示されている。カスタマイザインタフェース２２４は、識別されたエンティティに追加される新しいプロパティのリストをフレームワーク２２０に導入するユーザインタフェース（ＵＩ）を含む。追加される新しいプロパティの仕様は、それを記憶するＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＴａｒｇｅｔ２４６に受け渡される。カスタマイザはまた、特定のカスタマイズが適用される、Ｃｏｎｔｅｘｔエンティティ２５６に記憶された特定のエンティティを識別することもできる。カスタマイズを指定するステップが、図６Ｂのブロック４０４に示されている。異なるカスタマイザが異なる時にコンテキストを設定できることも理解されよう。カスタマイザがディベロッパである場合、開発時にコンテキストを設定することができる。カスタマイザがシステム管理者である場合、管理業務の一環としてコンテキストを設定することができる。いずれの場合でも、最終的にはコンテキストが設定される。

カスタマイズをアクティブにするために、サブシステム２２６は最初に、インストールの前にサブシステム２２６が全体として必要とする処理を実行する、Ｓｕｂｓｙｓｔｅｍ Ａｄａｐｔｅｒ２３４中のＰｒｅＩｎｓｔａｌｌ（）メソッドを呼び出す。サブシステム２２６は次に、ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＡｄａｐｔｅｒ２３６中のＡｐｐｌｙＣｕｓｔｏｍｉｚａｔｉｏｎｓ（）メソッドを呼び出す。それに応答して、ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＡｄａｐｔｅｒ２３６は、（図２に示す）データアクセスシステム２０６を使用して、カスタマイズされたプロパティを含むＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＴａｒｇｅｔ２４６のインスタンスを識別する。ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＡｄａｐｔｅｒ２３６は次に、特定のＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＴａｒｇｅｔ２４６中のＩｎｓｔａｌｌ（）メソッドを呼び出す。これについては、図６Ｂのブロック４０６に示されている。

この呼び出しによって、ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＴａｒｇｅｔ２４６は、Ｅｘｔｅｎｓｉｏｎエンティティと呼ばれる新しいエンティティを生成する。２つのＥｘｔｅｎｓｉｏｎエンティティ３００、３０２が図６Ａに示されている。Ｅｘｔｅｎｓｉｏｎエンティティ３００、３０２の各々は、カスタマイズされたプロパティを識別する少なくとも１つの拡張プロパティ３０４、３０６をそれぞれ含む。図６Ａには、カスタマイザＸＹＺおよびカスタマイザＡＢＣと名付けられた２人の異なるカスタマイザによって実施されたカスタマイズの一実施形態が示されている。したがって、Ｅｘｔｅｎｓｉｏｎエンティティ３００は説明上、ＸＹＺ．ＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎと命名され、Ｅｘｔｅｎｓｉｏｎエンティティ３０２は説明上、ＡＢＣ．ＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎと命名される。

例えば、カスタマイザＸＹＺが、Ｃｕｓｔｏｍｅｒエンティティ２８０をカスタマイズして、エンティティ２８０で識別される顧客が好む技術者の識別情報を含ませることを望んだと仮定する。その場合、ＸＹＺ．ＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎエンティティ３００は、「好まれる技術者（preferred technician）プロパティ」と呼ばれる拡張プロパティ３０４を含む。カスタマイザＡＢＣが、Ｃｕｓｔｏｍｅｒエンティティ２８０をカスタマイズして、エンティティ２８０で識別される顧客に関連する信用限度を含ませることを望んだと仮定する。その場合、ＡＢＣ．ＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎエンティティ３０２は、対象の顧客に関する「信用限度」を識別する拡張プロパティ３０６を含む。

ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＴａｒｇｅｔ２４６は、Ｅｘｔｅｎｓｉｏｎエンティティ３００、３０２を、対応する拡張プロパティ３０４、３０６と共に生成するばかりでなく、説明上、Ｅｘｔｅｎｓｉｏｎエンティティ３００、３０２の各々に対応するＥ−Ｒマップ３１０、３１２と、Ｅ−Ａマップ３１４、３１６をそれぞれ生成する。さらに、ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＴａｒｇｅｔ２４６は、Ｅｘｔｅｎｓｉｏｎエンティティ３００、３０２および他の関連するデータ構造に対応するテーブルをリレーショナルデータベース２０４内に（データアクセスシステム２０６を介すなどして）生成する。これについては、図６Ｂのブロック４０８に示されている。

最後に、基底のＥｘｔｅｎｓｉｏｎエンティティ２８８を再コンパイルし、Ｅｘｔｅｎｓｉｏｎエンティティ３００、３０２との新しい関係を反映したＥ−Ｒマップを再生成する。同様に、Ｅｘｔｅｎｓｉｏｎエンティティとの新しい関係を同じく反映したＥ−Ａメタデータも生成する。これについては、図６Ｂのブロック４１０に示されている。例えば、ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＡｄａｐｔｅｒクラス中のＰｏｓｔＩｎｓｔａｌｌ（）メソッドを呼び出すことによって、これを行うことができる。こうすることで、その再コンパイルで、ＡＢＣとＸＹＺの両者による変更に対応することができる。対象のターゲットをインストールする際に行うことも可能だが、各ターゲット毎に１回、合計ｎ回のエンティティの再コンパイルが必要になる。

図６Ａには、行われたエンティティ拡張を反映したデータベーススキーマを実装できる、複数の異なる例示的な方法も示されている。第１の実施形態では、図６Ａに３２０と記されたテーブルにエンティティ拡張を保存する。テーブル３２０がＣｕｓｔｏｍｅｒエンティティ２８０に関連するデータを保存するオリジナルのテーブル２８６を含むことが分かる。オリジナルテーブルは、エンティティ拡張に対応する複数の追加フィールド３２２、３２４を含むように単純に拡張される。名前衝突（ｎａｍｅ ｃｌａｓｈ）を回避するために、名前の前に作成者の名前空間を付加して、一意性を確保する。したがって、テーブル２８６内のオリジナルの列が変更されることはない。エンティティ拡張の対象となるオリジナルテーブルに、拡張部分が単に追加されるだけである。

第２の実施形態では、エンティティ拡張の各々が、それ専用のテーブルに保存される。そのようなテーブルが、符号３２６および３２８によってそれぞれ示されている。もちろん、カスタマイズ毎に異なるテーブルを生成することができ、またはあるカスタマイザ（ＡＢＣまたはＸＹＺ）が行うすべてのカスタマイズを単一のテーブルに保存することもできる。

第３の実施形態によれば、両方のカスタマイズが単一のテーブル３３０に保存される。テーブル３３０では、エンティティ拡張「好まれる技術者」と「信用限度」の両方がこのテーブルに保存される。この実施形態では、列名の前に作成者の名前空間を付加して、一意性を確保する。もちろん、すべてのエンティティのすべてのカスタマイズを含むように、または単一のエンティティのすべてのカスタマイズを含むように、テーブル３３０を拡大することができる。後者の場合、各エンティティ毎に、そのエンティティのすべてのカスタマイズを保持する新しいテーブルが生成される。

さらに別の実施形態によれば、カスタマイズを含む１つまたは複数のテーブルがすでに生成されており、したがって、それらがリレーショナルデータベース２０４内にすでに存在しているようなシステムでも、本発明を使用することができる。この実施形態では、Ｅｘｔｅｎｓｉｏｎエンティティ３００、３０２は、カスタマイズを含む既存のテーブルに単純にマップされる。

エンティティ拡張は、エンティティ間の関係をカスタマイズするのにも使用することができ、これが図６Ｃに示されている。図６Ｃには、カスタマイザが、「好まれる技術者」カスタマイズを単一のフィールドに文字列として書き込むのではなく、そのカスタマイズを関連するマップ３０３、３０５をもつ別のエンティティ３０１として作成する、一実施形態が示されている。その場合、対応するＥＡマップ中にＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎエンティティ２８８とＰｒｅｆｅｒｒｄＴｅｃｈｎｉｃｉａｎエンティティ３０１との間のＥＡメタデータ関係を追加することによって、カスタマイズが行われる。

メタデータカスタマイズ
図７Ａには、メタデータ構造、および本明細書で「デルタベースカスタマイズ（ｄｅｌｔａ−ｂａｓｅｄ ｃｕｓｔｏｍｉｚａｔｉｏｎ）」と呼ぶメタデータカスタマイズが示されている。図７Ａのメタデータ構造は、メタデータ構造木（ｍｅｔａｄａｔａ ｓｔｒｕｃｔｕｒｅ ｔｒｅｅ）５００の一部分として示されている。図７Ａに示す木５００の一部分が、システムのメタデータを定義するはるかに大きな木の非常に小さな部分を例示的に示したものにすぎないことは理解されよう。図７Ａに示す部分は、メタデータがＦｏｒｍｓセクションを含み、ＦｏｒｍｓがＣｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿Ｓｃｒｅｅｎを含むことを示している。Ｃｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿Ｓｃｒｅｅｎは、複数のタブコントロールを有するフィールド（Ｆｉｅｌｄｓ）を含む。タブコントロール１は、それに関連づけられたＦｉｅｌｄ１を有する。Ｆｉｅｌｄ１は、フィールド名、フィールド背景色、フィールドが有効か無効か、フィールド長、およびフィールドのデータ型（この例ではＭａｘＶａｌｕｅ）を始めとする複数のプロパティを有する。もちろん、フィールドは、複数の追加のプロパティをさらに有することができる。メタデータ構造５００は、メタデータストア（ｍｅｔａｄａｔａ ｓｔｏｒｅ）に保存される。

メタデータ構造５００をカスタマイズするために、カスタマイザは、カスタマイザインタフェース２２４を介してカスタマイズ仕様を入力する。こうすることで、あるコンテキストでカスタマイズを利用するＭｅｔａｄａｔａＴａｒｇｅｔエンティティ２４８中にコードが含まれる。

本発明の一実施形態では、メタデータ構造５００内のメタデータの型のカスタマイズはすべて、デルタを使用して達成される。デルタは、メタデータ構造５００内での、オリジナルの形式からの変更を表す。カスタマイズは、任意の個数ｎのデルタを含み、各デルタは、基底ターゲットの既知のインスタンスに関する特定の変更を表す。さらに、デルタは、既存ノードに対する変更を表す必要が全くない。代わりに、デルタは、メタデータ構造５００への新ノードの追加を表すことができる。

オリジナルのデータ構造５００内で値を変更する例として、名前が「ｆｏｏ」であるフィールドの背景色は黄色であり、カスタマイザがその背景色を青に変更したいと思ったと仮定する。この例では、カスタマイザは、単一のデルタを含む単一のカスタマイズを行う。カスタマイズは、Ｃｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿ＳｃｒｅｅｎのＴａｂ１の下の「ｆｏｏ」フィールドに関連する。カスタマイズは、メタデータストアの別個の部分に保存することができ、またはリレーショナルデータベース２０４にマップされるＭｅｔａｄａｔａＣｕｓｔｏｍｉｚａｔｉｏｎエンティティ５０２に保存することができる。メタデータストアの一部分を形成することができるリレーショナルデータベース２０４内のテーブルは、テーブル５０４によって示されており、このテーブルは、ＦｏｒｍｓのＣｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿Ｓｃｒｅｅｎ部中のフィールドのＴａｂ１の下のＦｉｅｌｄ１の背景色プロパティを識別するメタデータＩＤを含む。テーブル５０４は、フィールドの背景色が青に変更されたことを表すデルタを識別するデルタ情報も含む。したがって、デルタは、修正された原情報のコピーではない。代わりに、デルタは、構造５００内のどの値を修正すべきかについての単なる仕様に過ぎない。デルタを追跡するだけで、多くの修正を動的にターゲットに適用することが可能になる。

デルタを適用するため、カスタマイズイネーブルサブシステム２２６は、アダプタ２３４を呼び出して、ＭｅｔａｄａｔａＡｄａｐｔｅｒ２３８を介してカスタマイズを適用する。ＭｅｔａｄａｔａＡｄａｐｔｅｒ２３８は、ＭｅｔａｄａｔａＴａｒｇｅｔ２４８中のＡｐｐｌｙ（）を呼び出し、現在のコンテキストでカスタマイズを適用する。例えば、カスタマイズイネーブルサブシステム２２６がＦｏｒｍローディングサブシステムであると仮定する。さらに、ユーザがＣｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿Ｓｃｒｅｅｎを表示するようリクエストしたと仮定する。もちろん、最初にＭｅｔａｄａｔａＡｄａｐｔｅｒ２３８は、Ｃｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿Ｓｃｒｅｅｎという名前のフォームに関して、現在のコンテキストに適用されるリレーショナルデータベース内のすべてのＭｅｔａｄａｔａＴａｒｇｅｔインスタンスを識別する。次にＭｅｔａｄａｔａＡｄａｐｔｅｒ２３８は、カスタマイズの適用対象として識別された各インスタンス毎に、ＭｅｔａｄａｔａＴａｒｇｅｔ２４８中のＭｅｔａｄａｔａＴａｒｇｅｔ．Ａｐｐｌｙ（）を呼び出す。メタデータに適用されるカスタマイズが、Ｃｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿ＳｃｒｅｅｎのＴａｂ１の下のＦｉｅｌｄ１の背景色を青に変更することを必要とすることが分かる。ＭｅｔａｄａｔａＴａｒｇｅｔ２４８中のコードがこの変更を行い、カスタマイズされた部分構造５００が、画面描画に使用されるため、カスタマイズイネーブルフォームローダ（ｃｕｓｔｏｍｉｚａｔｉｏｎ ｅｎａｂｌｅｄ ｆｏｒｍ ｌｏａｄｅｒ）（符号２２６）に返される。

一実施形態によれば、本発明は、異なるカスタマイズの複数のデルタが同じプロパティを参照することによって生じる競合を解決するための機構も含む。例えば、あるマネージャが、Ｃｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿ＳｃｒｅｅｎのＴａｂ１の下の所定のＦｉｅｌｄ１の背景色がオレンジになるようにカスタマイズしたと仮定する。さらに、その部下の１人が、個人的な好みから、背景色を青に変更するカスタマイズを行ったと仮定する。その個人ユーザには、これらの２つの別個のカスタマイズが両方とも適用される。その個人ユーザは、オレンジに変更するカスタマイズが行われた部署の一員であるが、その個人ユーザは自身で、青に変更するカスタマイズを行っている。したがって、これら２つのカスタマイズインスタンスは競合を起す。両方のカスタマイズが、同じフィールドの背景色を異なる色に設定しようとする。しかし、フィールドに設定できる色などの値は１つだけである。したがって、一方のカスタマイズを優先させ、他方を無視しなければならない。

本発明の一実施形態によれば、カスタマイズ競合は、競合解決ポリシー（ｃｏｎｆｌｉｃｔ ｒｅｓｏｌｕｔｉｏｎ ｐｏｌｉｃｙ）を用いて解決される。こうしたポリシーは、説明の都合上、メタデータ構造５００内の異なるデータ型の各々に適用される一定のポリシーを識別するテーブルに保存されるものとする。そのようなテーブルの一部が、図７Ｂにテーブル５１０として示されている。もちろん、テーブル５１０は例示的なものであるに過ぎない。テーブル５１０は、構造５００内のデータ型を識別するデータ型フィールドと、適用される競合解決ポリシーを指示するポリシーフィールドを含む。例示の一実施形態では、競合解決ポリシーは以下を含む。
１．最も限局的な値
２．最も狭いコンテキスト
３．１度しか設定できない値
４．追加
５．管理的オーバライド

最も限局的な値（ｍｏｓｔ ｒｅｓｔｒｉｃｔｉｖｅ ｖａｌｕｅ）というポリシーは、列挙に対して使用することができる。例えば、あるカスタマイズが値Ａ〜Ｅを有効とし、別のカスタマイズが値Ｃ〜Ｆを有効とする場合、競合する２つのカスタマイズの最も限局的な組合せは、値Ｃ、Ｄ、Ｅであるので、これらだけを有効とする。このポリシーは数値フィールドに対しても使用することができる。例えば、データ型が最大値データ型であり、２つのカスタマイズが数値を２つの異なる値に設定しようとした場合、小さい方の値がより限局的であり、その値が優先される。データ型が最小値データ型である場合、大きい方の値がより限局的であり、その値が優先される。

最も狭いコンテキスト（ｎａｒｒｏｗｅｓｔ ｃｏｎｔｅｘｔ）というポリシーは、最も狭いコンテキストに関するカスタマイズを優先して、競合を解決する。例えば、単一のユーザを対象とするカスタマイズは、すべてのユーザ向けのコンテキストに対応する競合カスタマイズよりも優先される。

１度しか設定できない値（ｓｅｔ ｏｎｃｅ ｖａｌｕｅ）というポリシーは、値を１度しか設定できないようにして競合を解決する。その後、その値を変更することはできない。

追加（ａｄｄｉｔｉｖｅ）というポリシーは、フィールドグループ（または画面上に表示されるフィールドのグループ）などのデータ型に適用される。フィールドは説明上、複数のグループに属することができる。したがって、あるフィールドがあるカスタマイズによって第１のグループに追加され、同じフィールドが別のカスタマイズによって第２のグループに追加された場合、両方のグループにそのフィールドを追加することによって競合が解決される。

最後の競合解決ポリシーは管理的オーバライド（ａｄｍｉｎｉｓｔｒａｔｉｖｅ ｏｖｅｒｒｉｄｅ）である。これによって、システム管理者が競合解決ポリシーを項目毎に個別にオーバライドすることが可能になる。

もちろん、これらの競合解決ポリシーは例示的なものに過ぎず、その他のポリシーまたは異なるポリシーを必要に応じて使用することができる。

図８Ａ〜図８Ｃには、カスタマイズがエンティティ拡張によってどのように実行されるかについてのさらに具体的な例が示されている。図８Ａ〜図８Ｃに示された例では、自動車販売代理店のモルテンズ（Ｍｏｒｔｅｎｓ）自動車が、財務ソフトウェアパッケージを購入したと仮定する。パッケージをインストールし、稼動させた後、モルテンズ自動車は、各顧客の自動車の好み（例えば、色、エンジン、製造元／型式など）を追跡するために、パッケージ製品にフィールドを追加するカスタマイズを行う。モルテンズ自動車はまた、顧客の自動車の好み用の新しいフィールドを顧客画面に追加し、いくつかの使用されたことのないフィールドを削除すると仮定する。

図８Ａには、モルテンズ自動車が購入した財務ソフトウェアパッケージの標準的な顧客画面のスクリーンショット４５０が示されている。自動車販売業では一般に使用されない注文品一覧（ｏｒｄｅｒ ｓｕｍｍａｒｙ）フィールドを、画面４５０が含んでいることが分かる。図８Ａには、カスタマイズを実施した後の同じ顧客画面も示されている。オリジナルの注文品一覧フィールドは、顧客の最後の購入および最後の購入日を示すフィールドで置き換えられている。さらに、顧客の自動車の好みを表示するために、自動車の好み（ｃａｒ ｐｒｅｆｅｒｅｎｃｅｓ）タブが追加されている。これらはすべて、上で説明したように、エンティティおよびメタデータを拡張するだけで達成される。

次に、別のソリューションプロバイダのコンソト（Ｃｏｎｓｏｔｏ）が、サービス案内用の電子メール通知を導入すると仮定する。コンソトが提供するＣｕｓｔｏｍｅｒエンティティは、顧客のお気に入り技術者の名前用の文字列をＣｕｓｔｏｍｅｒエンティティに追加し、また新しいフィールド用のテキストボックスを顧客画面に追加するとさらに仮定する。コンソトの顧客画面の一例を図８Ｂに示す。モルテンズ自動車が、サービス部門を運営するために、コンソトからソフトウェアパッケージを購入すると仮定する。

インストール後、先に行ったカスタマイズはすべて、手動介入または再作成しなくても、これまで通り動作する。この画面を図８Ｃに示す。例えば、顧客の自動車の好みフィールドが画面上に表示され、オリジナルの注文フィールドが画面から削除されている。同様に、コンソトが行った変更も提供されている。具体的には、Ｃｕｓｔｏｍｅｒエンティティには新しいフィールドが、顧客画面上にはテキストボックスが含まれている。先に説明したように、新しいソフトウェアパッケージをインストールする場合、カスタマイズサブシステムのフレームワークが呼び出され、ユーザの介入を必要とせず、自動的にカスタマイズがインストールされ、適用される。

処理のカスタマイズ
処理は一般に、定義された１組のステップに従って作業の順を決めるワークフロー仕様と、各データについて明確に定義されたアクションを実行する低レベルの処理ロジックを含む。本明細書では、処理を業務アクティビティと呼び、業務アクティビティは実行時間の長い業務処理とすることができる。

図９には、どのように業務アクティビティ６００を実装できるかが示されている。本発明の一実施形態では、業務アクティビティ６００は、業務オペレーションと呼ばれる、複数の個別の処理ステップに分割される。業務アクティビティを構成する業務オペレーションの各々は、オペレーションの２つの異なるタイプの一方に分類することができる。最初のタイプを本明細書では、計画されたオペレーション置換（ｐｌａｎｎｅｄ ｏｐｅｒａｔｉｏｎ ｒｅｐｌａｃｅｍｅｎｔ）と呼ぶ。言い換えると、オリジナルアプリケーションのデベロッパがロジック置換を予定した場合、そのアプリケーションは実行する特定のロジックを実行時に選択できるように記述される。このようにすることで、サードパーティのデベロッパが、実行する処理のタイプを拡張することができる。オリジナルの作成者は、「プラグポイント（ｐｌｕｇ ｐｏｉｎｔ）」と、１つまたは複数のデフォルト実装を開発する。サードパーティのデベロッパはその後、追加の実装を作成し、インストールすることができる。そうしたアプリケーションは一般に、あるインスタンスで実行される業務オペレーションの選択候補を格納する領域をアプリケーションデータベース内に提供する。そのようなロジックの一例に、販売手数料計算エンジンがある。オリジナルの作成者は、手数料選択情報をＳａｌｅｓＰｅｒｓｏｎエンティティ中に組み込み、「定率」デフォルトも提供するかもしれない。もちろん、サードパーティのデベロッパは、よりきめ細かな計算表を作成し、インストールすることができる。

第２のタイプの業務オペレーションを本明細書では、随時的なオペレーション置換（ａｄｈｏｃ ｏｐｅｒａｔｉｏｎ ｒｅｐｌａｃｅｍｅｎｔ）と呼ぶ。例えば、オリジナルの作成者がオペレーションの置換を予定しない場合もある。したがって、その作成者は、代替実装を選択できるように、何らかの特別なロジックをアプリケーションに組み込まないかもしれない。しかし、そのような場合でも、ベンダは、オリジナルのオペレーションを自分たちのロジックに置換しなければならないことがある。オリジナルのオペレーションに代って、ベンダのオペレーションを呼び出すために、選択ロジックを修正するフレームワーク機構が提供される。

これらの機構をより詳細に説明する前に、別の概念について最初に説明する。本発明の一実施形態による業務オペレーションは、エージェント−サービスパターン（ａｇｅｎｔ−ｓｅｒｖｉｃｅ ｐａｔｔｅｒｎ）に従う。業務オペレーションエージェントは、クライアントが直接対話する、処理の一部分であるに過ぎない。業務処理を実行する必要があるクライアントは、業務オペレーションエージェントのインスタンスを生成し、必要な入力を提供するプロパティをそのインスタンスに送信する。エージェントは、（サービスファクトリを介して）対応するサービスクラスを探し出し、それをインスタンス化した後、呼び出して、サービスを実施する作業を実際に実行する。

上述の置換シナリオのどちらでも、エージェント自体は置換されない。クライアントは常に、同一のオリジナルの業務オペレーションエージェントを生成し、それを呼び出す。つまり、エージェントのインタフェースは不変であり、そのため、クライアントは常に必ずエージェントを呼び出すことができるようになる。業務オペレーションエージェントはエンティティであり、より多くのプロパティが追加された関連するＥｘｔｅｎｓｉｏｎエンティティをもつことができる。このことによって、オリジナルのエージェントインタフェース規約を崩すことなく、エージェントの拡張性が提供される。エージェントは、複数の異なる方法で、実行する適切なサービスを探し出すことができる。

図９には、業務アクティビティ６００が、３つの業務オペレーション、すなわちオペレーション１、オペレーション２、オペレーション３を用いて実装されていることがさらに示されている。業務オペレーション１は、エージェント６０２と、業務オペレーションサービスファクトリ６０４を有する。業務オペレーション２も、エージェント６０６と、サービスファクトリ６０８を有する。業務オペレーション３も、エージェント６１０と、業務オペレーションサービスファクトリ６１２を有する。

計画された置換の場合、呼び出し側アプリケーション（またはクライアント）は、サービスＩＤを現在呼び出されているエージェントに受け渡す。サービスＩＤは、どのサービスを起動するかを指示する。したがって、呼び出し側がある特定のサービスＩＤをエージェント６０２に受け渡した場合、エージェント６０２は、サービスファクトリ６０４を介して、業務オペレーションサービス６１４を識別し、それをインスタンス化した後、呼び出して、オペレーションを実行する。異なるサービスＩＤを受け渡すだけで、サービスを変更することができる。

随時的な置換の場合、業務オペレーションサービスの組み込み選択候補をオーバライドするのに例示的に使用できる２つの異なる方法が存在する。例えば、業務オペレーション３を置き換えると仮定する。本発明の一実施形態では、サービスＩＤは、図１０に示すメタデータ構造などのメタデータ構造内に記憶される。図１０には、Ｏｐｅｒａｔｉｏｎｓと呼ばれるメタデータ項目を含む、メタデータ構造６２５の一部分が示されている。Ｏｐｅｒａｔｉｏｎｓは３つの業務オペレーションを含み、その各々は複数のプロパティを含み、その１つがサービスＩＤである。この場合、ベンダは、オーバライドされる業務オペレーションのサービスＩＤを保持するメタデータの一部を単純にカスタマイズすることができる。

例えば、業務オペレーション１のサービスＩＤをカスタマイズして、代わりに業務オペレーション番号４のサービスＩＤにすると仮定する。図１０には、業務オペレーションカスタマイズテーブルと呼ばれるテーブル６２７が示されており、このテーブルは、メタデータ識別子（メタデータ構造内のサービスＩＤエントリ用の識別子）と、サービスＩＤを番号４にカスタマイズすることを示すデルタを含む。カスタマイズをこの処理に適用する場合、サービスＩＤ番号１が、カスタマイズされたサービスＩＤ番号４に置き換えられる。このＩＤが、使用される業務オペレーションサービスファクトリに受け渡され、サービス番号４の業務オペレーションがインスタンス化され、呼び出される。エージェントがファクトリにサービスＩＤを受け渡すことはなく、ファクトリは通常通り、メタデータ構造内の関連するデフォルトサービスＩＤを検索しに行く。この検索によって取得されるのは、カスタマイズされたサービスＩＤであり、ファクトリは、オリジナルとして指定されたサービスの代わりに、置換業務オペレーションサービスをインスタンス化する。

随時的置換カスタマイズを実装するための別の方法も、図９には示されている。この実施形態では、利用される特定のサービスファクトリがイベントを伝達する。サービスオペレーションをカスタマイズしたいベンダは、このイベントを予約し、サービスＩＤの値を変更するため、関連するイベントハンドラ中にロジックを置く。この方法は、業務オペレーションのカスタマイズを可能にするばかりでなく、業務オペレーションエージェント内に含まれるデータに基づいた動的なサービス選択も可能にする。例えば、図９に示すように、エージェント６１０が業務オペレーションサービスファクトリ６１２を呼び出して、業務オペレーションサービスをインスタンス化するとき、ファクトリ６１２は、イベント６２２を伝達することができる。関連するイベントハンドラに追加されたカスタムロジックは、サービスＩＤの値を変更し、それをファクトリ６１２に返すことができる。カスタムイベントコードがサービスＩＤの設定を選択しない場合、サービスＩＤのデフォルト値（および可能性としてカスタマイズ値）がメタデータ記憶域から読み出される。

依存関係
本発明の一実施形態が、カスタマイズ間に依存関係（ｄｅｐｅｎｄｅｎｃｙ）を導入していることも注目に値する。言い換えると、あるベンダまたは製造元が製品をカスタマイズして出荷し、さらにユーザがその製品をカスタマイズする場合、データ項目のカスタマイズを、同じデータの先に行われたカスタマイズに依存させることができる。したがって、カスタマイズフレームワークの基底クラスは、どのカスタマイズが他のどのカスタマイズに依存しているかを示すリストを維持する。カスタマイザがカスタマイズの生成または削除を行いたい場合、基底アダプタクラスは最初に、当該カスタマイズに他のカスタマイズが依存しているかどうか判定する。したがって、各カスタマイズは、関連する依存関係リストを有する。カスタマイザがカスタマイズを行う前にすべての依存関係に確かに対処したかどうかを依存関係に照らして確かめるメソッドが、アダプタシステム内で呼び出される。

具体的な実施形態を参照しながら本発明を説明してきたが、本発明の主旨および範囲から逸脱することなく、形態および細部に変更を施すことができることは、当業者には理解されよう。

本発明を適用できる実施形態の一環境のブロック図である。 本発明を適用できる実施形態のオブジェクトリレーショナル（またはエンティティリレーショナル）データベースのブロック図である。 本発明を適用できる実施形態の、カスタマイズフレームワークのＵＭＬクラス図である。 本発明を適用できる実施形態の、コンテキスト維持の一実施形態を示したブロック図である。 本発明を適用できる実施形態の、エンティティ拡張システムを示した図である。 本発明を適用できる実施形態の、エンティティがカスタマイズまたは拡張された後の図５に示すエンティティ拡張システムを示した図である。 本発明を適用できる実施形態の、エンティティを拡張する方法を示したフローチャートである。 本発明を適用できる実施形態の、エンティティ間のリレーションを変更することによってエンティティをカスタマイズする方法を示したブロック図である。 本発明を適用できる実施形態の、メタデータ構造およびカスタマイズの一実施形態を示した図である。 競合解決テーブルの一実施形態を示した図である。 本発明を適用できる実施形態のシステム画面のカスタマイズの一例を示したスクリーンショットの図である。 本発明を適用できる実施形態のシステム画面のカスタマイズの一例を示したスクリーンショットの図である。 本発明を適用できる実施形態のシステム画面のカスタマイズの一例を示したスクリーンショットの図である。 本発明を適用できる実施形態の業務アクティビティの表現の一実施形態を示したブロック図である。 本発明を適用できる実施形態のメタデータのカスタマイズによって業務アクティビティをカスタマイズする一実施形態を示した図である。

符号の説明

１００ コンピューティングシステム環境
１１０ コンピュータ
１２０ プロセッサ
１２１ システムバス
１３０ システムメモリ
１３１ ＲＯＭ
１３２ ＲＡＭ
１３３ ＢＩＯＳ
１３４ オペレーティングシステム
１３５ アプリケーションプログラム
１３６ その他のプログラムモジュール
１３７ プログラムデータ
１４０ ノンリムーバブルメモリインタフェース
１４１ ハードディスクドライブ
１４４ オペレーティングシステム
１４５ アプリケーションプログラム
１４６ その他のプログラムモジュール
１４７ プログラムデータ
１５０ リムーバブルメモリインタフェース
１５１ 磁気ディスクドライブ
１５２ リムーバブルな不揮発性磁気媒体
１５５ 光ディスクドライブ
１５６ リムーバブルな不揮発性光ディスク
１６０ ユーザ入力インタフェース
１６１ ポインティングデバイス
１６２ キーボード
１６３ マイクロホン
１７０ ネットワークインタフェース
１７１ ＬＡＮ
１７２ モデム
１７３ ＷＡＮ
１８０ リモートコンピュータ
１８５ リモートアプリケーションプログラム
１９０ ビデオインタフェース
１９１ モニタ
１９５ 出力周辺インタフェース
１９６ プリンタ
１９７ スピーカ
２００ Ｅ−Ｒ図
２０２ エンティティ
２０４ リレーショナルデータベース
２０６ データアクセスシステム
２０８ エンティティ−リレーショナル（ＥＲ）マップ
２２０ カスタマイズフレームワーク
２２２ カスタマイズサブシステム
２２４ カスタマイザユーザインタフェース
２２６ カスタマイズイネーブルサブシステム
２２８ 外部コンポーネント
２３０ アダプタサブシステム
２３２ ターゲットサブシステム
２３４ 基底クラスＳｕｂｓｙｓｔｅｍＡｄａｐｔｅｒ
２３６ データ型アダプタ
２３８ データ型アダプタ
２４０ データ型アダプタ
２４２ データ型アダプタ
２４４ 基底クラスＴａｒｇｅｔ
２４６ データ型ターゲット
２４８ データ型ターゲット
２５０ データ型ターゲット
２５２ データ型ターゲット
２５４ ＧｅｎｅｒａｔｅｄＡｓｓｅｔエンティティ
２５６ Ｃｏｎｔｅｘｔエンティティ
２５７ コンテキストテーブル
２５９ カスタマイズテーブル
２６１ カスタマイズ−コンテキストテーブル
２８０ 基底のエンティティ
２８２ 顧客ＥＲマップエントリ
２８４ 顧客ＥＡマップ
２８６ 顧客テーブル
２８８ 基底のＥｘｔｅｎｓｉｏｎエンティティ
３００ Ｅｘｔｅｎｓｉｏｎエンティティ
３０１ 好まれる技術者エンティティ
３０２ Ｅｘｔｅｎｓｉｏｎエンティティ
３０３ 好まれる技術者Ｅ−Ｒマップ
３０４ 拡張プロパティ
３０５ 好まれる技術者Ｅ−Ａマップ
３０６ 拡張プロパティ
３２０ テーブル
３２２ 追加フィールド
３２４ 追加フィールド
３２６ テーブル
３２８ テーブル
３３０ テーブル
４５０ スクリーンショット
５００ メタデータ構造木
５０２ メタデータカスタマイズエンティティ
５０４ メタデータカスタマイズテーブル
５１０ 競合解決テーブル
６００ 業務アクティビティ
６０２ 業務オペレーションエージェント
６０４ 業務オペレーションサービスファクトリ
６０６ 業務オペレーションエージェント
６０８ 業務オペレーションサービスファクトリ
６１０ 業務オペレーションエージェント
６１２ 業務オペレーションサービスファクトリ
６１４ 業務オペレーションサービス
６２７ 業務オペレーションカスタマイズテーブル

Claims (14)

1. ソフトウェアで実施される業務処理をカスタマイズする方法であって、
   オペレーションの実行を要求するリクエストに応答して、サービス識別子に基づき、サービスをインスタンス化し呼び出すエージェントを提供するステップと、
   カスタマイズされたサービスを識別するために、前記エージェントが使用する前記サービス識別子をカスタマイズするステップと
   を備えることを特徴とする方法。
2. 前記サービス識別子を変更するステップは、前記エージェントで実行するメソッド中で、前記変更された識別子を前記エージェントに渡すステップを含む
   ことを特徴とする請求項１に記載の方法。
3. 前記識別子は、前記サービスに関連する、メタデータストア内のサービス識別子メタデータとして保存され、変更するステップが、
   前記カスタマイズされたサービスを指示するように、前記サービス識別子メタデータをカスタマイズするステップを含む
   ことを特徴とする請求項１に記載の方法。
4. 前記サービス識別子メタデータをカスタマイズするステップは、
   カスタマイズストア中の前記カスタマイズされたサービス識別子メタデータを指示するデルタ値を保存するステップを含む
   ことを特徴とする請求項３に記載の方法。
5. 前記サービス識別子メタデータをカスタマイズするステップは、
   前記エージェントが後で呼び出されたときに、前記サービス識別子を前記デルタ値を用いてカスタマイズするステップを含む
   ことを特徴とする請求項４に記載の方法。
6. 前記業務処理は、前記エージェントによって呼び出されるサービスファクトリを含み、前記サービスファクトリは、前記メタデータにアクセスし、前記サービス識別子によって識別される前記サービスを呼び出すように構成され、前記サービス識別子をカスタマイズするステップは、
   前記サービスファクトリが前記メタデータにアクセスする前に、前記サービス識別子を前記デルタ値を用いてカスタマイズするステップを含む
   ことを特徴とする請求項５に記載の方法。
7. デルタ値を保存するステップは、
   サービス識別子を前記メタデータに追加するよう指示するデルタ値を保存するステップを含む
   ことを特徴とする請求項４に記載の方法。
8. デルタ値を保存するステップは、
   前記メタデータ中の既存のサービス識別子に変更するよう指示するデルタ値を保存するステップを含む
   ことを特徴とする請求項３に記載の方法。
9. 前記業務処理は、前記エージェントによって呼び出されるサービスファクトリを含み、カスタマイズするステップは、
   前記エージェントによって呼び出されたときにイベントを伝達するように前記サービスファクトリを構成するステップと
   前記イベントに応答して前記サービスファクトリにサービス識別子を返すように構成されたイベントハンドラを提供するステップとを含む
   ことを特徴とする請求項１に記載の方法。
10. クライアントからのリクエストによって呼び出し可能なエージェントと、
    サービス識別子をインスタンス化し呼び出すことを要求するリクエストに応答して、前記エージェントによって呼び出し可能なサービスファクトリと
    を備えたことを特徴とするカスタマイズ可能な業務処理。
11. 前記サービスファクトリは、カスタマイズされたサービス識別子を受け取り、前記カスタマイズされたサービス識別子に基づくサービスをインスタンス化し呼び出すように構成される
    ことを特徴とする請求項１０に記載の処理。
12. 前記サービスファクトリは、前記カスタマイズされたサービス識別子を前記エージェントから受け取るように構成される
    ことを特徴とする請求項１１に記載の処理。
13. 前記サービスファクトリは、前記サービス識別子をメタデータとして取得するように構成され、
    前記サービスファクトリが前記サービス識別子を取得する前に、前記サービス識別子をカスタマイズされた値を用いてカスタマイズするように構成されるカスタマイズサブシステムをさらに含む
    ことを特徴とする請求項１１に記載の処理。
14. コンピュータで実施される業務処理をカスタマイズするためのシステムであって、
    カスタマイズ可能なサブシステムからの処理カスタマイズの入力を受け取るため呼び出されるように構成されるメソッドを有するアダプタサブシステムであって、前記入力はカスタマイズされる処理にカスタマイズを適用するよう要求するリクエストを示し、前記アダプタサブシステムは前記リクエストに基づいてカスタマイズされるコンポーネントを識別するアダプタサブシステムと、
    前記リクエストされたカスタマイズを前記識別されたコンポーネントに適用するため前記アダプタサブシステムによって呼び出されるように構成されるメソッドを有するターゲットサブシステムと
    を備えたことを特徴とするシステム。
    

Images