JPH07509582A - システム管理方法およびその装置 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるため要約のデータは記録されません。

Description

【発明の詳細な説明】 システム管理方法およびその装置 発明の技術分野 本発明は、コンピュータシステムにより提供するよう意図された少なくとも１つ のサービスに関連する少な゛くとも１つの管理タスクを実行するためのシステム 管理方法およびその装置に関する。特に本発明は（これに限られたものではない が）、コンピュータのネットワーク上に提供される（ログオン、電子メール、印 刷スプール等の）多数の異なるサービスに関連する（インストール、監視、障害 診断等の）多数の管理タスクの実行を容易にするための方法およびその装置に関 する。

発明の背景 近年、コンピュータシステム（特にコンピュータネットワーク）の複雑さが相当 増大し、かかるシステムは、多様な異なるサービスを提供する際の多数のシステ ムエンティティの対話を特徴とする。

その結果、かかるシステムの維持および運転が課せられたシステム管理資源にか なりの負担がかかることになる。システムエンティティ同士の結合に使用される 技術の高度性が増大するのに伴って、プロトコルアナライザ等の低レベルの障害 診断装置が発達したが、かかる装置は、メンテナンスエンジニアの助けとなるよ う機能することしか意図されていないものが多く、試験中の特定のポイントでの 問題点をメンテナンスエンジニアに知らせるだけのものであった。

同様に、ネットワークの全ての部分からデータを収集することによって全体的な システム性能の概観を提供しようとする高レベルのネットワーク管理システムも また、その大部分が用途の限定されたものであり、ネットワークスーパバイザに 何が起こっているのかを理解することに関して多くの問題が残うている。

更に近年になって、ネットワークの障害診断および管理にエキスパートシステム 技術を導入するよう多数の提案がなされている。かかる技術を用いたネットワー ク管理システムの１つに、ＦｅｒｉｄｕｎＳＭ。

ＬｅｉｂＳＭ、Ｎｏｄｉｎｅ、およびＪ、Ｏｎｇによる論文ｒＡＮＭ：　Ａｕｔ ｏｍａｔｅｄ　Ｎｅｔｗｏｒｋ　Ｍａｎａｇｅｍｅｎｔ　ｓｙｓｔｅｍｊ　（Ｉ ＥＥＥ　Ｎｅｔｗｏｒｋ、　Ｍａｒｃｈ　１９８８−ｖｏｌ、２．　Ｎｏ、２） に説明されているΔＮＭ（自動ネットワーク管理）システムがある。

このへＮＭシステムでは、ゲートウェイ等のネットワークエンティティが分散形 管環モジュール（ＤＭＭ）のコアにデータを提供し、そのＤＭＭが、ネットワー ク管理サービスを提供する「クライアント−１にサービスを行う。クライアント は、ＤＭＭコアによってネットワークエンティティから収集された生データを要 求してそれを受信する。クライアントはまた、ＤＭＭコアに特定の動作の実行を 要求することができる。インテリジェントネットワークマネージャと呼ばれる特 殊なりライアントが設けられ、このクライアントは、ネットワークエンティティ から受信したトリガデータを、特定種類のネットワーク問題を各々が理解する別 のエキスパートに送る、最上位レベルのエキスパートとして編成されたエキスパ ートシステム（エキスパート）の集合体からなる。それらエキスパートは、前記 トリガデータを説明する可能性のある考え得る仮説を提案することができる。必 要であれば、各エキスパートは、ネットワークエンティティからの更なるデータ を要求することができる。エキスパートが仮説を提案、確認または拒絶すると、 それがネットワークのオペレータに通知される。新しいタイプのネットワーク問 題に関する専門知識をΔＮＭのインテリジェントネットワークマネージャに追加 するためには、そのシステムに新しいエキスパートを追加しなければならず、ま たシステムが諸問題に関する推論を行う方法を変更するためには、かかる推論を 行うエキスパートを全て変更しなければならない。

当業界におけるエキスパートシステム技術の使用のもう１つの例として、ヨーｏ 　ツバ特許出願第０４７３２５５八２号（ｌｌｅｗｌｅｔｔ−Ｐａｃｋａｒｄ） に記載のネットワーク監視／分析装置がある。この装置にも多数の異なるエキス パートシステム（コンサルタント）が設けられている。

しかし、ネットワーク問題のそれぞれのタイプにエキスパートが関連するΔＮＭ システムとは異なり、そのＩｌｅｗｌｅｔｔ−Ｐａｃｋａｒｄの装置では、あら ゆる所与のネットワーク問題の分析に通常伴う動作のタイプのうちのそれぞれ１ つに各コンサルタントが関連する。

後者のいずれの構成においても、専門知識がエキスパートシステム中に符号化さ れて、ネットワークの障害を識別するオブジェクトに症状が与えられ、考え得る 解決策が提案される。システムに何が発生しているかについてのいかなる知識も 、解決すべき問題に密接に結び付けられる。その結果として、その専門知識は、 障害の存在しない他のタイプの管理タスク（サービスのインストール等）には利 用することができない。これが、ネットワーク管理タスクの実行の支援を提供す ることを意図した今日のシステムの特徴であり、その結果として、各々の管理タ スクがそれ自体の特殊な援助を（一般にはソフトウェアツールという形態で）有 することになり、各タスク毎の援助の数は、そのタスクが実行されることになる ネットワークサービスの数に対応する。

本発明の目的は、システムに関する専門知識をより有用な形態で提供することに よりシステム管理を容易にすることである。

及匪立皿塗 一般に、本発明は、特定のサービスに必要な要件を宣言モデルという形態で利用 可能となるように指定し、次いで、かかるモデルについて実行可能な一般的な推 論動作に関して管理タスクを規定することにより、前記目的を達成する。その結 果として、各サービスモデルを各タスクにより使用することができる。

ここで使用するように、「宣言モデル」という用語は、サービスの概念的記述を 意味するものであり、そのモデルの意味は、そのモデルが受ける可能性のある処 理のいかなる形態からも独立したものである。従って、１つのモデルは（実行型 モデルの場合に典型的であるのとは対照的に）その使用方法に関して順序、反復 、または選択の表記を有さす、その代わりに、このモデルは、論理演算子（ＡＮ Ｄ、　ＯＲ，ＮＯＴ等）を用い、また必要に応じて再帰を用いる。勿論、順序、 反復および選択の概念を、関連するサービスのモデル化の一部としてモデル中で 表現することもできるが、これは、モデルの宣言的な性質に影響を与えるもので はない。

ここでいうタイプのモデルは、管理される現実のネットワークをシミュレートす る「仮想ネットワーク」がその現実のネットワーク中の各エンティティの「モデ ル」から構築される国際用ｊｉＷｏ　９２１０５４８５　（Ｃａｂｌｅｔｒｏｎ 　Ｓｙｓｔｅｍ）に開示されているものとは基本的に異なる。

「仮想ネットワーク」もＣａｂｌｅｔｒｏｎ　Ｓｙｓｔｅｍの個々の「モデル」 も本発明の場合のようにネットワークサービスの記述を意図するものではなく、 更に、Ｃａｂｌｅｔｒｏｎの「モデル」は現実の世界の項目と一対一の対応関係 を有しており、これもまた本発明とは異なっており、本発明では、現実のシステ ムにおけるサービスの実例が存在しないのか、また１つあるいはそれ以上存在す るのかにかかわらず、単一のサービスモデルが１つのサービスの要件を規定する 。

一層圧式にいうと、本発明の一態様によれば、互いに協働する物理エンティティ および論理エンティティからなるコンピュータシステムにより提供することが意 図された少なくとも１つのサービスに関連する少なくとも１つの管理タスクを実 行するためのシステム管理方法が提供される。この方法は次の諸ステップからな る。即ち、前記の少なくとも１つのサービスの各々について、そのサービスが利 用可能となるために満たす必要のある要件を特定の前記タスクのいずれからも独 立して指定する個々の宣言モデルを提供し、前記要件が、必要とされるエンティ ティとその相互関係とに関して記述されており、 前記の少なくとも１つの管理タスクの各々について、対応するタスクの実行を、 特定の前記モデルのいずれからも独立した態様で、前記モデルのいずれについて も実行可能な一般的な推論動作に関して制御する、タスク制御手段をそれぞれ提 供し、前記の少な（とも１つのサービスに関連する前記の少なくとも１つの管理 タスクを、その管理タスクに関連する前記タスク制御手段の制御下で、対応する 宣言モデルについて推論動作を行うことを含む処理により実行する、 というステップからなる。

好適には、前記の各タスク制御手段は、対応するタスクを実行するために推論エ ンジンの動作を制御する個々のタスクプログラムを有し、同一エンジンが、処理 すべきモデルにかかわらず各タスク毎に用いられる。しかし、前記タスク制御手 段を推論エンジンの機能アーキテクチャ内で実施するよう構成し、これによりそ のエンジンを対応するタスクに適応させることが可能である。この場合には、実 行すべき各タスク毎に推論エンジンがそれぞれ存在することになる。また、共通 の推論エンジンの機能アーキテクチャが実行すべきタスクにより決定されるが、 更に、プログラムされた態様でその機能を実行するタスクプログラムが存在する 、という中間的な方法力く可能である。この方法は、推論エンジンが、標準的な ）１−ドウエア上でソフトウェアルーチンにより一般に実施され、それを構成す る諸ルーチンの相互関係を変更することにより、その推論エンジンの機能を変更 することができるようになっている、という事実より、実施可能なものである。

本発明のシステム管理方法は、多数のサービスと実行すべき多数のタスクとが存 在する場合に特に有利なものである。これは、サービスおよびタスクの各対を実 行するために特殊なプログラムを書く必要がないからである。しかし、この方法 はまた、提供すべきサービスが１つしか存在しない場合、または、実行すべきタ スクが１つしか存在しない場合にも適用することができる。

一般に、管理すべきコンピュータシステム（典型的にはコンピュータネットワー ク）は、サービスの複数の例示をサポートすることが可能なものであり、そのサ ービスに関連する管理タスクを実行するステップには、サービスの例示を識別し 、次いで適当なサービスモデルを用いて、その識別されたサービスの例示に関連 する情報を推論する。

好適には、サービスの宣言モデルは、エンティティを相互に対応付ける階層構造 の宣言ステートメントからなり、その階層中の下位のステートメントは、その階 層中の上位のステートメントによって指定される要件を詳述する働きをする。

これらのステートメントは、要件を直接指定するステートメントに加えて、エン ティティを相互に対応付けし特定の要件が満たされたか否かを推論するのに用い ることのできるステートメントを含むことができる。適当な場合であれば、１つ のモデルを他のモデルと対応付けて、１つのモデル中で記述され特定のエンティ ティに関連するステートメントが、同じエンティティと関連して他のモデルで使 用できるようにすることができる。

１つのサービスモデル中で指定された要件は、複数の組、即ち、必須の技術的要 件からなる組や、例えば特定のファイルに使用される名称を記述する動作方針要 件からなる組に有効に分割することができる。

好適には、管理タスクの実行を容易にするために、システムとの対話を介して更 新されて所望の情報を提供することができる事実ペースを参照することにより、 システムに関する情報を得ることができる（後者の場合、その所望情報は、特定 の情報項目を引き出すよう設計された照会を介して直接的に確認することができ 、また、対話により実行される特定のシステム機能の結果からの推論により間接 的に確認することができる）。

このシステム管理方法は、コンピュータシステムを不変に維持するタスク（例え ば障害診断タスク）だけでなく、（エンティティの追加または除去により、また は、少なくとも２つのエンティティ間の相互関係を修正することにより）何らか の態様でシステムを変更することを必要とするタスク（特定ユーザのためのサー ビスのインストール等）にも適用することができる。

本発明の別の態様によれば、互いに協働する物理エンティティおよび論理エンテ ィティからなるコンピュータシステムによって提供することが意図された少なく とも１つのサービスに関連する少なくとも１つの管理タスクを実行するためのシ ステム管理装置が提供される。この装置は、 前記の少なくとも１つのサービスの各々について、そのサービスが利用可能とな るために満たす必要のある要件を特定のタスクのいずれからも独立して指定する 宣言モデルであって、前記要件が必要とされるエンティティとその相互関係とに 関して記述される、前記宣言モデルと、 前記宣言モデルに関して推論動作を実行する推論エンジン手段と、前記の少なく とも１つの管理タスクの各々について、前記推論エンジン手段による対応するタ スクの実行を、特定のモデルのいずれからも独立した態様で、一般的な推論動作 に関して制御する、それぞれのタスク制御手段と、 １つの特定のサービスに関連して１つの管理タスクを実行させる手段であって、 その実行が、その管理タスクに関連する前記タスク制御手段の制御下で、対応す る宣言モデルについて前記推論エンジン手段を動作させることにより行われる、 前記実行手段とを備えたものである。

好適には、このシステム管理装置は更に、そのシステムに関する事実を格納する ための事実ベース手段と、システムと対話を行ってそのシステムに関する事実を 直接的に確認しまたは前記対話の結果からの推論を介して確認する対話手段とを 有し、推論エンジン手段が、前記管理タスクの実行中に動作して事実ベース手段 を参照することにより、前記要件がそのシステムにより満たされているが否がを チェックし、事実ベース手段にある事実が不十分である場合には、前記対話手段 にシステムとの対話を行わせて更に事実を引き出すことにより、前記要件がその システムにより満たされているか否かをチェックする。

図面の簡単な説明 本発明を実施したシステム管理装置を、本発明を制限することの無い実施例によ り添付図面に関連して説明する。

図１は、エンドユーザ側から見たコンピュータシステムを示している。

