JPH09504394A - タスク実行のためのプロセス構造を定義するシステムおよび方法 - Google Patents

Abstract

(57)【要約】 タスクを実行するためのプロセス構造を定義するシステムおよび方法が開示されている。システムはデータ・ストレージ・メモリ、データ入力用のキーボードおよびスクリーンを装備したコンピュータを備えている。ユーザは、動詞ワードとオブジェクト・ワードを含んでいて、その構造を作成しようとしているタスクを定義している第１プロセス定義を入力する。そのあと、ユーザは第１プロセス定義を実行すると予想される結果となる、あるいは第１プロセス定義を実行するときの予想される構成ステップとなる後続のプロセス定義を定義することができる。各ステージでの各プロセス定義を分析することにより、タスクを実行するための完全なプロセス構造を構築し、改良していくことができる。また、ユーザはある特定のプロセス定義のオブジェクト・ワードの意味の範囲に入る特定のオブジェクト・ワードを指定し、これらをスクリーン上に表形式で呼び出して、プロセス構造内のプロセス定義のディスプレイにオーバライトすることもできる。

Description

【発明の詳細な説明】 タスク実行のためのプロセス構造を定義するシステムおよび方法発明の分野 本発明は、タスク（仕事）を実行する上で必要なステップ（段階）を判別しお よび／または改良できるような形で、さらに、タスクでのプロセス・ステップの 実行をモニタできるような形で、プロセス構造を作成またはモデル化するための システムおよび方法に関する。発明の背景 ユーザがシステム構造を分析して、システム・ステップのシーケンスのどこで ホールドアップ（停止、休止、停滞など）が起こるおそれがあるかを明らかにで きるようにする方法は公知である。そのような方法の例として、ＧＡＮＴチャー トまたはＰＥＲＴソフトウェアがあり、この方法による分析はクリティカル・パ ス分析法(critical path analysis)に基づいている。これらの方法は、ユーザが どのような方法で、タスクでのステップの判別を識別すべきかのガイダンスを提 供していない。 タスクを実行するときによく起こることは、不必要なステップを実行したり、 相対的に重要でないステップや単純なステップに集中したりすることに大量の時 間が浪費され、他方では、もっと注意すべきステップを避けたり、そのようなス テップに殆ど時間をかけないことである。タスクの実行において、より関心のあ るステップや特定の作業員の得意な分野を反映するようなステップに大量の時間 や注意力を消費するのは、人間の常である。これらの得意な分野が最大の詳細を 必要とするステップと一致していれば、結果は満足すべきものとなる可能性があ る。しかし、あるタスクがその性質上いくつかの分野にまたがるときや、多少で も作業員の経験外にあるときは、作業員は相対的に得意な分野に集中する傾向が あるか、あるいはどの分野に最大の努力を向けるべきかを明確化できないことに なる。 この問題は、いくつかの分野にまたがるチームを利用すると解決できるかもし れないが、それでもなお、チームのメンバに任せられる重要な分野を判別できる 能力が必要になる。大規模で複雑なタスクを実行する場合には、これが、タスク ・ステップとその実行を識別する重要な側面となる場合がある。しかし、小規模 である場合や、タスクのステップを定義する初期ステージにおいて、対象のタス クがそのような入力を判断できないステージでは、作業員の時間が大量に浪費さ れることになる。 タスクを定義する人は、特定のタスクを実行する上で必要なステップ自体の認 識と定義を論理的に進めて行くのを支援するツールを使用すると、便利なことが ある。 さらに、タスクのセットアップが完了したとき、タスクの進行状況を各タスク ・ステップのステータス（状況）に従ってモニタすると役に立ち、そうすること が不可欠であることがよくある。従って、タスクとタスクを構成するステップの 進行状況を追跡するのを支援するツールがあると、ユーザにとっては好都合であ る。 本発明の第１の側面によれば、タスクを実行するためのプロセス構造を構築す るシステムが提供され、該システムは、 コンピューティング・デバイスと、 コンピューティング・デバイスによってアクセスされるデータをストアするデ ータ・ストレージ手段と、 コンピューティング・デバイスに接続されて、データを入力する手段と、 同じくコンピューティング・デバイスに接続されて、データを表示するディス プレイ手段とを備えており、コンピューティング・デバイスは、１つまたは複数 の動詞ワード(verb word)と１つまたは複数のオブジェクト・ワード(object wor d)を含んでいて、タスクまたはタスクのステップを定義している第１プロセス定 義(process definition)を、データ入力手段を通してユーザから受け取るように 構成されていると共に、第１プロセス定義を受け取ったときの応答として、 第１プロセス定義を実行すると予想される結果となるような第２プロセス定義を データ入力手段から入力することをユーザに要求するように構成されていること を特徴としている。 本発明の第２の側面によれば、タスクを実行するためのプロセス構造を構築す るシステムが提供され、該システムは、 コンピューティング・デバイスと、 コンピューティング・デバイスによってアクセスされるデータをストアするデ ータ・ストレージ手段と、 コンピューティング・デバイスに接続されて、データを入力する手段と、 同じくコンピューティング・デバイスに接続されて、データを表示するディス プレイ手段とを備えており、コンピューティング・デバイスは、１つまたは複数 の動詞ワードと１つまたは複数のオブジェクト・ワードを含んでいて、タスクま たはタスクのステップを定義している第１プロセス定義をデータ入力手段を通し てユーザから受け取るように構成されていると共に、第１プロセス定義を受け取 ったときの応答として、第１プロセス定義を実行するとき予想される構成ステッ プとなるような第２プロセス定義をデータ入力手段から入力することをユーザに 要求するように構成されていることを特徴としている。 本発明の第３の側面によれば、タスクを実行するためのプロセス構造を構築す るシステムが提供され、該システムは、 コンピューティング・デバイスと、 コンピューティング・デバイスによってアクセスされるデータをストアするデ ータ・ストレージ手段と、 コンピューティング・デバイスに接続されて、データを入力する手段と、 同じくコンピューティング・デバイスに接続されて、データを表示するディス プレイ手段とを備えており、コンピューティング・デバイスは、１つまたは複数 の動詞ワードと１つまたは複数のオブジェクト・ワードを含んでいて、タスクま たはタスクのステップを定義している第１プロセス定義をデータ入力手段を通し てユーザから受け取るように構成されていると共に、第１プロセス定義を受け取 ったときの応答として、第１プロセス定義のオブジェクト・ワードの意味の範 囲に入る特定のオブジェクト・ワードを指定することをユーザに要求するように 構成されていることを特徴としている。 また、本発明は、タスクをコンピュータ上で実行するためのプロセス構造を構 築する方法にも範囲が及び、該方法は、 １つまたは複数の動詞ワードまたは１つまたは複数のオブジェクト・ワードを 含んでいて、タスクまたはタスクのステップを定義している第１プロセス定義を 入力し、 第１プロセス定義を実行すると予想される結果となるような第２プロセス定義 を入力することをユーザに要求することを含んでいることを特徴としている。 また、本発明は、タスクをコンピュータ上で実行するためのプロセス構造を構 築する方法も包含しており、該方法は、 １つまたは複数の動詞ワードまたは１つまたは複数のオブジェクト・ワードを 含んでいて、タスクまたはタスクのステップを定義している第１プロセス定義を 入力し、 第１プロセス定義を実行する際に予想される構成ステップとなるような第２プ ロセス定義を入力することをユーザに要求することを含んでいることを特徴とし ている。 また、本発明は、タスクをコンピュータ上で実行するためのプロセス構造を構 築する方法にも範囲が及び、該方法は、 １つまたは複数の動詞ワードまたは１つまたは複数のオブジェクト・ワードを 含んでいて、タスクまたはタスクのステップを定義している第１プロセス定義を 入力し、 第１プロセス定義のオブジェクト・ワードのインスタンスとなる特定のオブジ ェクト・ワードを入力することをユーザに要求することを含んでいることを特徴 としている。 また、本発明によれば、タスクを実行するためのプロセス構造を構築するシス テムが提供され、該システムは、 コンピューティング・デバイスと、 コンピューティング・デバイスによってアクセスされるデータをストアする データ・ストレージ手段と、 コンピューティング・デバイスに接続されて、データを入力する手段と、 同じくコンピューティング・デバイスに接続されて、データを表示するディス プレイ手段とを備えており、コンピューティング・デバイスは、少なくとも１つ の動詞ワードと少なくとも１つのオブジェクト・ワードを含んでいるデータ・プ ロセス定義をデータ入力手段を通してユーザから受け取るように構成され、各プ ロセス定義は複数のステージから構成されたタスクのステップを定義していくこ とにより最終的にタスクのプロセス定義が得られるようになっており、さらに、 コンピューティング手段は、タスクのステージの少なくとも１つのステージの１ つのプロセス定義に関連するデータをストアするように動作可能であることを特 徴としている。 本発明によれば、タスク・ステップがプロセス構造の構成部分としてどのよう に行うべきかを検討することにより、プロセス構造を明確化し、あるいは開発す ることが可能である。また、本発明によれば、ユーザは、タスク・ステップがプ ロセス構造定義ルーチンの構成部分として行うときの方法を検討することにより 、プロセスを改善することも可能である。データベースとプロセス構造は、ユー ザがコンピューティング手段からのプロンプトを選択して応答すると、自動的に 開発され、動的に調整可能になっている。 好ましくは、前記１つのプロセス定義の前のステージでの構成プロセス定義の オブジェクト・ワード（１つまたは複数）は、検索可能データ・ディスプレイに コンピューティング手段によって配置されている。 従って、本発明によれば、情報ウィンドウを、モデル化したタスクの中のプロ セスのいずれか、あるいはすべてと関連づけることが可能である。これらは標準 情報ウィンドウの形体にして、プロセス完了／未完了、完了日といったチェック リスト・エントリ（項目）を指定することが可能である。しかし、プロセスをカ ストマイズした情報ウィンドウの中で使用して、モデル化したタスクの先行ステ ップを表すようにすると、タスクに関する種々のデータをそのステップで表示し て評価および分析を行うことも可能である。 好ましくは、本発明は、オプションとして、モデル化したタスクの中の各プロ セスごとに情報ウィンドウを構築するように構成されている。例えば、ある与え られたプロセスについて、本発明は、その与えられたプロセスのステージの直前 に置かれたモデル・ステージでのプロセスの各々ごとに、関連情報ウィンドウに 列見出し（column header−カラム・ヘッダ）を生成するように構成することが 可能である。 好ましくは、データ・ディスプレイは表形式になっている。例えば、先行ステ ージの関連構成プロセス定義のオブジェクト・ワード（１つまたは複数）は列見 出し(column heading)として配列され、前記１つのプロセス定義の特定のオブジ ェクトは行見出し(row heading)として配列されている。 大部分のデータは前記構成プロセス定義と関連づけられるが、他方では、コン ピューティング手段は、データ・ディスプレイの配置においてさらに別のオブジ ェクト・ワードを受け付けるように構成されていることも望ましい。コンピュー ティング手段は、オブジェクト・ワード（１つまたは複数）がユーザによってデ ータ・ディスプレイに追加されたとき、構成プロセス定義を作成するように構成 することが可能である。好ましくは、コンピューティング手段は、オブジェクト ・ワード（１つまたは複数）がユーザの裁量でデータ・ディスプレイに追加され たとき、構成プロセス定義の作成を禁止するように構成されている。 特定の形体では、本発明はタスクを実行するためのプロセス構造をモデル化す るシステムからなり、該システムは、 コンピューティング手段と、 コンピューティング手段によってアクセスされるデータ・ストレージ手段と、 コンピューティング手段に接続されて、プロンプトと、入力手段からおよびコ ンピューティング手段から入力されたデータを表示するように動作可能であるデ ィスプレイ手段とを備えており、コンピューティング手段は、第１プロセス定義 を求めるプロンプトを選択的に表示して、ユーザによってデータ入力手段から入 力された１つまたは複数の動詞ワードと１つまたは複数のオブジェクト・ワード を要求するように構成されていると共に、コンピューティング手段からの別のプ ロンプトを選択することをユーザに要求して、第１プロセス定義を実行すると その結果となるような、あるいは第１プロセス定義を実行するときの構成ステッ プとなってタスク・モデルの一連のステージを作成し、最終的にタスクを実行す るモデルが得られるような第２プロセス定義を入力することをユーザに要求し、 あるいは、第１プロセス定義のオブジェクト・ワードのインスタンスとなる特定 のオブジェクト・ワード（１つまたは複数）を指定することをユーザに要求する ように構成されており、コンピューティング手段は、さらに、１つのステージで の１つのプロセスに関連づけられていて、前記１つのプロセス定義の直前に置か れたステージでのプロセス定義の構成オブジェクト・ワード（１つまたは複数） が列見出しとして配列され、該１つのプロセスの特定オブジェクトが行見出しと して配列されている検索可能データ・ディスプレイを生成するように動作可能で あることを特徴としている。 本発明によれば、作業の計画と管理を単純な方法で行うことができる。基本的 プロンプトを通して、ユーザは、経験が不足している分野では小さなステップを とってタスク構造を定義することができ、また、経験が十分にあり、複数の中間 の、より基本的なステップを注意して調べる必要のないような分野では、より大 きなステップをプロセス定義間で定義または明確化することができる。従って、 タスクを実行する各プロセス構造は、論理的に、しかもユーザの経験レベルまた は分野を反映するように定義することができる。従って、開発されたプロセス構 造またはモデルは、システムのプロンプトのガイドに従って重要な考慮をしてき たユーザにユニークに適合したものになる。ユーザの経験が乏しい分野ではタス クのステップをモニタする必要性は、より詳細化されたステージを使用すること により自動的に満たされる。 好ましくは、コンピューティング手段は、プロセスの第２またはそれ以降のス テージをディスプレイ手段上に順番に追加することを要求するように構成されて いる。例えば、第１プロセス定義を実行するとその結果となる第２プロセス定義 の要求（ＷＨＹ？プロンプト）は、ディスプレイ手段の一方向に配列され、第１ プロセス定義を実行するときの予備的ステップとなる第２プロセス定義の要求（ ＨＯＷ？プロンプト）は、ディスプレイ手段の反対方向に配列される。これらの プロセス定義の要求は相互に対立するものと扱われる。従って、２つの要求を 受けてプロセス定義を反対方向に順序を付けると、トランスペアレントなタスク ・モデル(transparent task model)が作成されるので、ユーザの経験度を反映す るように各ステージごとにより詳細化するように、あるいは詳細度が粗くなるよ うに構築していくことができる。 正しい順序にするためには、タスク・モデルまたはプロセス構造の開発は、基 本的タスク・プロセスから始めて種々のプロセス・ステージを経て、基本的初期 化プロセスに到達するように進めていくことが望ましい。この進め方はディスプ レイ手段の右から左へ行うのが望ましいが、左から右へ行っても、ディスプレイ 手段の上下のどちらの方向に行っても、その効果は同じである。 好ましくは、コンピューティング手段は、同じタスク・ステージ・レベルのプ ロセス定義を、ディスプレイ手段上で並列に配列するように構成されている。こ のようにすると、同じレベルの各ステップは、プロセス定義の別々のシーケンス をサポートすることになる。 第１プロセス定義のオブジェクト・ワードの意味の範囲に入る特定のオブジェ クト・ワードをユーザが指定するように求める、コンピューティング手段の要求 は、オーバーレイしたイメージまたはウィンドウとしてディスプレイ手段上に現 れて、そこにオブジェクト・タイプに従った特定オブジェクトのより詳細化した 例がリストされるように配置することが可能である。 上述した特定形体の本発明を利用すると、ユーザはタスク・モデルをどちらの 方向にも構築していくことができる。例えば、タスクの初期特定をガイドとする と、ユーザはＨＯＷ？プロンプトに対する応答に基づいてモデルを構築していき 、モデル内の特定オブジェクトを必要な個所に定義していくことができる。また 、オプションとして、ユーザは、ＷＨＹ？プロンプトに応答しながら逆方向に作 業を進めていくと、タスクまたはタスクのステップの値を確かめることもできる 。 本発明には、カルキュレータ動詞(calculator verb)を含めることも可能であ り、その場合、コンピューティング手段は、カルキュレータ動詞に応答して、タ スク・ステージに配列されているオブジェクトの値（これはデータ・ストレージ 手段にストアされている）について算術演算プロセスを実行するように構成され ている。これは、金額またはオブジェクト数といった、オブジェクトの数値に関 係するオブジェクトに対するものである。 好ましくは、コンピューティング手段は、プロセスに関するデータ入力手段か らのコマンドに応答して、テキスト・サブファイルおよび／またはドキュメント ・ヘッダを作成するように構成されており、テキスト・サブファイルはデータ入 力手段から送られたユーザのコマンドに応答して、ディスプレイ手段から表示可 能になっている。ヘッダで示されたドキュメントは、コンピューティング手段と 関連づけられたテキスト処理言語で書いて、タスク・モデルからアクセスするこ とが可能である。このようにすると、ユーザはコンピューティング手段の基礎と なるデータ構造を使用して、特定のオブジェクトに関係する他のファイルをアク セスすることができる。 コンピューティング手段は、データ入力手段からユーザによって与えられ、タ スク・モデルの各プロセスに関連づけられた重み付け(weighting)から、困難度 の等級を生成するように構成することも可能である。例えば、重み付けはユーザ による割当てが可能な数値にすることができる。 本発明によれば、あるプロセス・オブジェクトを選択することができる。この 方法によると、選択されたオブジェクトはプロセスのインスタンスとなるので、 オリジナル・プロセス動詞と選択されたオブジェクトとを含む別の現プロセスが 定義されることになる。ＨｏｗタスクまたはＷｈｙタスクは、あるオブジェクト と関連をもつプロセスと関連づけることができる。この方法によると、Ｈｏｗタ スクまたはＷｈｙタスクは、別の現プロセスおよびそのオブジェクト・プロセス だけのオブジェクトを更に細分化したものと特定の関係をもつことになる。 ＨｏｗタスクまたはＷｈｙタスクは、あるオブジェクトと関係をもつ現プロセ スによって継承することができる。この方法によると、プロセス・オブジェクト 関係の上位レベル・オブジェクトのＨｏｗタスクまたはＷｈｙタスクは、現プロ セスと別々に関連づけられているＨｏｗタスクとＷｈｙタスクのほかに、現プロ セスにも適用されることになる。 Ｈｏｗプロセスは合成(compound)することが可能である。この方法によると、 Ｈｏｗプロセスは、それ自体も合成できる先行Ｗｈｙプロセスの選択されたオブ ジェクトと関連づけられることになる。 プロセスはチェインブレーキング(chainbreaking)を含むことが可能である。 この方法によると、Ｈｏｗプロセス・オブジェクトは、合成の有無に関係なく、 そのプロセスのオブジェクトとだけ関連づけられることになる。Whatと情報ウィ ンドウ内のオブジェクトは継承できるので、表示されるオブジェクトは、Ｗｈｙ プロセス・オブジェクトと関係づけれたものと一緒に、Ｗｈｙプロセス・オブジ ェクトの上位レベル・オブジェクトと関係づけられたものになる。図面の簡単な説明 本発明は種々の態様で実施することが可能であるが、以下では、その一部を例 示して添付図面を参照して説明することにする。図面において、 図１は、本発明をインストールできるコンピュータ・システムを示す概略ブロ ック図である。 図２は、本発明の一実施例の基本ディスプレイ・スクリーンを示す図である。 図３は、タスク・モデルの始まりが形成されているディスプレイ・スクリーン を示す図である。 図４は、より完成したタスク・モデルのディスプレイ・スクリーンを示す図で ある。 図５は、改良されたタスク・ステップの細部のディスプレイ・スクリーンを示 す図である。 図６は、オーバーレイされたウィンドウのディスプレイ・スクリーンを示す図 であり、そこでは、タスク・ステップ・プロセス内のオブジェクトが指定されて いる。 図７は、図６と同じようにオーバーレイされたウィンドウのディスプレイ・ス クリーンを示す図であり、そこでは、ツールボタン(Tool Button)が押され、ツ ールバー(Tool Bar)がオープンしている。 図８は、図７と同じようにオーバーレイしたウィンドウのディスプレイ・スク リーンを示す図であり、そこでは、オブジェクトが２つの追加レベルに展開され ている。 図９は、図７と同じようにオーバーレイされたウィンドウのディスプレイ・ス クリーンを示す図であり、そこでは、オブジェクトが２つの追加レベルに展開さ れている。 図１０は、図６と同じようにオーバーレイされたウィンドウのディスプレイ・ スクリーンを示す図であり、そこでは、１つの特定オブジェクトに焦点を当てて いる。 図１１は、図６と同じようにオーバーレイされたウィンドウのディスプレイ・ スクリーンを示す図であり、そこでは、そのウィンドウからのオブジェクトが選 択されて、プロセス選択フィールドに入れられている。 図１２は、２つのオーバーレイされたウィンドウのディスプレイ・スクリーン を示す図であり、そこではオブジェクトの関連づけを示している。 図１３は、図６と同じようにオーバーレイされたウィンドウのディスプレイ・ スクリーンを示す図である。 図１４は、２つのオーバーレイされたウィンドウのディスプレイ・スクリーン を示す図であり、そこでは、オブジェクト継承を示している。 図１５は、オーバーレイされたウィンドウのディスプレイ・スクリーンを示す 図であり、そこでは、Ａ１１モードを示している。 図１６は、オーバーレイされたウィンドウのディスプレイ・スクリーンを示す 図であり、そこでは、Ａ１１モードのSelect（選択）とDe-select（選択解除） を示している。 図１７は、オーバーレイされたウィンドウのディスプレイ・スクリーンを示す 図であり、そこでは、Normal（通常）モードを示している。 図１８は、オーバーレイされたウィンドウのディスプレイ・スクリーンを示す 図であり、そこでは、プロセス・ボックスはオブジェクトの合成を示している。 図１９は、オーバーレイされたウィンドウのディスプレイ・スクリーンを示す 図であり、そこでは、プロセス・ボックスはプロセスとオブジェクトのチェイ ン・ブレークを示している。 図２０は、Ｈｏｗモードのプロセス・ボックスのディスプレイ・スクリーンを 示す図であり、そこでは、ＨｏｗプロセスがPSFの設定値に依存することを示し ている。 図２１は、Ｗｈｙモードのプロセス・ボックスのディスプレイ・スクリーンを 示す図であり、そこでは、ＷｈｙプロセスがPSFの設定値に依存することを示し ている。 図２２は、プロセスの情報ウィンドウのディスプレイ・スクリーンを示す図で ある。 図２３は、プロセスの情報ウィンドウと計算プロセスのディスプレイ・スクリ ーンを示す図である。 図２４は、重み付けされたタスク・モデルのディスプレイ・スクリーンを示す 図であり、そこでは、プロセスの困難度を示している。 図２５はタスク・モデルの一部のディスプレイ・スクリーンを示す図である。 図２６は、ここで説明している本発明の実施例の場合のエンティティ関係図で ある。好適実施例の詳細な説明 システムの主要エレメントは図１にブロック形式で示されている。これらのエ レメントはユーザ１０によって使用され、データがユーザによってそこからコン ピュータ１４に入力されるキーボード１２を含んでいる。データはコンピュータ によってモニタ・ディスプレイ・スクリーン１６上に表示される。当業者ならば 理解されるように、コンピュータには、データをストアするメモリ１８が関連づ けられている。 以下には、「カーソル」と言及している個所があるが、カーソルとは、当業者 ならば理解されるように、あるアクションまたは機能がそこでまたはそこにアド レスされている、スクリーン上の「現在の」(current)エリアを示すマークのこ とである。カーソルは「マウス」によってスクリーン上のどこにでも移動するこ とが可能である。アクションまたは実行スイッチはマウスに一体になっている。 カーソルは、従来のＱＷＥＲＴＹワードプロセシング・キーボード上の上向き／ 下向き／左向き／右向きキーなどの、従来のキーストロークで移動することも可 能である。従来、キーボード上でのコマンドまたは機能の実行は、例えば、“Ｒ ＥＴＵＲＮ”または“ＳＰＡＣＥ”キーをたたたくか、マウスを「クリック」す ることにより行われている。理解を容易にするために、カーソルの移動とコマン ドまたは機能の実行は、従来のように、マウスまたはキーボードとマウス・スイ ッチの作動（クリック）またはキーストロークによってカーソルを移動したとき の結果であるものとする。スクリーンのあるエリアまで移動し、そこで特定の機 能を指示し、それを実行するプロセスは上記と同じであるものとし、以下の説明 では、これを「セレクション(selection：選択）」と呼ぶことにする。 同様に、マウスは、スクリーン上に表示されているアイコンまたは文字を「捕 らえる」(capture)ためにも使用できる。捕らえたアイテム（項目）はスクリー ン上で「ドラッグ」して、ユーザがそれを必要とする個所に置くことができる。 これらは公知の操作である。 ユーザ１０は、特定のタスクを効率よく実行するにはどのように進めていくか を明確化する仕事を担当している。本発明の１つの見方として、有形、無形を問 わず、定義できるオブジェクトの概念がある。例として、作成する報告書、行わ れるセールス、サービスを提供されるカストマ（顧客）がある。どのオブジェク トも、ＷＨＡＴ？アイコンを選択することにより、ユーザが要求する通りにカテ ゴリに分割し、さらにサブカテゴリに分割することができる。オブジェクトは従 業員であることもあり、従業員のカテゴリはセールスマンであることもあり、セ ールスマンのサブカテゴリは名前別の個人セールスマンにすることもできる。 オブジェクトに関連づけられるものとして、動詞(verb)／目的語（オブジェク ト）のペア（「プロセス」）を作成する動詞があり、これは実行すべきタスク全 体またはそれを達成するまでの途上にあるステップを包含している。ユーザがシ ステムでモデルとして管理したいタスクを、上で定義したように、動詞／オブジ ェクト・プロセスの形で設定したあと、ユーザはアイコンＨＯＷ？とＷＨＹ？の どちらかを選択することができる。 ＨＯＷ？について説明すると、理解されるように、ユーザは、なにを次のステ ップにするか、現在のステップに特有のものにするか、あるいは以前に定義した ステップ・レベルまたはステージのステップの１つにするかを、作業を進めてい く過程で考える必要がある。最終的に、タスク・モデルが開発され、そこには、 異なるタスク・ステージでの中間プロセスの階層(hierarchy)が含まれている。 各プロセスは、タスク・モデルのステージにおけるステップである。 ＷＨＹ？はＨＯＷ？の逆方向と見ることができる。実際には、ＨＯＷ？をアド レスすると、タスクの開始または初期化ステップに導かれるのに対し、ＷＨＹ？ を使用すると、基本的タスク・プロセスに向かって作業することにより、タスク のプロセス・ステップを改良することができる。ささいなプロセスや重要でない プロセス、あるいは無関係なプロセスに不釣り合いに努力を向けると、タスクを 実行するとき大量の時間が浪費されることがよくある。従って、ＷＨＹ？という 質問にアドレスすることによりタスク・プロセスに向かって作業を行える能力は 、タスク・モデルを構築するときの改良ツールとなることを目的としている。 以下、具体例について説明する。システムは、INTEL 486DX/3-MHzマイクロプ ロセッサをベースとし、４Ｍバイト・メモリとＶＧＡモニタ・ディスプレイによ ってサポートされたパーソナル・コンピュータ上で稼働する。コンピュータには 、Microsoft Windows 3.1とDOS 5（または以降のバージョン）オペレーティング ・ソフトウェアが、本発明によるシステムを実行するプログラムと共に、ロード されている。このケースでは、本発明によるシステムのプログラムは、Windows およびDOSオペレーティング・ソフトウェアと互換性があることが必要である。 このようなプログラムの作成は、その大部分が、熟練したソフトウェア・プログ ラマにとってはルーティンの開発の問題である。また、当業者ならば理解される ように、本発明のエレメントは、適当なソフトウェア言語ならば、どの言語で書 くことも可能である。本発明の場合は、Ｃ++プログラミング言語が使 用されている。付録ＡとＢは、本発明の基礎となる概念に関連するソース・コー ドの一部をリストしたものである。これについては、以下で詳しく説明する。 システム・プログラムがMicrosoft Windowsプログラム・マネージャを通して インストールされると、図２に示すプロセス・シートをＶＧＡモニタのスクリー ン上に呼び出すことが可能になる。スクリーン・ディスプレイはタイトルバー２ ０、メニューバー２２およびボタンバー２４を含んでいる。モデルを作るには、 オプション'File'（ファイル）をメニューバー２２から選択する。これにより、 ユーザは既存のファイルを名前で指定することも、新しいモデルを作ることもで きる。新しいモデルを作ることを例にして、本発明を説明する。これの結果はフ ィールド・スクリーンとなるが、これはプロセス・エントリ・ボックス２６を除 き、大部分がブランクになっている。まず最初に、モデル化しようとするタスク ・プロセス全体になると考えられるものはなんであるかを定義するには、物理的 エンティティまたは抽象的概念となり得るオブジェクトを、さらに、オブジェク トに対して行いたいものはなんであるかを定義した動詞を、エントリ・ボックス ２６に入力する必要がある。キーボード上のＴＡＢキーを押すと、ボックス２６ の動詞とオブジェクトの領域の間で移動することが可能である。 図３は、オブジェクト'business'（ビジネス）に適用される動詞'set up'（設 定）を含んでいる仮想上のタスク・プロセスのスクリーン・ディスプレイを示す 図である。タスクの必要なすべての構成プロセスを含めるようにモデルを取り扱 うには、カーソルを既存プロセスの左側へ移動し、マウスをクリックするか、キ ーボード上の'return'キーをたたくだけでよい。'set up business'（ビジネス を設定）プロセスのすぐ左側に別のエントリ・ボックス２６′がスクリーンに現 れる。 これはＨＯＷ？モードである。システムは、スタートアップ時にＨＯＷ？モー ドがデフォルトになるように構成されている。ボタンバー２４からＷＨＹ？また はＷＨＡＴ？モードを選択すると、ＨＯＷ？モードから出る。同様に、ボタンバ ー２４からＨＯＷ？を選択すると、ＨＯＷ？モードに入る。 これを受けて、ユーザは基本タスクを実行するときの構成ステップになると思 われる動詞／オブジェクト・プロセスを自由に定義することができる。このケー スでは、予備的プロセスは'build a business plan'（ビジネス・プランを構築 ）になっている。モデルはＨＯＷモードに応答して、スクリーン上を右から左へ 向かって開発されていく。第２ステージからの引き継ぎとして、図４は、タスク ・モデルを開発する際に必要なステップであるとユーザが示した一連のプロセス を示している。ＨＯＷ？モードでは、開発中のタスク・モデルの隣接ステージの 関連ステップは、右から左へ向かうように（つまり、オリジナル・タスク・プロ セスから離れて、初期化するプロセスヘ向かうように）指している矢印と'HOW' という記号でリンクされている。 図に示すように、タスク・モデルの各ステージは並列プロセスの縦方向のカラ ム（列）からなっている。あるステージのすべてのプロセスは、これらがすぐ右 側のステージでリンク（'AND'（かつ）で結ばれている）されていると示されて いるプロセスを達成する上で必要なものと扱われる。ビジネス・プランのセット アップに経験のあるユーザの場合は、ビジネス・プランの各詳細側面の定義は、 定義されるプロセス数が少なくなるまで狭めていくことができるので、ユーザは ビジネス・プランの構築を経験度に応じて管理することができる。経験のある人 は、担当するプロセスに自信があれば、取り扱うステップ数を少なくし、あるい はタスク・ステップにおけるプロセスを詳しく記述しないで済むはずである。も っと多くのガイダンスを必要とするユーザは、投入するステージ数を増やし、プ ロセスを詳細化すると、関係するプロセスの判別が容易化し、実際になにが必要 であり、なにを改良する必要があるかを判断しやすくなる。この例は、図４に示 す追加のプロセスでさらに展開される。 上述したように、ＨＯＷ？の反対はＷＨＹ？である。本発明のシステムによれ ば、ユーザは特定のプロセスから戻るように作業すると、タスク・モデルにおい てそのプロセスが適切かどうかを明確に確かめることができる。タスク・モデル のあるプロセスがなぜそこに置かれているかの、正確な理由にユーザが集中でき るようにすると、モデルを効率化し、タスク向きにすることが容易化される。 図４に示すように、'develop financial plan'（財務計画を開発）というプロ セスがある。ここで、ユーザはボタンバー２４からＷＨＹモードを選択すること ができる。この例でのユーザは逆方向に作業を行い、ＷＨＹ？という質問を尋ね ると、このプロセスの適切性をモデルに合わせて定義することができる。これを 示したのが図６であり、そこでは、'build a business plan'(ビジネス・プラン を構築)と'secure finances'(資金を確保)の基本タスク・プロセスが示されてい る。この場合も、ブランク・エントリ・ボックスが現れて、モデルに組み入れよ うとしているプロセスの理由を考慮するようにユーザに要求する。 同じタスク・ステージでエントリ・ボックスを追加するには、カーソルを下方 に動かし、マウスをクリックするか、キーボード上の“ＴＡＢ”キーをたたくと 、新しいブランク・エントリ・ボックスが呼び出される。これらのプロセスは、 プロセス'develop a financial plan"（財務計画を開発）の存在を正当化（また はその逆）するのに役立つ。正当化は、質問ＷＨＹ？に対する追加の返答に付加 された重みと関連づけられる。従って、カーソルをプロセスに対して移動すると 、質問ＨＯＷ？とＷＨＹ？がアドレスされるので、複数のプロセスを特定のタス ク・ステージに組み入れることができる。 モデルのいずれかのステージで、プロセスのオブジェクトをもっと具体的に定 義する必要が起こることがある。図６は、カーソルを特定のプロセスの上に置い てボタンバー２４からＷＨＡＴ？アイコンを選択したとき生成されるオンスクリ ーン・ディスプレイを示したものである。このケースでは、プロセスはプロダク トの概念を確立するためのものである。ＷＨＡＴ？ウィンドウをタスク・モデル ・スクリーンの上にオーバーレイさせると、ユーザはオブジェクトのリスト（こ のケースでは、問題のプロセスが関係するプロダクト概念）をキーボードから入 力することが可能になる。従って、同一オブジェクト定義のもとに異なるア イテムを指定する必要のある、タスクのプロセスについては、システムは、関係 アイテムを追加または削除できる、オプションのインベントリを提供するように 構成されている。ＷＨＡＴ？ウィンドウには、図７に示すように関連のツールバ ーがある。ツールバー３４はツールボタン群からなり、これらは下述するように 個々の機能をアクチベートさせるものである。ツールバーは、ツール・アイコン ３２上でクリックし、ボタンを上下させると、オープンし、クローズする。 ＷＨＡＴ？照会の結果としてインベントリに入れられたアイテムは、いずれも 、別のＷＨＡＴ？照会の対象にすることができる。図８は、インベントリ"WHAT PRODUCT CONCEPT"(製品コンセプトは何？)内の"talking tree"（話せる木）オブ ジェクト・アイテムと関係づけて、これを示したものである。 "talking tree"の下にインデントされたサブアイテム・リストは言語のインベン トリを列挙している。インデントされたリストは、Tool Bar（ツール・バー）の What 38とNot What 40上でクリックすると、オープンまたはクローズする。 ＷＨＡＴ？リストは、ユーザが必要とするレベル数までインデントすることが できる。図９は、"Talking Tree"（話せる木）オブジェクトの"French"(フラン グ語)オブジェクトを示し、これを展開すると、現在入力されているフランス語 の方言４２が表示される。 図９に示すインデントされたリストのほかに、ユーザは、図１０に示すように ＷＨＡＴ？リスト内の特定のオブジェクト層に集中することができる。あるオブ ジェクトとその細分化されたものに集中するには、ユーザはリスト内の必要とす るオブジェクト（この例では、"Talking Tree"）までカーソルを移動し、Focus ボタン４８上でクリックする。ＷＨＡＴ？ウィンドウが再表示され、"What Talk ing Tree"（話せる木は何？）はタイトルバー４６に置かれ、オブジェクトとイ ンデントしたオブジェクトのリストは"Talking Tree"４４の細分に限定されてい る。 ユーザは、オブジェクトをオブジェクト・インベントリからプロセス選択フイ ールド(Process Selection Field‐PSF)へプロモートすることにより、プロセス ・モデルのコンテキストを変更することができる。これを行うには、ユー ザはＰＳＦセレクションをもつプロセスの左側に表示されている、すべての情報 のコンテキストを変更する。ＰＳＦセレクションの例は図１１に示されているが 、そこでは、"Talking Tree"がＰＳＦ５２へプロモートされている。ユーザは、 必要とするオブジェクト５０をハイライトにし、ツール・バー(Tool Bar)のSele ct（選択）ボタン５４上でクリックすることによりオブジェクトをＰＳＦへプロ モートする。ユーザがDe-Select(選択解除)ボタン５６上でクリックすると、オ ブジェクト・コンテキストがＰＳＦから除去される。 オブジェクト・コンテキストがプロセスＰＳＦコントロールを使用して変更さ れると、ＷＨＡＴ？のインベントリが表示される。図１２は、プロセス"Establi sh Product Concept"（プロダクト概念の確立）のＰＳＦへプロモートされたオ ブジェクト"Electric Car"（電気自動車）を示している。プロセス"Identify Re quirements"(要件を特定)でオープンされたＷＨＡＴ？ディスプレイは、"Produc t Concept" "Electric Car"に関係する"Requirements"（要件）のインベントリ( inventory)を示している。 プロセスのＰＳＦが右側にあるとき表示されるオブジェクト・インベントリは 、オブジェクト階層でＰＳＦオブジェクトよりも上位にあるオブジェクトのオブ ジェクト・インベントリにも従属している。この振舞い（作用）はオブジェクト 継承(Object Inheritance)であり、図１３と図１４に示されている。図１３に示 すように、オブジェクト"Financial Support"(財務援助)はプロセス"Identify R equirements"(要件を特定)のインベントリに入力され、右側のプロセスはＰＳＦ セレクションがない"Establish Product Concept"（製品コンセプトを確立）６ ４になっている。従って、"Requirements"（要件）の"Financial Support"（財 務援助）は"Product Concept"(製品コンセプトおよび"Product Concept"（製品 のコンセプト）に対するオブジェクトの完全インベントリと関連づけられている 。図１４は、"Establish Product Concept"のＰＳＦへプロモ連トされた"Electi rc Car"を示しており、図１２に最初に示したように、"Product Concept" "Elec tric Car"に関連するプロセス"Identify Requirements"の関連ＷＨＡＴ？はイン ベントリの一部として"Financial Support"を含んでいるが、これは、"Financia l Support"が"Product Concept" から継承されたためである（"Electric Car"は"Product Concept"のＷＨＡＴ？ のインベントリの一部である）。 オブジェクトのインベントリ内のすべてのオブジェクトは、コンテキストに関 係なく、ＷＨＡＴ？ディスプレイをＡ１１モードにセットすると、表示すること が可能である。図１５は、Ａ１１モードにあるプロセス"Identify Requirements "（要件を特定）のＷＨＡＴ？インベントリを示す図であり、インベントリに存 在するオブジェクトのすべてをコンテキストに関係なく示している。ＷＨＡＴ？ ディスプレイを通常モードからＡ１１モードに変更するには、ユーザはツール・ バーのボタン７０上でクリックする。ＷＨＡＴ？ディスプレイを通常（非Ａ１１ ）モードで再表示するには、同じＡ１１ボタン７０をクリックする（上げる）。 ＷＨＡＴ？ディスプレイがＡ１１モードになると、ディスプレイ内の各オブジェ クトの右側のボックス・アイコンは、オブジェクトが右側のプロセスと関係（コ ンテキスト）があるかどうかを示している。コンテキストがあるオブジェクトは ボックス７２にチェックがあり、コンテキストのないオブジェクトはボックス７ ４にチェックがない。 ユーザは、Ａ１１モードSelectとDe-Selectを使用すると、オブジェクトと右 側のプロセスとの関係を作成し、あるいは削除することができる。Ａ１１モード SelectとDe-Selectは図１６と１７に示されている。図１６に示す"Requirement" "Aluminium Body"（アルミ・ボディ）は、オブジェクト"Aluminium Body"をハ イライトにし、ツール・バーのDe-Selectボタン７８をクリツクすると、"Produc t Concept" "Electric Car"との関係から除去される。"Requirement" "Energy S hortage"（エネルギ不足）は、オブジェクト"Energy Shortage"をハイライトに し、ツール・バーのSelectボタン７６をクリックすると、"Product Concept" "E lectric Car"との関係に入る。図１７は、上記の関係変更の結果を示したもので ある。"Identity Requirements"のＷＨＡＴ？ディスプレイは、ツール・バーの ボタン８６をクリックし、持ち上げることにより通常モードに変更されて、"Req uirement" "Aluminium Body"はインベントリに表示されなくなるのに対し、"Req uirement" "Energy Shortage"はインベントリに表示されている。 関係がプロセスおよび／または右側のプロセスＰＳＦセクションに依存するこ とは合成(Compounding)と呼ばれる。合成は、Ｈｏｗモードでプロセス・モデル を左へ移動していくと続けられる。図１８は、さらに左への合成を示している。 プロセス"Establish Product Concept"は"Electric Car"がＰＳＦへプロモート されている。プロセス"Identity Requirements"は"Energy Shortage"がＰＳＦへ プロモートされている。Ｗは"Electric Car Energy Shortage"９２のように合成 されている。"Identify Requirements"の左側のプロセス"Assess Probability" （可能性をアクセス）はＰＳＦセレクションと"60%"のＷＨＡＴ？インベントリ をもっている。このことは、"Electric Car Energy Shortage"（電気自動車「エ ネルギー不足」）が"Probability"（可能性）"60%"をもち、"Probability" "60% "が"Energy Shortage"と合成され、"Energy Shortage"が"Electric Car"と合成 されていることを示している。 合成は、プロセスでチェインブレークすると中止することができる。プロセス がチェインブレーク(chain-break)であるときは、これは、左側の別の依存関係 がそのプロセスから合成を開始することを意味する。図１８と図１９はチェイン ブレークと通常プロセスを示している。プロセスをチェイン・ブレークにセット するには、通常(Normal)ボタン８８をクリックするか、あるいは押す。ボタン８ ８はチェインブレーク(chain-break)というワードを表示する。チェインブレー ク・プロセスを通常(Normal)に戻すには、同じボタン（現在Chain-breakという ワード９４を表示している）を押すと、ボタンはNormalというワードを表示する 。ボタン８８／９４は、各プロセスごとにそれがプロセス・モデルの中で選択さ れると、プロセスでどちらのモードがセットされているかに応じて、Chain-brea kまたはNormalを表示する。図１９はチェインブレークとセットされたプロセス" Assess Probability"（可能性をアクセス）を示し、ＰＳＦエントリと"30%"のＷ ＨＡＴ？インベントリをもつプロセス"Assess Probability"を示している。この ような（チェインブレーク）状況の下では、"Probability"(可能性)"30%"は、プ ロセス"Establish Product Concept"(製品コンセプトを確立)でどのようなコン テキストがセットされているかに関係なく、"Requirements"（要件）"Energy Sh ortage"（エネルギー不足）と関連づけられている。 ＰＳＦセレクションをもつプロセスは、そのＰＳＦセレクションをもつプロセ スとだけ関係づけられたＨｏｗ？とＷｈｙ？プロセス関係をもつことができる。 図２０はＨｏｗプロセス関係をもつＰＳＦプロセスを示している。プロセス"Ide ntify Climate Changes"（気候変化を特定）１００は、オブジェクト"Energy Sh ortage"が選択されて"Identify Requirements"１０２のＰＳＦに入れられたとき だけ、"Identify Requirements"のＨｏｗ？になっている。図２１は、Ｗｈｙ？ プロセス関係をもつＰＳＦプロセスを示している。プロセス"Manage Finances" （資金を管理）は、オブジェクト"Financial"（財務）が選択されて"Manage Act ions"（活動を管理）のＰＳＦに入れられたときだけ、"Manage Actions"のＷｈ ｙ？になっている。なお、継承はプロセス関係にも適用される。図２０において 、プロセス"Assess Probability"がＰＳＦセレクションをもつプロセス"Identif y Requirements"のＨｏｗ？のままになっているのは、プロセス"Assess Probabi lityがプロセス"Identify Requirements"と関連づけられ、ＰＳＦセレクション" Energy Shortage"がプロセス"Identify Requirements"のインベントリの一部に なっているためである。 Ｉｎｆｏボタンを選択すると、情報ウィンドウが生成され、そこでは、行見出 し(row headings)は情報テンプレートの場合と同様に、現プロセスのサブオブジ ェクトのそれになっている。しかし、列見出し(column heading)は、現プロセス より下位の（左側の）ステージの構成プロセスのオブジェクトから自動的に派生 される。関連プロセスが追加または削除されると、情報ウィンドウ内の列はそれ に応じて変化する。プロセスがモデルに追加されると、特定プロセスの情報ウィ ンドウは自動的に列見出しを生成し、これは、Ｈｏｗ？方向に沿った次のモデル ・ステージの構成関連プロセスのオブジェクト・ワードから取り出される。これ により、プロセスのステータスを表形式で表わしたものを呼び出すことができる ので、そこで、先行プロセス・オブジェクトのステータスをレイアウトすること ができる。図２２は、プロセスと情報ウィンドウの列見出しとの関係を示す図で ある。 必要とするオブジェクトを選択すると、関係の情報ウィンドウが表示される。 明らかなように、ユーザは、プロセス構造と情報ウィンドウを使用して構造をブ レンドすることにより、タスク・モデルを構築することができる。本発明によれ ば、情報ウィンドウに追加された列見出しに対して情報ウィンドウが関連づけら れている構成レベルで、プロセス・ボックスが自動的に作成される。従って、テ ンプレートに追加されたプロセス・オブジェクトはタスク・モデルにプロセス・ ボックスとして現われるが、そこに付加された動詞が脱落している。この脱落し た動詞はユーザのオプションでタスク・モデルに追加することが可能である。ま た、本発明によれば、プロセス・ボックスが表示されたタスク・モデルに現われ るのを望まなければ、テンプレートを通して追加されたプロセス・ボックスを、 ユーザのオプションで削除することが可能である。 システムには、関係する人々のアドレス・リストといったように、いずれかの タスク・モデルと必ずしも関連づけられていない事前に準備したテンプレートを 日常的に使用するように用意しておくことも可能である。例えば、標準プロセス "contact people"（連絡先）は、定期的に連絡する人達に関する基本データをリ ストする情報テンプレートが関連づけられているシステムにインストールするこ とが可能である。ここで注意すべきことは、これは必ずしもタスク・モデルの一 部でないプロセスであるが、独立に呼び出すことができることである。同様に、 日常的な機能を、タスク・モデルまたはプロセスとリンクされていない別ルーチ ンとしてインストールすることも可能である。 タスク・モデルの一部として、また、システムが異なるスキル要件に対して柔 軟性があることを例示するものとして、ボタンバー２４に'Calc'ボタンがあるの で、ユーザは数字を計算するためのプロセスをタスク・モデルに作ることができ る。図２３は、プロセス"Develop Financial Plan"（財務計画を開発）用に計算 が設定されたとき、表示されるタスク・モデルを示す図である。この計算のステ ップはタスク・プロセスとして設定されている。 計算は、タスク・モデルのステップにおいて重要なデータを表わしている。計 算は、図２３に示す関連の情報ウィンドウのオブジェクトに適用される。数値デ ータは、計算の対象となるオブジェクトについて入力され、その結果は、情報ウ ィンドウの'Profit'（利益）行見出しの個所に自動的に表示される。従って、情 報ウィンドウは、情報ウィンドウに表形式で自動的に配列された'Calc'プロセ スに対して、スプレッドシート計算を行う機能を備えている。計算は、情報ウィ ンドウ内の行、列、および特定のセルに対して行なうことができる。さらに、ユ ーザは、事前定義した数値および会計関数(financeial function)の中から選択 して、計算の中で使用することが可能である。 タスク・モデルを詳細に見直したり、全体を概観するために、OPTIONSメニュ ー・アイテムにはFEEDBACK（フィードバック）があり、これを選択すると、タス ク・モデルの詳細フィードバックまたは概要フィードバックのどちらかを選択す ることができる。詳細ビューによると、タスク・モデルの完全性とロジックにつ いて診断することができ、タスクのプロセスをハイライトした時間ベース経過セ クションがあり、そこでは、アクション・ウィンドウの日付ベースの目標と共に 、期日(due date)が設定されていなかったか、期日を経過したかが示されている 。詳細フィードバック・モードで比較を呼び出すと、ターゲットが設定された目 標の実際の達成度を知ることもできる。 概観モードでは、フィードバックは、メニュー・バー２２からOPTIONSメニュ ー・アイテムを選択すると、図２４に示すように表示される。各プロセスには、 赤の三角形の注釈が付けられ、プロセス実行の困難度が数字で示されている。こ の数字は、例えば、０から９９までの適当な範囲から割り当てることができる。 数字が大きくなると、特定プロセスに関連する困難度が大になる。リストされた プロセスのいずれについても、システムがモデル全体を調べていくとき、重み付 けがシステムによって使用される。見つかった各条件のインスタンスの数にこの 重み付けをかけて、その条件の合計スコアが求められる。ユーザがフィードバッ クに詳細モードを選択していれば、情報はユーザ条件について条件別に表示され る。概観モードでは、三角形が表示されて、プロセスのすべての条件の合計が０ から９９までの数字になるように計算される。 モデルはブランク・スクリーンからユーザによって作ることができるが、公知 のタスクや特定されたタスクについては、事前に書かれたモデルをシステムにロ ードすることも可能である。これはシステムの一部として得ることも、既存シス テムにロードされる別ファイルとして得ることも可能である。 理解されるように、同じタスク・ステージでの並列プロセスは'AND'というワ ードでリンクされており、これはロジカル（論理）ＡＮＤであり、そのステージ のすべてのプロセスが満足されてから、右側の上にある、次のステージの関連プ ロセスが完成できることを示している。もちろん、ロジカルＡＮＤをロジカルＯ ＲまたはＴＨＥＮに置き換えて、それぞれ選択プロセスまたは順次プロセスを示 すことも可能である。 特定のユーザは、種々のキー・オブジェクトや動詞ワードおよびフレーズを異 なるタスク・モデルの中で再使用することが起こり得る。システムは、そのよう なワードとフレーズをすべて維持していて、ディクショナリから取り出せるよう にしている。オブジェクト・ディクショナリは、サブオブジェクトがあればそれ らと一緒に、すべてのオブジェクトの記録をとっている。オブジェクトは多数の 異なるモデルの中に存在することができ、モデル内で異なるレベルで存在するこ とができる。従って、ある特定のオブジェクトが使用されると、後続のＨＯＷ？ ステップは最高レベルからのステップ、つまり、モデル化している基本タスク・ プロセスに最寄りのステップになる。これは計算にも適用されるので、一度だけ 定義しておけば、異なるモデルの中で、あるいは同じモデルの異なる部分の中で 再使用することができる。その結果として、あるオブジェクトに関連づけられた 情報やテキストは、そのオブジェクトがタスク・モデルの中で再使用されている 個所と関連づけて、あるいはオブジェクトがあとで表示される任意のタスク・モ デルと関連づけて、取り出すことが可能になる。以上のように、本発明によると 、モデル間の相互参照データベース(cross referenced database)を得ることが できる。 動詞ディクショナリは、すべての動詞と動詞がその中で使用されるプロセスの 記録をとっている。プロセス・ディクショナリはすべてのプロセスとプロセスが 使用されている場所の記録をとっている。 ロードされたタスク・モデルを変更するには、モデルのステージで変更を行お うとする位置までカーソルを移動する。変更としては、ステップを追加する場合 と、すでにモデルに存在するステップを補足する場合とがある。後者の場合は、 補足ステップを置こうとしている、モデルの既存ステップの下の縦方向のエ リア内にカーソルを移動する。図２５に示すように、プロセス"achieve sales t arget"(売上げ目標を達成)がタスク・モデルに追加されている。このケースでは 、この新プロセスに従属する他の種々オブジェクトも、ＨＯＷ？モードによって 追加されており、各ステージでの並列プロセスは上述したように、カーソルを下 方向に移動することにより追加される。参照ディクショナリにエントリがあるタ スク・モデルにプロセスを挿入する必要が起こった場合は、これらのプロセスも 自動的に追加するようにシステムを構成することが可能である。 図１７のエンティティ関係図および付録ＡとＢを参照して、ソース・コードの 抜粋と関連付けながら本発明について説明することにする。 付録Ａは、ディスプレイ（Ｗｈａｔ，Ｈｏｗ，Ｗｈｙウィンドウ）上の移動を 管理するＣ++クラスである。付録Ｂは、第１次オブジェクトと第２次オブジェク トを作成するＣ++クラスである。これらの付録は、データ構造と関連処理から見 た論理設計の基本原理を示している。001 第１次と第２次の関係 １．第１次関係は、任意のプロセスOBJECTとその直接のHOWプロセスの各々との 関係を示し、ストアするために使用される。 ２．第２次関係は、あるプロセスのすべての第１次関係の集合を示し、ストアす るために使用される。また、情報ウィンドウとしては、タスク・モデルの一部を 表示する別の方法となるだけである。 ３．情報ウィンドウ内の行(row)は第２次関係である。 ４．情報ウィンドウ内の各列(column)は、その列と左端の列との第１次関係であ る（WHATリスト）。 005 プロセス １．プロセスは動詞フレーズと名詞フレーズとして捕獲される。 ２．動詞フレーズをOBJECTCATEGORYのOBJECT（第２次）として、またユーザが入 力したテキストをOBJECT TEXTインスタンスとしてストアする。 ３．名詞フレーズをCATEGORYのOBJECT（オブジェクト・プリミティブ）としてス トアする。このOBJECT PRIMITIVEのOBJECT TEXTインスタンスを作成して、ユー ザが入力したテキストをストアできるようにする。 ４．CATEGORYのOBJECT（第２次）を作成し、これを上記２で定義したOBJECTの子 として、OBJECT INHERITANCE（オブジェクト継承）関係を用いて結合する。 ５．CATEGORYのOBJECT（第１次）を作成し、これと上記３で作成した名詞フレー ズとのOBJECT ASSOCIATION（オブジェクト関連）を作成する。 ６．最後に、上記４と５で作成したOBJECT間の関係を、OBJECT ASSOCIATIONエン ティティを用いて作成する。 010 HOW コネクション HOWプロセスがユーザによって入力されると、そのプロセスについて005を実行 し、次に、HOWコネクション（結合）を次のように行う。 １．OBJECT（第１次）を作成する。これと以下のものとの間は、別々のOBJECT A SSOCIATIONを有する。（1）このHOWプロセス（子プロセス）の 005/4OBJECT（2）HOWプロセスを結合しようとするプロセス（親プロセス）の005 /3OBJECT ２．010/1を親プロセスの005/4と結合する。 ３．これが最初のHOWプロセスでなければ、結合ロジック、つまり、AND、OR、TH EN (AOT)がユーザによって入力されている。010/1 OBJECTのOBJECT CHARACTERIS TICS（AOT）を作成して結合子をストアする。 020 WHY コネクション WHYコネクションはHOWコネクションを逆方向から見たものである。従って、ま ず、ユーザが入力したWHYプロセスについて005を実行する。次に、010を実行す るが、ユーザが入力したプロセスを親プロセスとして使用し、現プロセスを子プ ロセスとして使用して実行する。 030 WHATリスト オブジェクトがユーザによってWHATリストに追加されたときは、 １．入力された名詞フレーズについてOBJECT(PRIMITIVE OBJECT)を作成する。こ れは005/3と同じルーチンである。 ２．030/1とのOBJECT INHERITANCE関係を子として作成し、WHAT IS OBJECTを親 として作成する。 ３．入力されたOBJECTをWHATコマンドを使用してさらに細分化する場合は、030/ 1とでさらにOBJECT INHERITANCE関係を親として、追加のOBJECTSを子として作成 する。 ４．ユーザが入力した別の細分については、以下同様。 040 THENロジックの影響 定義010と020はユーザが結合子ANDまたはORを入力したとき適用される。しかし 、THEN結合子が入力されたときはロジックは若干異なる。その違いは次のとおり である。 １．010/1（1）で定義された0BJECTは、010/1で作成されたオブジェクトで置き 換えられる。情報ウィンドウ 050 情報ウィンドウの表示 情報ウィンドウは、Ｙ軸（行）を表すWHATリストを延長したものである。Ｘ軸 （列）はシステムによって設定されたデフォルトとして作成されるか、ユーザに よる明示の指示に従って作成される（出力の定義を参照）。デフォルトの情報ウ ィンドウは次のように計算される。 １．現プロセスのOBJECT（第２次）を取り出す。 ２．050/1の005/3を取り出す。 ３．050/3のOBJECTINHERITANCE関係を調べ、各インスタンスをWHATリストとして 表示する。 ４．次に、050/1のOBJECT ASSOCIATIONSを調べて、050/1が関連づけられている 各0BJECT（第１次）を見つける。 ５．見つかった各OBJECT（第１次）ごとに、OBJECT ASSOCIATESをもう一度調べ て010/1（1）OBJECTを見つける。 ６．CATEGORY（第２次）に属する各010/1（1）OBJECTごとに、OBJECT ASSOCIATI ONをもう一度調べて005/5OBJECTを見つける。各005/5OBJECTごとに、OBJECT ASS OCIATIONをもう一度調べて005/3OBJECTを見つける。このOBJECTとその関連OBJEC T TEXTインスタンスは列見出しを表している。 060 出力の定義 ユーザは出力定義関数を使用すると、デフォルト情報ウィンドウをオーバライ ドすることができる。 １．デフォルト列の削除が示されていれば、該当のCHARACTERISTICS（特性）イ ンスタンスを作成することにより、データ構造内でこれにフラグを付ける。 ２．追加の列が示されていれば、CATEGORYのOBJECT（OBJECT PRIMITIVE）として 入力されたテキストを005/3と同じようにストアする。 ３．これらの追加列について、010/1（1）OBJECTが上記060/2で作成されたOBJEC Tで置き換えられることを除き、010/1と同じようにOBJECT（第１次）も作成する 。 注意：このユーザ定義列オブジェクトがHOWプロセスでなく、かつ表示しない ことを指示するにはCHARACTERISTICSを使用する。 070 行 左端列は現プロセスのWHATリストであり、定義030が適用される。ユーザが列 エントリを作る行について、次のことを行う。 １．ユーザがこの行に到達するまでたどっていったWHAT階層の各レベルごとにOB JECT（第１次）を作成する。 ２．これらの第１次の各々ついて、第１次と次のものとの間の別々のOBJECT ASS OCIATIONSを作成する。 (1) 行の030/1 OBJECT (2) 上のレベルで作成された070/2 OBJECT。 上のレベルがプロセス・オブジェクトであれば、該当の005/3 OBJECTを使用す る。 ３．最下位レベルの070/1 0BJECT（必要とする行）はその行のプロセス・オブジ ェクト、つまり、合成オブジェクトを表している。 ４．次に、行のOBJECT（第２次）を作成し、これと070/3との間のOBJECT ASSOCI ATIONを作成する。 ５．次に、この第２次と現プロセスの005/4との間のOBJECT INHERITANCEインス タンスを作成する。 ６．ユーザが作ろうとしている列エントリについて、カーディナリティ‐080を チェックする。 ７．各列エントリについて、まだ存在していなければOBJECT（PRIMITIVE OBJECT ）を作成し、列エントリとのOBJECT INHERITANCE関係を子として、列見出しとの 関係を親として作成する。 ８．次に、各列エントリについて、OBJECT（第１次）を作成し、これと次のもの との間の別々のOBJECT ASSOCIATIONを作成する。 (1) 070/7 (2) 070/3 ９．070/8を070/4に結合する。 075 タスク・モデル・ウィンドウ内の行の選択 ユーザは情報ウィンドウを使用すると行を作成することもできる。行は親プロ セスおよびその近親のHOWプロセスと等価である。Sub object（サブオブジェク ト）を選択してプロセス選択フィールドに入れることは、関連情報ウィンドウ内 の該当列に入れることとまったく同じである。 078 WHATとSELECTの比較 WHATコマンドは、OBJECT INHERITANCE構造を徐々に詳細化するレベルまでたど っていくために使用される。必要とするOBJECTが判別されると、SELECTコマンド は、そのOBJECTとOBJECT INHERITANCEネットワーク内の関係する「子」が現在の 関係に結合されたことを示している。070と075に関しては、これは行内の列とプ ロセス選択フィールドに適用される。 080 カーディナリティ(Cardinality) 出力定義ウィンドウを使用すると、ユーザはカーディナリティを定義すること ができる。最小関係と最大関係の指定が許される。これらの各々は、1:nの形式 で指定する。ただし、ｎは整数または'many'のワードである。最小関係を指定す ると、ユーザは列を必須または任意として指定することができる。また、ユーザ は、列エントリが列見出しのサブオブジェクトとして存在しなければならないこ とを指定することもできる。 ユーザが論理結合子にONLYを指定していれば（CHARACTERISTICとしてストアさ れている）、この結合子の両辺のプロセスは相互排他的であり、この結合子の両 辺のエントリは、同一列内では、禁止しなければならない。 090 構造シーケンス データベースへ入力する順序は次の場合には重要である。 １．OBJECT INHERITANCEでは、順序はユーザ入力順序を反映していなければなら ない。 ２．OBJECT ASSOCIATIONでは、ルーチン050と070で使用されるときは、列と関連 行エントリ間の順序は、関連のOBJECT INHERITANCEをたどっていくとき保たれて いなければならない。 ボタン・バー２４はハッピ・フェース（喜んでいる顔）とサッド・フェース（ 悲しんでいる顔）の２つのシンボルももっている。これらは、ユーザが判別され たプロセスに自信があるか否かを示すようにタスク・モデルがセットアップされ るとき使用することができる。これらのフェースは、マウスで選択したときスク リーン上のどこにでも「ドラッグ」することができる。システムは、一時的表示 を目的に基本タスク・モデルにオーバーレイする動詞／オブジェクト・プロセル およびウィンドウ・フィールドをもつオンスクリーン・ディスプレイを中心にし て説明されているが、タスク・モデルの他の構成および配置が可能であることも もちろんである。例えば、タスク・モデルのプロセス・ステップをディスプレイ の上下に進めていくことが可能である。日々の日記のように、他の周辺機能をシ ステムに含めることも可能である。日記をシステム上の１つまたは２つ以上のモ デルのプロセスにリンク可能にすると、日記に記載したイベントを使用して、例 えば、デッドラインが近づいたことをユーザに警告することができる。同様に、 システムには、電話、ファックスおよびアドレス・リスト・テンプレートがプリ インストールされているので、カーソルが'contact people'（人物と連絡）プロ セスを示すボックス内に置かれているときにアクションボタンを選択することに より、標準プロセス'contact people'からアクセスすることができる。テンプレ ートが現れているとき、該当する人または企業までスクロールすることができる 。アクションボタンを再度選択すると、関係の詳細を記載した入力テンプレート が現れることになる。 法の規定に従って、構造上および機能上の特徴に関して多少でも分かりやすく 本発明を説明してきたが、本発明は上述した特定の特徴に限定されないことはも ちろんである。これまでに開示してきた構造の手段と方法は、本発明を実施する ときの好適な実施態様を示したにすぎない。この分野の当業者ならば理解される ように、装置および方法は他の改良および他の変形形態も可能である。従って、 上述してきた説明は単なる例示であり、それに限定されるものではない。本発明 は種々の形態または改良形態で請求の範囲に明確化されているが、その合法的か つ有効な範囲は均等論に従って正しく解釈されるものである。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＭＷ，ＳＤ，ＳＺ)，ＡＭ， ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，Ｃ Ｎ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ ，ＨＵ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ， ＬＲ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＮ，ＭＷ，Ｎ Ｌ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ ，ＳＩ，ＳＫ，ＴＪ，ＴＴ，ＵＡ，ＵＳ，ＵＺ，ＶＮ

Claims (1)

1. 【特許請求の範囲】 １．タスクを実行するためのプロセス構造を作成するシステムであって、該シス テムは、 コンピューティング・デバイスと、 コンピューティング・デバイスによってアクセス可能であるデータをストアし ているデータ・ストレージ手段と、 コンピューティング・デバイスに接続されていてデータを入力する手段と、 同じくコンピューティング・デバイスに接続されていてデータを表示するディス プレイ手段とを備えており、コンピューティング・デバイスは、少なくとも１つ の動詞ワードと少なくとも１つのオブジェクト・ワードを含んでいる第１プロセ ス定義をデータ入力手段を通してユーザから受け取るように構成され、該プロセ ス定義はタスクまたはタスクのステップを定義しており、コンピューティング・ デバイスは、さらに、第１プロセス定義を受け取ったときの応答として、第１プ ロセス定義を実行すると予想される結果となる第２プロセス定義をデータ入力手 段から入力することをユーザに要求するように構成されていることを特徴とする システム。 ２．コンピューティング・デバイスは、プロセス定義のディスプレイをディスプ レイ手段上に生成するように動作可能であり、タスクのステップの１つにおける プロセス定義は行に配列され、ステップにおけるプロセス定義の行はディスプレ イ手段を横切って進行していくことを特徴とする請求項１に記載のシステム。 ３．タスクのステップの進行はディスプレイ手段上を水平方向にわたっているこ とを特徴とする請求項２に記載のシステム。 ４．ステップは左から右へ進行していくことを特徴とする請求項３に記載のシス テム。 ５．データ入力手段はキーボードを含むことを特徴とする請求項１に記載のシス テム。 ６．タスクを実行するためのプロセス構造を作成するシステムであって、該シス テムは、 コンピューティング・デバイスと、 コンピューティング・デバイスによってアクセス可能なデータをストアしてい るデータ・ストレージ手段と、 コンピューティング・デバイスに接続されていてデータを入力する手段と、 同じくコンピューティング・デバイスに接続されていてデータを表示するディ スプレイ手段とを備えており、コンピューティング・デバイスは、少なくとも１ つの動詞ワードと少なくとも１つのオブジェクト・ワードを含んでいる第１プロ セス定義をデータ入力手段を通してユーザから受け取るように構成され、該プロ セス定義はタスクまたはタスクのステップを定義しており、コンピューティング ・デバイスは、さらに、第１プロセス定義を実行するとき予想される構成ステッ プとなる第２プロセス定義を入力することをユーザに要求するように構成されて いることを特徴とするシステム。 ７．コンピューティング・デバイスは、プロセス定義のディスプレイをディスプ レイ手段上に生成するように動作可能であり、タスクのステップの１つにおける プロセス定義は行に配列され、ステップにおけるプロセス定義の行はディスプレ イ手段を横切って進行していくことを特徴とする請求項６に記載のシステム。 ８．タスクのステップの進行はディスプレイ手段上を水平方向にわたっているこ とを特徴とする請求項７に記載のシステム。 ９．ステップは左から右へ進行していくことを特徴とする請求項８に記載のシス テム。 １０．コンピューティング・デバイスは、あらかじめ決められたプロセス定義を データ・ストレージ手段から取り出すように構成され、該プロセス定義は、ユー ザによってキーボードから入力された第２プロセス定義を実行するときの構成ス テップであることを特徴とする請求項６に記載のシステム。 １１．タスクを実行するためのプロセス構造を作成するシステムであって、該シ ステムは、 コンピューティング・デバイスと、 コンピューティング・デバイスによってアクセス可能なデータをストアしてい るデータ・ストレージ手段と、 コンピューティング・デバイスに接続されていてデータを入力する手段と、 同じくコンピューティング・デバイスに接続されていてデータを表示するディ スプレイ手段とを備えており、コンピューティング・デバイスは、少なくとも１ つの動詞ワードと少なくとも１つのオブジェクト・ワードを含んでいる第１プロ セス定義をデータ入力手段を通してユーザから受け取るように構成され、該プロ セス定義はタスクまたはタスクのステップを定義しており、コンピューティング ・デバイスは、さらに、第１プロセス定義のオブジェクト・ワードの意味の範囲 に人る特定のオブジェクトを指定することをユーザに要求するように構成されて いることを特徴とするシステム。 １２．コンピューティング・デバイスはデータ入力手段から入力されたコマンド を受けると、その応答として、第１プロセス定義の少なくとも１つのオブジェク ト・ワードの意味の範囲に入るオブジェクト・ワードに関連する検索可能データ ・ディスプレイを作成することを特徴とする請求項１１に記載のシステム。 １３．データ・ディスプレイは表形式であり、コンピューティング・デバイスは 、データ入力手段からコマンドを受けたとき、その応答として、ディスプレイ手 段上のプロセス定義にデータ・ディスプレイをオーバライトするように構成され ていることを特徴とする請求項１２に記載のシステム。 １４．タスクを実行するためのプロセス構造をモデル化するシステムであって、 該システムは、 コンピューティング手段と、 コンピューティング手段によってアクセス可能であるデータ・ストレージ手段 と、 コンピューティング手段に接続されていてデータを入力する手段と、 同じくコンピューティング手段に接続されていて、プロンプトと、入力手段か らおよびコンピューティング手段から入力されたデータを表示するディスプレイ 手段とを備えており、コンピューティング手段は、ユーザによってデータ入力手 段から入力された第１プロセス定義を求めるプロンプトをディスプレイ手段から 選択的に表示して、少なくとも１つの動詞ワードと少なくとも１つのオブジェク ト・ワードを要求するように構成されていると共に、第１プロセス定義を実行す ると予想される結果となる、あるいは第１プロセス定義を実行してタスク・プロ セス構造内の一連のステージを作成するときに予想される構成ステップとなる第 ２プロセス定義を入力することをユーザに要求する、コンピューティング手段か らの別の入力プロンプトを選択することをユーザに要求するようにあるいは第１ プロセス定義のオブジェクトの意味の範囲に入る特定のオブジェクト・ワード（ １つまたは複数）を指定することをユーザに要求するように構成されており、コ ンピューティング手段は、さらに、１つのステージでの１つのプロセスに関連す る検索可能な表形式データ・ディスプレイを作成するように動作可能であり、そ こでは、前記１つのプロセス定義の前のステージにおける構成プロセス定義のオ ブジェクト・ワード（１つまたは複数）は、列見出しとして配列され、該１つの プロセス定義の特定のオブジェクトは、行見出しとして配列されていることを特 徴とするシステム。 １５．タスクを実行するためのプロセス構造をコンピュータ上で作成する方法で あって、該方法は、 少なくとも１つの動詞ワードと少なくとも１つのオブジェクト・ワードを含ん でいる第１プロセス定義を入力するステップであって、該第１プロセス定義はタ スクまたはタスクのステップを定義しているものと、 第１プロセス定義を実行すると予想される結果となる第２プロセス定義を入力 することをユーザに要求するステップとを含むことを特徴とする方法。 １６．プロセス定義のディスプレイをディスプレイ手段上に生成するステップを 含み、タスクのステップの１つにおけるプロセス定義は行に配列され、ステップ におけるプロセス定義の行はディスプレイ手段を横切って進行していくことを特 徴とする請求項１５に記載の方法。 １７．タスクのステップはスクリーン上を水平方向に進行していくことを特徴と する請求項１６に記載の方法。 １８．ステップは左から右へ進行していくことを特徴とする請求項１７に記載の 方法。 １９．タスクを実行するためのプロセス構造をコンピュータ上で作成する方法で あって、該方法は、 少なくとも１つの動詞ワードと少なくとも１つのオブジェクト・ワードを含ん でいる第１プロセス定義を入力するステップであって、該第１プロセス定義はタ スクまたはタスクのステップを定義しているものと、 第１プロセス定義を実行するとき予想される構成ステップとなる第２プロセス 定義を入力することをユーザに要求するステップとを含むことを特徴とする方法 。 ２０．プロセス定義のディスプレイをディスプレイ手段上に生成するステップを 含み、タスクのステップの１つにおけるプロセス定義は行に配列され、ステップ におけるプロセス定義の行はディスプレイ手段を横切って進行していくことを特 徴とする請求項１９に記載の方法。 ２１．タスクのステップはスクリーン上を水平方向に進行していくことを特徴と する請求項２０に記載の方法。 ２２．ステップは左から右へ進行していくことを特徴とする請求項２１に記載の 方法。 ２３．ユーザによってキーボードから入力された第１プロセス定義を実行すると きの構成ステップとなる、あらかじめ決められたプロセス定義を取り出すステッ プを含むことを特徴とする請求項１９に記載の方法。 ２４．タスクを実行するためのプロセス構造をコンピュータ上で作成する方法で あって、該方法は、 少なくとも１つの動詞ワードと少なくとも１つのオブジェクト・ワードを含ん でいる第１プロセス定義を入力するステップであって、該第１プロセス定義はタ スクまたはタスクのステップを定義しているものと、 特定のオブジェクト・ワードを指定することをユーザに要求するステップであ って、該オブジェクト・ワードは第１プロセス定義のオブジェクト・ワードのイ ンスタンスであることを特徴とする方法。 ２５．データ入力手段から入力されたコマンドを受けると、その応答として、第 １プロセス定義のオブジェクト・ワードのインスタンスであるオブジェクト・ワ ードに関連する検索可能データ・ディスプレイを作成するステップを含むことを 特徴とする請求項２４に記載の方法。 ２６．コンピューティング手段はデータ入力手段から入力されたコマンドを受け ると、その応答として、ディスプレイ手段上のプロセス定義に表形式のデータ・ ディスプレイをオーバライトすることを特徴とする請求項２４に記載の方法。