(57)【特許請求の範囲】
【請求項１】
コンピュータに実装されるソフトウェアシステムをカスタマイズするためのカスタマイズフレームワークであって、
カスタマイザに前記カスタマイズフレームワークへのアクセスを提供し、前記カスタマイザから、前記ソフトウェアシステムのカスタマイズ対応サブシステムのエンティティに対して適用すべきカスタマイズの指定を受け取るように構成された、カスタマイザインターフェースと、
前記カスタマイズ対応サブシステムによって、カスタマイズを行うためのメソッドが呼び出されると、前記ソフトウェアシステムのコンテキストに基づいて前記カスタマイズ対応サブシステムのカスタマイズすべきエンティティを特定し、前記特定されたエンティティの拡張エンティティを作成し、前記作成された拡張エンティティを前記カスタマイズ対応サブシステムに適用する、ターゲットシステムであって、前記拡張エンティティを作成することは、前記特定されたエンティティのプロパティをカスタマイズすることを含む、前記ターゲットシステムと
を備えるカスタマイズフレームワークとしてコンピュータを機能させることを特徴とするプログラム。
【請求項２】
前記カスタマイズ対応サブシステムのエンティティはメタデータを備え、前記拡張エンティティを作成することは、前記エンティティのメタデータをカスタマイズすることを含むことを特徴とする請求項１に記載のプログラム。
【請求項３】
前記カスタマイズフレームワークは、前記ソフトウェアシステムのコンテキストを識別するためのコンテキスト情報を有するコンテキストエンティティと、
前記コンテキストに基づいて前記カスタマイズ対応サブシステムのカスタマイズすべきエンティティを特定するように構成されたアダプタサブシステムと
をさらに備えたことを特徴とする請求項１に記載のプログラム。
【請求項４】
コンピュータに実装されるソフトウェアシステムを、ソースコードを変更することなくカスタマイズするための方法であって、
コンピュータが、カスタマイザから、前記ソフトウェアシステムのカスタマイズ対応サブシステムのエンティティに対して適用すべきカスタマイズの指定を受け取ることと、
コンピュータが、前記カスタマイズ対応サブシステムによってカスタマイズを行うためのメソッドを呼び出すことと、
コンピュータが、前記ソフトウェアシステムのコンテキストに基づいて前記カスタマイズ対応サブシステムのカスタマイズすべきエンティティを特定することと、
コンピュータが、エンティティ拡張のためのインストールメソッドをコールして、前記特定されたエンティティの拡張エンティティを作成し、および前記作成された拡張エンティティを前記カスタマイズ対応サブシステムに適用することであって、前記拡張エンティティを作成することは、前記特定されたエンティティのプロパティをカスタマイズすることを含むことと
を備えることを特徴とする方法。
【請求項５】
コンピュータが、所与のカスタマイズとコンテキストのマッピングを示すコンテキスト情報を有するコンテキストコンポーネントにアクセスして、前記ソフトウェアシステムの現在のコンテキストを識別することと、
コンピュータが、前記コンテキスト情報に基づいて識別される前記現在のコンテキストに基づいてカスタマイズされる前記エンティティを特定することを特徴とする請求項４に記載の方法。
【請求項６】
前記特定されたエンティティは、メタデータを備え、
前記拡張エンティティを作成することは、前記メタデータをカスタマイズすることを備えることを特徴とする請求項４に記載の方法。
【請求項７】
前記特定されたエンティティは、プロセスを備え、
前記拡張エンティティを作成することは、前記プロセスをカスタマイズすることを備えることを特徴とする請求項４に記載の方法。
【請求項８】
前記特定されたエンティティは、イベントコードを備え、
前記拡張エンティティを作成することは、前記イベントコードをカスタマイズすることを備えることを特徴とする請求項４に記載の方法。
【請求項９】
前記拡張エンティティを前記カスタマイズ対応サブシステムに適用することは、
前記特定されたエンティティに既に存在する情報を変更することを備えることを特徴とする請求項４に記載の方法。
【請求項１０】
前記拡張エンティティを前記カスタマイズ対応サブシステムに適用することは、
前記特定されたエンティティに情報を追加することを備えることを特徴とする請求項４に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソースコードを使用してユーザが望むアプリケーションおよびプログラムを実施するコンピューティング環境に関する。より詳細には、本発明は、ソースコードを変更することなくコンピュータプログラムまたはコンピュータアプリケーションのカスタマイズを可能にするフレームワークに関する。
【背景技術】
【０００２】
コンピュータソフトウェア関連製品を設計し、販売することに対する１つの手法は、製品が大きな業界区分にわたり、また多くの異なる国々にわたって広く適用可能となるように水平的な機能を中心に扱うことである。そのようなシステムはまた、特定の垂直的なターゲット市場および特定の会社の固有のニーズを満たすアフターマーケットを振興することができることが望ましい。同様に、製品は、顧客の個々のニーズに合わせてユーザが製品を変更したり、またはカスタマイズしたりすることができるようにすることもできることが望ましい。
【０００３】
顧客の固有のニーズを満たすように製品を拡張することができない場合、基本的に顧客は、購入したばかりのソフトウェアに自身のビジネスを合致するように変更することを求められる。当然、それらのタイプのシステムは顧客から抵抗を受ける。というのは、ビジネス活動の変更には、コストがかかり、時間がかかるからである。
【０００４】
従来、システムをカスタマイズすることができるようにするために使用されてきたいくつかの異なる技法が存在する。そのような従来の技法には、例えば、ソースコード変更が含まれる。この技法は、製品に関するソースコードのコピーを顧客に提供することを必然的に伴う。したがって、この技法は、熟練した専門家が相当な量の内容を変更することを可能にし、それらの変更が、あたかも製品の一部であるかのように見えるようにすることができる。というのは、実際、それらの変更は、変更されたソースコード製品の一部になっているからである。
【０００５】
しかし、ソースコード変更は、相当な欠点を抱えている。例えば、ソースコード変更は、製品を使用するのに先立って多額の費用がかかる。というのは、多くの場合、ユーザまたは顧客が、どのように製品を構築するかのニュアンスについて特別に訓練を受けたコンサルタントおよび開発者を雇わなければならないからである。すると、ユーザは、問題を推定するというリスクに耐えなければならず、これは非常に困難で不明確な作業である。それらの問題を克服し、やり通すことができたとしても、結果は、変更されたソースコードである。元のソースコードの製造業者が、バグ修正、更新、および新しいバージョンなどの追加のソフトウェアを出荷したときには、顧客は、製造業者によって出荷された新しいソースコードにそれらの変更を結合させるために再び有能な技術者または開発者（願わくは、最初の変更を行ったのと同じ者）を雇い、新たに変更されたソースコードに問題が生じると、その問題を１つずつ解決することを余儀なくされる。あるいは、ユーザは、ユーザのビジネスに利益をもたらす可能性があるこうしたバグ修正や新しい機能なしで単に済ますことができる。
【０００６】
さらに、ソースコード変更により、複数の異なるベンダーから単に「既製品として（ｏｆｆ  ｔｈｅ  ｓｈｅｌｆ）」アドオン（ａｄｄ−ｏｎ）モジュールを購入することが極めて困難になる。というのは、それらのベンダーのそれぞれが、ソースコードを同様に変更して、彼ら特有の既製品のモジュールを適応させなければならない可能性が高いと思われるからである。その結果、製造業者が、基本製品のソースコードを出荷しなければならないだけでなく、各アドオンベンダーも、それぞれのソースを同様に出荷しなければならない。すると、ユーザは、何らかのアドホック的な結合プロセス（ａｄｈｏｃ  ｍｅｒｇｅ  ｐｒｏｃｅｓｓ）を行うか、それらランダムなセットのソースコードから単一の製品を合成しなければならない。もちろん、これにより、アップグレードで、またはベンダーのいずれかがバグ修正を出荷した際に問題が出ることはほとんど間違いない脆弱なコードセットがもたらされる結果になる。
【０００７】
また、ソースコード変更では、世界中で１つの組織（ソースコードを変更した特定の開発者または技術者）だけが、変更されたソースコード製品がどのように構築されたかを知っているという問題も抱えている。したがって、顧客のサイトにおいて実行されている製品のいずれに関しても、規模の経済や製品サポートを実現することが、不可能ではないとしても、困難である。
【０００８】
ソースコード変更が抱える問題は、単一の顧客内でさえも、多様なニーズおよび好みのセットを有する多様なユーザの集合が存在する場合、顕著に増大する。それらのユーザの１人が、自らの特定のニーズに対応させるためにソースコード変更の方策を通じて製品を変更するたびに、それらのユーザを雇用している顧客は、事実上、新たなソースコードベースを有する結果となる。言い換えれば、顧客は、単一のカスタムコードベースを有するだけでなく、顧客内のどれだけの数の特定のユーザまたは部門がコードベースを変更したかに応じて、実際には多数のカスタムコードベースを有することになる。この場合も、バグ修正が公開されたり、すべてのユーザに適用されるカスタマイズの変更が行われたりするたびに、顧客は、作成されたソースの他のすべてのコピーを対象に何らかの結合プロセスを行わなければならない。
【０００９】
以上は、ソースコード変更技法に関連する多くの問題の部分的リストに過ぎない。これらの問題により、顧客の経営陣、ならびに従業員自身にとって相当な困難がもたらされる可能性がある。
【００１０】
オブジェクトに基づいているコンピュータプログラムをある限られた範囲で変更できるようにする別の技法には、ユーザが定義することができるユーザフィールドを追加することが含まれる。言い換えれば、「カスタマイズ可能」となっている各オブジェクトは、ユーザの望みどおり、ユーザが定義したり、使用したりすることができる１つまたは複数のユーザフィールドを有するように最初に定義される。この技法は、ある種のカスタマイズを可能にするが、前述したすべての問題を解決するわけではない。また、この技術は、多くの独自の問題も抱えている。例えば、ユーザフィールドに関連する命名規則は、それらのユーザフィールドの特定の用途との関連付けを直感的ではなく、困難にしている。例えば、追加のユーザフィールドには、通常、「ＵＳＥＲＦＩＥＬＤ．１」ないし「ＵＳＥＲＦＩＥＬＤ．Ｎ」のような非常に一般的な名前が付けられる。各ユーザフィールドが何に使用されていたかをユーザが憶えていることは、不可能ではないとしても、困難である。さらに、追加のユーザフィールドは、複数ベンダー、または異なる組織による複数の変更に関連する問題を解決しない。例えば、１つのベンダー、または１名のユーザが、ユーザフィールドを第１のやり方で割り当てるが、別のベンダー、または別のユーザが、同じユーザフィールドを異なるやり方で割り当てた場合、そのユーザフィールドがどのように定義されているかに矛盾が存在し、その２つのベンダー、または２名のユーザに関連する２つの製品は、さらなる変更がなくしては一緒に機能しないであろう。
【００１１】
カスタマイズを行うためのその他の技法も同様に試みられている。例えば、カスタムイベントコードを書き込むことによってカスタマイズを行うことができる。すると、ソースコードの元のオブジェクトに対して１対１のマッピングを使用することにより、元のオブジェクトに関してイベントが発生したときに「カスタマイズされた」オブジェクトを操作することができる。以前使用されている別の技法は、「プロパティバッグ（ｐｒｏｐｅｒｔｙ  ｂａｇ）」や名前−値ペア（ｎａｍｅ−ｖａｌｕｅ  ｐａｉｒ）を含めることである。これらの技法は両方とも、かなりの欠点を有し、ソースコード変更に関連する不備を改善しない。
【特許文献１】米国特許第５９３６８６０号明細書
【発明の開示】
【発明が解決しようとする課題】
【００１２】
以上のように、従来の技法には種々の問題があり、さらなる改善が望まれている。本発明は、このような状況に鑑みてなされたものであり、その目的とするところは、ソースコードを変更することなくコンピュータプログラムまたはコンピュータアプリケーションのカスタマイズを可能にするフレームワークを提供することにある。
【課題を解決するための手段】
【００１３】
カスタマイズフレームワークが、カスタマイズ可能なサブシステムからカスタマイズを示すカスタマイズ入力を受け取るように構成された設計コンポーネントを含む。ランタイムコンポーネントが、カスタマイズ可能なサブシステムから要求を受け取り、その要求に基づいてカスタマイズ可能なサブシステムの部分を特定し、カスタマイズする。
【発明を実施するための最良の形態】
【００１４】
本発明は、コンピュータソフトウェアのカスタマイズに関する。しかし、本発明をさらに詳細に説明する前に、本発明を使用することができる例示的な環境の一実施形態について説明する。
【００１５】
図１は、本発明を実施することができる適切なコンピューティングシステム環境１００の一例を示している。コンピューティングシステム環境１００は、適切なコンピューティング環境の一例に過ぎず、本発明の用途または機能の範囲に関して何らの限定を示唆するものではない。また、コンピューティング環境１００が、例示的な動作環境１００に例示した構成要素のいずれか１つ、またはいずれの組合せに関連して何らの依存関係または要件を有するものと解釈されるべきではない。
【００１６】
本発明は、数多くの他の汎用または特殊目的のコンピューティングシステム環境または構成で機能する。本発明と共に使用するのに適している可能性がある周知のコンピューティングシステム、コンピューティング環境、および／またはコンピューティング構成の例には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマ可能な民生用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、以上のシステムもしくはデバイスのいずれかを含む分散コンピューティング環境等が含まれるが、これらには限定されない。
【００１７】
本発明は、コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で説明することができる。一般に、プログラムモジュールには、特定のタスクを行うか、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等が含まれる。また、本発明は、通信網を介してリンクされた遠隔の処理デバイスによってタスクが行われる分散コンピューティング環境において実施することも可能である。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含むローカルおよび遠隔のコンピュータ記憶媒体の両方に配置することが可能である。
【００１８】
図１を参照すると、本発明を実施するための例示的なシステムは、コンピュータ１１０の形態の汎用コンピューティングデバイスを含んでいる。コンピュータ１１０の構成要素は、処理ユニット１２０、システムメモリ１３０、ならびにシステムメモリから処理ユニット１２０までを含む様々なシステム構成要素を結合するシステムバス１２１を含むことができるが、これらには限定されない。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺バス、および様々なバスアーキテクチャのいずれかを使用するローカルバスを含むいくつかのタイプのバス構造のいずれかとすることができる。限定としてではなく、例として、そのようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ  ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニン（Ｍｅｚｚａｎｉｎｅ）バスとしても知られるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）バスが含まれる。
【００１９】
コンピュータ１１０は、通常、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０によってアクセスすることができる任意の利用可能な媒体とすることができ、揮発性の媒体および不揮発性の媒体、取外し可能な媒体および取外し不可の媒体がともに含まれる。限定としてではなく、例として、コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を格納するために任意の方法または技術で実装された揮発性および不揮発性の媒体、取外し可能および取外し不可の媒体がともに含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光ディスクストーレッジ、磁気カセット、磁気テープ、磁気ディスクストーレッジまたは他の磁気記憶装置、あるいは所望の情報を格納するために使用することができ、コンピュータ１１０によってアクセスすることができる任意の他の媒体が含まれるが、これらには限定されない。通信媒体は、通常、搬送波などの変調されたデータ信号、または他のトランスポート機構においてコンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータを実体化し、任意の情報配信媒体を含む。「変調されたデータ信号」という用語は、信号内に情報を符号化するような仕方でその特性の１つまたは複数が設定または変更されている信号を意味する。限定としてではなく、例として、通信媒体には、有線ネットワークまたは直接配線接続などの有線媒体、ならびに音響媒体、ＲＦ媒体、赤外線媒体、およびその他の無線媒体などの無線媒体が含まれる。また、前述した媒体のいずれかの組合せも、コンピュータ可読媒体の範囲に含まれるべきものである。
【００２０】
システムメモリ１３０は、読取り専用メモリ（ＲＯＭ）１３１やランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性メモリおよび／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。起動中など、コンピュータ１１０内の要素間で情報の転送を助ける基本ルーチンが入っている基本入力／出力システム（ＢＩＯＳ）１３３は、通常、ＲＯＭ１３１に格納されている。ＲＡＭ１３２は、通常、処理ユニット１２０によって即時にアクセス可能であり、そして／または現在処理中のデータおよび／またはプログラムモジュールを収容する。限定としてではなく、例として、図１は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示している。
【００２１】
また、コンピュータ１１０は、他の取外し可能／取外し不可、揮発性／不揮発性のコンピュータ記憶媒体を含むこともできる。単に例として、図１は、取外し不可の不揮発性の磁気媒体に対して読取り、または書込みを行うハードディスクドライブ１４１、取外し可能な不揮発性の磁気ディスク１５２に対して読取り、または書込みを行う磁気ディスクドライブ１５１、およびＣＤ−ＲＯＭまたは他の光媒体などの取外し可能な不揮発性の光ディスク１５６に対して読取り、または書込みを行う光ディスクドライブ１５５を示している。例示的な動作環境において使用することができる他の取外し可能／取外し不可の揮発性／不揮発性のコンピュータ記憶媒体には、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ等が含まれるが、これらには限定されない。ハードディスクドライブ１４１は、通常、インターフェース１４０のような取外し不可のメモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、通常、インターフェース１５０のような取外し可能なメモリインターフェースによってシステムバス１２１に接続されている。
【００２２】
前述し、図１に示したドライブおよび関連するコンピュータ記憶媒体により、コンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータのストーレッジがコンピュータ１１０に提供される。図１では、例えば、ハードディスクドライブ１４１が、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納しているのを示している。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じであっても、異なっていてもよいことに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７には、ここでは、少なくともそれらが異なるコピーであることを示すために異なる符号を付与している。
【００２３】
ユーザは、キーボード１６２、マイクロホン１６３、ならびにマウス、トラックボール、またはタッチパッドなどのポインティングデバイス１６１などの入力デバイスを介して、コンピュータ１１０にコマンドおよび情報を入力することができる。その他の入力デバイス（図示せず）には、ジョイスティック、ゲームパッド、衛星用アンテナ、スキャナ等を含むことができる。これらおよびその他の入力デバイスは、多くの場合、システムバスに結合されているユーザ入力インターフェース１６０を介して処理ユニット１２０に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースおよびバス構造で接続されてもよい。また、モニタ１９１、または他のタイプの表示デバイスは、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタに加えて、コンピュータは、スピーカ１９７やプリンタ１９６などの他の周辺出力デバイスも含むことができ、これらは出力周辺インターフェース１９５を介して接続することができる。
【００２４】
コンピュータ１１０は、遠隔コンピュータ１８０のような１つまたは複数の遠隔コンピュータに対する論理接続を使用してネットワーク化された環境において動作することができる。遠隔コンピュータ１８０は、パーソナルコンピュータ、ハンドヘルドデバイス、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることができ、通常、コンピュータ１１０に関連して前述した要素の多く、またはすべてを含む。図１に描いた論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３を含むが、その他のネットワークを含むこともできる。そのようなネットワーキング環境は、オフィス、企業全体のコンピュータ網、イントラネット、およびインターネットにおいて一般的である。
【００２５】
ＬＡＮネットワーキング環境で使用される場合、コンピュータ１１０は、ネットワークインターフェースまたはネットワークアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用される場合、コンピュータ１１０は、通常、モデム１７２、またはインターネットなどのＷＡＮ１７３を介して通信を確立するための他の手段を含む。内蔵であることも、外付けであることもあるモデム１７２は、ユーザ入力インターフェース１６０、またはその他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０に関連して示したプログラムモジュール、またはその部分は、遠隔のメモリ記憶装置に格納することができる。限定としてではなく、例として、図１は、遠隔コンピュータ１８０上に常駐しているものとして遠隔のアプリケーションプログラム１８５を示している。図示したネットワーク接続は、例示であり、コンピュータ間で通信リンクを確立する他の手段も使用できることが認められよう。
【００２６】
図２は、オブジェクト−リレーショナル（またはエンティティ−リレーショナル）データストレージシステムのブロック図である。この説明では、エンティティは、「オブジェクト」という用語と交換可能な仕方で参照することにする。Ｅ−Ｒシステム２００は、リレーショナルデータベース２０４に格納されたデータに対応する１組のエンティティ（またはオブジェクト）２０２を含んでいる。エンティティは、エンティティ−リレーショナル（ＥＲ）マップ２０８を利用するデータアクセスシステム２０６を介してリレーショナルデータにアクセスする。ＥＲマップ２０８には、エンティティ２０２とリレーショナルデータベース２０４内のテーブルエントリとの間のマッピングが入っている。本発明は、Ｅ−Ｒシステム以外の他のシステムにおいても使用することができ、図２に示したシステムは、本発明を使用することができるシステムの一例に過ぎないことに留意されたい。
【００２７】
図３は、本発明の一実施形態によるカスタマイズサブシステム２２２に関するカスタマイズフレームワーク２２０のＵＭＬ（Ｕｎｉｆｉｅｄ  Ｍｏｄｅｌｉｎｇ  Ｌａｎｇａｕｇｅ：  統一モデリング言語）のクラス図である。カスタマイズサブシステム（Ｃｕｓｔｏｍｉｚａｔｉｏｎ  Ｓｕｂｓｙｓｔｅｍ）２２２は、カスタマイザ（開発者、ユーザ、またはマネージャのような中間カスタマイザ）とカスタマイズサブシステム２２２との間の対話を提供するカスタマイザユーザインターフェース（Ｃｕｓｔｏｍｉｚｅｒ  Ｉｎｔｅｒｆａｃｅ）２２４に接続されているのが示されている。また、サブシステム２２２は、カスタマイズ対応サブシステム（ＣｕｓｔｏｍｉｚａｔｉｏｎＥｎａｂｌｅｄＳｕｂｓｙｓｔｅｍ）２２６に接続されているのが示されており、このサブシステム２２６は、次に本発明のカスタマイズ機能の外部のコンポーネント２２８に接続されている。
【００２８】
以下により詳細に説明するとおり、カスタマイザインターフェース２２４により、カスタマイザがシステム２２２にアクセスして、コンピュータソフトウェアにカスタマイズを行うことが可能になる。外部のコンポーネント２２８は、カスタマイズされたソフトウェアの一部にアクセスすること望む、ユーザなどの任意のコンポーネントとすることができる。カスタマイズ対応サブシステム２２６は、ユーザによって使用されるコンピューティング環境内の任意のサブシステムであり、カスタマイズすることが可能なようにカスタマイズシステム２２２と対話するように構成されている。
【００２９】
カスタマイズサブシステム２２２は、アダプタシステム（ａｄａｐｔｏｒ  ｓｙｓｔｅｍ）２３０およびターゲットシステム（ｔａｒｇｅｔ  ｓｙｓｔｅｍ）２３２を含む。アダプタシステム２３０は、基本クラスのＳｕｂｓｙｓｔｅｍＡｄａｐｔｅｒ２３４、および複数のデータ型のアダプタ２３６、２３８、２４０、および２４２を使用して実装されている。ターゲットシステム２３２は、基本クラスのＴａｒｇｅｔ２４４、および複数のデータ型のターゲット２４６、２４８、２５０、および２５２を介して実装されている。また、ターゲットシステム２３２は、ＧｅｎｅｒａｔｅｄＡｓｓｅｔエンティティ２５４に対してコンポジションの関係にもある。システム２３０と２３２はともに、Ｃｏｎｔｅｘｔエンティティ２５６へのアクセスを有している。
【００３０】
アダプタシステム２３０は、カスタマイズ対応サブシステム２２６とフレームワーク２２０の間の１次接続ポイントとして動作する。アダプタシステム２３０は、サブシステム２２６に全体として適用するカスタマイズロジックを実装している。他方、ターゲットシステム２３２には、カスタマイズが望まれるデータ型の特定のインスタンスをカスタマイズするために使用されるロジックが入っている。
【００３１】
Ｃｏｎｔｅｘｔエンティティ２５６は、現在のコンテキストを特定するコンテキスト情報が入っている。例えば、カスタマイズが、組織において異なる役割をする人々に異なる仕方で適用されるようにすることが望ましい場合がある。同様に、カスタマイズが、組織内の異なる部門に異なる仕方で適用されることも望ましい場合がある。Ｃｏｎｔｅｘｔエンティティ２５６は、現在のコンテキストに該当し、関連付けられたカスタマイズが行われるように、そのコンテキストを識別する情報が入っている。これについては、図４に関連してより詳細に説明する。
【００３２】
以下に説明するとおり、フレームワーク２２０は、拡張可能である。サブシステムがカスタマイズ対応になるためには、単にフレームワーク２２０に対するインターフェースをサポートしなければならない。サブシステムが、カスタマイズについて追加のデータ型を有する限りにおいて、行われなければならないステップは、カスタマイズが望まれるデータ型にアダプタ（アダプタ２４２のような）を提供することである。同様に、サブシステムの作成者は、ターゲット（ターゲットエンティティ２５２のような）を作成しなければならない。アダプタとターゲットエンティティは、共に、サブシステムの作成者によって所望されたとおりサブシステムをカスタマイズするためのカスタマイズロジックを有する。そのようなサブシステムは、ユーザがそれを通してサブシステムの型のカスタマイズを作成することができる追加のカスタマイザインターフェース２２４を作成することができることも理解されよう。
【００３３】
本発明の一実施形態によれば、カスタマイズされる必要があるかもしれないソフトウェアには、コンテンツのいくつかの基本クラスが含まれ、このコンテンツには、ユーザインターフェースコンテンツ、データおよびプロセスコンテンツが含まれる。ユーザインターフェースコンテンツには、ユーザがスクリーン上またはレポート上で見るコンテンツが含まれる。ユーザインターフェースコンテンツは、レイアウト情報、メッセージ、フィールドラベルなどの事項を収容することができる。データは、システムが格納する情報を表わす。例えば、データには、顧客、在庫品目、注文等が含まれる。プロセスコンテンツは、定義されたステップのセットを通じて作業を経路指定するワークフロー仕様、ならびにあるデータに関して明確に定義されたアクションを実行するより低レベルの処理ロジックを含む。プロセスコンテンツの例には、例えば、ワークフロー、および注文を元帳に記入したり、在庫品目を確保したりするより低レベルの処理ロジックを挙げることができる。これらのタイプのコンテンツ、ならびに他のタイプは本発明の様々な実施形態に従ってカスタマイズすることができる。
【００３４】
カスタマイズされるコンテンツのタイプにかかわらず、カスタマイズは、所与のコンテキストと関連付けられることが望ましい場合がある。コンテキストは、いつカスタマイズが該当するかを決定する。つまり、コンテキストの意向により、一部のカスタマイズを特定のユーザだけに適用し、他のカスタマイズを特定の集団に属するユーザの集合全体に適用し、さらに別のカスタマイズをユーザにかかわらず、会社全体に適用することが可能になる。以上は、コンテキストの３つの異なる例に過ぎず、多くの他のコンテキストも同様に使用することができる。
【００３５】
コンテキスト（Ｃｏｎｔｅｘｔ）エンティティ２５６をアダプタシステム２３０またはターゲットシステム２３２によって呼び出し、現在のコンテキストを取得することができる。図４は、コンテキストエンティティ２５６によって表されるデータ構造の一実施形態を例示している。もちろん、コンテキストエンティティ２５６は、リレーショナルデータベース２０４の中にマップされたデータを表わす。図４は、どのカスタマイズがどのコンテキストに適用されるかを特定するために使用されるテーブルの一実施形態を例示している。
【００３６】
例示した実施形態では、コンテキストエンティティ２５６は、コンテキストテーブル２５７、カスタマイズテーブル２５９、およびカスタマイズ−コンテキストテーブル２６１を含むリレーショナルデータベース２０４内のテーブルにマップする。図４に例示した実施形態では、コンテキストテーブル２５７は、コンテキスト識別番号でコンテキストを識別するフィールドを含む。コンテキストテーブル２５７は、特定のユーザを識別するユーザＩＤ、マネージャ、販売員、副社長などの組織内の役割を識別する役割、出荷部門、販売部門などの会社の事業単位を識別する組織、および地理的場所を表わす場所を含む４つの項目のコンテキストを示している。もちろん、多種多様な追加のコンテキスト要素も同様に使用することができる。
【００３７】
コンテキストテーブル２５７内の第１のコンテキストエントリは、第１のコンテキストＩＤが欧州のすべてのマネージャと関連付けられていることを示している。第２のコンテキストＩＤは、ユーザＩＤ１２３４５を有する特定のユーザと関連付けられており、第３のコンテキストＩＤは、出荷部門のマネージャと関連付けられている。カスタマイズテーブル２５９は、システムに入力されている種々のカスタマイズと関連付けられた識別子、ならびにカスタマイズＩＤと関連付けられた特定のカスタマイズを指定するカスタマイズデータを含む。カスタマイズ−コンテキストテーブル２６１は、コンテキストＩＤとカスタマイズＩＤとの間をマップする。したがって、指定されたＩＤを有するカスタマイズが、関連付けられたコンテキストＩＤフィールドで特定された様々なコンテキストに適用される。もちろん、複数のコンテキストを任意の所与のカスタマイズにマップすることができ、複数のカスタマイズを任意の所与のコンテキストにマップすることができる。
【００３８】
また、他のテーブル構成も使用することができ、図４に示した構成は一例に過ぎない。例えば、テーブル２６１をなくすことができ、コンテキストテーブル２５７が、カスタマイズＩＤフィールドを備えることも同様に可能である。コンテキストテーブルに複数の行を持たせることにより、単一のカスタマイズに対して多くのコンテキストをさらに存在させることができる。
【００３９】
いずれにしても、システム２３０および２３２は、コンテキストエンティティ２５６から現在のコンテキストを要求することができ、エンティティ２５６は、一実施形態では、現在のコンテキストにおいて適用される必要がある特定のカスタマイズの識別情報を戻すこともできる。
【００４０】
（エンティティ拡張）
カスタマイズフレームワーク２２０の動作をよりよく例示するため、次に、図５〜６Ｂと併せて図３に関する説明に進む。これらの図は、エンティティのカスタマイズをよりよく例示している。これは、本明細書で、「エンティティ拡張（Ｅｎｔｉｔｙ  Ｅｘｔｅｎｓｉｏｎ）」とも呼ぶ。
【００４１】
図５は、カスタマイズ対応サブシステム内のエンティティが作成されるときに作成されるデータ構造を示している。図６Ａは、エンティティがカスタマイズされるときに作成され、または変更されるデータ構造に加えて、図５に示したデータ構造を示している。図６Ｂは、図６Ａのエンティティがどのように作成されたり、変更されたりするかを示す流れ図である。
【００４２】
図５は、ビジネスアプリケーションにおける基本エンティティ２８０を示している。例示的なビジネスエンティティ２８０は、ビジネスアプリケーションにおいて顧客を識別する「顧客（Ｃｕｓｔｏｍｅｒ）」エンティティである。図示した特定の例は、例に過ぎず、本発明の概念は他のエンティティにも同様に適用されることが、当然に理解されよう。基本エンティティ２８０は、実行（またはカスタマイズ）されているエンティティを表わす。図５は、基本エンティティ２８０が、ＥＲマップ２０８（図２に示す）内の顧客ＥＲマップエントリ２８２によってリレーショナルデータベース２０４にマップされていることも示している。基本エンティティ２８０とその他のエンティティとの間の関係は、顧客ＥＡ（Ｅｎｔｉｔｙ  Ａｓｓｏｃｉａｔｉｏｎ：  エンティティの関連）マップ２８４の中で識別特定される。図５は、リレーショナルデータベース２０４が、例示として、顧客ＩＤフィールド、名前フィールド、アドレスフィールド、および顧客を識別するために所望される任意の他のフィールドを含む顧客（Ｃｕｓｔｏｍｅｒ）エンティティ２８０と関連付けられた顧客テーブル２８６を含むこともさらに示している。
【００４３】
本発明は、エンティティをカスタマイズするためにソースコード変更を必要としないので、基本拡張エンティティ２８８をさらに提供して、基本エンティティ２８０を再コンパイルすることなく基本エンティティに新しいエンティティ関係を動的に追加することを可能にしている。基本拡張エンティティ２８８は、作成される基本エンティティ２８０ごとに作成される。基本拡張エンティティ２８８は、例示として、基本エンティティ２８０の名前を含み、本例では、基本拡張エンティティ２８８は、「ＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎ（顧客拡張）」と名付けられている。基本拡張エンティティ２８８は、最初は空であるが、顧客拡張Ｅ−Ｒマップ２９０および顧客拡張ＥＡマップ２９２を含むことができ、これらもやはり空である。基本エンティティ２８０は、基本拡張エンティティを識別するコンポジションフィールドを収容する。例えば、基本エンティティ２８０は、「ＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎ」というタイプの「Ｅｘｔｅｎｓｉｏｎ」と名付けられたコンポジションフィールドを含むことができる。顧客（Ｃｕｓｔｏｍｅｒ）エンティティ２８０のエンティティ関連メタデータは、顧客拡張（ＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎ）エンティティ２８８との関係を反映する。エンティティ２８０と２８８とはともに、例示として、本発明に従って製品がインストールされるときにＤＬＬとして出荷され、配備される。これらのエンティティおよび関連するマップの生成を図６Ｂにブロック４００および４０２で示している。この時点で、カスタマイザは、図３に示したインターフェース２２４のようなカスタマイザユーザインターフェースを介してＣｕｓｔｏｍｅｒエンティティ２８０に拡張プロパティを追加し始めることができる。
【００４４】
図６Ａは、どのように拡張プロパティが追加されることになるかを例示している。カスタマイザインターフェース２２４には、識別されたエンティティに追加されることになる新しいプロパティのリストを使用してフレームワーク２２０中にコールを行うユーザインターフェース（ＵＩ）を含む。追加されることになる新しいプロパティの指定は、エンティティ拡張ターゲット（ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＴａｒｇｅｔ）２４６に渡され、そこに格納される。カスタマイザは、特定のカスタマイズが適用されることになるコンテキスト（Ｃｏｎｔｅｘｔ）エンティティ２５６に格納された特定のコンテキストを識別することもできる。カスタマイズを指定することは図６Ｂのブロック４０４で示されている。また、コンテキストは、様々な時点で様々なカスタマイザによって設定することができることも理解されるであろう。カスタマイザが開発者である場合、コンテキストは、開発時に設定することができる。カスタマイザが管理者である場合、コンテキストは、管理者の職務の一環として設定することができる。いずれにしても、コンテキストは、いずれ設定されることになる。
【００４５】
カスタマイズをアクティブにするために、サブシステム２２６はまず、サブシステムアダプタ（ＳｕｂｓｙｓｔｅｍＡｄａｐｔｅｒ）２３４上でＰｒｅＩｎｓｔａｌｌ（）メソッドをコールして、インストールに先立ち、全体として、サブシステム２２６に必要とされるあらゆるプロセスを行う。次に、サブシステム２２６は、ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＡｄａｐｔｅｒ２３６上でＡｐｐｌｙＣｕｓｔｏｍｉｚａｔｉｏｎｓ（）メソッドを呼び出す。これに応答して、ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＡｄａｐｔｅｒ２３６は、データアクセスシステム２０６（図２に示す）を使用して、カスタマイズされたプロパティが入っているＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＴａｒｇｅｔインスタンス２４６を識別する。次に、ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＡｄａｐｔｅｒ２３６は、特定のＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＴａｒｇｅｔ２４６に関してＩｎｓｔａｌｌ（）をコールする。これを図６Ｂのブロック４０６で示している。
【００４６】
これにより、ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＴａｒｇｅｔ２４６に、ＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙと称される新しいエンティティを作成させるようにする。２つのＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙ（拡張エンティティ）３００および３０２を図６Ａに示している。各ＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙ３００および３０２はそれぞれ、カスタマイズされたプロパティを識別する少なくとも１つのＥｘｔｅｎｓｉｏｎ（拡張）プロパティ３０４および３０６を含む。図６Ａは、カスタマイザＸＹＺおよびカスタマイザＡＢＣとラベル付けされた２つの異なるカスタマイザによってカスタマイズが行われた実施形態を示している。したがって、ＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙ３００は、例示として、ＸＹＺ．ＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎ（ＸＹＺ顧客拡張）と名付けられ、ＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙ３０２には、例示として、ＡＢＣ．ＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎ（ＡＢＣ顧客拡張）と名付けられている。
【００４７】
例として、カスタマイザＸＹＺが、Ｃｕｓｔｏｍｅｒ（顧客）エンティティ２８０をカスタマイズして、エンティティ２８０によって識別された顧客が優先する技術者の識別情報を含むように所望したものと想定する。その場合、ＸＹＺ．ＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎエンティティ３００は、「優先される技術者プロパティ」と称されるＥｘｔｅｎｓｉｏｎプロパティ３０４を含む。同様に、カスタマイザＡＢＣが、Ｃｕｓｔｏｍｅｒエンティティ２８０をカスタマイズして、エンティティ２８０によって識別された顧客に関連する信用限度を含むように所望したものと想定する。その場合、ＡＢＣ．ＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎエンティティ２０３は、この所与の顧客に関連する「信用限度」を識別するＥｘｔｅｎｓｉｏｎ（拡張）プロパティ３０６を含む。
【００４８】
ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＴａｒｇｅｔ２４６は、ＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙ３００および３０２をその対応するＥｘｔｅｎｓｉｏｎプロパティ３０４および３０６とともに作成するだけでなく、例示として、ＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙ３００および３０２のそれぞれに対応するＥ−Ｒマップ３１０と３１２、およびＥ−Ａマップ３１４と３１６をそれぞれ作成することも行う。さらに、ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＴａｒｇｅｔ２４６は、ＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙ３００および３０２、ならびにその他の関連するデータ構造に対応するリレーショナルデータベース２０４に（データアクセスシステム２０６を介するなどして）テーブルを作成する。これを図６Ｂのブロック４０８で示している。
【００４９】
最後に、基本ＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙ２８８が再コンパイルされ、そのＥ−Ｒマップが再生成されて、ＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙ３００および３０２との新しい関係を反映する。同様に、Ｅ−Ａメタデータも再生成されて、ＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙとの新しい関係を反映する。これを図６Ｂのブロック４１０で示している。これは、例えば、ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＡｄａｐｔｅｒクラス上でＰｏｓｔＩｎｓｔａｌｌ（）メソッドをコールすることによって行うことができる。このようにして、再コンパイルは、ＡＢＣおよびＸＹＺからの両方の変更を含む。これは、所与のターゲットのインストール時に行うこともできるが、エンティティをｎ回、各ターゲットにつき１回、再コンパイルする必要があるであろう。
【００５０】
図６Ａは、行われたエンティティ拡張を反映するようにデータベーススキーマを実装することができる複数の異なる例示的なやり方も示している。第１の実施形態では、エンティティ拡張は、図６Ａの３２０として示すテーブルに格納されている。テーブル３２０は、Ｃｕｓｔｏｍｅｒエンティティ２８０と関連するデータを格納する元のテーブル２８６を含むことが見て取れる。元のテーブルは、単にエンティティ拡張に対応する複数の追加のフィールド３２２および３２４を含むように拡張されている。名前の衝突を回避するため、名前に作成者の名前空間を前置して、固有性を確保する。それゆえ、テーブル２８６の元の列は変更されない。拡張は、エンティティ拡張に対応する元のテーブルに単に追加される。
【００５１】
第２の実施形態では、エンティティ拡張のそれぞれが、各自のテーブルに格納される。それらのテーブルをそれぞれ符号３２６および３２８で示している。もちろん、カスタマイズごとに異なるテーブルを作成することもできるし、または所与のカスタマイザ（ＡＢＣまたはＸＹＺ）のすべてのカスタマイズを単一のテーブルに格納することもできる。
【００５２】
第３の実施形態によれば、それらのカスタマイズはともに、単一のテーブル３３０に格納される。テーブル３３０では、「優先される技術者」および「信用制限」というエンティティ拡張がともに、テーブル３３０に格納されている。この実施形態では、列の名前に作成者の名前空間が前置されて、固有性を確保している。もちろん、テーブル３３０は、すべてのエンティティのすべてのカスタマイズを含むように、または単一のエンティティのすべてのカスタマイズを含むように拡大することもできる。後者の場合、エンティティごとに、そのエンティティに関するすべてのカスタマイズを保持する新しいテーブルが作成される。
【００５３】
さらに別の実施形態によれば、本発明は、カスタマイズが入っている１つまたは複数のテーブルが既に作成されており、それゆえリレーショナルデータベース２０４内に既に存在するシステムと共に使用することができる。その実施形態では、ＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙ３００および３０２が、カスタマイズを収容する既存のテーブルに単にマップされる。
【００５４】
エンティティ拡張は、エンティティ間の関係をカスタマイズするために使用することもでき、これを図６Ｃに示している。図６Ｃは、カスタマイザが、「優先される技術者」カスタマイズを簡易フィールドの文字列名として書き込まず、代わりに、マップ３０３および３０５と関連する別のエンティティ３０１として作成した実施形態を示している。その場合、カスタマイズは、対応するＥＡマップにおいてＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎ（顧客拡張）エンティティ２８８と優先される技術者のエンティティ３０１との間のＥＡメタデータの関係を追加することによって行われる。
【００５５】
（メタデータカスタマイズ）
図７Ａは、本明細書で「デルタ（差分）ベースのカスタマイズ」と称するメタデータ構造およびメタデータカスタマイズを示している。図７Ａのメタデータ構造は、メタデータ構造ツリー５００の一部分として例示されている。図７Ａに示したツリー５００の部分は、例示的ではあるが、システムのメタデータを定義するはるかに大きなツリーの非常に小さな一部分に過ぎないことが理解されよう。図７Ａに示した部分は、メタデータが、Ｆｏｒｍセクションを含み、このセクション自体、Ｃｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿Ｓｃｒｅｅｎを含むことを示している。Ｃｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿Ｓｃｒｅｅｎは、複数のＴａｂコントロールを有するフィールドを含む。Ｔａｂコントロール１は、関連するＦｉｅｌｄ１を有する。Ｆｉｅｌｄ１は、フィールド名、フィールドの背景色、フィールドが使用可能か、または使用不可か、フィールドの長さ、およびフィールドのデータ型（この場合、ＭａｘＶａｌｕｅ）を含む複数のプロパティを有する。もちろん、フィールドは、複数の追加のプロパティも同様に有することができる。メタデータ構造５００は、メタデータストアに格納されている。
【００５６】
メタデータ構造５００をカスタマイズするために、カスタマイザは、カスタマイザインターフェース２２４を介してカスタマイズ指定を入力する。これにより、ある種のコンテキストにおいてカスタマイズを適用することになるＭｅｔａｄａｔａＴｒａｇｅｔエンティティ２４８にコードが含められるようになる。
【００５７】
本発明の実施形態では、データ構造５００内のすべてのタイプのメタデータのカスタマイズが、デルタを使用することによって達せられる。デルタは、メタデータ構造５００における元の形態からの変更を表わす。カスタマイズは、基本ターゲットの既知のインスタンスに対する特定の変更をそれぞれが表わす任意の数ｎのデルタを含むことができる。さらに、デルタは、既存のノードに対する変更を単に表わすだけである必要はない。代わりに、デルタは、メタデータ構造５００内の新しいノードの追加を表わすこともできる。
【００５８】
値を変更することの例として、元のデータ構造５００において、「ｆｏｏ」という名前を有するフィールドの背景色を黄（ＹＥＬＬＯＷ）とする。カスタマイザが背景色を青に変更したいと望むものと想定する。その場合、カスタマイザは、単一のデルタが入っている単一のカスタマイズを行っていることになる。カスタマイズは、Ｃｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿ＳｃｒｅｅｎのＴａｂ１の下の「ｆｏｏ」というフィールドに対するものである。カスタマイズは、メタデータストアの別の部分に格納することも、またはリレーショナルデータベース２０４にマップされるメタデータカスタマイズエンティティ５０２に格納することもできる。メタデータストアの一部分を形成することができるリレーショナルデータベース２０４内のテーブルが、ＦｏｒｍのＣｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿Ｓｃｒｅｅｎ部分にあるフィールドのＴａｂ１の下のＦｉｅｌｄ１の背景色プロパティを識別するメタデータＩＤが入っているテーブル５０４として例示されている。テーブル５０４は、フィールドの背景色が青（ＢＬＵＥ）に変更されるという、デルタを識別するデルタ情報も含む。それゆえ、デルタは、変更されたソースのコピーではない。そうではなく、デルタは、構造５００内のどの値が変更されるべきかの単なる指定である。デルタのみを追跡することにより、多くの変更をターゲットに動的に適用することが可能である。
【００５９】
デルタを適用するために、カスタマイズ対応サブシステム２２６は、アダプタ２３４をコールして、ＭｅｔａｄａｔａＡｄａｐｔｅｒ２３８を介してカスタマイズを適用する。ＭｅｔａｄａｔａＡｄａｐｔｅｒ２３８は、ＭｅｔａｄａｔａＴａｒｇｅｔ２４８上でＡｐｐｌｙ（）をコールして、現在のコンテキスト内でカスタマイズを適用する。例えば、カスタマイズ対応サブシステム２２６がフォーム（Ｆｏｒｍ）をロードするサブシステムであるものと想定する。さらに、ユーザが、Ｃｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿Ｓｃｒｅｅｎが表示されることを要求しているものと想定する。すると、ＭｅｔａｄａｔａＡｄａｐｔｅｒ２３８は、当然、Ｃｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿Ｓｃｒｅｅｎと名付けられたフォームについて現在のコンテキストに適用されるリレーショナルデータベース内のすべてのＭｅｔａｄａｔａＴａｒｇｅｔインスタンスを特定する。ＭｅｔａｄａｔａＡｄａｐｔｅｒ２３８は、次に、カスタマイズを適用するために特定された各インスタンスについてＭｅｔａｄａｔａＴａｒｇｅｔ２４８上でＭｅｔａｄａｔａＴａｒｇｅｔ．Ａｐｐｌｙ（）をコールする。メタデータに適用されることになるカスタマイズにより、Ｃｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿ＳｃｒｅｅｎのＴａｂ１の下のＦｉｅｌｄ１の背景色が青に変更されることを要求していることが見て取れる。ＭｅｔａｄａｔａＴａｒｇｅｔ２４８内のコードがこの変更を行い、カスタマイズされた部分構造５００がスクリーンをレンダリングする際の使用のためにカスタマイズ対応フォームローダー２２６に返される。
【００６０】
一実施形態によれば、本発明は、異なるカスタマイズからの複数のデルタが同一のプロパティを参照する場合の競合を解決するメカニズムも含んでいる。例えば、マネージャが、Ｃｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿ＳｃｒｅｅｎのＴａｂ１の下の所与のＦｉｅｌｄ１の背景色をオレンジにするようにカスタマイズしたものと想定する。さらに、従業員が、背景色を青に変更する個人の好みのカスタマイズを有するものと想定する。これら２つの別々のカスタマイズはともに、個人ユーザに適用される。個人ユーザは、オレンジへのカスタマイズが行われた部門の一部であるが、個人ユーザは、自身で、青へのカスタマイズを行っている。したがって、これら２つのカスタマイズインスタンスは、競合している。両方のカスタマイズがともに、同一のフィールドの背景色を異なる色に設定しようと試みている。しかし、フィールドは、色などの値に関して１つの設定しか有することができない。そのため、一方のカスタマイズが優先され、他方は優先されてはならない。
【００６１】
本発明の一実施形態によれば、カスタマイズの競合は、競合解決ポリシーを使用して解決される。そのようなポリシーは、例示として、メタデータ構造５００内の異なるデータ型のそれぞれに適用されるある種のポリシーを特定するテーブルに格納される。そのようなテーブルの一部分を図７Ｂのテーブル５１０として示している。もちろん、テーブル５１０は、単に例示である。テーブル５１０は、構造５００内のデータ型を識別するデータ型フィールド、および適用されるべき競合解決ポリシーを示すポリシーフィールドを含む。例示的な一実施形態では、競合解決ポリシーは、以下のものを含む。  
１．最も制限的な値（Ｍｏｓｔ  ｒｅｓｔｒｉｃｔｉｖｅ  ｖａｌｕｅ）
２．最も狭いコンテキスト（Ｎａｒｒｏｗｅｓｔ  ｃｏｎｔｅｘｔ）
３．１回限り設定される値（Ｓｅｔ  ｏｎｃｅ  ｖａｌｕｅ）
４．加法的（Ａｄｄｉｔｉｖｅ）、および
５．管理上のオーバーライド（Ａｄｍｉｎｉｓｔｒａｔｉｖｅ  ｏｖｅｒｒｉｄｅ）である。
【００６２】
最も制限的なポリシーは、列挙（ｅｎｕｍｅｒａｔｉｏｎ）のために使用することができる。例えば、あるカスタマイズは、値Ａ〜Ｅが有効であることを示し、別のカスタマイズは、値Ｃ〜Ｆが有効であることを示す場合、値Ｃ、Ｄ、およびＥだけが有効である。というのは、それが、この２つの競合するカスタマイズの最も制限的な組合せだからである。このポリシーは、数値フィールドに使用することもできる。例えば、データ型が、最大値データ型であり、２つのカスタマイズが、２つの異なる値に設定しようと試みる場合、その最小値が最も制限的であり、優先される。データ型が最小値データ型である場合、最大値が最も制限的であり、優先される。
【００６３】
最も狭いコンテキストのポリシーは、最も狭いコンテキストに関連するカスタマイズを優先して競合を解決する。例えば、単一のユーザをターゲットとしたカスタマイズが、すべてのユーザに設定された対応するコンテキストと競合するカスタマイズに勝る。
【００６４】
１回限り設定される値のポリシーは、値を１回限り設定することが可能であるように競合を解決する。値は、以降、変更することができない。
【００６５】
加法的ポリシーは、フィールドグループ（または、スクリーン上に現れるフィールドのグループ）などのデータ型に適用される。フィールドは、例示として、複数のグループに属することができる。したがって、あるカスタマイズが、第１のグループにフィールドを追加し、別のカスタマイズが、第２のグループに同じフィールドを追加する場合、両方のグループにフィールドを追加することによって競合を解決する。
【００６６】
最後の競合解決ポリシーは、管理上のオーバーライドである。これにより、管理者が、項目ごとに競合解決ポリシーをオーバーライドすることが可能になる。
【００６７】
もちろん、これらの競合解決ポリシーは単に例示であり、所望に応じて、他のポリシーまたは異なるポリシーを使用することもできる。
【００６８】
図８Ａ〜８Ｃは、エンティティ拡張を介してどのようにカスタマイズを行うことができるかのさらに具体的な例を示している。図８Ａ〜８Ｃに示した例では、自動車販売代理店Ｍｏｒｔｅｎｓ  Ａｕｔｏｓが、財務ソフトウェアパッケージを購入したものと想定する。パッケージのインストールおよび実行の後、Ｍｏｒｔｅｎｓ  Ａｕｔｏｓは、その製品をカスタマイズして、各顧客の自動車の好み（色、エンジン、作り／モデルなど）を追跡するためのフィールドを追加する。Ｍｏｒｔｅｎｓ  Ａｕｔｏｓは、顧客の自動車の好みについての新たなフィールドを顧客スクリーンに追加し、いくつかの使用していないフィールドを削除することも行うものと想定する。
【００６９】
図８Ａは、Ｍｏｒｔｅｎｓ  Ａｕｔｏｓにより購入された財務パッケージによって表示される標準の顧客（Ｃｕｓｔｏｍｅｒ）スクリーンのスクリーンショット４５０を示している。スクリーン４５０は、自動車販売業界では一般に使用されない注文一覧（Ｓｕｍｍａｒｙ）フィールドを含むことが見て取れる。また、図８Ａは、カスタマイズが実装された後の同じ顧客スクリーンも示している。元の注文一覧フィールドは、顧客の最新の購入（Ｌａｓｔ  Ｐｕｒｃｈａｓｅ）および最新の購入日（Ｌａｓｔ  Ｐｕｒｃｈａｓｅ  Ｄａｔｅ）を示すフィールドで置き換えられている。さらに、自動車の好み（Ｃａｒ  Ｐｒｅｆｅｒｅｎｃｅｓ）タブを追加して、顧客の自動車の好みを表示する。以上はすべて、前述したエンティティおよびメタデータを単に拡張することによって達せられる。
【００７０】
次に、別のソリューションプロバイダであるＣｏｎｓｏｔｏが、サービス案内（ｓｅｒｖｉｃｅ  ｒｅｍｉｎｄｅｒ）に関する電子メール通知を導入したものと想定する。さらに、Ｃｏｎｓｏｔｏによって提供される顧客エンティティは、顧客のお気に入りの技術者の名前の文字列を顧客エンティティに追加し、新しいフィールドのテキストボックスを顧客スクリーンに追加したものと想定する。Ｃｏｎｓｏｔｏの顧客スクリーンの一例を図８Ｂに示している。Ｍｏｒｔｅｎｓ  Ａｕｔｏｓが、サービス部門を運営するためにソフトウェアパッケージをＣｏｎｓｏｔｏから購入したものと想定する。
【００７１】
インストールの後、すべての以前のカスタマイズは、依然として、手動による介入または手直しなしで機能している。これを図８Ｃに示している。例えば、顧客の自動車の好みフィールドが、スクリーン上で示され、元のＯｒｄｅｒフィールドがスクリーンから削除されている。同様に、顧客スクリーンに対するＣｏｎｓｏｔｏの変更も提供されている。具体的には、顧客エンティティ上の新しいフィールド、および顧客スクリーン上のテキストボックスが含まれている。前述したとおり、新しいソフトウェアパッケージがインストールされた際、カスタマイズサブシステムフレームワークがコールされ、カスタマイズが、ユーザの介入なしで自動的にインストールされ、適用される。
【００７２】
（プロセスのカスタマイズ）
プロセスには、通常、定義された１組のステップを通じて作業を経路指定するワークフロー仕様、ならびにあるデータに関する明確に定義されたアクションを実行するより低レベルの処理ロジックが含まれる。プロセスは、本明細書では、長期の継続するビジネスプロセスとすることができるビジネス活動として述べる。
【００７３】
図９は、ビジネス活動６００をどのように実装することができるかをさらに示している。一実施形態では、ビジネス活動６００は、ビジネスオペレーションと称される複数の個々のトランザクション上のステップに分けられる。ビジネス活動を構成するビジネスオペレーションのそれぞれは、２つの異なるタイプのオペレーションの１つに分類することができる。第１のタイプは、本明細書で、計画的なオペレーションの置き換え（ｐｌａｎｎｅｄ  ｏｐｅｒａｔｉｏｎ  ｒｅｐｌａｃｅｍｅｎｔ）と称する。言い換えれば、元のアプリケーション開発者が、ロジックの置き換えを計画する場合、アプリケーションが、ランタイムにて実行すべき特定のロジックを選択するように書かれている。このようにして、第三者の開発者が、行われる処理のタイプを拡張することができる。元の作成者は、「プラグポイント（ｐｌｕｇ  ｐｏｉｎｔ）」、および１つまたは複数のデフォルトの実装を開発する。すると、第三者の開発者は、追加の実装を作成し、インストールすることができる。アプリケーションは、通常、ある所与の場面でどのビジネスオペレーションを実行するかの選択についてアプリケーションデータベース内に記憶域を提供している。そのようなロジックの一例が、販売手数料計算エンジンである。元の作成者は、手数料選択情報をＳａｌｅｓＰｅｒｓｏｎエンティティに組み込むことができ、「定率」のデフォルトを与えることもできる。もちろん、第三者の開発者は、より高度な計算器（ｃａｌｃｕｌａｔｏｒ）を作成し、インストールすることもできる。
【００７４】
第２のタイプのビジネスオペレーションは、本明細書で、アドホック的なオペレーションの置き換え（ａｄｈｏｃ  ｏｐｅｒａｔｉｏｎ  ｒｅｐｌａｃｅｍｅｎｔ）と称する。例えば、元の作成者が、あるオペレーションに関して置き換えられることを予定していない場合がある。したがって、作成者は、代替の実装を選択するための何らの特殊なロジックもアプリケーションに組み込んでいない場合がある。しかし、ベンダーは、それでも、自身のロジックで元のオペレーションを置き換える必要がある場合がある。ベンダーのオペレーションが元のオペレーションの代わりにコールされるようにするためには、選択ロジックを変更するフレームワークメカニズムを提供する。
【００７５】
それらの機構をさらに詳細に説明する前に、まず、別の概念を説明するべきである。本発明の一実施形態によるビジネスオペレーションは、エージェント−サービスパターンに従う。ビジネスオペレーションエージェントは、クライアントが直接対話するプロセスの唯一の部分である。ビジネスプロセスを実行する必要があるクライアントは、ビジネスオペレーションエージェントのインスタンスを作成し、プロパティをそのインスタンスに送って必要とされる入力を提供する。今度はエージェントが、（サービスファクトリを介して）対応するサービスクラスを探し出し、そのクラスをインスタンス化し、そのインスタンスをコールして、そのサービスを実装する作業を実際に行う。
【００７６】
前述した置き換えのシナリオのいずれにおいても、エージェント自体は置き換えられない。クライアントは、常に、同じ元のビジネスオペレーションエージェントを作成し、コールする。これにより、エージェントは安定したインターフェースを有しているため、クライアントが、常にエージェントをコールすることができることを確実なものにする。ビジネスオペレーションエージェントは、エンティティであり、エンティティと関連する拡張エンティティを有することができ、拡張エンティティはそれらに付加される追加のプロパティを有することができる。これにより、元のエージェントインターフェース契約に違反することなく、エージェントの拡張性が提供される。エージェントは、正しいサービスを探し出して、いくつかの異なる仕方で実行することができる。
【００７７】
図９は、ビジネス活動６００が３つのビジネスオペレーション、オペレーション１、２、および３を使用して実装されていることをさらに例示している。ビジネスオペレーション１は、エージェント６０２およびビジネスオペレーションサービスファクトリ６０４を有する。ビジネスオペレーション２も、エージェント６０６およびサービスファクトリ６０８を有する。ビジネスオペレーション３も、エージェント６１０およびビジネスオペレーションサービスファクトリ６１２を有する。
【００７８】
計画的な置き換えについては、コールしているアプリケーション（またはクライアント）が、サービスＩＤを現在コールされているエージェントの中に渡す。サービスＩＤは、どのサービスをアクティブにするかを示す。したがって、コール側が特定のサービスＩＤをエージェント６０２に渡す場合、エージェント６０２は、サービスファクトリ６０４を介して、ビジネスオペレーションサービス６１４を識別し、サービス６１４をインスタンス化し、そのインスタンスをコールしてオペレーションを行う。単に異なるサービスＩＤを渡すことにより、サービスを変更することができる。
【００７９】
アドホック的な置き換えについては、ビジネスオペレーションサービスの組み込まれた選択をオーバーライドするために、例示として、使用することができる２つの異なる方法がある。例えば、ビジネスオペレーション３が置き換えられるものと想定する。一実施形態では、サービスＩＤは、図１０に示したようなメタデータ構造の中に格納される。図１０は、Ｏｐｅｒａｔｉｏｎｓと称されるメタデータの項目を含むメタデータ構造６２５の一部分を示している。Ｏｐｅｒａｔｉｏｎｓは、３つのビジネスオペレーションを含み、そのそれぞれが複数のプロパティを含み、そのプロパティの１つがサービスＩＤである。この事例では、ベンダーは、オーバーライドされるべきビジネスオペレーションのサービスＩＤを保持するメタデータの部分を単純にカスタマイズすることができる。
【００８０】
例えば、ビジネスオペレーション１のサービスＩＤをカスタマイズして、代わりにビジネスオペレーション番号４のサービスＩＤにするものと想定する。図１０は、メタデータ識別子（メタデータ構造内のサービスＩＤエントリの識別子）と、サービスＩＤのカスタマイズを番号４にするデルタとを含むビジネスオペレーションカスタマイズテーブルと称されるテーブル６２７を示している。このプロセスにカスタマイズが適用されると、サービスＩＤ番号１が、カスタマイズされたサービスＩＤ番号４で置き換えられる。これは、使用されているビジネスオペレーションサービスファクトリに手渡され、そのファクトリが、ビジネスオペレーションサービス番号４をインスタンス化し、コールすることになる。エージェントは、自らのファクトリにどのようなサービスＩＤも渡すことはなく、ファクトリは、次に通常どおり進行して、メタデータストアにある関連するデフォルトのサービスＩＤをルックアップすることになる。これにより、カスタマイズされたサービスＩＤが取得され、ファクトリは、元々指定されたサービスの代わりに置き換えのビジネスオペレーションサービスをインスタンス化することになる。
【００８１】
アドホック的な置き換えカスタマイズを実装するための別の方法も図９に示されている。この実施形態では、利用されている特定のサービスファクトリが、イベントを伝搬する。サービスオペレーションをカスタマイズしたいと望むベンダーは、このイベントにサブスクライブし、関連するイベントハンドラにロジックを入れてサービスＩＤの値を変更することができる。この方法により、ビジネスオペレーションのカスタマイズが可能になるだけでなく、ビジネスオペレーションエージェントに入っているデータに基づく動的なサービス選択も可能になる。例えば、図９に示すとおり、ビジネスオペレーションサービスファクトリ６１２は、エージェント６１０がファクトリ６１２をコールして、ビジネスオペレーションサービスをインスタンス化するときに、イベント６２２を伝搬することができる。関連するイベントハンドラに追加されたカスタムロジックは、サービスＩＤの値を変更し、値をファクトリ６１２に返すことができる。カスタムイベントコードがサービスＩＤを設定することを選択しない場合、サービスＩＤのデフォルトの（可能性として、カスタマイズされた）値が、メタデータストレージから読み出される。
【００８２】
（依存関係）
本発明の一実施形態は、カスタマイズ依存関係を施行することも注記に値する。言い換えれば、あるベンダーまたは製造業者が製品をカスタマイズして出荷し、ユーザがその製品をさらにカスタマイズする場合、データの項目のカスタマイズは、同じデータの以前のカスタマイズに依存する場合がある。このように、カスタマイズフレームワークの基本クラスは、どのカスタマイズが他のどのカスタマイズに依存するかのリストを保持する。カスタマイザが、カスタマイズを作成したり、削除したりすることを望む場合、基本Ａｄａｐｔｅｒクラスがまず、他のカスタマイズがそのカスタマイズに依存しているかどうかを判定する。各カスタマイズは、このように、関連する依存関係のリストを有している。アダプタシステム内で、メソッドをコールして依存関係を施行し、これによりカスタマイザがカスタマイズを行う前にすべての依存関係に間違いなく対処したことを確実にすることになる。
【００８３】
本発明は特定の実施形態を参照して説明されているが、当分野の技術者には、本発明の趣旨および範囲を逸脱することなく形態および詳細の変更を行うことができることが認識されるであろう。
【図面の簡単な説明】
【００８４】
【図１】本発明を使用することができる一環境を示すブロック図である。
【図２】オブジェクト−リレーショナル（またはエンティティ−リレーショナル）データベースシステムのブロック図である。
【図３】本発明の一実施形態によるカスタマイズフレームワークを示すＵＭＬクラス図である。
【図４】本発明に従ってコンテキストを維持管理する一実施形態を示すブロック図である。
【図５】本発明の一実施形態によるエンティティ拡張システムを示す図である。
【図６Ａ】エンティティが本発明の一実施形態に従ってカスタマイズされたり、拡張されたりした後の図５に示したエンティティ拡張システムを示す図である。
【図６Ｂ】本発明の一実施形態に従ってどのようにエンティティが拡張されるかを示す流れ図である。
【図６Ｃ】本発明の一実施形態に従ってエンティティ間の関係を変更することによりエンティティがどのようにカスタマイズされるかを示すブロック図である。
【図７Ａ】本発明の一実施形態に従ってメタデータ構造およびカスタマイズの一実施形態を示す図である。
【図７Ｂ】競合解決テーブルの一実施形態を示す図である。
【図８Ａ】本発明の一実施形態に従ってシステムスクリーンのカスタマイズの一例を示すスクリーンショットである。
【図８Ｂ】本発明の一実施形態に従ってシステムスクリーンのカスタマイズの一例を示すスクリーンショットである。
【図８Ｃ】本発明の一実施形態に従ってシステムスクリーンのカスタマイズの一例を示すスクリーンショットである。
【図９】ビジネス活動の表現の一実施形態を示すブロック図である。
【図１０】メタデータカスタマイズを通じてビジネス活動のカスタマイズの一実施形態を示す図である。
【符号の説明】
【００８５】
１００  コンピューティングシステム環境
１１０  コンピュータ
１２１  システムバス
１４１  ハードディスクドライブ
１５１  磁気ディスクドライブ
１５２  取外し可能な不揮発性の磁気ディスク
１５６  取外し可能な不揮発性の光ディスク
２００  エンティティ−リレーショナル（Ｅ−Ｒ）システム
２２０  カスタマイズフレームワーク
２２２  カスタマイズサブシステム
２３０  アダプタシステム
２３２  ターゲットシステム
４５０  スクリーンショット
５００  メタデータ構造ツリー
６２５  メタデータ構造
【図１】
0005460941.tif 000002
【図２】
0005460941.tif 000003
【図３】
0005460941.tif 000004
【図４】
0005460941.tif 000005
【図５】
0005460941.tif 000006
【図６Ａ】
0005460941.tif 000007
【図６Ｂ】
0005460941.tif 000008
【図６Ｃ】
0005460941.tif 000009
【図７Ａ】
0005460941.tif 000010
【図７Ｂ】
0005460941.tif 000011
【図８Ａ】
0005460941.tif 000012
【図８Ｂ】
0005460941.tif 000013
【図８Ｃ】
0005460941.tif 000014
【図９】
0005460941.tif 000015
【図１０】
0005460941.tif 000016