図２は、システム管理者側から見たコンピュータシステムを示している。

図３は、本発明を実施したシステム管理装置の概略図であり、タスクプログラム およびサービスモデルの任意の対を示している。

図４は、図３の装置の推論エンジンの図である。

図５は、所定の１組の事実が与えられた場合におけるサービスモデルの一例に関 する図４の推論エンジンの動作を示す探索ツリーである。

図６は、図５の場合と同じサービスモデルに関する図４の推論エンンンの動作を 示す探索ツリーであるが、照会を用いて事実を引き出している。

図７は、互いに対応付けされた関係を有する３つのエンティティタイプの規定を 含むサービスモデルの形式を示す図である。

図８は、サービスモデルエンティティとモデル間の移入（ｉｍｐｏｒｔａＬｉｏ ｎ）との間の引き継ぎを示す図である。

図９は、ネットワークのユーザに印刷スプーラサービスを提供する際に含まれる 機能の図である。

図１０は、図９のサービスをサービスモデルおよびエンティティに関して如何に 表現することができるかを示している。

図１１は、管理されているコンピュータシステムから情報を得るのに使用可能な 照会の形式を示す図である。

図１２は、管理されているコンピュータシステムのユーザについての情報を与え るリターンストリングの構文解析を示している。

本発明の最良の実施態様 凰週 図１は、ブリッジ１３を介して結合されたＬＡＮセグメント１２を含むネットワ ークを介して相互接続されたワークステーションＩＯおよび周辺機器ＩＩ（例え ばプリンタ）からなるコンピュータシステムを示すものである。図１は、このシ ステムをエンドユーザ側から見た図である。ワークステーション１０で作業を行 うエンドユーザ１４は、コンピュータシステムへのログイン、特定アプリケーシ ョンプログラムの実行、印刷スプール処理、電子メール、およびログオフといっ た１つ以上のサービス１５の提供をシステムに希望する。

図２は、図１と同じコンピュータシステムを、同システムの前記ワークステーシ ョンｌＯで作業を行うシステム管理者１６の側から見た図である。このシステム 上でエンドユーザに利用可能な各サービス毎に、システム管理者１６は、そのサ ービスのインストール、そのサービスの構成、障害の診断、障害の修正およびサ ービスの除去等を含む多数のタスク１７を実行できるように準備しなければなら ない。

このために、システム管理者のワークステーションは、各サービスに関連して各 タスクを実行するために、そのワークステーションを管理システムに変更する適 当なソフトウェアを実行する。従来のシ、ステムでは、この管理システムは、サ ービスおよびタスクの各対毎に固有のプログラムを書き込む必要があった。以下 で説明する本発明を実施した管理システムは、その必要性を無くし、各タスクお よび各サービスの別々の特性化しか必要としないものである。

本発明で実施したシステム管理装置の一般的形態を図３に示す。

本装置の主な構成要素は、１組のタスクプログラム２１（実行すべきｍのタスク のそれぞれに１つずつ）と、１組のサービスモデル２２（このコンピュータシス テムにより提供されるｎのサービスのそれぞれに１つずつ）と、このコンピュー タシステムのワークステーションｌＯと適当なソフトウェアにより構成される管 理システム２０である。

各サービスモデル２２は、関連するサービスの宣言モデルであり、サービスが利 用可能となるために満たされる必要のある要件を指定する。かかる要件は、この コンピュータシステムの物理エンティティおよび論理エンティティに関して記述 される。サービスモデルは、それを異なる管理タスクに使用する方法に関する情 報を含んでいない。各サービスモデルには、照会および動作２８が対応付けられ ている。照会は、関連するサービスについて指定された要件に関する情報をコン ピュータシステムとの対話により如何にして得ることができるかについての情報 を詳述する。また、動作は、あるタスクの実行に必要となる可能性のあるモデル 化されたサービスに関連する手続きの実行を開始させる方法を詳述する。

管理システム２０は、推論エンジン２５と事実ベース２６と対話マネージャ２７ とからなる。タスクプログラム２１のうちの１つの制御下でいずれかの特定タス クを実行する場合には、推論エンジン２５は、そのタスクが実行されている関連 するサービスのサービスモデルを使用してそのサービスに関する要件を識別し、 次いで利用可能となるあらゆる情報を使用して、それらの要件から（特に、それ らの要件が既に満たされているか、または満たされる必要があるかについて）あ る種の推論を行う。事実ベース２６は、管理システムにとって既知の事実であり 、したがって推論エンジン２５が直接利用することのできる事実を格納する。所 望の事実が事実ベース２６に存在しない場合には、推論エンジン２５は、関連す るサービスモデル２２に対応付けされた照会を用いて対話マネージャ２７にコン ピュータシステムとの対話を行わせて、直接的にまたは経験から間接的に関連す る事実を得る。更に、タスク（例えば、サービスのインストールまたはリムーブ ）を完了させるために、管理されているシステムを修正する必要がある場合には 、推論エンジンは、対話マネージャ２７を介して、関連するサービスモデル２２ に対応付けされた適当な所定動作を開始させるよう動作することができる。

一例として、疑似自然言語を用いて、ユーザのログインサービスに関するログイ ンサービスモデルは、４つの要件が満たされた場合にそのサービスがユーザに利 用可能となることを指定できる。

「名称」と称するユーザに関するログインサービスは、システムがこの名称によ るユーザの記録を有しており、このユーザがパスワードを有しており、このユー ザがホームディレクトリを有しており、このユーザがそのディレクトリへの実行 アクセスを有している、という場合に０にである。

１人の特定ユーザに関するログインサービスの診断を実行することが所望される 場合には、診断タスクプログラムが、推論エンジアン２５に、ログインサービス モデルを調べさせ、満たされなければならない全ての要件を識別させる。例えば 、ｒ　ＪｏｈｎＪと称するユーザがログインできない場合、そのモデルは、その 名称を有するユーザをシステムが知っていなければならず、そのユーザがパスワ ードを有していなければならず、そのユーザがホームディレクトリを有していな ければならず、そのユーザがそのディレクトリへの実行アクセスを有していなけ ればならない、ということを記述している。また推論エンジン２５は、診断タス クプログラムの制御下でこれらの要件のうちのどれが満たされていないのかを確 認する。

システムに新規ユーザを追加したい場合には、「ユーザ追加」タスクプログラム が、推論エンジン２５に、ログインサービスモデルを調べさせて、この新しいユ ーザがログインするために如何なる要件を満たさなければならないかを識別させ る。次いで、かかる要件をシステム上の適当な動作により満たすことができる。

タスクプログラム、サービスモデル、照会および動作の全ては、一般に、高級言 語で書かれ、オブジェクトコードへとコンパイルされて、実行されることになる 。

推論エンジン 推論エンジン２５の一般的形態を図４に示す。概念的には、この推論エンジンは 、それに供給されるタスクプログラム２１に従ってその推論エンジンを制御する タスク制御層３０と、検査機構（ｖｅｒｉｆｉｅｒ）３１と知識アシミレータ３ ２と定理プルーバ３３とからなるプルーフシステムと、当業者にはいずれも周知 のＰｒｏｌｏｇまたはＳｍａｌｌｔａｌｋ等の適当な言語により提供される論理 支援層（統合化、述語、および変数を提供するもの）とから構成されている。

前記プルーフシステムに関し、その検査機構３１は、真であることを証明できな いものは偽であるとみなされる閉じた世界の（ｃｌｏｓｅｄｗｏｒｌｄ）演鐸シ ステムを用い、照会を使用することはない。したがって、検査機構３１は、現在 の知識の状態が与えられた場合に真となり得るものを発見するのに有用である。

知識アシミレータ３２は、成る形態の差熱的三段論法（ａｂｄｕｃｔｉｏｎ）を 用いて、照会の結果から生じる観測を説明するのに十分な、−貫した事実ベース への拡張を見つけ出す。主定理プルーバ３３は、やはり照会を考察する、開いた 世界の演鐸システムであり、その推論エンジンの核である。タスク制御層３０の 役割は、実行中のタスクについて所望される結果を生成するような態様でプルー フシステムの各要素の動作を統合することである。

しかし、一般には次のように述べることができる。即ち、定理プルーバ３３は、 事実ベース中の現在利用可能な事実に基づいて特定の定理を証明することができ ない場合に、照会を参照して所望の事実を提供するものを見つけ出すように知識 アシミレータ３２に要求し、その照会が実行されると、知識アシミレータがこの 照会の結果がら可能な限り多くの情報を抽出し、この新しい情報を、定理プルー バ３３による使用に備えて事実ベースに格納する。

サービスモデル２２中で与えられ事実ベース２６中の利用可能な事実に関連する 規則に基づいて定理プルーバ３３が行う推論の態様の簡単な一例を次に説明する こととする。

各サービスモデルは、そのモデルに関連する１つ以上のエンティティに関するス テートメントを含み、一般にががるステートメントが使用されて、例えば成る条 件が満たされた場合に成るサービスエンティティが利用可能となることを指定す る、多数の規則（条件的な関係）が形成される。したがって、図４のサービスモ デル２２を参照すると、そのサービスモデル２２には、３つの規則へと編成され た貞の値を有するステートメントＡ〜Ｈが存在する。

ＢまたはＣであればＡ ＤかつＥかつＦであればＢ ＧまたはＩ（であればＣ ステートメントΔは、ステートメントＢまたはステートメントＣが真であれば関 連するサービスが利用可能であることを表す。次いで上記の２番目の規則は、ス テートメントＢが真であるために満たすべき条件を規定し、３番目の規則は、ス テートメントＣが真であるための条件を規定する。

一例として、Ｄ、Ｆ、Ｇが真であるがＥ、Ｈが偽であるという事実を事実ベース が含んでいる状況をまず考察する。上記の規則とこれら事実とから、主定理プル ーバ３３は、モデル２２により表されるサービスが利用可能であるか否か、即ち 、Ａが真であるが否かを演鐸することができる。この証明は、次のように進めら れる（図５参照）。

（１）八に関する事実は存在しないが規則が存在するので、解の探索は２つの部 分解ノードに展開される。

（２）Ｂを考察する。この場合も事実は存在しないが関連する規則が存在するの で、探索が再び展開される。

（３）　Ｄ、Ｅ、、Ｆを考察する。Ｄに関する事実があるので、次の部分解はノ ードＥ、Ｆである。

（４）Ｅ、Ｆを考察する。Ｅが偽であることが既知なので、この分岐は失敗であ る。

（５）次の未展開の部分解ノード（即ちＣ）に戻る。Ｃに関する事実は存在しな いが規則が存在するので、探索が展開される。

（６）Ｇを考察する。これは真であることが既知なので、解が見つかっている。

この−例は、解空間にわたる簡単なｄｅｐｔｈ−ｆｉｒｓｔ探索に過ぎないこと に留意されたい。勿論、ｒｂｅｓｔ　ｆｉｒｓｔＪ戦略等の他の探索戦略もまた 可能である。

次に、事実ベース２６に事実が存在しない場合を考える。しかし、１組の照会が モデル２２に対応付けられて２つの照会Ｑ１．Ｑ２が提供される。ここで、照会 Ｑ１は、Ｄ、Ｅに［有効な（ｇｏｏｄｆｏｒ）Ｊ　（即ち、Ｄ、Ｅの値を与える ）ものであり、照会Ｑ２は、Ｆ、Ｇ、！−１に「有効な」ものである。この場合 、証明は次にように進められる（図６参照）。

（１）Δの証明は、部分解ノードＤ、Ｅ、Ｆに達するまで上述と同様に開始され る。この場合、Ｄに関する事実は存在しないが、照会Ｑ１が存在する。したがっ て、照会Ｑ１が実行され、これにより、「Ｄは真である」という事実と「Ｆは偽 である」という事実が事実ベースに入れられて、次の部分解ノードの作成が可能 になる。

（２）Ｅ、Ｆを考察する。この場合には、事実ベース中にはＥに関する事実が存 在する。この事実（Ｅは偽である）により、この分岐は失敗することになる。

（３）次の未展開の部分解ノード（即ちＣ）に戻る。探索は上述のように続行さ れる。

（４）Ｇを考察した場合、それに関する事実は存在しないが、照会Ｑ２が存在す る。これが実行されると、「Ｆは真である」、「Ｇは真である」、「Ｈは偽であ る」という事実が事実ベースに加えられ、これにより解が得られる。

適当な照会の選択、および、照会の結果からの情報の抽出は、検査機構３１およ び知識アシミレータ３２を必要とするものである。

勿論、上記の例は非常に簡単なものであるが、推論エンジン２５の一般的な動作 を、モデル２２、照会２３、および事実ベース２５に関連して説明するのに役立 つものである。

サービスモデル サービスモデルは、システムにより提供されるサービスを、そのサービスに関連 するシステムエンティティと、かがるエンティティ間の関係とに関して指定する ものである。

「エンティティ」は、それについて事実を表明することのできる項目であり、整 数、ファイル、動作モード他の論理オブジェクトに対応し、または、マシン、プ リンタ他の実世界の物理オブジェクトに対応することができるものである。多数 の基本エンティティタイプまたはコアエンティティタイプが、整数、キャラクタ 、ストリング等のように予め適宜に規定されて、いずれのサービスモデルでも暗 黙に利用可能である。次いで、一層高レベルのエンティティタイプが適当なサー ビスモデル中で規定されて、かかるエンティティタイプの各特性が、コアエンテ ィティ間の関係および／または以前に規定された一層高レベルのエンティティ間 の関係に関して指定される。各エンティティタイプおよびそれに関連する特徴付 は関係を、ここでは一般にエンティティ関係グループ（または簡単にＥＲグルー プ）と称することにする。

