(57)【要約】  企業や機関の実際のＩＴシステムや計画されているＩＴシステムを運営することに関するオペレーション上のポリシーをモデル化すること。ＩＴシステムは、アプリケーション、アプリケーション・ホスト、１つまたは複数のネットワークやそれらのコンポーネント、ハードウェア、それらのコンポーネントどうしの間における相互関係などのコンポーネントを含むことができる。ＩＴシステムは、コンポーネントの存在や多数性、それらのコンポーネントがどのように相互に関係付けられるか、それらのコンポーネントおよび相互関係がどのように構成されるか、および／またはそのＩＴシステムを管理および保守するための手動のプロセスまたは自動化されたプロセスを管理するオペレーション上のポリシーに従って運営されることになる。このモデル化は、ＩＴシステムのコンポーネントに対応する型を使用して抽象を宣言するステップによって、ＩＴシステムの相互関係に対応する相互関係の型を宣言するステップによって、ならびにそれらの抽象型に関する制約およびそれらの抽象型どうしの間における制約を定義するステップであって、それらの制約は、ＩＴシステムを運営することに関するオペレーション上のポリシーに対応するステップによって、言語に準拠するコードを作成するステップを含むことができる。
2009515252.tif 000002
【特許請求の範囲】
【請求項１】
ＩＴシステムを展開し、構成し、運営するためのポリシーをモデル化する前記ＩＴシステムのモデルを作成するステップであって、前記モデルは、宣言型言語のタイピングシンタックス内における型の宣言を含み、前記型の宣言は、前記ＩＴシステムを構成して運営するための前記ポリシーを共にモデル化し、前記型の宣言は、前記ＩＴシステムのクラス／コンポーネントの型、前記ＩＴシステムのクラス／コンポーネントどうしの間における関係の型、および前記ＩＴシステムの制約を宣言するステップと、
前記モデルをコンピュータ読み取り可能な記録媒体に格納するステップと
を含むことを特徴とする方法。
【請求項２】
前記制約は、前記ＩＴシステムのコンポーネントおよび／または前記ＩＴシステムの関係に関して演算を行う演算子を含む式を含み、前記式が真であるかを評価して、前記制約が満たされているかどうかを判定することができることを特徴とする請求項１に記載の方法。
【請求項３】
前記宣言型言語は、式を構築する式シンタックスを有し、前記制約を含む前記式は、前記式シンタックスに準拠する形式であることを特徴とする請求項２に記載の方法。
【請求項４】
前記制約は、前記ＩＴシステムを運営し、展開し、構成する上での制約をモデル化することを特徴とする請求項１に記載の方法。
【請求項５】
前記格納されたモデルのインスタンスを、少なくとも１つのタイプチェックアルゴリズムを含み、前記インスタンスが前記モデルの前記ポリシーを満たしているかどうかを確認する前記言語のインプリメンテーションに渡すステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項６】
クラス／コンポーネントの前記型は、ホストのタイプ、サーバのタイプ、およびアプリケーションのタイプを含み、関係の前記型は、ホスティングの関係、依存の関係、委任の関係、および通信の関係を含むことを特徴とする請求項１に記載の方法。
【請求項７】
新たな宣言を用いて前記モデルを拡張すること、または前記モデル内で宣言される型を制限することによって前記モデルを制限することのいずれかを行う宣言を追加することによって、前記モデルから新たなモデルが導き出されることを特徴とする請求項１に記載の方法。
【請求項８】
ＩＴシステムのモデルの定義を格納する１つまたは複数のコンピュータ読み取り可能な記録媒体であって、
前記定義は、宣言型言語のソースコードまたはコンパイルされたコードを含み、
前記ソースコードまたはコンパイルされたコードは、
ソフトウェアコンポーネントおよびハードウェアコンポーネントの型の宣言であって、前記コンポーネントの型は、前記ＩＴシステムを運営する上でのポリシーをモデル化するプロパティを有するように宣言される宣言と、
コンポーネントどうしの間における関係の型の宣言であって、前記関係の型は、前記ＩＴシステムを運営する上でのポリシーをモデル化するプロパティを有するように宣言される宣言と、
前記関係および前記コンポーネントに関する制約の宣言であって、前記制約は、前記ＩＴシステムを運営する上でのポリシーをモデル化する方法で前記関係および前記コンポーネントの組合せを制約する宣言と
を含むことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項９】
前記定義は、前記ＩＴシステムを運営する上での前記ポリシーを拡張またはリファインする制限的な派生をさらに含むことを特徴とする請求項８に記載のコンピュータ読み取り可能な記録媒体。
【請求項１０】
前記定義は、前記ＩＴシステムにとって満たさなければならない前記ＩＴシステムの不変の側面を指定することを特徴とする請求項８に記載のコンピュータ読み取り可能な記録媒体。
【請求項１１】
前記ＩＴシステムの状態を示す情報と、
前記定義を使用して、前記ＩＴシステムの前記状態に対する変更が、前記ＩＴシステムを運営する上での前記ポリシーに違反することになるかどうかを判定するためのコンポーネントと
をさらに含むことを特徴とする請求項８に記載のコンピュータ読み取り可能な記録媒体。
【請求項１２】
前記制約のうちのいくつかは、前記制約の分類を示す情報をさらに含むことを特徴とする請求項８に記載のコンピュータ読み取り可能な記録媒体。
【請求項１３】
新たな宣言を用いて前記モデルを拡張すること、または前記モデル内で宣言される型を制限することによって前記モデルを制限することのいずれかを行う宣言を追加することによって前記モデルから導き出された第２のモデルの定義をさらに含むことを特徴とする請求項８に記載のコンピュータ読み取り可能な記録媒体。
【請求項１４】
前記制約の前記宣言は、コンポーネントおよび／または関係に関して演算を行う演算子を含む式を含み、前記式は、真の評価を受けやすいことを特徴とする請求項８に記載のコンピュータ読み取り可能な記録媒体。
【請求項１５】
企業や機関の実際のＩＴシステムや計画されているＩＴシステムを運営することに関するオペレーション上のポリシーをモデル化する方法において、前記ＩＴシステムは、アプリケーションと、アプリケーション・ホストと、１つまたは複数のネットワークや前記ネットワークのコンポーネントと、ハードウェアと、前記コンポーネントどうしの間における相互関係とを含むコンポーネントを含み、前記ＩＴシステムが、コンポーネントの存在や多数性、前記コンポーネントがどのように相互に関係付けられるか、前記コンポーネントおよび相互関係がどのように構成されるか、および前記ＩＴシステムを管理および保守するための手動のプロセスまたは自動化されたプロセスを管理するオペレーション上のポリシーに従って運営される方法であって、
前記方法は、
前記ＩＴシステムの前記コンポーネントに対応するクラスの型を宣言することと、
前記ＩＴシステムの相互関係に対応する相互関係の型を宣言することと、
前記型に関する制約および前記型どうしの間における制約を定義することであって、前記制約は、前記ＩＴシステムを運営することに関する前記オペレーション上のポリシーに対応することと
によって言語に準拠するコードを生成するステップを含み、
前記コードは、前記ＩＴシステムから独立していることを特徴とする方法。
【請求項１６】
前記型は、前記言語のタイピングシステムのシンタックスおよびセマンティクスに従って宣言型のコードの部分を用いて宣言されることを特徴とする請求項１５に記載の方法。
【請求項１７】
前記制約は、前記言語によって定義される論理式の領域内にある式を含むことを特徴とする請求項１６に記載の方法。
【請求項１８】
前記制約は、抽象型のうちのいくつかを制約し、前記抽象型のインスタンスを前記制約に照らして確認することができることを特徴とする請求項１７に記載の方法。
【請求項１９】
前記宣言された型のインスタンスが、前記型によってモデル化されているオペレーション上のポリシーを満たしているかどうかを自動的に判定するステップをさらに含むことを特徴とする請求項１５に記載の方法。
【請求項２０】
前記型のうちの１つのインスタンスに対する提案されている修正が前記オペレーション上のポリシーに違反することになるかどうかを自動的に判定するステップをさらに含むことを特徴とする請求項１５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＴオペレーション／ポリシーのモデリング方法に関し、より詳細には、ＩＴシステムを展開し、構成し、運営するためのポリシーをモデル化するためのＩＴシステムのモデルを作成する方法に関する。
【背景技術】
【０００２】
さまざまな企業および機関によって所有され運営されているＩＴ（Information Technology）システムは、非常に複雑になることがある。典型的なＩＴシステムは、複数のコンピュータを伴うが、それぞれのコンピュータ上には、相互接続されたソフトウェアの多くの要素が存在可能である。これらのＩＴシステムの展開、構成、および管理は、手作業が多く、また人間の経験と、共同で使用する知識と、無関係なソフトウェアツールどうしの集まりと、多くの場合は不完全で、古く、必要とされるときに見つけにくく、あるいは理解しにくいドキュメントとをその場その場で組み合わせることを通じて達成される。ＩＴシステムのオペレーションに手作業が多いことに起因して、機能不良がもたらされ、システムのパフォーマンスが最適な状態に達しない場合が多い。ＩＴシステムに対する変更はまた、通常は非公式に、たとえばＥメールメッセージを通じて管理される。あるＩＴシステムが、たとえば３層のアプリケーションを有していて、修正や変更を施す必要がある場合に、その修正や変更が有効であるかどうか、またはその修正や変更によってそのＩＴシステムが壊れることになるかどうかを判断するための便利な方法はない。そのような変更に先立って、広範囲にわたるテストが行われるかもしれない。ＩＴシステムがさらに複雑になるにつれて、その場その場でのアプローチは破綻し、情報は十分に共有されず、あるいは古くなり、非効率および誤りが増大する、といった具合になる。つまり、変化のスピードが遅くて、改良がＩＴシステムの複雑さの増大に追い付いていない技術を使用して、現代の複雑なＩＴシステムは管理されている。ＩＴシステムの構成を標準化するための方法はない。このようにＩＴシステムの管理において標準化が欠如していること、および改良が欠如していることによって、会社、機関、およびその他の企業は、多大なリスクおよびコストにさらされ続けている。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
標準化された構成ツールおよび構成モデルがないため、ＩＴシステムのオペレーション上のポリシーおよび設定（preference）が満たされているかどうかをチェックするための確かな方法や簡単な方法がない。柔軟性がなく、ＩＴシステムの変更および拡張を有効にすることが困難である。いくつかの事前に定義されたコンポーネントを「プログラム」してオペレーション上のポリシーをモデル化したり取り込んだりすることができるシステムがない。ＩＴシステムのオペレーション上の知識、すなわち、ＩＴシステムの望ましい構成環境およびオペレーションに関連付けられた知識を取り込んで定式化するための方法があれば、上述の問題の多くを軽減することができる。
【０００４】
下記の概要は、あくまでも、以降の詳細な説明において論じられるいくつかのコンセプトを紹介するために本明細書に含まれている。この概要は、包括的なものではなく、添付の特許請求の範囲によって示されている保護できる主題の範囲を画定することを意図するものではない。
【課題を解決するための手段】
【０００５】
企業や機関の実際のＩＴシステムや計画されているＩＴシステムを運営するためのオペレーション上のポリシーをモデル化することができる。ＩＴシステムは、アプリケーション、アプリケーション・ホスト（application host）、１つまたは複数のネットワークやそれらのコンポーネント、ハードウェア、各コンポーネント間における相互関係などのコンポーネントを含むことができる。ＩＴシステムは、コンポーネントの存在や多数性、それらのコンポーネントがどのように相互に関係付けられるか、それらのコンポーネントおよび相互関係がどのように構成されるか、および／またはそのＩＴシステムを管理および保守するための手動のプロセスまたは自動化されたプロセスを管理するオペレーション上のポリシーに従って運営される。このモデル化は、ＩＴシステムのコンポーネントに対応する型（type）を使用して抽象（abstraction）を宣言するステップによって、ＩＴシステムの相互関係に対応する相互関係の型を宣言するステップによって、ならびにそれらの型に関する制約およびそれらの型どうしの間における制約を定義するステップであって、それらの制約がＩＴシステムを運営する上でのポリシーに対応するステップによって、言語に準拠するコードを生成するステップを含むことができる。
【発明を実施するための最良の形態】
【０００６】
付随する特徴の多くについては、以降の詳細な説明を添付の図面との関連から考察しながら参照することによって、より容易に理解できるであろう。また、添付の図面においては、同様の部分を指すために同様の参照番号が使用されている。
【０００７】
本明細書において論じる実施形態は、形式言語を使用することによってＩＴシステムのオペレーション上の知識をモデル内に取り込むことに関する。より具体的には、宣言型モデルが、ＩＴシステムのオペレーション上の知識、すなわちＩＴシステムの構成環境、ポリシー、ならびに進行中のオペレーションおよび管理に関連する情報を取り込む。このような知識取り込み式の宣言型モデル（knowledge-capturing declarative model）は、ＸＭＬ（あるいは、ＸＭＬに基づくモデリングスキーマ（modeling schema））、ＵＭＬ、Ｃ＃などの形式言語（どの特定の言語かは、重要ではない）のタイピングシステム（typing system）を使用して形成される。
【０００８】
いったん確立すれば、このようなモデルは、多くの用途に利用できる。モデルは、ＩＴ管理者、システムオペレータ、システム設計者、開発者、テスターなど、すべての関係者にＩＴシステムのオペレーション上の知識を明確に伝達する。このモデルは、ＩＴシステムが何をすべきか、およびどのように機能すべきかに関する合意を推し進めるための基盤として使用することができる。さまざまな利害関係者は、そのモデルを検討して、そのＩＴシステムに関する期待に合意することもでき、あるいは合意しないこともできる。このようなモデルは、現実世界のシステムを実際に構成するために使用することができる。さらに、よく宣言されたモデルは、そのモデルと、そのモデルが取り込むことができるさまざまな不変条件とに現実世界のシステムが準拠しているかどうかを定期的にチェックするために使用することができる。また、ＩＴシステムに対する変更が提案された場合には、それらの変更をＩＴシステムに適用する前に、それらの変更をモデル（および、そのモデルによって具体化される知識およびポリシー）に照らして確認することができる。モデルは、言語に基づいているため、容易に解釈すること、コンパイルすること、操作すること、リッチに視覚化することなどができる。
【０００９】
図１は、オペレーション上の知識と、モデル５２と、ＩＴシステム５４とを有するコミュニティー５０を示す。オペレーション上の知識は、モデル５２内で具体化されるか、あるいはモデル５２内に取り込まれる。モデル５２は、ＩＴシステム５４を構成すること、確認すること、理解することなどを行うために使用することができる。注目すべきことに、モデル５２は、ＩＴシステム５４そのものからは切り離され、独立している。モデル５２は、ＩＴシステム５４の望ましい状態や好ましい状態を反映する。すなわちモデル５２は、現実世界から独立しているが、現実世界のＩＴシステム５４（たとえば、サーバ、アプリケーションなど）において見受けられる情報のタイプをモデル化することができ、しかもその情報を、必ずしも現在の状態としてではなく、そのあるべき状態としてモデル化することができる。つまりモデル５２は、望ましい構成の状態を取り込み、ＩＴシステム５４の現在の状態と、そのあるべき状態との間における相関付けを可能にすることができる。
【００１０】
上述のように、言語は、展開および／または継続中のオペレーションに関連する情報を含む方法でＩＴシステムのモデルを宣言するために使用される。モデルは、ＩＴシステムの青写真のようなものである。図２において見られるように、モデル５２／６８は、ＩＴシステムの構造、すなわちそのＩＴシステムのさまざまな要素、およびそれらの要素がお互いにどのように関連しているか（たとえば、ウェブアプリケーションはカタログＤＢと通信し、カタログＤＢはＳＱＬ上にホストされているなど）を取り込むことができる。モデル６８は、ＩＴシステムの任意の層またはすべての層をモデル化することができる。モデル６８などのモデルは、任意のタイプのアプリケーション７０、アプリケーション・ホスト７２、ネットワークコンポーネントおよびオペレーティングシステム７４、ならびにハードウェア７６さえ宣言することができる。アプリケーション７０は、データアクセスクライアント、情報労働者向け生産性向上ツール、あるいはＪａｖａ（登録商標）やＡＳＰ．ＮＥＴでコード化されたネットワーク型アプリケーションとすることができる。アプリケーション・ホスト７２は、任意のウェブサーバとすることができ、あるいは少しばかり例を挙げるならば、Ｗｏｒｋｅｒ  Ｐｒｏｃｅｓｓ  Ｉｓｏｌａｔｉｏｎ  ＭｏｄｅのＩＩＳ（Internet Information Server）とすることができる。ネットワークコンポーネント７４は、データネットワークと同じぐらいシンプルなものとすることができるが、ネットワーキング用の任意のコンポーネントとすることもできる。オペレーティングシステム７４は、Ｗｉｎｄｏｗｓ（登録商標）ベースのオペレーティングシステム、Ｕｎｉｘ（登録商標）ベースのオペレーティングシステム、仮想化されたオペレーティングシステム、あるいはその他のオペレーティングシステムとすることができる。ハードウェア７６は、特に制限はないが、周辺機器デバイス、メモリ、ＣＰＵ、ストレージ、ＲＡＩＤ構成など、典型的なコンピュータコンポーネントを含むことができる。
【００１１】
ＩＴシステムのモデルはまた、制約や不変条件（invariant）、すなわち、システムが最適である、または機能しているとみなされるために当てはまり続けるべきである、または当てはまり続けなければならないルールやポリシーのセット（たとえば、ホストカスタマー・トランザクションＤＢ（host customer transaction DB）は、ＳＱＬクラスタ上になければならず、各ＤＦＳインスタンスは、少なくとも３つのサーバを有していなければならず、それぞれのリンクごとに少なくとも２つのターゲットが存在しなければならず、１つのリンクに関するターゲットは、別々のファイルサーバ上でホストされるべきであるなど）を取り込む。
【００１２】
図３は、ＩＴシステムのモデルの１つの用途を示す。システム管理者９０は、モデル９４に対するモデル更新要求９２をサブミットすることができる。要求９２をモデル９４に照らして確認することができ（９６）、モデル９４のルール、制約、あるいは不変条件のすべてが引き続き満たされる場合には、要求９２によってモデル９４を更新することができる。更新されたモデル９８は、たとえば、その更新されたモデル９８と、現実世界のＩＴシステム１０２との間における橋渡しを提供するアダプタ１００を駆動するために使用することができる。たとえば、ＳＱＬサーバ用のアダプタが存在することができ、そのアダプタは、現実世界のＩＴシステム１０２内のＳＱＬサーバの構成パラメータを変更することによって、更新されたモデル９８内のポリシーや制約を実装することができる。上述のように、モデルは、その他の多くの用途を有することができる。
【００１３】
図４は、モデルを宣言するためのプロセスを示す。はじめに、モデルを作成する人が、ＩＴシステムのコンポーネント／クラス、関係（relationship）、および制約に関する型（type）を１２０において定義する。そしてこの人は、ＩＴシステムを運営するポリシーや側面の知識をモデル化したり映し出したり（mirror）するために、それらの型を１２２において調整する。それらの型は、１２４において、モデルを宣言するために使用されている言語のタイピングシンタックス（typing syntax）内に格納される。詳細については後述する。
【００１４】
図５は、宣言型モデル１４０を示す。モデル１４０は、図４のプロセスと同様にして作成することができる。モデル１４０を作成する設計者は、ある特定の言語１４２を選択することによって開始することができる。言語１４２は、型（type）を宣言して使用するためのルールおよびシンタックスを含むタイプシステム１４４と、ソースコードにタイピング違反がないことを確かにするためのタイプチェックアルゴリズム１４６（タイプチェッカー）とを有するべきである。タイプシステムとは、変数の型（type）、および一般には言語における表現のタイプを追跡把握するタイプ分けされた言語（typed language）のコンポーネントである。タイプシステムは、プログラムやコードがよく機能しているかどうか、あるいはよく形成されているかどうかを記述することができる。タイプシステムは、範囲を定めるルール（scoping rules）や、タイプの等価性（type equivalence）など、その他の側面を含むこともできる。最後に、タイプシステムは、強制できるべきであり、型の宣言は、ある程度静的にチェックできるべきである。型は、物事に関する（アルゴリズム的な知識とは対照的な）静的な知識を表現するため、タイプシステムは、ＩＴシステムのオペレーション上の知識をモデル化する上で役に立つ。タイプチェッカーすなわちタイプチェックアルゴリズム１４６は、さまざまな方法で宣言型モデルを使用する上で役に立ち、宣言型モデルを実際に構築する必要はないという点に留意されたい。
【００１５】
図５に戻ると、人間の設計者は、モデル化することが望ましい利用可能なオペレーション上の知識１４８をすべて収集することができる。これは、人々１５０から、あるいはドキュメント１５２、１５４から知識を得ることを含む。ドキュメント１５２は、Ｅメールや、大まかに保守されている「オペレーションポリシー」ドキュメントなど、非公式なドキュメントとすることができる。ドキュメント１５４は、ＩＢＭ  Ｒｅｄｂｏｏｋ、ＩＴＩＬ（IT Infrastructure Library）の刊行物、組織的なＩＴポリシーのマニュアル類、アプリケーションを構成したりインストールしたりする好ましい方法を示すソフトウェアの発行元からのドキュメントなど、より公式なドキュメントとすることができる。
【００１６】
設計者は、言語１４２を選択し、オペレーション上の知識１４８を収集すると、ＩＴシステムのコンポーネント／クラス、関係、および制約に関する型（type）を符号１２０において宣言または定義することによって進むことができる。
【００１７】
クラス／コンポーネントおよび関係の型は、ＩＴシステムのモデルのためのソフトウェアおよびハードウェアの構成要素を形成する。いくつかの型は、整数（integer）、文字列（string）、ブール値（boolean）、列挙型（enumerations）など、事前に定義された型である値タイプ（value type）とすることができる。クラス型（class type）やコンポーネント型（component type）は通常、基本的なシステムおよびリソースを表し、モデル化して保守すべき不変の（invariant）状態を取り込むプロパティを有することができる。制約型（constraint type）は、不変の要件を取り込むプロパティ上で、あるいはそうしたプロパティどうしの間で機能する。
【００１８】
関係型は、２つまたはそれ以上のクラスの間における意味的な関係（semantic relationship）を表す。関係型は、「〜の間における通信」、「〜への参照」、「〜の／上でのホスティング」、「委任（delegation）」、「特定の種類の対話」、「どんなオブジェクトを別のオブジェクトは含むことができるか」、「どのエンドポイントどうしを結び付けることができるか」、「どんな環境が特定のオブジェクトをホストすることができるか」などを含むいかなる任意の関係も表すことができる。関係の包含タイプ（containment types of relationships）は、モデルの包含構造（containment structure）を定義するための基本的な構成要素として使用することができる。関係型は、その関係に関連付けられている不変の状態を表すためのプロパティを有することができ、そして関係は、制約することができる。
【００１９】
複数の部分からなる複雑な型を構築するために、合成型（composite type）または複雑型（complex type）を使用することができる。合成型は、現実世界のシステム（あるいはサブシステム）をモデル化する上で重宝することができ、（常にというわけではないが）通常はシステムの拡張および展開に関する詳細を含むことができる。合成型は、システムのリソースを表すために、任意のクラス型のオブジェクトを（参照または値によって）含むことができる。合成型は、合成のオブジェクト（the composite's object）どうしの間における関係を表すために、任意の関係型のコネクタを含むことができる。合成型は、複合の不変の要件（または設定）を取り込むオブジェクトに関する制約やルール、あるいはそうしたオブジェクトどうしの間における制約やルールを含むこともできる。つまり合成型は、クラスと関係とを、望ましい状態、構造、制約、および動作と共にコンテキストに当てはめて複合したものである。
【００２０】
制約の型を定義することもできる。制約は、所与のクラス型や関係（コネクション）型（relationship (connection) type）のインスタンス（オブジェクト）に関する不変条件を表す。制約は、値や構造を制約することができる。制約は通常、プロパティ／役割．．．などへアクセスすることができる論理式（boolean expression）である。制約は通常、真または偽のいずれかとして評価することができ、その場合、偽の評価は、その制約に違反していること、あるいはその推奨に沿っていないことを示す。
【００２１】
モデル１４０を設計する人によって符号１２０において定義することができる型が与えられ、そして言語１４２およびオペレーション上の知識１４８が与えられると、その設計者は、ＩＴシステムをモデル化するために必要となるクラス、関係、制約、および／または合成の型を定義する。その設計者は、オペレーション上の知識１４８をモデル化したり取り込んだりするために、それらの型を符号１２２において調整する。これがどのように実行されるかに関する詳細は、複数の例を図６〜図１２を参照して論じるにつれて、さらに明らかになるであろう。このポイントまでのプロセスは、設計プロセスであり、鉛筆および紙、モデリングツールなど、任意の数の方法で、型を符号１２０において定義して、符号１２２において調整することができる。しかし型はファイナライズされると、符号１２４において、言語１４２のタイピングシンタックス１４４内に、クラス（またはコンポーネントあるいは値）の型の宣言１５６、関係の型の宣言１５８、モデル１４０を制約する制約の宣言１６０、および合成型（composite type）の宣言１６２として格納される。モデル１４０およびその型の定義または宣言１５６〜１６２は、符号１２４において、磁気メディア、光メディア、揮発性メモリや不揮発性メモリなど、任意のコンピュータ可読メディア内に１つまたは複数の電子ファイルやドキュメントとして格納することができる。さらにモデル１４０は、たとえばマシンコード、バイトコード、中間コード（intermediary code）などへコンパイルすることによって変換することができる。
【００２２】
図６は、モデルの別の表現を示す。モデル１８０のコード化された定義について、図７〜図１２を参照して論じる。モデル１８０は、望ましいｅ−コマースウェブシステムを表す。クラス型のうちのいくつかは、ウェブアプリケーション１８２、Ｗｏｒｋｅｒ  Ｐｒｏｃｅｓｓ  Ｉｓｏｌａｔｉｏｎ１８４、カスタマートランザクションデータベース１８６、ＳＱＬサーバ（クラスタ）１８８、カタログデータベース１９０、およびＳＱＬサーバ（スタンダード）１９２である。関係型のうちのいくつかは、ホスト依存関係（host dependency）１９４、１９６、１９８、および通信２００、２０２である。以降で論じるように、複数のオペレーション上の制約２０４も、モデル１８０によって取り込まれる。
【００２３】
関係のうちのいくつかは、多数性不変条件（numerosity invariant）を有することができる。たとえば通信関係２００は、通信関係２００のそれぞれの終端に１つのエンティティーがなければならないという多数性不変条件２０６を有する。クラスのうちのいくつかも、多数性不変条件を有する（クラス１８２〜１９２を表す四角い枠の右上の隅を参照されたい）。たとえばＳＱＬサーバ（標準）１９２は、同じものの１つまたは複数の発生（「［１．．*］」）であることができる。
【００２４】
図７は、図６の例において使用されているさまざまな関係型およびクラス型を定義するコード２２０を示す。モデル化のために選択されている言語にかかわらず、型の宣言は、それらが型の宣言であるということを示す何らかの構造や情報、および宣言されている型の種類を示す何らかの構造や情報、たとえば、関係の型が宣言されているということを示す「ＲｅｌａｔｉｏｎｓｈｉｐＴｙｐｅ」や、クラスの型が宣言されているということを示す「ＣｌａｓｓＴｙｐｅ」を有する。図７において宣言されている型およびそのプロパティのほとんどは、その内容が一目瞭然である。当然ではあるが、これらの基本の型は、より複雑な合成型の部分として機能することができる。
【００２５】
図８〜図１０は、ｅ−コマースウェブサイトのオペレーション上の知識を取り込む複雑クラス（complex class）型を宣言するコード２２２、２２４、２２６を示す。ｅＣｏｍｍｅｒｃｅＳｉｔｅ複雑クラス（eCommerceSite complex class）の部分およびコネクションとして宣言されている部分および関係は、図７において定義された型である。ｅＣｏｍｍｅｒｃｅＳｉｔｅは、いくつかのオペレーション上の側面やポリシーを取り込む。ｅＣｏｍｍｅｒｃｅＳｉｔｅは、その構成要素の多数性を指定する。ｅＣｏｍｍｅｒｃｅＳｉｔｅはまた、部分どうしの間におけるコネクタ、ならびにエンドポイントおよび役割を指定する。図１０は、その他のいくつかのオペレーション上の知識をｅＣｏｍｍｅｒｃｅＳｉｔｅ型の制約の形式で示す。ＷｏｒｋｅｒＰｒｏｃｅｓｓＭｕｓｔＢｅＥｎａｂｌｅｄという名前の制約は、すべてのＩＩＳ６  ｗｅｂｓｅｒｖｅｒ  ｐａｒｔ（図８参照）が自分のＷｏｒｋｅｒＰｒｏｃｅｓｓＥｎａｂｌｅｄプロパティを真に設定されていなければならないということを必要とするように定義されている。これは、実際にはｅ−コマースインスタンスのｗｅｂｓｅｒｖｅｒメンバーのプロパティを設定せず、むしろｅ−コマース型（e-commerce type）に関する望ましい制約を宣言し、ｅコマース型のそのインスタンスは、それらのＷｏｒｋｅｒＰｒｏｃｅｓｓのすべてが有効にされていない場合には有効にならない。別の制約は、すべてのｔｒａｎｓａｃｔｉｏｎＳｑｌＳｅｒｖｅｒｓが自分の認証モード（AuthenticationMode）を「Ｗｉｎｄｏｗｓ（登録商標）」に設定されていなければならないということを指定する。
【００２６】
図１１は、オペレーション上のポリシーの例２２８、２３０をルールや制約の形式で示す。例２２８においては、ｅＣｏｍｍｅｒｃｅＳｉｔｅクラスのｗｅｂａｐｐオブジェクトは、アプリケーションごとに１，０００人のユーザを超えないように定義されている。例２３０においては、制約は、パフォーマンスのために推奨されるものとして分類されている。
【００２７】
制約やルールは、情報のほとんどあらゆる断片から作成することができる。さらに制約は、真または偽として評価できる論理式として構築することができる。これらの式を構築するために、「ａｌｌ  ｏｆ」や「ｎｏｎｅ  ｏｆ」などの論理演算子を使用することができる。複雑な複数の演算子を用いる式を構築することができる。論理式のセットは、式＝式＜演算子＞式、または式＝項によって大まかに定義される式の領域（universe of expressions）内に存在することができ、この場合、演算子は、数学演算子（math operator）やブール演算子などであり、項は、モデル内で定義される任意の型（たとえば、関係、クラスなど）や、それらの型のプロパティ、もしくは定数、または日付や時間などのグローバル情報でさえ、あるいはモデル本体そのものの設定のうちのいずれにすることもできる。論理式の同様の定義に関しては、Ｃ＃、．Ｎｅｔ、あるいはＪａｖａ（登録商標）を参照されたい。したがって、ＩＴシステムのほとんどいかなるタイプのオペレーション上の制約も、モデル化することができる。制約は、厳格な制約または助言的な（advisory）制約のいずれかとしてタイプ分けすることができるが、それらの制約は、同じ方法でその他の形で宣言される。その他の型の制約や不変条件を定義することもでき、したがって、たとえば制約をそれらの型に基づいて確認することができる。
【００２８】
上述の説明および例を考慮すれば、モデル化されている望ましいＩＴシステム（ｅ−コマースウェブシステム）のポリシーは、宣言型の構造を使用して確立することができ、アルゴリズム的なコードや動作的なコード（algorithmic or behavioral code）を構築する必要はないということが明らかなはずである。さらに、これらの例はＸＭＬでコード化されているが、その他の言語を使用することもできる。たとえば、Ｃ＃のスタイルでの宣言を容易に使用することができ、たとえ実行可能ステートメントの形式の動作（behavior）がそのようなコード内に含まれていても、宣言型のコード（型の宣言）は、そのような動作的なコードとは論理的に切り離されているとみなすことができる。すなわち、モデルの有効性は、そのモデルのコード内に偶然に含まれている可能性のあるいかなる動作にもかかわらずに（型のチェック、ルールのテスト、不変条件のテストなどを利用して）テストすることができる。
【００２９】
図１２は、制限や拡張による派生（derivation）の例２３２、２３４を示す。モデル内に取り込まれたオペレーション上の知識は、派生を通じて再利用され、洗練されることができる。既存のモデル内に取り込まれた知識を専門化するために、制限による派生を使用することができる。例２３２に見られるように、ｅ−コマースサイトのためのモデルの場合には、そのモデルを再利用して（制限的に導き出して（restrictively derive））、１つのウェブサーバまたは１つのカタログデータベースサーバの障害に対する回復力を有するように少なくとも２つのウェブサーバと少なくとも２つのカタログサーバとを有するフォルト・トレラントなｅ−コマースサイトのためのモデルを定義することができる。ベースモデルも、拡張によって派生することができる。モデル内に取り込まれた知識を拡張するために、拡張による派生を使用することができる。例２３４に見られるように、ｅ−コマースサイトのモデルを拡張して、ウェブサーバおよびデータベースサーバに加えてメディアサーバを有するオンライン・ミュージックストアのためのモデルを定義することができる。
【００３０】
最後に、プログラム命令を格納するために利用されるストレージデバイスは、ネットワーク全体にわたって分散されうるということを当業者なら認識するであろう。たとえばリモートコンピュータは、ソフトウェアとして説明したプロセスの一例を格納することができる。ローカルコンピュータまたは端末コンピュータは、リモートコンピュータにアクセスして、プログラムを実行するためのソフトウェアの一部またはすべてをダウンロードすることができる。別の方法として、ローカルコンピュータは、ソフトウェアの断片を必要に応じてダウンロードすることもでき、あるいは、いくつかのソフトウェア命令をローカル端末で実行し、いくつかのソフトウェア命令をリモートコンピュータ（またはコンピュータネットワーク）で実行することによって、分散処理を行うこともできる。当業者に知られている従来の技術を利用することによって、ソフトウェア命令のすべてまたは一部をＤＳＰやプログラマブルロジックアレイなどの専用回路によって実行することができるということも当業者なら認識するであろう。
【００３１】
上述の実施形態および特徴はすべて、コンピュータやデバイスによって読み取ることができる揮発性や不揮発性のメディア内に格納された情報の形態で実現することができる。これは、少なくとも、マシンによって実行できる命令、またはソースコード、あるいはコンピューティングデバイスがさまざまな実施形態を実行できるようにするために使用することができるその他の任意の情報を格納するＣＤ−ＲＯＭ、磁気メディア、フラッシュＲＯＭなどのメディアを含むとみなされる。これはまた、少なくとも、一実施形態を実行するプログラムの実行中にＣＰＵ命令などの情報を格納するＲＡＭなどの揮発性メモリを含むとみなされる。
【図面の簡単な説明】
【００３２】
【図１】オペレーション上の知識と、モデルと、ＩＴシステムとを有するコミュニティーを示す図である。
【図２】モデルによって表すことができる層を示す図である。
【図３】ＩＴシステムのモデルの１つの用途を示す図である。
【図４】モデルを宣言するためのプロセスを示す図である。
【図５】宣言型モデルを示す図である。
【図６】モデルの別の表示を示す図である。
【図７】図６の例において使用されているさまざまな関係型およびクラス型を定義するコードを示す図である。
【図８】ｅコマースウェブサイトのオペレーション上の知識を取り込む複雑クラス型を宣言するコードを示す図である。
【図９】ｅコマースウェブサイトのオペレーション上の知識を取り込む複雑クラス型を宣言するコードを示す図である。
【図１０】ｅコマースウェブサイトのオペレーション上の知識を取り込む複雑クラス型を宣言するコードを示す図である。
【図１１】ルールや制約の形式のオペレーション上のポリシーの例を示す図である。
【図１２】制限や拡張による派生の例を示す図である。
【図１】
2009515252.tif 000003
【図２】
2009515252.tif 000004
【図３】
2009515252.tif 000005
【図４】
2009515252.tif 000006
【図５】
2009515252.tif 000007
【図６】
2009515252.tif 000008
【図７】
2009515252.tif 000009
【図８】
2009515252.tif 000010
【図９】
2009515252.tif 000011
【図１０】
2009515252.tif 000012
【図１１】
2009515252.tif 000013
【図１２】
2009515252.tif 000014
【国際調査報告】
2009515252.tif 000015
2009515252.tif 000016