「関係」は、エンティティ間の基本的な無条件の関係、または、１つ以上の要件 が満たされた場合にのみ真となる導出された条件付きの関係である（かかる条件 は、それ自体がエンティティ間の関係に関して指定されていることになる）。１ つの関係は、少なくとも１つのエンティティを識別し、特定の１つの関係述語を 指名する。

一般に、成る関係にあるエンティティは、特定のエンティティタイプの変数に関 して指定されることになる。ががる変数は、そのサービスモデルが推論エンジン により使用される場合にのみ、その値が設定される。しかし、特定のエンティテ ィの用例（ｉｎｓｔａｎｃｅ）を１つの関係（特定のストリングのエンティティ を構成する名称等）に直接書き込むことが可能である。

１つの関係を規定する場合には、その関係中の１つのエンティティの１つの用例 がそれと同じ関係中の他のエンティティの２つ以上の用例と関係し得る否かを指 定するのが有用である。この関係の特性は、その「基本性（ｃａｒｄｉｎａｌｉ ｔｙ）Ｊと呼ばれる。例えば、１つのディレクトリは多数のファイルを含むこと ができるが、各ファイルは１つのディレクトリにしか入ることができず、ファイ ルおよびディレクトリを対応付ける関係のいずれかにおいてこの特性を指定する のが有用である。

「直接（ｓｔｒａｉｇｈｔｆｏｒｗａｒｄ）モデル」は、例えば、サービス自体 に対応するエンティティと、１組の条件が満たされた場合にそのサービスエンテ ィティが「ＯＫ」となる（即ち機能する）という趣旨の関連する導出された関係 とからなり、かかる条件は、そのサービスの提供に係わるエンティティ間の特定 の関係である。これらの後者のエンティティに関連する関係により、そのサービ スエンティティが「ＯＫ」となるための条件が満たされたか否かについて判定を 行うことが可能となる。

図７は、ファイルを削除するための想像上のサービスについての単純なサービス モデル５０を一例として示すものである。この例示的なモデルは、実際上期待さ れるものよりかなり簡略化され、サービスモデルに含まれる概念の例証を助ける ためにのみ示すものである。

更に、含まれる関係の基本性が簡略化のために省略されている。本明細書では、 エンティティタイプはそのイニシャルを大文字とし、また対応する変数は小文字 で始まり、そのエンティティタイプとほぼ同様の名称を有するものとする。実際 に、変数のタイプは、その変数が用意に識別できる場合を除き、その変数が最初 に発生した際に宣言される。ある関係内では、エンティティ（１つの変数により 表されるものまたは特定の用例として指定されたもの）は角括弧で囲まれ、エン ティティの値が重要でない場合には、括弧中に下線記号「立が含まれる。論理演 算子ＡＮＤ、ＯＲ，ＮＯＴは、それぞれｒ、Ｊ　、　ｒ；Ｊ　、　ｒ〜」により 表される。

図７のサービスモデル５０は、そのモデルを識別するヘッダ５１と、次の３つの エンティティタイプを規定する３つのＥＲグループ５２，５３．５４とからなる 。

ＤｅｌｅｔｅＪｉｌｅ　・・・サービス自体を表すものＵｓｅｒ　・・システム が既知のユーザを表すものＦｉｌｅ　・・システム上のファイルを表すものスト リングおよび整数のコアエンティティもまた使用される。

サービスエンティティＤｅｌｅｔｅＪｉｌｅは、ＥＲグループ５２の規定５５で 宣言される。規定５５には次の２つの関係が対応付けされている。

サービス（変数“Ｄｅｌｅｔｅ　ｆｉｌｅ’で表されるもの）の用例が、所与の ファイル（変数’ｆｉｌｅ’で表されるもの）に関して所与のユーザ（変数’　 ｕｓｅｒ’で表されるもの）についてＯＫとなるべき場合に満たす必要のある要 件５７〜５９を記述する既導出関係５６゜変数’　ｕＳｅｒ’およびｆｉｌｅ゛ は、それぞれタイプＵｓｅｒおよびＦｉｌｅのものであり、そのように、特定的 に宣言される。

このサービスに対する使用料（ここではストリング’　ＦＲＥＥ’で指定されて いる）を与える基本関係６０゜ 第２の関係６０は、サービスの機能の状態の決定には使用されないが、他の目的 にとって有用な関係を宣言するものである。

関係５６の本質は、変数’　ｕｓｅｒ’によって表されるユーザに対して、変数 ’ｆｉｌｅ’によって表されるファイルに関し、そのユーザがそのファイルを所 有しく条件５７）、他にそのファイルを使用しているものがなく（条件５８）、 そのファイルの法的状態が明示的にＮ０Ｎ−ＲＥＴＥＮＴＩＯＮ（非保存）′で ある場合に、ファイル削除サービスが利用可能になる、ということである。それ ら条件が適用される際に、その様々な条件における対応する変数に同じ値が設定 される。それらの値は、既導出関係５６の第１行中の変数に既に設定されている ものである。

ＥＲグループ５３は、エンティティタイプＵｓｅｒを規定し、各ユーザ（変数’ 　ｕｓｅｒ’により表されるもの）が整数形態のユーザアイデンティティを有す ることを指定する１つの基本関係６１を有している。

ＥＲグループ５４は、エンティティタイプＦｉ　ｌｅを規定し、３つの基本関係 ６２．６４．６５と１つの既導出関係６３とを有する。関係６２．６４．６５は 、それぞれ、１つのファイル（変数’ｆｉｌｅ’により表されるもの）に属する ものであり、そのファイルの所有者を識別するための整数と、その所有者以外の ファイルのユーザの現在の数を指定する整数と、そのファイルの法的保存状態を 指定するストリングとに関するものである。関係６３は、所与のファイルが所与 のユーザにより所有されるために満たす必要のある２つの条件を記述する。即ち 、そのファイルの所有者ＩＤがそのユーザのユーザＩＤと対応していなければな らない。この対応関係は、整数変数’　ｕｉｄ’を用いてユーザにより指定され 、その整数変数は、関係６３の適用中に、推論エンジンが要件６６．６７を形成 するステートメントの論理積を証明しようとしてファイルの所有者ＩＤを与える 関連事実を見つけ出してそれを要件６６に適用する際に、１つの値が設定される ものであり、これにより、’　ｕｉｄ’の値が設定されて、条件６７がテスト可 能になる、という点に留意されたい。

１つのサービスモデルに含まれる関係中で指定される変数は、（例えばシステム マネージャによる）１つのタスクの開始時に明示的に割り当てられた値、または 事実ベースを参照して割り当てられた値、または照会システムを用いて割り当て られた値を有する。

システムの同じオブジェクト（例えばファイルシステムマネージャ）により提供 される１組のサービス等の多数の密接関係にあるサービスが存在する一層高性能 のモデルでは、かかる各サービス毎に別個のエンティティを有するのではなく、 関連する全てのサービスに概念的に及ぶ１つの一般的サービスエンティテイを規 定することが有用である（このエンティティは、このシステムの関連サービスの 提供者のオブジェクトと同一と考えることができる）。次いで、この一般的サー ビスエンティティが、対応する関係（通常は関連する特定サービスが利用可能に なるための条件を記述する既導出関係）を介して各々の特定サービスと対応付け される。したがって、上記のファイルを削除するサービスの例の場合、一般的サ ービスエンティティタイプ”Ｆｉｌｅ　５ｅｒｖｉｃｅ”は、ファイルの関係す るサービスを全て包含するように規定することができるものである。

［ｆｉｌｅ　５ｅｒｖｉｃｅ］　ｄｅｌｅｔｅ−ｆｉｌｅ　ｆｏｒ　［Ｕｓｅｒ 　ｕｓｅｒ］　ｏｎ　［Ｆｉｌｅ　ｆｉｌｅコ　ｌ５Ｏｋ　ＩＦ： Ｅｆｉｌｅｌ　ｉｓ−ｏｗｎｅｄ　ｂｙ　［ｕｓｅｒ］。

これは、変数”Ｆｉｌｅ−ｓｅｒｖｉｃｅ”により表されるエンティティタイプ Ｆｉ］ｃ　５ｅｒｖｉｃｅの用例は、”ＩＦ”の後に指定された条件が満たされ た場合に、変数”ｆｉｌｅ”により表されるファイルに関して変数”ｕｓｅｒ” により表されるユーザにファイル削除サービスを提供することができる、という ことを述べているものと解釈することができる。

好適には、２つの反復低減（ｒｅ　ｅｔｉｔｉｏｎ−ｒｅｄｕｃｉｎ　）機構が 、エンティティタイプと関係との規定の不必要な反復を防止するために設けられ 、そうでない場合には、その反復が実際のサービスのモデル化のいずれにおいて も発生する可能性がある。これらの機構は、次の通りである。

１つのエンティティが他のエンティティの関係を引き継ぐことができるようなエ ンティティタイプ間の「引き継ぎ」。

１つのモデルが他のモデル中のエンティティを参照できるようにする「移入」。

これら機構について、図８を参照して以下で更に考察する。

図８は、旧、　Ｍ２．　Ｍ３．　Ｍ４という名称を付した４つのモデル７０を示 すものである。モデルＭ１は、Ｅｌ−Ｅ６と名称を付したエンティティタイプに それぞれ関係する６つのＥＲグループ７１を含むものとして示されている。モデ ルＭ２は、Ｅｌという名称を付したエンティティタイプに関する１つのＥＲグル ープ７１を有するものとして示されている。モデルＭ３は、ＥＩＰという名称を 付したエンティティタイプに関する２つのＥＲグループ７１を有するものとして 示されている。各エンティティタイプを特徴付ける関係は明示されていない。

図７に関連して既に説明したように、１つのモデルの１つのＥＲダグループ中関 係は、同じモデル中で規定されたタイプのエンティティを参照することができる 。第２のエンティティタイプに対応付けされたＥＲグループの関係内から第１の タイプのエンティティへの参照を、ここではｒＲＩ　ＲＪ参照（”Ｒｃｆｃｒｃ ｎｃｃ　ｉｎ　Ｒｅ１ａｔｉｏｎ”の略）と称する。図８は、エンティティタイ プＥｌに対応付けされたＥＲグループの関係からタイプＥ２のエンティティへの ＲＩＲ参照を示すものであり、この参照を矢印で示す。

同じモデル中のエンティティタイプはまた、２つのエンティティ間の引き継ぎ関 係として指定を行うｒｌｓＡＪ参照により対応付けされ、これ【こより、１つの エンティティに対応付けされた関係が他のエンティティにより引き継がれる。成 るエンティティが、別のエンティティに対応付けされた関係を引き継ぐ場合、こ れは、前者のエンティティタイプの規定中で、典型的にはｒｌｓＡＪステートメ ントにより宣言される。モデル旧のエンティティタイプＥ４．　Ｅ３間の■ＳΔ 関係を図８に示す。引き継ぐ側のエンティティを「サブエンティティ」と称し、 関係が引き継がれる側のエンティティを「スーパーエンティティ」と称する。引 き継ぎは、幾つかのレベルにわたって発生して階層をなす引き継ぎを構築するこ とができる。

最も実際的なシステムでは、多数のサービスモデルが規定されることになり、モ デルの境界を越えて拡張するＲＩＲ参照およびＩＳＡ参照を実行可能にすること が有用であり、これにより、共通するエンティティタイプと関係との規定の重複 を防止することができる。

かかるモデル境界を越えることは、上述の移入（ｉｍｐｏｒｔ）機構により可能 になり、この機構により、他のモデルにより参照される任意のモデルが、その前 者のモデル中のモデル名の直後のセクションで明示的に宣言される。したがって 、図８のエンティティタイプＥ５に対応付けされたＥＲグループ７１中の成る関 係が、モデルＭ２中に既に規定されているタイプＥ７のエンティティにＲＩ　Ｒ 参照を行いたい場合には、モデノい（２がモデル旧の「移入」セクション７２で 既に宣言されていれば、それを行うことができる。同様に、モデル旧のエンティ ティタイプし６は、モデルλ１３がモデル旧のセクション７２で宣言されていれ ば、ＩｓΔ参照を用いて、モデルＭ３のエンティティタイプＥ８に対応付けされ た関係を引き継ぐことができる。

図８の例において、モデルλ１３のエンティティタイプＥ８は、モデル旧のエン ティティタイプＥ６のスーパーエンティティであるばかりでなく、モデルＭ３の エンティティタイプＥ９のサブエンティティでもあり、更に、モデルＭ４のエン ティティタイプＥＩＯに対してＲＩＲ参照を行う。勿論、このＲＩＲ参）１ｑは 、モデルに＋４がモデルＭ３のセクション７２て適当に宣言されることによりモ デルＭ３に移入されることを必要とする。

「移入」機構は、モデル間の引き継ぎを提供するよう動作するものではなく、引 き継ぎの階層中に構造化させることのできるエンティティにすぎない、というこ とに留意されたい。

コアエンティティタイプ（整数、キャラクタ、およびストリング）は、他の全て のモデルに移入されてそれらモデルでのコアエンティティの使用を可能にする「 支援」サービスモデルの一部をなすものと考えることができる。これらのエンテ ィティタイプは非常に広範に使用されるので、この移入は、明示的な移入の宣言 を必要としないものとみなされる。

ここで、次のような表記を有するＢＮＦ型の言語を用いてサービスモデルの正式 な説明を行う。

・・・［によって規定される」を意味する。

＊　・・・「関係する項目の用例が１つ以上存在する可能性がある」を意味する 。

１　・・ＯＲを意味する。

（ＸＹＺＩ）　・・・項目ＸＹＺ　ＯＲは項目が無いことを意味する■、モデル Ｍｏｄｅｌ　：：＝　Ｍｏｄｅｌｈｅａｄ　（ＩｍｐｏｒｔｓＩＸＥＲｇｒｏｕ ｐ）本Ｍｏｄｅｌｈｅａｄ　：：＝　’ＭＯＤＥＬ’　ｍｏｄｅｌ　ｎａｍｅＩ ｍｐｏｒｔｓ　：：＝　（’ＩＭＰＯＲＴ’　ｍｏｄｅｌ　ｎａｍｅ）木ＥＲｇ ｒｏｕｐ　：：＝　Ｅｎｔｉｔｙ（Ｒｅｌａｔｉｏｎ）＊Ｍｏｄｅｌｎａｍｅ　 ：：＝　Ｓｔｒｉｎｇ２、エンティティ Ｅｎｔｉｔｙ　：：＝　ＣｏｒｅＥｎｔｉｔｙ　ｌ　ＭｏｄｅｌＥｉｎｔｉｔｙ ＭｏｄｅｌＥｎｔｉｔｙ　：＋：’ＥＮＴＩＴＹ’ｅｎｔｉｔｙＮａｍｅ（’Ｉ ＳＡ’　ｓｕｐｅｒＥｎｔｉｔｙＮａｍｅ　ｌ）ｅｎｔｉｔｙＮａｍｅ　：：＝ 　ｓｔｒｉｎｇｓｕｐｅｒＥｎｔｉｔｙＮａｍｅ　：：＝　ｓｔｒｉｎｇ３、関 係 Ｒｅ１ａｔｉｏｎ　：：＝　Ｂａ５ｉｃＲｅｌａｔｉｏｎ　ｌ　Ｄｅｒｉｖｅｄ ＲｃｌａｔｉｏｎＢａｓｉｃＲｅｌａｔｉｏｎ　：：＝　’Ｂ八へＩＣ’　ｒｅ ｌａｔｉｏｎｌｌｅａｄｃａｒｄｉｎａｌｉｔｙ（ｅｘｐｌａｎａｔｉｏｎ　１ ）ｒｅｌａｔｉｏｎｌｌｅａｄ　：：＝　ｔｙｐｅｉｎｆｏ　（ｒｅｌａｔｉｏ ｎＮａｍｅ　ｔｙｐｅｉｎｆｏ）＊（ｒｅｌａｔｉｏｎＮａｍｅ　１） ｔｙｐｅｉｎｆｏ　：：＝　’ビ（（ｍｏｄｅｌＮａｍｅ　’、’　ｌ）　ｅｎ ｔｉｔｙＮａｍｅ　１）ｖａｒｉａｂｌｅ　’　］’ ｃａｒｄｉｎａｌＨｙ　：：＝　’Ｏ’　１’Ｍ’ｅｘｐｌａｎａｔｉｏｎ　： ：＝　’ＥＸＰＬ八Ｎ八Ｔへ０へ’（ｓｔｒｉｎｇ　１　ｔｙｐｅｌｎｆｏ　ｌ 　ｏｐｔｉｏｎ）＊ｏｐｔｉｏｎ　：：＝　’（’（ｓｔｒｉｎｇ　１）　’ビ （ｓｔｒｉｎｇ　ｌ）　’）’注、関係の”ｅｘｐｌａｎａｔｉｏｎ”は、シス テムが成る事実の疑似自然言語【こよる表現を出力したい場合に使用される。

ＤｅｒｉｖｃｄＲｅｌａｔｉｏｎ　：：：　ｔｌｅａｄ’ｌＦ’ＢｏｄｙＩｌｅ ａｄ　：：＝　’ＤＥＲＩＶＥＤ’　ｒｅｌａｔｉｏｎｔｌｅａｄ　ｃａｒｄｉ ｎａｌｉｔｙ（ｅｘｐｌａｎａｔｉｏｎ　１） ［１ｏｄｙ　：：＝　ｅｘｐｒｅｓｓｉｏｎｅｘｐｒｅｓｓｉｏｎ　：：＝　ａ ｎｄＥｘｐｒｅｓｓｉｏｎ　（’；’ａｎｄＥｘｐｒｅｓｓｉｏｎ）＊ａｎｄＥ ｘｐｒｅｓｓｉｏｎ　：：＝　ｅｘｐｅｌｅｍｅｎｔ（’、’ｅｘｐｅｌｅｍｅ ｎｔ）本ｅｘｐｅｌｅｍｅｎｔ　：：＝　（’ｅｘｐｒｅｓｓｉｏｎ’）■’　 〜’　ｅｘｐｅｌｅｍｅｎｔ　１ｒｃｌａｔｉｏｎｌｌｅａｄ モデルの構造化 実際のコンピュータシステムの場合、印刷スプール等の任意のシステムサービス は、特定のシステムオブジェクトに提供される多数の内部システムサービスから なるものとして最も良好にモデル化される。このような場合のサービスモデルの 構造化は、一般に大なり小なりそのシステムの物理的な世界の構造を反映するこ とになる。

例えば、マシン８１（ＰＳクライアントマシン）で作業中のユーザ８゜（ＰＳユ ーザ）が、ネットワーク８４（ネットワーク）を介してマシン８１とプリンタ８ ２（プリンタ）とに接続された印刷サーバ８３（ＰＳサーバマシン）を用いてプ リンタ８２上でファイルを印刷しようとする、図９に示すプリンタスプーラサー ビスのモデル化について考察する。

第１ステツプは、どのオブジェクトが他のどのオブジェクトに何のサービスを要 求しているかについての分析を実行することである。

同図から分かるように、ユーザ８０は、”ｃａｎＰｒｉｎｔ［ｆｉｌｅコｏｎ［ ｐｒｔＮａｍｅ］”と呼ばれる「サービスＪＳＩを必要とする。このサービスの 目的はその名称から明らかである。ユーザのマシン８１がこのサービスＳｌをユ ーザ８０に提供するためには、このマシンは次の条件を満たさなければならない 。

１、それ自体がそのサービスを提供するように内部的に適切に構成されている。

２、（印刷サーバ８３を識別するために）何れかの場所から”ｃａｎＦｉｎｄ［ ｐＳＳｅｒｖｅｒ］＾ｄｄｒ”と呼ばれるサービスＳ２を得ることができる（こ の場合、サービスＳ２は名称サーバ８５により提供される）。

３　（指名された印刷サーバ８３にネットワークを介してコンタクトできるよう に）何れかの場所から”ｈａｓＲｏｕ　ＬｅＴｏ［ｐＳＳｅｒｖｅｒコ”と呼ば れるサービスＳ３を得ることができる。

４、何れかの場所からサービスＳ４″ｐｒｉｎｔ［ｆｉｌｅコｏｎ［ｐｒｔＮａ ｍｅコｆｒｏｍ［ｈ。

Ｓ　ｔＮａｍｃドを得ることができる。

上記項目のうち、最後の「サービス」だけがファイルの印刷に直接関係している 。

サーバマシン８３がマシン８１にサービス５４”ｐｒｉｎｔ［ｆｉｌｅコｏｎ［ ｐｒｔＮａｍｅ　３ｆｒｏｍ［ｈｏｓｔＮａｍｃ］”を提供できるためには、次 の条件を満たさなければならない。

１　それ自体がそのサービスを提供するように内部的に適切に構成されている。

２、何れかの場所からサービスＳ５”ｈａｓＲｏｕｔｅＴｏ［ｐｒｉｎｔｅｒ］ ”を得ることができる。

３、何れかの場所からサービスＳ６”ｐｒｉｎＬ［ｐｓＦｉｌｅ］”を得ること ができる。

図１０は、プリンタスプーラサービスのコアの考え得る１つのモデル構造を示す ものである（便宜上、ネットワーク８４と名称サー、＜８５とプリンタ８２との モデル化の詳細は省略する。実際に、これらのオブジェクトにより提供されるサ ービスのモデルは、プリンタスプーラサービス等の高レベルのサービスのモデル 化に先立って行われていることになる）。

図１０のモデル構造では、ユーザのマシン８１　（ｒｒ’ｓクライアントマノ刈 ）により提供されるサービスＳ１は、そのサーヒスＳｌ自体（こ対応するエンテ ィティタイプ９１　（ｒＰＳクライアントサービス」）を含むサービスモデル９ ０（ここでは簡略化のため同じ名称を付す）として示されている。このサービス エンティティタイプ９１は、典型的には、サービスＳｌが利用可能になるために 満たさなければならない条件を記述する対応付けされた既導出関係を有し、かか る条件は、ユーザのマシン８１がサービスＳ１を提供する場合の上述の条件に対 応するものである。サービスモデル９０はまた、ユーザ８０（ＰＳクライアント ）のエンティティタイプ９２を含む。これは、一般にユーザのＩＤによって決ま るサービスエンティティ９１に対応付けされた条件が存在するからである。

印刷サーバ８３（ＰＳサーバマシン）により提供されるサービスＳ４は、図１０ のモデル構造では、サービス８４自体に対応するエンティティタイプ９４（ＰＳ サーバサービス）を含むサービスモデル９３として示す。

このサービスエンティティタイプ９４は、典型的には、サービスＳ４が利用可能 になるために満たされる必要のある条件を記述する対応付けされた既導出関係を 有し、かかる条件は、サーバマシン８３に関連して上述したものに対応するもの である。また、サーバマシン８３の構成に関する条件を詳述するために、別のエ ンティティタイプ９５（Ａサーバエンティティ）およびエンティティタイプ９６ （ＰＳサーバマシン）が記述される。

左旦 特定のサービスが利用可能になるためにサービスモデル中で指定される条件は、 その全てがそのサービスの技術要件により決定される必要はない、ということに 留意されたい。条件は、サービスの利用可能性について設定することができ、ま た、より一般的には、関係するエンティティの状態について設定することができ 、これは局所的な方針または会社規模の管理方針によって決定される。したがっ て、ユーザのホームディレクトリがユーザの名称で呼び出される局所方針が存在 し得り、かかる方針は、ログインに関する条件中に容易に組み込むことができる （即ち、ユーザは、そのユーザの名称に対応するホームディレクトリが存在する 場合にのみコンピュータシステムにログインすることができる）。かがる方針条 件は、好適には、所与のサービスが利用可能になるために「ＯＫ」になる必要の ある方針エンティティに対応付けされたＥＲグループにグループ化される。勿論 、成る条件が技術条件であるか方針条件であるかが常に明らかであるとは限らな い。例えば、パスワード条件はいずれのタイプのものともみなすことができる。

照会 上述のように、各モデルには、管理対象となるシステムから情報を得ることを可 能にするための１組の照会が対応付けされている。

各照会は、１つ以上の事実に「有効な」ものであり、かかる事実が照会により識 別されて、所望の事実にとって適当な照会の選択が可能となる。

照会は、管理対象となるシステムと対話し、結果的に得られる応答を構文解析し てトークンを得ることにより働き、そのトークンがエンティティおよび関係に関 連（＝１けられる。本実施例では、対話マネージャ２７が照会の実行に関する義 務履行能力を有し、その応答の意味解析が知識アシミレータ３２により実行され 、このアシミレータはまた、事実ベースの更新に関する義務履行能力も有してい る。

３つの主要な対話タイプが可能である。第１に、照会は、システムの既存情報提 供サービスを用いて、必要な情報（ただし、通常は、他の情報とパッケージされ ており、構文抽出を必要とする）を直接提供することができる。第２に、照会は 、システムの特定の能力を実行させることができる。その特定能力は、必要な情 報を直接供給するものではないが、知識アシミレータ３２が成る事実を観察され た結果から推論することを可能にするものである。第３に、管理対象となるシス テムの特定のマシンで実行される特定のエージェントプログラムを書き込んで、 これらのエージェントに特定の照会に対する特定の解答を提供させることができ る。がかるエージェントは、強力な分析ツールを提供することができるが、管理 対象となるシステムにそれを追加する必要があり、これは実用的には問題があり 、したがってこの方法は好ましくない。

照会＋００の一般的な形式を図１１に簡単に示す。この照会１００には、勿論、 固有の名称１０１が割り当てられる。次に、システムにより実行すべき動作が、 その照会の「コマンド仕様（ｃｏｍｍａｎｄｓｐｅｃ）Ｊを構成するコマンド行 ＋０２で指定される。その照会の残りの部分は、コマンド行１０２により開始さ れた動作の結果として如何なる応答を予想し得るか、および、この応答が対象と なるエンティティおよび関係と如何なる関係にあるかを記述する「リターン仕様 （ｒｅ　ｔｕ　ｒｎｓｐｃｃ　）　Ｊである。

このリターン仕様は、ＲＥＴＬＩＲＮとという名称を付したプロダクションの一 部においてその応答の一般的な形態（リターン行１０３）を与え、そのプロダク ションはまた、完全な情報が利用可能な項目を指定するりスト１０４　（’ｃｏ ｍｐｌｃｔｃｎｅｓｓＰａｒｔ’と称する）を含む。次いで「リターン行Ｊ　１ ０３が構文的に指定されて（１０５参照）多数のｒｅｔｕｒｎＰａｒｔｓ°が得 られ、次いでそれらの’　ｒｅｔｕｒｎＰａｒｔｓ’がエンティティと関係とに 関連付けられる（１０６参照）。成る照会が「有効」である事実がその照会のセ クション＋０６中で暗黙に識別され、典型的には、その照会がコンパイルされる 際に、それらの事実の明示的なリストが生成される。

照会の一層正式な説明を行う前に、Ｕｎｉｘのｒ／ｅｔｃ／ｐａｓｓｗｄＪファ イルへのアクセスに用いられる’　ｐａｓｓｗｄ’と称される照会の一例を説明 することが有用であると思われる。この照会例の形式を以下に示す。

この照会は、 ｃａｔ／ｅｔｃ／ｐａｓｓｗｄ というコマンド行を用いる。その結果として、ファイル全体が１行ずつ返される ことになり、その各行は異なるユーザに関するものである。１つの行の形式をユ ーザ例″ａｊｐ’に関して図１２に示す。同図から分かるように、その行は、以 下の７つの要素からなる。

ｎａｍｅ　・システム上でのユーザの名称ｐａｓｓｗｏｒｄ　・ユーザの暗号化 されたパスワードｕｉｄ　・・・ユーザのＩＤ番号 ｇｉｄ　・ユーザのグループＩＤ番号 １ｎｆｏ　・・各種の情報項目 ｈｏｍｅＤｉ　ｒ　・・・ユーザのホームディレクトリ５ｈｅｌｌ　・・ユーザ のシェル したがって、照会’　ｐａｓｓｖｄ’は、ユーザを上記の項目のそれぞれに対応 付ける事実に「有効な」ものである。

この例では、この照会が以下のタイプの事実に関する完全な情報を提供すること を、ＲＥＴＵＲＮに続（’　ｃｏｍｐｌｅｔｅｎｅｓｓｓｐｅｃ’が指定する、 ということが理解されよう。

［Ｕｓｅｒ、　］　ｎａｍｅ　［−］ ［ＵｓｅｒＪ　ｅｎｃｒｙｐｔｅｄＰａｓｓｗｏｒｄ　［−］［ＩＪｓｅｒ　］ 　ｕｓｅｒｌｄ　［−コ［ＬＩｓｅｒ−］　ｇｒｏｕｐｌｄ　［−コ［ＩＪｓｃ ｒ−］　ｉｎｉｔｉａｌｌｌｏｍｃＤｉｒＰａｔｈ　［−］［Ｌ］５ｃｒ−］　 １ｎｉｔｉａｌｓｈｃｌｌｒ’ａｔｈじコ各すターン行の構文は、’　１ｉｎｅ ’に続くキーワードＮＥＷの後に与えられる。この構文は、図１３に関して既に 説明したパターンに続くものである。次に、°リターン部分°（この場合には’ 　ｎａｍｅ’　）を考えると、この例では、’　１ｉｎｅ’に含まれる指定に従 い構文解析に続いてｎａｍｅ’について導出されたストリングが、変数＜ｎａｍ ｅ＞に割り当てられ、次いで、関係”［Ｕｓｅｒ］ｎａｍｅ［ｎａｍｅドに適用 されて、事実が生成される。

同様にして、リターン部分’ｐａｓｓｗｏｒｄ’、　’ｕｉｄ’、　’ｇｉｄ’ 、　’ｈｏｍｅＤｉｒ’。

’５ｈｅｌｌ’から事実が生成される。

ＱＵＥＲＹ　ｐａｓｓｗｄ ＣＯＭＭＡＮＤ　：：＝　’ｃａｔ／ｃｊｃ／ｐａｓｓｗｄ’ＲＥＴＵＲＮ　： ：：　１ｉｎｅ　（［ＬＩｓｅｒ−］　ｎａｍｅ　［−］　＆　［Ｕｓｅｒ−］ ｅｎｃｒｙｐｔｅｄＰａｓｓｖｏｒｄ　［］　＆　［ＵｓｃｒＪ　ｕｓｅｒｌｄ 　ｃ−］＆　［Ｕｓｅｒ　］　ｇｒｏｕｎｄ　［］＆　［ＵｓｅｒＪ　ｉｎｉｔ ｉａｌＨｏｍｅＤｉｒＰａｔｈ　［］＆　［Ｕｓｅｒｊ　１ｎｉｔｉａｌｓｈｅ ｌｌＰａｔｈ　［−］１゜１ｉｎｅ　：：＝　（ＮＥＴ　［ｕｓｅｒ］　ｎａｍ ｅ’　：’　ｐａｓｓｗｏｒｄ　’　：’　ｕｉｄ’　：’　ｇｉｄ　’：’　 （ｉｎｆｏ　ｌ）　’：’　ｈｏｍｅＤｉｒ　’：’　（ｓｈｅｌｌ　ｌ）　Ｅ ＯＬ）　＋。

ｎａｍｅ　：：＝　ｓｔｒｉｎｇ　＜ｎａｍｅ＞　［ｕｓｅｒ］　ｎａｍｅ　［ ｎａｍｃ］。

ｐａｓｓｗｏｒｄ　：：＝　ａｌｐｈａＮｕｍｓｔｒｉｎｇじ本／、、’］　＜ ｐａｓｓｗｏｒｄ＞［ｕｓｅｒ］　ｅｎｃｒｙｐｔｅｄＰａｓｓｖｏｒｄ［ｐａ ｓｓｗｏｒｄ］。

ｕｉｄ　：：＝　ｎｕｍｂｅｒ　＜ｕｉｄ＞　［ＵｓｃｒＪ　ｕｓｅｒＩｄ　［ ｕｉｄ］。

ｇｉｄ　：：＝　ｎｕｍｂｅｒ　＜ｇｉｄ＞　［ｕｓｅｒ］　ｇｒｏｕｐｌｄ　 ［ｇｉｄコ。

１ｎｆｏ　：　：＝　ａｌｐｈＮｕｍｓｔｒｉｎｇ［’　（）？、、Ｏ／〜’　 Ｉ＠＃％−＆＊−４＝＋１［コ′　コ、ｈｏｍｅＤｉｒ　：：：　ａｌｐｈａＮ ｕｍｓｔｒｉｎｇ［’／、　−’　］　＜ｐａｔｈ＞　［ｕｓｅｒコｉｎｉｔｉ ａｌｌｌｏｍｅＤｉｒＰａｔｈ　［ｐａｔｈ］５ｈｅｌｌ　：：＝　ａｌｐｈａ Ｎｕｍｓｔｒｉｎｇ［’／、−−’］　＜ｐａｔｈ＞　［ｕｓｅｒコ１ｎｊｔｉ ａｌｓｈｅｌｌＰａｔｈ　［ｐａｔｈ］。

照会の一層正式な説明を次に行う。この場合も、前記照会の例を参照する。

照会の規定は次の項目からなる。

Ｑｕｅｒｙ　：：：　’ＱＵＥＲＹ’　ｑｕｃｒｙＮａｍｃ　ｖａｒｉａｂｌｅ Ｄｅｃｌａｒａｔｉｏｎｓｃｏｍｍａｎｄｓｐｅｃ　ｒｅｔｕｒｎｓｐｅｃ　ｄ ｅｌｉｍｉｔｅｒｓｐｅｃ　ｃｏｍｍｅｎｔｓｐｅｃｑｕｃｒｙＮｎａｍｅは、 その照会を識別するために選択された単語である。

ｖａｒｉａｂｌｅＤｅｃｌａｒａｔｉｏｎｓは、ｃｏｍｍａｎｄＳｐｅｃで使用 するためにランタイム時に値が渡されることになる変数を宣言するのに用いられ るものであり、次のように規定される。

ｖａｒｉａｂｌｅＤｃｃｌａｒａｔｉｏｎｓ　：：：　ｔｙｐｅＩｎｆｏ＊ｃｏ ｍｍａｎｄｓｐｅｃは、遠隔地にある装置／マシン上で実行すべきコマンドの仕 様であり、次のように規定される。

ｃｏｍｍａｎｄｓｐｅｃ　：：＝　’ＣＯＭＭＡＮＤ’　：：：　’（ｓｔｒｉ ｎｇ　ｌｖａｒｉａｂｌｅＮａｍｅ）　＋ｒｅ　ｔｕｒｎｓｐｅｃは、コマンド の実行からのリターン値の構文的および意味的な仕様を規定する。前述の例がら ゎがるように、この部分には、リターンストリングの構文を規定する１組のＢＮ Ｆタイプの文法プロダクション（ｐｒｏｄｕｃｔｉｏｎ）が含まれる。最初のｐ ｒｏｄｕｃｔｉｏｎＮａｍｅは、ＲＥＴＵＲＮでなければならない。規定は次の 通りである。

ｒｅｔｕｒｎＳｐｅｃ　：：：　ｐｒｏｄｕｃｔｉｏｎ　＋ｐｒｏｄｕｃｔｉｏ ｎ　：：＝　ｐｒｏｄｕｃｔｉｏｎＮａｍｅ　’　：：＝’　ｒｅｔｕｒｎＬｉ ｎｅ（’＋’　ｌ）　’、’ ｒｅｔｕｒｎｌ　ｉｎｅは、各プロダクションのほとんどを形成し、主として他 のプロダクションの名称（これによりリターンストリングの階層的な分解が可能 になる）と予約語（例えば整数等の終端記号のタイプを指定するもの）とからな る。しがし、ががるプロダクションには、何らかの関係ヘッドおよび完全性情報 が含まれる。規定は次の通りである。

ｒｅｔ、ｕｒｎＬｉｎｃ　：：＝　（ｒｅｔｕｒｎＥｎｃｌｏｓｕｒｅ　１ｐｒ ｏｄｕｃｔｉｏｎＮａｍｅ１ｎｃｗＯｂｊ　］　ｒｅｔｕｒｎｌ’ａｒＬ　１　 °ＴｏＥＯＬ’　ｌ　’ＥＯＬ’　ｌｃｏｍｐｌｃｔｅｎｃｓｓＰａｒｔ）本ｒ ｅｔｕｒｎＥｎｃｌｏｓｕｒｅ　：：＝　’（’　ｒｃｔｕｒｎＬｉｎｅ　（’ 　ｌ’　ｒｅｔｕｒｎＬｉｎｅ）本　ｌ）ｌｎｅｗｏｂｊ　：：−’ＮＯ’　ｔ ｙｐｅｉｎｆ。

ランタイム時にＮＥＷに遭遇するたびに、そのＮＥＷは、新しいエンティティの 用例の作成を生じさせる。したがって、上記の例の場合、”／ｅｔｃ／ｐａｓｓ ｖｄ”の構文解析中にプロダクション”１ｉｎｅ”に遭遇した場合には必ず、’ 　Ｕｓｅｒ”エンティティの用例が作成されて、変数”ｕｓｅｒ”に割り当てら れる。

ｒｅｔｕｒｎｔ”ａｒｔは、構文解析から返されたトークンをエンティティと関 係とに対応付けて、事実ベースに加えられる事実を生成させる。

規定は次の通りである。

ｒｃｔｕｒｎｌ”ａｒｔ　：：＝　ｆｉｘｅｄＲｃＬｕｒｎ　１ｖａｌｕｅＲｅ ｔｕｒｎｆｉｘｅｄＲｅｔｕｒｎ　：：＝　ｓｔｒｉｎｇ　（ｎｅｗｏｂｊ　１ ｒｅｌａｔｉｏｎｌｌｅａｄ　１）ｖａｌｕｅＲｃｔｕｒｎ　：：＝　ｒｅｓｅ ｒｖｅｄＷｏｒｄ　（（’＜’　ｖａｒｉａｂｌｅＮａｍｅ　’＞’　１）ｒｃ ｌａｔｉｏｎｌｌｅａｄ　ｌ　） ｒｃｓｃｒｖｃｄＷｏｒｄ　：：＝　’ｎｕｍｂｅｒ’　ｉ’ｈｅｘＮｕｍｂｃ ｒ’　ｌ’ｓｔｒｉｎｇ’　（’［’　ｓｔｒｉｎｇ　’］’　ｌ）　ｌ’ａｌ ｐｈａＮｕｍｓｔｒｉｒ＋ｇ’　（’［’　ｓｔｒｉｎｇ　’］’　ｌ）　ｌ’ ｆｉｌｃＮａｍｅ’　ｊ°ｐｒｊｎｔａｂｌｅｓｔｒｉｎｇ’予約語”ｓｔｒｉ ｎｇ”および”ａｌｐｈａＮｕｍｓｔｒｉｎｇ”の後の角括弧中のオプションス トリンクにより、ユーザがこれら項目の規定にキャラクタを追加することが可能 になる。ＴｏＥＯＬは、パーサに現在のポイントから行末までのあらゆるものを スキップさせる。

ＥＯＬは、このポイントで行末を予測するようにパーサに要求する。

前述した”Ｃｏｍｐｌｃｔｅｎｃｓｓ”は、照会の実行後に、成る項目に関する 全情報があるか否かを示す。例えば、”／ｅｔｃ／ｐａｓｓｖｄ”ファイルは、 システム上の全てのユーザに関する情報を含む。このように、この照会の実行後 には、事実ベースは全ての既知のユーザに関する情報を有する。したがって、特 定の名称のユーザが存在したことを証明するようにシステムが要求され、そのシ ステムがこの名称のユーザが存在したことを示すことができなかった場合には、 そのシステムはその名称のユーザが存在しないと推論することができる。それは 、システムが全てのユーザに関する情報を有していることを知っているからであ る。規定は次の通りである。

ｃｏｍｐｌｃｔｃｎｃｓｓＰａｒｔ　：：＝　’（’　ｒｅｌａｔｉｏｎｌｌｃ ａｄ　（’＆’　ｒｃｌａｔｉｏｎｌｌｅａｄ）本１）１ｄｅ］　１ｍ１ｔｅｒ ｓｐｅｃは次のように規定される。

ｄｅｌｉｍｉｔｅｒｓｐｅｃ　：：＝　’ＤＥＬＩ旧ＴＥＲ：：＝　’（’＋’ 　ｌ　’−’）　ｓｔｒｉｎｇ省略時には、照会リターンストリングパーサは、 スペースおよびタブキャラクタを用いてトークンを区切る。しかし、照会のライ タがこの組を変更したい場合がある。上記の例は、この−例を示すものである。

即ち、プロダクション”１ｎｆｏ”は、１つの情報ストリング中の１つの有効キ ャラクタとしてスペースキャラクタを用いなければならない。１組の区切り文字 からスペースを除去することにより、それがａｌｐｈａＮｕｍｓ　ｔｒｉｎｇの 規定に自動的に追加されることになる。

ｃｏｍｍｃｎ　ｔｓｐｃｃは、照会のライタが照会リターンストリング中のコメ ントに使用される表記を指定できるようにするために設けられる。

これにより、パーサがこれらの部分をスキップすることが可能となる。規定は次 の通りである。

ｃｏｍｍｅｎｔｓｐｅｃ　：：＝　’ＣＯＭＭＥＮＴ’　：：＝　’ｓｔｒｉｎ ｇ　’Ｔｏ’　ｓｔｒｉｎｇ勉作 特定のタスクの完了を可能にするために実行しなければならない動作は、各サー ビスモデル毎に、照会の場合と同様の方法で、しかし一層簡単な基本形式を用い て、次のように規定される。

八ＣＴｌ０Ｎ　・・動作の名称 ＣＯＭＭＡＮＤ　・・・コマンド行 ＰＲＥ　・・・動作に関する事前条件 Ｆ’Ｏ３Ｔ　・・・事後条件（即ち、動作の結果）ＩＮＶＡＬＩＤＡＴＥ　・・ ・動作により無効化された変数コマンド行は、影響を及ぼすべき項目の識別子と 共にシステムコマンド（例えば、Ｕｎｉｘシステム用のｔｌｎｉｘコマンド）を 指定する（例えば、コマンド行は、動作を実行すべきマシンを指定するための宣 言されたタイプの変数を含む場合がある）。ＰＲＥで指定される事前条件は、動 作を実行する前に真でなければならない条件である、ＰＯ３Ｔで指定される事後 条件は、動作の結果を規定する。動作を規定するサービスモデルに関する特定タ スクを実行するのに適当な動作を識である。ＩＮＶＡｌ、ＩＤＡＴＥは、動作に より無効化された変数を識別するものである。この情報は、この無効化された項 目に依存して事実ベースから事実を除去するのに用いられる。

タスクプログラム 前述のように、各タスクプログラム２１（図３）の役割は、推論エンジン２５の 動作を、実行すべきタスクに適応させることである。診断タスクプログラムの一 例を、理解を容易にするために、疑似自然言語形式で以下に示す。

診断タスク ＷＩＩＩＬＥ　ｎｏ　５ｏｌｕｔｉｏｎ　ｆｏｕｎｄ　Ｄ。

Ｔｈｅｏｒｅｍ　Ｐｒｏｖｅｒ　：　５ｅａｒｃｈ　ｆｏｒ　５ｏｌｕｔｉｏｎ ；ＩＦ　ｍｏｒｅ　ｉｎｆｏｒｍａｔｉｏｎ　ｎｅｅｄｅｄ　ＴＨＥＮＲＥＰＥ ＡＴ　ｆｉｎｄ　ａ　ｑｕｅｒｙ　ＵＮＴＩＬ　Ｖｅｒｉｆｉｅｒ：　ｐｒｏｖ ｅｐｒｅ−ｃｏｎｄｉｔｉｏｎｓ　ＥＮＤｐｅｒｆｏｒｍ　ｑｕｅｒｙ； ＩＦ　ｑｕｅｒｙ　ｐａｓｓｅｓ　ＴＩＩＥＮＫｎｏｗｌｅｄｇｅ　Ａｓ５１ｍ １ｌａｔｏｒ：　ａｓｓｉｍｉｌａｔｅ　ｑｕｅｒｙ　ｐａｓｓ　ｒｅａｓｏｎ ｓＬＳＥ Ｄｉａｇｎｏｓｉｓ　Ｔａ５ｋ：　ｏｎ　ｑｕｅｒｙ　ｆａｉｌｕｒｅ　ｒｅａ ｓｏｎｓＮＤ ＮＤ ＮＤ 任意のサービスモデルに関して使用可能な上記タスクプログラムは、関係するサ ービス（対応するモデルのエンティティにより表されるもの）が利用可能である か否かについての解を探索する。この探索は、必要な条件が満たされていないこ とが証明されるか、または、全ての条件が満たされてそのサービスが利用可能で あることが証明されるまで、その関係するサービスエンティティに対応付けされ ている関係で指定された全ての条件を介して進められる。解の探索を行う際に・ は、照会を用いて事実の確認を行うことができる。

この診断タスクプログラムを一層詳細に考察すると、解の探索を行うために主定 理プルーバ３３（図４）が最初に呼び出される。この探索中に、必要な事実が事 実ベース２６にないために定理プルーバ３３が続行不能になった場合には、検査 機構３１を用いて、システムから所望の事実を引き出す照会が選択される。次い で、その選択された照会が（対話マネージャ２７により）実行される。この照会 が正常に実行された場合には、その照会の結果が知識アシミレータ２１により事 実ベースに同化され、次いでそのプログラムは、定理プルーバ３３が新しく確立 された事実を用いてその探索を継続するようループする。しかし、その照会が失 敗した場合（即ち、正常に実行されなかった場合には）、この診断タスクが再帰 的に呼び出されて、この失敗の原因を突き止める。

診断されているサービスに問題がある場合には、上記の診断タスクプログラムは 、そのサービスが利用可能であるための条件が満たされていないことを証明する 事実に定理プルーバ３３が最初に行き当たった際に終了する。事実ベースに同化 される事実が、一般に低レベルの事実であるため、この段階でのプログラムの終 了は通常は許容可能なものである。これは、サービスが利用不可能となる低レベ ルの事実を終了ポイントが示すことになり、この事実は、一般に、関係するコン ピュータシステム障害（資源の不在を含む）に容易に翻訳できるからである。し かし、事実ベースが高レベルの事実を格納する場合には、診断タスクプログラム は、サービスが利用可能でないことを証明する高レベルの事実では終了せず、そ の事実を分解して、低レベルの事実で表される根底にある原因を導き出すことが 望ましい。これは、上記診断タスクプログラムを次の形式のループ’　Ｗｌｌ　 ＩＬＥ’に入れることにより容易に達成することができる。

ＷＨＩＬＥ　ｆａｉｌｕｒｅ　ｅｘｐｌａｎａｔｉｏｎ　ｐｏｓｓｉｂｌｅ　Ｄ 。

Ｄｉａｇｎｏｓｉｓ　Ｔａ５ｋ ＮＤ この場合、コア診断タスクは、サービスが利用可能でないことを証明する事実の 発見時に終了する際には必ず、その事実を証明する（および事実ベース中でのそ の存在を無視する）解を発見するように要求される。この処理は、（関係する照 会の不存在により示されるように）それ以上の説明が不可能になるまで繰り返さ れる。

実際、上記の追加のＷＩＩＩＬＥループが障害の説明に限定されず、任意の解の 説明に用いられる場合には、その拡張された診断タスクを用いて特定サービスに 要求される全条件（高レベルおよび低レベル）についての完全なチェックを提供 することができる。

この探索を追跡し、および各関係の’　ｅｘｐｌａｎａｔｉｏｎ’要素に含まれ る疑似自然言語による事実の表現を用いることにより、解を発見する際に定理プ ルーバ３３が従う「推論」のリストを出力することが可能となる。

タスクプログラムの他の例を監視タスクに関連して示す。

監視タスク ｆｌｌｌＬＥ　Ｄｉａｇｎｏｓｉｓ　Ｔａ５ｋ：　ｐｒｏｖｅｓ　ｍｏｎｉｔｏ ｒｅｄ　ｇｏａｌ　ｔｒｕｅ　Ｄ。

ｄｅｌａｙ　ｆｏｒ　ｍｏｎｉｔｏｒｉｎｇ　１ｎｔｅｒｖａｌＥＮＤ； Ｄｉａｇｎｏｓｉｓ　Ｔａ５ｋ：　ｏｎ　ｗｈｏｌｅ　５ｅｒｖｉｃｅこれから 分かるように、この監視タスクは、その実行に診断タスクを用いている。

堡 本発明の概念と、その一実施例での実施態様とを詳細に説明してきたが、ここで サービスモデルの最終的な一層完全な例を示すことにする。その選択された一例 は、Ｕｎｉｘワークステーション（ＵｎｉｘはＡＴ＆Ｔの登録商標）により提供 されるログインサービスのサービスモデルである。

他のモデル中で規定されたエンティティ、および、ログインサービスモデルＬｏ ｇｉｎを再使用することが望ましいので、そのオペレーティングシステムをモデ ル化するモデルＵｎｉｘの部分もまた示す。

ＬｌｎｉｘＵｎｉｘモデルｉｘオペレーティングシステムを扱う際に関連する基 本エンティティを提供する。ここでは、ログインモデルの各部の理解に有用なＵ ｎｉｘモデルからのそれらエンティティと関係のみを以下に説明する。

ＭＯＤＥＬ　Ｕｎｉｘ ＥＮＴＩＴＹ　Ｌｌｓｅｒ ＢＡＳ［Ｃ ［ｕｓｅｒ］　ｉｎｉｔｉａｌｌｌｏｍｅＤｉｒｒ’ａｔｈ　［ｐａｔｈｎａｍ ｅｌ。

［ｕｓｅｒ］ｎａｍｅ　［ｕｓｅｒＮａｍｃｌ。

［ｕｓｅｒ］　Ｕｓｅｒｌｄ　［ｉｎｔｃｇｃｒｌ。

（ｕｓｅｒ］　１ｎｉｔｉａｌｓｈｅｌｌｌ’ａｔｈ　［ｐａｔｈｎａｍｅコ。

［ｕｓｅｒ］　ｇｒｏｕｐｌｄ　［ｉｎｔｃｇｃｒｌ。

［ｕｓｅｒ］　ｅｎｃｒｙｐｔｅｄＰａｓｓｖｏｒｄ　［ｓｔｒｉｎｇ］。

ＤＥＲＩＶＥＤ Ｅｕｓｅｒ］　ｈａｓＲｃａｄＷｒｉｔｃ八ｃｃｅｓｓＴｏ　［へａｔｈｎａｍ ｅｌ　ＩＦ［Ｆｉｌｅ　ＦｉｌｃＪ　ｐａｔｈｎａｍｅ　［ｐａｔｈｎａｍｅｌ 。

［ｕｓｅｒ］　ｈａｓ　［’　ｒｅａｄ’　］　ａｃｃｅｓｓＴｏ　［Ｆｉｌｃ Ｊ。

［ｕｓｅｒ］　ｈａｓ　［’ｗｒｉｔｅ’　］　ａｃｃｅｓｓＴｏ　［Ｆｉｌｃ Ｊ。

［ｕｓｅｒ′３　ｈａｓ　ＣＦｉｌｅｋ！ｏｄｅ　ｍｏｄｅｌ　ａｃｃｅｓｓＴ ｏ　［ＦｉｌｃＪ　ＩＦ（［ＦｉｌｃＪ　１ｓｏｖｎｅｄＢｙ　［ｕｓｅｒ］。

［ＦｉｌｃＪ　ｏｖｎｅｒＭｏｄｅ　［ｍｏｄｅコ）；（〜［ＦｉｌｃＪ　ｉｓ ＯｗｎｅｄＢｙ　［ｕｓｅｒ］。

［ＦｉｌｃＪ　１ｓｌｎＧｒｏｕｐｏｆ　［ｕｓｅｒｌ。

［ＦｉｌｃＪ　ｇｒｏｕｐＭｏｄｅ　［ｍｏｄｅｌ）；（−［ｆｉｌｅｌ　ｉｓ ｏｗｎｅｄＢｙ　［ｕｓｅｒ］。

〜［ＦｉｌｃＪ　１ｓｌｎＧｒｏｕｐＯｆ　［ｕｓｅｒ］。

［ＦｉｌｃＪ　ｗｏｒｌｄｋｌｏｄｅ　［ｍｏｄｅｌ）；Ｉｕｓｅｒ］　１ｓｓ ｕｐｅｒＵｓｅｒ。

ＥＮＴＩＴＹ　Ｆｉｌｅ ＡＳＩＣ ［ｆｉｌｅｌ　５ｅｔＧｒｏｕｐｌｄ ［ｆｉｌｅｌ　ｏｗｎｅｒＭｏｄｅ　［ｆｉｌｅＭｏｄｅｌ。

［ＦｉｌｃＪ　５ｔｉｃｋｙＢｉｔ。

［ＦｉｌｃＪ　ｎａｍｅ　［ｆｉｌｅＮａｍｅ］。

［ｆｉｌｅｌ　５ｉｚｅ　［ｉｎｔｃｇｃｒｌ。

Ｅｆｉｌｅ］　ｗｏｒｌｄＭｏｄｅ　［ｆｉｌｅＭｏｄｅｌ。

［ＦｉｌｃＪ　ｏｖｎｅｒｌｄ　［ｕｓｅｒｌｄｅｎｔｉｆｉｅｒ］。

［ｆｉｌｅｌ　ｄａｔｅ　［ｓｔｒｉｎｇ］。

［ＦｉｌｃＪ　１ｉｎｋｓｃｏｕｎｔ　［ｉｎｔｃｇｃｒｌ［ＦｉｌｃＪ　ｇｒ ｏｕｐＭｏｄｅ　［ｆｉｌｅＭｏｄｅｌ。

Ｅｆｉｌｃ３　ｇｒｏｕｐｌｄ　［ｇｒｏｕｐｌｄｅｎｔｉｆｉｅｒ］。

［ＦｉｌｃＪ　５ｅｔＬｌｓｅｒｌｄ。

ＤＥＲＩＶＥＤ ［ＦｉｌｃＪ　１ｓｏｖｎｅｄＢｙ　［ｕｓｅｒ］ＩＦ［ＦｉｌｃＪ　ｏｖｎｅ ｒｌｄ　［ｉｎｔｃｇｃｒｌ。

［ＦｉｌｃＪ　ｕｓｅｒｌｄ　［ｉｎｔｃｇｃｒｌ。

勿論、ＬｌｎｉｘＵｎｉｘモデルこれらエンティティおよび関係の他に照会もあ り、その−例は先に挙げられている（照会：’　ｐａｓｓｖｄ’　）。

ログインサービスモデルは次の通りである。

ＭＯＤＥＬ　ＬｏｇｉｎＳｅｒｖｉｃｃＩＭＰＯＲＴ　Ｕｎｉｘ ＥＮＴＩＴＹ　Ｌｏｇｉｎ ［１ｏｇｉｎｌ　ｆｏｒ　［ｕｓｅｒＮａｍｃｌ　ｊｓＯｋ　（Ｍ：Ｏ）　ＩＦ ［Ｌｉ５ｅｒ　ｕｓｅｒ］ｎａｍｅ　［ｕｓｅｒＮａｍｃｌ［ｕｓｅｒ］　ｃｎ ｃｒｙｐｔｅｄＰａｓｓｗｏｒｄ　［Ｓｔｒｉｎｇ−］。

［ｕｓｅｒ］　ｕｓｅｒｌｄ　［Ｕｓｅｒｌｄｅｎｔｉｆｉｅｒ−］。

Ｃｕ５ｃｒ］　ｇｒｏｕｐｅｄ　［Ｇｒｏｕｐｌｄｃｎｔｉｆｉｅｒ　３ｊｕｓ ｅｒコ　ｉｎｉｔｉａｌＨｏｍｅＤｉｒｌｓｏｋ。

［ｕｓｅｒ３１ｎｉｔｉａｌｓｈｅｌｌｌｓｏｋ。

：ｌｏｇｉｎ］ｅｘｅｃｕｔａｂｌｅＦｏｒ　［ｕｓｅｒ］　１ｓＯｋ。

１１ｏｇ］ｎＥ　ａｕｄｉｔＦｉｌｅｓＡｒｅｏｋ。

エンティティＬｏｇｉｎについての上記の既導出関係は次のように読むことがで きる。

成るユーザ塩についてのログインは次の場合にＯＫである。

そのユーザ塩を有するユーザが存在し、そのユーザがパスワード（その値は重要 ではない）を有しており、そのユーザがユーザ１０（その値は重要ではない）を 有しており、そのユーザがグループＩＤ（その値は重要ではない）を有しており 、そのユーザのホームディレクトリがＯＫであり、そのユーザのシェルが０にで あり、 ログイン実行可能ファイルがそのユーザについて０にであり、ログイン監査ファ イルがＯＫである。

”ｎａｍｅ”ごｅｎｃｒｙｐｔｅｄＰａｓｓｖｏｒｄ″、”Ｌｌｓｅｒｌｄ″、 および”ｇｒｏｕｐＩｄ”ｌ；Ｌ、全て、エンティティＵｓｅｒの基本関係であ る（その実世界の値は上述の照会’　ｐａｓｓｗｄ’を用いて得られる）。その 他の関係は導出されたものである。そのうちの１つの規定を以下に示す。

［ｌｏｇｉｎ］　ａｕｄｉｔＦｉｌｅｓＡｒｅＯｋ　（Ｍ）　ＩＦ［ＩＪｓｅｒ 　ｒｏｏｔｌ　１ｓｓｕｐｅｒＵｓｅｒ。

［ｒｏｏｔｌｈａｓＲｃａｄＷｒｉ　ｔｃＡｃｃｃｓｓＴｏ［ｐａｔｈｎａｍｃ ’　／ｅｔｃ／ｕｔｍｐ’　］。

［ｒｏｏｔｌｈａｓＲｃａｄＷｒｉ　ｔｅＡｃｃｅｓｓＴｏ［ｐａｔｈｎａｍｅ ’　／ｅｔｃ／ｂｔｍｐ’　コ。

［ｒｏｏｔコｈａｓＲｅａｄＷｒｉｔｅＡｃｃｅｓｓＴｏ［ｐａｔｈｎａｍｅ’ 　／ｅｔｃ／ｗｔｍｐ’　］。

［ｒｏｏｔコｈａｓＲｅａｄｌｒｉｔｅＡｃｃｅｓｓＴｏ［ｐａｔｈｎａｍｅ’ 　／ｅｔｃ／ｌｏｇｉｎｇｒｏｕｐ’　］。

［ｌｏｇｉｎ］　５ｅｃｕｒｅＴｔｙＦｉｌｅｌｓＯｋ。

［ｌｏｇｉｎ］　ｄｉａｌＦｉｌｅｓＡｒｅｏｋ。

これにより参照される既導出関係のうちの１つの規定を次に示す。

［１ｏｇｉｎｌ　５ｅｃｕｒｅＴｔｙＦｉｌｅｌｓｏｋ　（Ｍ）　ＩＦ〜　［Ｆ ｉｌｅ　］　ｐａｔｈｎａｍｅ　［Ｐａｔｈｎａｍｅ’／ｅｔｃ／５ｅｃｕｒｅ ｔｔｙ’　コニ（［ＦｉｌｃＪ　ｐａｔｈｎａｍｅ　［Ｐａｔｈｎａｍｅ”　／ ｅｔｃ／５ｅｃｕｒｅｔｔｙ’　］。

［Ｌｌｓｅｒ　ｒｏｏｔｌ　１ｓｓｕｐｅｒＬ］ｓｅｒ。

［ｒｏｏｔｌ　ｈａｓＲｃａｄＡｃｃｅｓｓＴｏ　［Ｐａｔｈｎａｍｅ　’　／ ｅｔｃ／５ｅｃｕｒｅｔｔｙ’　］）。

この関係は次のように翻訳することができる。

ファイル“ｌｏｇｉｎ　５ｃｃｕｒｃ　ｔｔｙ”は次の場合にＯＫである。

ファイル”／ｅｔｃ／５ｅｃｕｒｅｔｔｙ”が存在しないか、または、（ファイ ル”／ｅｔｃ／５ｅｃｕｒｅｔｔｙ”が存在し、スーパーユーザが存在し、その スーパーユーザが／Ｃｔｅ／５ｅｃｕｒｅｔｔｙ″に対して読出アクセスを既に 行っている）。

サービスの検証 以下は、’５ｉｊｔ’という名称のユーザについてのログインが°ＯＫ’である ことが上述の拡張された診断タスクにより証明された際のシステム管理装置から の出力である。上記で詳述したモデルの各部分についての理由だけを以下に展開 する。

［ｌｏｇｉｎ］　ｆｏｒ　［’５ｉｊｔ’コ１ｓｏｋ　ｉｓ　ｔｒｕｅｂｅｃａ ｕｓｅ　［Ｕｓｅｒ２５’　］　ｎａｍｅ　［’５ｉｊｔ’　］　ｉｓ　ｔｒｕ ｅｂｅｃａｕｓｅ　ｉｔ　ｉｓ　ｐｒｏｖｅｄ　ｂｙ　ａ　ｑｕｅｒｙｂｅｃａ ｕｓｅ　［’Ｕｓｅｒ２５’　コ　ｅｎｃｒｙｐｔｅｄｒ’ａｓｓｖｏｒｄ　［ ’　ｒＸ２ｖｓｓ９Ａ３ｑｋｌ’　］　ｉｓｒｕｅ ｂｅｃａｕｓｅ　［’Ｕｓｅｒ２５’　］　ｕｓｅｒｌｄ　［３２７コ　ｉｓ　 ｔｒｕｅｂｅｃａｕｓｅ　［’Ｕｓｅｒ２５’　］ｇｒｏｕｐｌｄ　［１５］　 ｉｓ　ｔｒｕｅｂｅｃａｕｓｅ　［’Ｕｓｅｒ２５’　Ｅ　１ｎｉｔｉａｌｓｈ ｅｌｌｌｓｏｋ　ｉｓ　ｔｒｕｅｂｅｃａｕｓｅ　［１ｏｇｉｎ］　ｅｘｅｃｕ ｔａｂｌｅＦｏｒ　［’Ｕｓｅｒ２５’　］１ｓｏｋ　ｉｓ　ｔｒｕｅｂｅｃａ ｕｓｅ　［’Ｕｓｅｒ２５’　］　ｉｎｉｔｉａｌｌｌｏｍｃＤｉｒｌｓＯｋ　 ｉｓ　ｔｒｕｅｂｅｃａｕｓｅ　［ｌｏｇｉｎ］　ａｕｄｉｔＦｉｌｅｓＡｒｅ ＯＫ　ｉｓ　ｔｒｕｅｂｅｃａｕｓｅ　［’１Ｊｓｅｒ１６２’　］ｈａｓＲｅ ａｄＷｒｉｔｅＡｃｃｅｓｓＴｏ　［’／ｅｔｃ／ｕｔｍｐ’　］　ｉｓｒｕｅ ｂｅｃａｕｓｅ　［’Ｆｉｌｅ３９７°］　ｅｎｄＰａｔｈｎａｍｅ　［’／ｅ ｔｃ／ｕｔｍｐ’　］　ｉｓ　ｔｒｕｅｂｅｃａｕｓｅ　［’Ｆｉｌｅ３９７° ］　ｐａｔｈｎａｍｅ　［’／ｅｔｃ／ｕｔｍｐ’　］　ｉｓ　ｔｒｕｅｂｅｃ ａｕｓｅ　［’　／ｅｔｃ／ｕｔｍｐ’　］　ｄｉｒＮａｍｃ　［’　／Ｃｔｅ ’　］　ｂａｓｃＮａｍｅ［’ｕｔｍｐ’］　ｉｓ　ｔｒｕｅ ｂｅｃａｕｓｅ　ｉｔ　ｉｓ　ｐｒｏｖｅｄ　ｂｙ　ａ　ｍｅｔｈｏｄｂｅｃａ ｕｓｅ　［Ｄｉｒ３９２°］　ｐａｔｈｎａｍｅビ／ｅｔｃ’　］　ｉｓ　ｔｒ ｕｅｂｅｃａｕｓｅ　［’　／ｅｔｃ’　］　ｄｉｒＮａｍｅ　［’　／’　］ 　ｂａｓｅＮａｍｅ　［’　ｅｔｃ’　］　ｉｓｒｕｅ ｂｅｃａｕｓｅ　ｉｔ　ｉｓ　ｐｒｏｖｅｄ　ｂｙ　ａ　ｍｅｔｈｏｄｂｅｃａ ｕｓｅ　［’Ｄｉｒ８０’　］　ｐａｔｈｎａｍｅ　［’／’　］　ｉｓ　ｔｒ ｕｅｂｅｃａｕｓｅ　［’／’　コ　ｅｑｕａｌｓ　じ／’　］　ｉｓ　ｔｒｕ ｅｂｅｃａｕｓｅ　ｉｔ　ｉｓ　ｐｒｏｖｅｄ　ｂｙ　ａ　ｍｅｔｈｏｄｂｅｃ ａｕｓｅ　［’Ｄｉｒ８０’　コｉｓ　Ｒｏｏｔ　ｉｓ　ｔｒｕｅｂｅｃａｕｓ ｅ　［’Ｄｉｒ８０’　］　ｎａｍｅ　［’／’　］ｉｓ　ｔｒｕｅｂｅｃａｕ ｓｅ　ｉｔ　ｉｓ　ｐｒｏｖｅｄ　ｂｙ　ａ　ｑｕｅｒｙｂｅｃａｕｓｅ　［’ Ｄｉｒ８０’　コ　ｃｏｎｔａｉｎｓ　［’Ｄｉｒ８０’　］　ｉｓ　ｔｒｕｅ ｂｅｃａｕｓｅ　ｉｔ　ｉｓ　ｐｒｏｖｅｄ　ｂｙ　ａ　ｑｕｅｒｙｂｅｃａｕ ｓｅ　［’Ｄｉｒ８０’　］　ｃｏｎｔａｉｎｓ　［’Ｄｉｒ３９２’　］　ｉ ｓ　ｔｒｕｅｂｅｃａｕｓｅ　ｉｔ　ｉｓ　ｐｒｏｖｅｄ　ｂｙ　ａ　ｑｕｅｒ ｙｂｅｃａｕｓｅ　［’Ｄｉｒ３９２°］　ｌａｍｅ　じｅｔｃ’コ　ｉｓ　ｔ ｒｕｅｂｅｃａｕｓｅ　ｉｔ　ｉｓ　ｐｒｏｖｅｄ　ｂｙ　ａ　ｑｕｅｒｙｂｅ ｃａｕｓｅビＦｉｌｅ３９７’コｎａｍｅ　［’ｕｔｍｐ’　］　ｉｓ　ｔｒｕ ｅｂｅｃａｕｓｅ　ｉｔ　ｉｓ　ｐｒｏｖｅｄ　ｂｙ　ａ　ｑｕｅｒｙｂｅｃａ ｕｓｅ　［’Ｄｉｒ３９２°コｃｏｎｔａｉｎｓ　［’Ｆｉｌｅ３９７°］　ｉ ｓ　ｔｒｕｅｂｅｃａｕｓｅ　ｉｔ　ｉｓ　ｐｒｏｖｅｄ　ｂｙ　ａ　ｑｕｅｒ ｙｂｅｃａｕｓｅ　［’Ｕｓｅｒ１６２’　］　ｈａｓ　［’ｗｒｉｔｅ’　］ 　ａｃｃｅｓｓＴｏじＦｉｌｅ３９７’ｌ　ｉｓｒｕｅ ｂｅｃａｕｓｅ　［’　Ｆｉｌｅ３９７’　］　ｏｖｎｅｒＭｏｄｅ　［’ｗｒ ｉｔｅ’　］　ｉｓ　ｔｒｕｅｂｅｃａｕｓｅ　ｉｔ　ｉｓ　ｐｒｏｖｅｄ　ｂ ｙ　ａ　ｑｕｅｒｙｂｅｃａｕｓｅ　［’Ｆｉｌｅ３９７°　］　１ｓｏｖｎｅ ｄＢｙ　［’Ｕｓｅｒ１６２　°コ　ｉｓ　ｔｒｕｅｂｅｃａｕｓｅ　［’Ｆｉ ｌｅ３９７’　］　ｏｗｎｅｒｌｄ　［０］　ｉｓ　ｔｒｕｅｂｅｃａｕｓｅ　 ｉｔ　ｉｓ　ｐｒｏｖｅｄ　ｂｙ　ａ　ｑｕｅｒｙｂｅｃａｕｓｅ　［’Ｕｓｅ ｒ１６２’　］　ｕｓｅｒｌｄ　［０１ｉｓ　ｔｒｕｅｂｅｃａｕｓｅ　ｉｔ　 ｉｓ　ｐｒｏｖｅｄ　ｂｙ　ａ　ｑｕｅｒｙｂｅｃａｕｓｅ　［’Ｕｓｅｒ１６ ２’　］　ｈａｓビｒｅａｄ’　］　ａｃｃｅｓｓＴｏ　［’　Ｆｉｌｅ３９７ ’　］　ｉｓｒｕｅ ｂｅｃａｕｓｅ　［’　Ｆｉｌｅ３９７’　］　ｏｖｎｃｒＭｏｄｅ　［’　ｒ ｅａｄ’　］　ｉｓ　ｔｒｕｅｂｅｃａｕｓｅ　ｉｔ　ｉｓ　ｐｒｏｖｅｄ　ｂ ｙ　ａ　ｑｕｅｒｙｂｅｃａｕｓｅ　じＦｉｌｅ３９７’　コ　１ｓｏｖｎｅｄ Ｂｙ　［’Ｕｓｅｒ１６２’　コ　ｉｓ　ｔｒｕｅｂｅｃａｕｓｅ　［’Ｆｉｌ ｅ３９７’　］　ｏｖｎｅｒｌｄ　［０１ｉｓ　ｔｒｕｅｂｅｃａｕｓｅ　ｉｔ 　ｉｓ　ｐｒｏｖｅｄ　ｂｙ　ａ　ｑｕｅｒｙｂｅｃａｕｓｅ　［’Ｕｓｅｒ１ ６γ　］　ｕｓｅｒＩｄ　［０コ　ｉｓ　ｔｒｕｅｂｅｃａｕｓｅ　ｉｔ　ｉｓ 　ｐｒｏｖｅｄ　ｂｙ　ａ　ｑｕｅｒｙｂｅｃａｕｓｅ　［’Ｕｓｅｒ１６γ］ 　１ｓｓｕｐｅｒＵｓｅｒ　ｉｓ　ｔｒｕｅｂｅｃａｕｓｅ　［’１Ｊｓｅｒ１ ６２’　］　ｕｓｅｒｌｄ　［０］　ｉｑ　ｔｒｕｅｂｅｃａｕｓｅ　ｉｔ　ｉ ｓ　ｐｒｏｖｅｄ　ｂｙ　ａ　ｑｕｅｒｙ上記において、［方法（ｍｅｔｈｏｄ ）Ｊによって証明されてＬする事実の参照は、成る特定の関係をテストするため に、事実ベースおよび照会機構を用いるのではなく、低レベルのコードを用（ま たことを単【こ意味している。典型的には、各コアエンティティ（数の比較、ス トリングの突き合わせ他）の間の関係について、この態様でテストを行うと好都 合である。

変更態様 本発明の上述の実施例についての様々な変形例が考え得ること（言明らかである 。したがって、例えば個々のタスクプログラムの主体として各タスクを説明した が、サービスモデルの処理をＩＩＩ御するｔこめの、プログラム以外の、タスク により決定される手段を設番することも可能である。かかる他の手段には、各タ スク毎の専用の４１言命エンジンや、各タスクを実行するための共通の汎用プロ セッサを制御する個々のハードウェア手段が含まれる。

より詳細には、事実ベース中に保持されるでいるあらゆる事実の有効性を妥当な 範囲内で保証するために、特定の基準を設けることができる。例えば、各照会に 、その照会の実行によって導出されるあらゆる事実が有効であるとみなすことの できる時間である「寿命」を割り当てることができる。照会の寿命が切れると、 導出された事実（およびそれら事実に基づく別の事実）の全てが事実ベースから 削除される。このような構成の場合、照会を用いてシステムの構成要素に関する 事実を導出し、監視期間に対応する寿命をその照会に持たせることにより、シス テムの構成要素の監視を実施することができる。即ち、照会が寿命の終わりに達 した際に、対象とする事実が事実ベースから削除され、これを、対応する照会の 再開させるためのトリガとして監視タスクにより用いることができるようになる 。

更に、各サービスモデルは、対応付けされた照会および動作（適宜のもの）を有 しているが、かかる照会および動作を、２つ以上のモデルによって共用すること もできる。例えば、ファイルが存在するか否かに関する照会は、幾つかの異なる サービスモデルによって使用されるものとすることが十分に可能であり、またそ の照会を、各モデル毎に指定するよりも、モデル間で共用したほうが明らかに効 率的である。

このシステム管理装置には、適当なあらゆるユーザインターフェースを設けるこ とができることが理解されよう。特に、［ドラッグおよびドロップ」動作が、異 なるサービスモデルの特定の用例に関してタスクを実施させるように機能するこ とができる、グラフィカルユーザインターフェースをイ史用することができる。

ＦＩＧ　７ Ｓ６　＝　ｐｒｉｎｔ［ｐｓＦｉｌｅ］ＩＧ　９ 特表千７−５０９５８２　（１９）

Claims (19)

【特許請求の範囲】
1. １．互いに協働する物理エンティティと論理エンティティとからなるコンピュー タシステムにより提供することが意図された少なくとも１つのサービスに関連す る少なくとも１つの管理タスクを実行するためのシステム管理方法であって、 前記少なくとも１つのサービスの各々について、そのサービスが利用可能となる ために満たす必要のある要件を特定の前記タスクのいずれからも独立して指定す る個々の宣言モデルを提供し、それら要件が、必要とされるエンティティとその 相互関係とに関して記述されており、 前記少なくとも１つの管理タスクの各々について、対応するタスクの実行を、特 定の前記モデルのいずれからも独立した態様で、前記モデルのいずれについても 実行可能な一般的な推論動作に関して制御する、個々のタスク制御手段を提供し 、前記少なくとも１つのサービスに関連する前記の少なくとも１つの管理タスク を、その管理タスクに関連する前記タスク制御手段の制御下で、対応する宣言モ デルについて推論動作を行うことを含む処理により実行する、 というステップを含む、前記システム管理方法。
2. ２．前記タスク制御手段が、前記少なくとも１つの管理タスクを実行するのに用 いられる推論エンジンの動作を制御するための個々のタスクプログラムを含む、 請求項１記載のシステム管理方法。
3. ３．対応するタスクを実行するのに用いられる個々の推論エンジンにおいて、前 記タスク制御手段が少なくとも部分的に実施される、請求項１記載のシステム管 理方法。
4. ４．前記コンピュータシステムが、多数のタスクが実行されるべき多数のサービ スを提供し、前記方法が、前記多数のサービスの各々について個々の前記サービ スモデルを提供し前記多数のタスクの各々について個々の前記タスク制御手段を 提供するというステップを含む、請求項１記載のシステム管理方法。
5. ５．前記コンピュータシステムが前記サービスの複数の例示を支援することがで き、前記少なくとも１つのサービスに関して前記少なくとも１つの管理タスクを 実行する前記ステップが、タスクが実行されるべきサービスの前記例示を識別し 、次いで適当なサービスモデルを用いて、その識別されたサービスの例示に関す る情報を推論することを含む、請求項１記載のシステム管理方法。
6. ６．少なくとも１つの前記宣言モデルが、エンティティを相互に対応付ける宣言 ステートメントからなる階層構造を有し、その階層中の下位のステートメントが 、前記階層中の上位のステートメントにより指定される要件を詳述するよう働く 、請求項１記載のシステム管理方法。
7. ７．前記少なくとも１つのモデルが、要件を指定する前記ステートメントに加え て、一般に前記エンティティを相互に対応付けると共に特定の前記要件が満たさ れたか否かを推論するのに使用可能なステートメントを含む、請求項６記載のシ ステム管理方法。
8. ８．個々の前記サービスを各々が指定する複数の前記サービスモデルが設けられ 、１つの前記モデルに記述されると共に特定の前記エンティティを伴うステート メントがそのエンティティを参照する他のモデル中で使用可能となるように少な くとも２つの前記モデルが対応付けされる、請求項６または請求項７記載のシス テム管理方法。
9. ９．前記要件が、１組の必須の技術要件と別の１組の動作方針要件との両方を有 し、それらの組が互いに別個に指定される、請求項１記載のシステム管理方法。
10. １０．前記少なくとも１つの管理タスクを実行する前記ステップが、前記システ ムと対話して、対象となるサービスに関連する要件がそのシステムにより満たさ れているか否かを直接的にまたは前記対話の結果から推論して確認することを含 む、請求項１記載のシステム管理方法。
11. １１．システムに関する事実を保持している事実ベースを提供するというステッ プを更に含み、前記少なくとも１つの管理タスクを実行する前記ステップが、前 記事実ベースを参照して、対象となるサービスに関連する前記要件がそのシステ ムにより満たされているか否かを確認することを含む、請求項１記載のシステム 管理方法。
12. １２．システムに関する事実を保持する事実ベースを提供するというステップを 更に含み、前記少なくとも１つの管理タスクを実行する前記ステップが、対象と なるサービスに関連する前記要件が前記システムにより満たされているか否かを 、前記要件に関連する事実について前記事実ベースを参照することにより確認し 、前記要件が満たされているか否かを確認するのに十分な事実が事実ベースに存 在しない場合には、前記システムと対話して、必要とされる事実を、直接的にま たは前記対話の結果から推論して確認する、ということを含む、請求項１記載の システム管理方法。
13. １３．システムとの対話から導出された結果が前記事実ベースに格納される、請 求項１２記載のシステム管理方法。
14. １４．実行される前記管理タスクが障害診断タスクである、上記請求項のいずれ か１つに記載するシステム管理方法。
15. １５．前記管理タスクを実行する前記ステップが、エンティティの追加または削 除により、または、少なくとも２つの前記エンティティ間の相互関係の修正によ り、対象とするサービスの前記要件を満たすように、前記システムを変更するこ とを含む、上記請求項のいずれか１つに記載するシステム管理方法。
16. １６．実行される前記管理タスクが、前記サービスのインストールである、請求 項１５記載のシステム管理方法。
17. １７．前記コンピュータシステムがコンピュータのネットワークからなる、上記 請求項のいずれか１つに記載するシステム管理方法。
18. １８．互いに協働する物理エンティティおよび論理エンティティからなるコンピ ュータシステムにより提供することが意図された少なくとも１つのサービスに関 連する少なくとも１つの管理タスクを実行するためのシステム管理装置であって 、この装置が、前記少なくとも１つのサービスの各々について、そのサービスが 利用可能となるために満たす必要のある要件を特定の前記タスクのいずれからも 独立して指定する宣言モデルであって、前記要件が、必要とされるエンティティ とその相互関係とに関して記述される、前記宣言モデルと、 前記宣言モデルに関して推論動作を実行する推論エンジン手段と、前記の少なく とも１つの管理タスクの各々について、前記推論エンジン手段による対応するタ スクの実行を、特定の前記モデルのいずれからも独立した態様で、一般的な推論 動作に関して制御する、個々のタスク制御手段と、 前記少なくとも１つのサービスに関連して前記少なくとも１つの管理タスクを実 行させる手段であって、その実行が、その管理タスクに関達する前記タスク制御 手段の制御下で、対応する宣言モデルについて前記推論エンジン手段を動作させ ることにより行われる、前記実行手段と を備えた、前記システム管理装置。
19. １９．前記システムに関する事実を格納する事実ベース手段と、前記システムと 対話してそのシステムに関する事実を直接的にまたは前記対話の結果からの推論 により確認する対話手段とを更に備え、前記推論エンジン手段が、前記管理タス クの実行中に、前記事実ベース手段を参照することにより前記要件が前記システ ムにより満たされているか否かをチェックし、事実ベース手段に十分な事実が存 在しない場合には、前記対話手段に前記システムとの対話を行わせて別の事実を 引き出すことにより前記チェックを行うように動作する、請求項１８記載のシス テム管理装置。