JP3979504B2 - コモン・プラットフォーム機能による対話的情報処理装置 - Google Patents
コモン・プラットフォーム機能による対話的情報処理装置 Download PDFInfo
- Publication number
- JP3979504B2 JP3979504B2 JP04157295A JP4157295A JP3979504B2 JP 3979504 B2 JP3979504 B2 JP 3979504B2 JP 04157295 A JP04157295 A JP 04157295A JP 4157295 A JP4157295 A JP 4157295A JP 3979504 B2 JP3979504 B2 JP 3979504B2
- Authority
- JP
- Japan
- Prior art keywords
- client
- processing
- server
- window
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/34—Graphical or visual programming
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/451—Execution arrangements for user interfaces
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Human Computer Interaction (AREA)
- Computer And Data Communications (AREA)
- User Interface Of Digital Computer (AREA)
- Information Transfer Between Computers (AREA)
- Multi Processors (AREA)
Description
【０００１】
【産業上の利用分野】
本発明は，クライアントがサーバと対話を行いながら、クライアントの意図にしたがったサービスを実行してゆく場としての各種ウインドウをもつコモン・プラットフォームを用意し、コモン・プラットフォーム内のコミュニケーション・マネージャが上記ウインドウを介在させて上記クライアントと上記サーバとの間でのデータ表記形式などの整合をとるなどの仲介を行うようにしたコモン・プラットフォーム機能による対話的情報処理装置に関する。
【０００２】
【従来の技術】
従来から情報処理装置の画面に向かって対話を行いつつ処理を実行することが行われる。そして、特開昭６３−１３８４３０号公報、特開昭６３−１３８４３１号公報に示すように、システムがオブジェクトや管理プログラムを意識することなく処理を実行するようにすることが知られている。
上記のオブジェクトに注目してプログラムを組立ててゆくことに関しては、一般に、オブジェクト指向と呼ばれている。諸々の処理を実行する上では、高頻度で利用される「処理対象」が存在する。
当該処理対象となるものは、名詞を示すものであったり、動詞を示すものであったり、あるいは処理に際して存在する制約条件であったりする。これらは夫々名詞オブジェクトとか動詞オブジェクトとか制約オブジェクトとかという表現で特定されている。
名詞オブジェクトをノードとし、動詞オブジェクトをあるノードに対して処理を行うブランチとして表すと、ノード間をブランチで結んだ、ひとかたまりの処理単位が成形されて１つのオブジェクト・ネットワークとみなされることもある。そのオブジェクト・ネットワークとしての処理単位も、高頻度で利用されるものであったとすると、例えば所定の処理を実行する単位としての名詞をつけて、名詞オブジェクトとして取り扱われることもあり、１つのオブジェクトとみなされることもある。
名詞オブジェクトや動詞オブジェクトや制約オブジェクトが所望する目的の処理を実行するものとして結合されたものがオブジェクト・ネットワークであって、オブジェクト・ネットワークは一般に多重階層的に把握されるものである。例えばカラー画像生成・色付け処理を行わせるためには、一般には、多くのオブジェクト（更には多くのオブジェクト・ネットワークを含めて）が組合されて、当該カラー画像生成・色付け処理を行うオブジェクト・ネットワークを構成することになる。例えば輪郭を描くためにオブジェクト・ネットワークと色付けをするためのオブジェクト・ネットワークとが組合わされる。夫々のオブジェクト・ネットワーク（即ち、下位階層のオブジェクト・ネットワークを含めて）は、当該オブジェクト・ネットワークに相当する処理を実行するためのプログラムとして、１つまたは複数のサービス・モジュールが対応づけられている。
クライアントの意図に合わせて所望する処理プログラムを形成して処理を実行させてゆくに当たっては、既存のオブジェクト（あるいはオブジェクト・ネットワーク）を当該目的のために組合わさせて、当該所望する処理プログラムが形成されて処理を実行させてゆくようにされる。換言すれば、既存のオブジェクト（あるいはオブジェクト・ネットワーク）に対応する処理を行う既存のサービス・モジュールを目的に合うように組立ててゆくようにする。
夫々のオブジェクト・ネットワークは、下位階層のオブジェクト・ネットワークや個々のオブジェクトが組立てられたものとして定義される。更に言えば、下位階層のオブジェクト・ネットワークに対応するサービス・モジュールが当該オブジェクト・ネットワークに対応する処理のために組立てられていることを示す情報（サービス・モジュール定義）をもって特定される。
【０００３】
ある課題を解決し処理結果を得るためには、好奇心から意図が発生し、その意図を満足させるようなサービス・システムが必要となる。このために図３０のようなクライアント・サーバ間の対話モデルを考えると、意図をグラフ構造によって表現したオブジェクト・ネットワークによって定義することが考えられる。そして、個々の意図が逐次あるいは並行的にサービスを行う対話図式によって、オブジェクト・ネットワークの内容が表現される。
【０００４】
図３０の左側はクライアントであって当該クライアントが行う意図についての内容記述作業を矩形の枠で示し、図示の右側はサーバであって当該サーバが行う処理を矩形の枠で示し、中央部に点線で囲ってディスプレイなどの表示機能を含む表示的プロセスが介在していることを表している。なお、クライアントが行う意図はクライアントからの指示および／またはデータを受取り、システム側において解読される。
【０００５】
クライアントは興味をもったサービス名によって意図として、表示的プロセスにサービスの要求を行う▲１▼。サーバは当該要求に対応して意図実現計画を実行して当該処理の対象となるオブジェクト・ネットワークを呈示する▲２▼。
【０００６】
当該呈示されたオブジェクト・ネットワークを画面でみながら、クライアントは単位意図の選択を行う▲３▼。この選択された単位意図はサーバ側に示されてそのときの処理を実行する上での制約データや条件や処理を実行する関数計画を実行して画面上で呈示する▲４▼。
【０００７】
クライアントは呈示されたデータや条件や関数を選択する▲５▼。サーバ側では選択されたデータや条件や関数にもとづいてサービス機能実行計画を実行してその実行結果を画面上で呈示する▲６▼。クライアントはその実行結果を評価して次の意図選択を行う▲７▼。
【０００８】
上記の如くクライアントおよびサーバが協調して意図を実現する。即ちクライアントは意図を選択する過程でサーバに単位意図を要求する。これに答えてサーバはサービス実行に必要な制約条項を計画し、クライアントに向けて、それの必要性を応答する。このようなインタラクションのための場が対話に有効である。
【０００９】
対話が円滑であるためには、対話プロセス意味論上の結束性が、意図駆動による意図内容の連接的整合性によって表現され、それはオブジェクト・ネットワークの妥当性を保証する。
【００１０】
【発明が解決しようとする課題】
対話プロセスを円滑に進行させるためには、サービス・プロセスに役割を特化させるのが効率的である。人間にとって表現シンボルとしては、画像・図形の方がテキスト文よりも一眼で直観的に理解されるのに対し、計算機は論理的記述が処理し易い。役割は、理解解読機能、実行処理機能などの諸機能、あるいは述語や表現スタイルなどの記述形式によって規定される。
【００１１】
本発明は、各種ウインドウをもつコモン・プラットフォームを用意し、コモン・プラットフォーム内のコミュニケーション・マネージャがクライアントとサーバとの間でのデータ表記形式などの整合をとるようにして、対話を効果的に進めうるようにすることを目的としている。
【００１２】
【課題を解決するための手段】
本発明は、上記の課題を達成するために、コモン・プラットフォームとテンプレートとを用いるようにしており、オブジェクト・ネットワークに対応した処理を実行する１つまたは複数のサービス・モジュールに対応して、当該サービス・モジュールに対して実行を指示しかつ当該実行結果を出力する処理を実行するサーバを１つまたは複数個そなえ、
クライアントからの指示および／または情報を受取って解読し、上記サーバに対して必要な処理の実行を依頼し、かつ当該サーバから受信した当該処理の結果を上記クライアントが識別できる情報として出力する処理を実行するコモン・プラットフォームをそなえた情報処理装置において、
上記コモン・プラットフォーム（２）が、
上記オブジェクト・ネットワーク（１９）に対応した構成と処理項目とを表す可視的表示項目を表示し、かつ上記クライアント（１）からの指示および／または情報が表示されると共に、上記サーバ（３）が実行した結果が表示されるウインドウ（４）、
クライアント（１）からの指示および／または情報にもとづいて選択された結果を、上記サーバ（３）に伝え、かつ当該サーバ（３）を介して上記サービス・モジュールの１つまたは複数個に処理を依頼した処理結果を上記ウインドウ（４）上に可視的に表示せしめるよう構成され、かつ上記サーバ（３）に指示を行って上記クライアント（１）からの指示および／または情報と上記サーバ（３）が送受する情報との間のデータ表記形式の違いについての翻訳を依頼するコミュニケーション・マネージャ（１０）、および
上記ウインドウ（４）上に可視的表示項目を表示する処理を行うディスプレイ・マネージャ（１５）と、上記ディスプレイ・マネージャ（１５）により上記ウインドウ（４）上に表示されている可視的表示項目を選択する処理を行うウインドウ・マネージャ（１４）と、処理を行うサービス・モジュールの処理に対応して関数処理を実行する関数実行マネージャ（１６）と、オブジェクト・ネットワーク（１９）を管理するグラフ構造エディタ（１３）と、上記コミュニケーション・マネージャ（１０）を介して変換された情報に基づき上記関数実行マネージャ（１６）および／またはグラフ構造エディタ（１３）による処理を制御するウエル・カーネル（１２）とを有するウエル・システム（１１）、
をそなえると共に、
上記オブジェクト・ネットワーク（１９）を構成する個々のオブジェクトに対応して、当該オブジェクトを特定しかつ当該オブジェクトに関する属性を記述したテンプレート（２２）が用意されており、
クライアントが入力したサービス要求情報にもとづいて、上記オブジェクト・ネットワークに対応した処理に対応する上記サービス・モジュールが選択され、
当該サービス・モジュールが処理に関連する個々のテンプレートを特定し、
クライアントからの情報が到来すると上記コミュニケーション・マネージャ（１０）が上記テンプレートを参照し、
当該情報を当該サービス・モジュールが処理できるデータ形式に変換が行われ、
対応するサービス・モジュールによって当該変換されたデータにもとづいた処理が行われ、当該処理結果が上記テンプレート上に格納されるようにされた
ことを特徴としている。
図１は本発明の原理構成図を示す。図中の符号１はクライアント、２はコモン・プラットフォーム、３はサーバを表している。コモン・プラットフォームにおいて、４はディスプレイなどの表示手段上に表示されるウインドウであり、大別して、ネットワーク・オペレーション・ウインドウ５とデータ・ウインドウ９とに分けられる。そして、６はオペレーション・ウインドウであって各種オペレーションを指示可能にする画像や文字を表示するもの、７はコマンド・ウインドウであって各種コマンドを指示可能にする画像や文字を表示するもの、８はメッセージ・ウインドウであって各種メッセージを表示可能にするものを表している。
【００１３】
またデータ・ウインドウ９は、処理結果を表すデータ・ウインドウ（Ｉ）９−１と、処理に必要な制約データなどを表すデータ・ウインドウ（II）９−２とからなる。
【００１４】
１０はコミュニケーション・マネージャであって、ウインドウ４を介して交換されるクライアント１とサーバ３との交信を仲介する。
１１はウエル・システム（各種のオブジェクト・ネットワークに対処できる拡張性をもっているという意味で、以下、エキステンシブ・ウエル・システムと呼ぶことがある）である。１２はウエル・カーネルであって上記コミュニケーション・マネージャ１０や以下の各種マネージャや、グラフ構造エディタを管理し、また作業領域をもっている。１３はグラフ構造エディタであってオブジェクト・ネットワークをも一種のデータと考えて、グラフ構造をテンプレートとして表現して処理を行う。
【００１５】
１４はウインドウ・マネージャであって、ウインドウ４の選択などを処理する機能をもつものである。１５はディスプレイ・マネージャであって、ウインドウを表示するディスプレイを制御する機能をもつものである。１６は関数実行マネージャであって、オブジェクト・ネットワークに対してクライアントの意図に沿った処理を行う上での関数を実行する上での処理を行う機能をもつものである。
【００１６】
１７−１，１７−２は夫々の目的に対応した処理を行うサービス・モジュールである。
【００１７】
【作用】
サーバ３はクライアントが処理対象にしようとしている意図内容を記述しているオブジェクト・ネットワークを呼び出して、グラフ構造エディタ１３はウエル・カーネル１２がもつ作業領域上に当該オブジェクト・ネットワークを記憶する。
【００１８】
この結果にもとづいて、ウインドウ・マネージャ１４などの働きによってかつコミュニケーション・マネージャ１０の仲介によってオブジェクト・ネットワークがオペレーション・ウインドウ６に表示される。
【００１９】
この状態の下で、クライアントは、表示されたオブジェクト・ネットワークにもとづいて、当該オブジェクト・ネットワーク上の全部または一部を特定して自己の意図を指示する。この指示に対応して、コミュニケーション・マネージャ１０が当該意図を解釈し、サーバに対して処理対象となる位置に該当するオブジェクト（名詞オブジェクト）についてのテンプレートを呼び出させる。そしてサービス・モジュールが当該テンプレートに対応した領域準備などを行い、ウインドウ４はそのときの制約データの存在をデータ・ウインドウ（II）９−２に表示する。
【００２０】
クライアントは、制約データをデータ・ウインドウ（II）９−２上で選択し、サーバが実行計画を実行し、サービス・モジュール１７が実行し、ウインドウ４が実行結果をデータ・ウインドウ（Ｉ）９−１に表示する。その結果をクライアントが評価し、次の指示を行う。
【００２１】
【実施例】
図３０に示した如きクライアントとサーバとの間の対話をより効果的に実現させるためには、クライアントと個々の処理を行うサーバとの間に、エイジェントの役割を行うエイジェント・ロール・サーバを介在させることが有効な場合がある。
【００２２】
コモン・プラットフォーム機能は、オブジェクト・ネットワークを表示するウインド５と、実行に伴って必要とするデータおよび実行結果のデータを可視画像として表示するデータ・ウインド９−ｉとを持ち、これらを支援するためのコミュニケーション・マネジャ１０などを有しており、これらの機能によりクライアント１としてのユーザに最も適した表示形式を使用可能にし、それをコモン・プラットフォーム２において、データ処理装置内部での処理用に変換するようにして、ユーザにとって使い易くしている。
【００２３】
一方、サーバ３にとっては、個々のデータなどはインデックス形式のタグが付いたテキスト形式で処理する必要がある。このようなクライアント１とサーバ３とはそれぞれ特有の役割をもっているので、コミュニケーション・マネージャ１０はそれらの役割に応じたデータ形式に変換する役割をもっている。このためのデータの型を規定するためにテンプレートで制御を行うようにする。
【００２４】
このテンプレートにもとづいて、変換が行われるが、この場合クライアント１とサーバ３との役割の差に対応して表記の形式が異なる。クライアントである人間にとっては、テキスト形式よりは、グラフのような図や画像の方が分かり易く、また指示も容易である。特に点や線についてはデータ・ウインド上で直接あるいはマウスによって参照指示が行えることが望ましい。一方、サーバとしての計算機にとっては、点については(x,y) の座標値として数値化され、線については始点から終点まで通過する画素点をリストの形式となっていなければ処理効率が悪い。このような観点から表１に示す如く役割機能に応じて表記形式が異なる必要がある。
【００２５】
【表１】
【００２６】
即ち、点や線を表すデータについては、クライアント１との間では、点や線を実体で表示しまたクライアント１がそれぞれの実体を参照しつつ指示できるようにし、サーバ３との間では、インデックス形式で特定しまた特定されたものについて一括転送したり連合して処理したりする。
【００２７】
図形や画像を表すデータについては、クライアント１との間では、画像や図形を実体表示しまたクライアント１が参照指示できるようにし、サーバ３との間ではリスト構造やラスタ構造で特定するようにする。
【００２８】
データ要素については、クライアント１との間では名前を指示し、サーバ３との間では名前ヘッダで特定するようにする。
サービス機能（エイジェントの抽象化サービス機能）については、クライアント１との間では、サービスをどのようなプログラムで行うかを明細にするサービス構造が先ずジェネリック・オブジェクト・ネットワーク形式で与えるようにする（クライアント１はこれにもとづいて所望するパラメータを与える）。そしてサービス実行の途中では、(i) サービス制約項目をパラメータとしてもつサービス項目や、(ii)サービス名をクライアント１が与え得るようにする。サーバ３との間では、(i) サービス構造表を与え、(ii)クライアント１からのサービス項目の指示に応じて、サービスを実行するサーバやサービスに当たって責任をもつサーバを指定するようにする。
【００２９】
図２はエイジェントをもつ構成を示している。図２に示すクライアント（Client）とサーバ（Specific role server）とが、図３０に示すクライアント１とサーバ３″とに対応している。そして、図２に示す場合には、エイジェント（Agent role server ）が中間において、例えて言えば旅行仲介業者の如き役割をはたすサーバ３′としてもうけられるようにされる。
【００３０】
図２に示す表示的プロセス２−１および従属表示的プロセス２−２は夫々図３０に示す表示的プロセスと同じ機能をもつものである。図２に示す場合には、クライアント１とエイジェント３′との間で表示的プロセス２−１に向かって、サービス要求と応答とが行われる。
【００３１】
エイジェント３′はクライアント１の意図にしたがったサービス計画を準備し、その役割を実行するサーバ（Specific role server）を検索し、サービス役割割当計画を行って、従属表示的プロセス２−２に向かって役割機能を実行すべく要求する。
【００３２】
サーバ（Specific role server）３″は割当サービス実行計画を実行し、実行結果を従属表示的プロセス２−２に呈示する。
エイジェント３′はサービス結果の内容をチェックして、サービス結果をクライアント１に呈示すべく表示的プロセス２−１に指示する。
【００３３】
図２に示す表示的プロセス２−１および従属表示的プロセス２−２は夫々、図１に示すコモン・プラットフォーム２によって実現される。そして図２に示すエイジェント３″は、図１に示すサービス・モジュール１７−ｉの１つとして与えられると考えてもよい。
【００３４】
図１に示すウエル・システム１１は、ＷＥＬＬ（Ｗindow-based Ｅ laborationＬanguage の略) と仮称される機能言語を取り扱う機能部であるとしているが、ＷＥＬＬと呼ばれる特別な言語を取り扱う機能部のみに限定して考えられるべきものではなく、ウインドウを用いて対話を行い得る、より広い意味の処理機能部が図１に示すウエル・システム１１であると考えるべきである。
【００３５】
図３はウエル・システムとオブジェクト・ネットワークとの関係を説明する図である。図中の符号１１は図１に示すウエル・システムに対応している。また１９Ａ、１９Ｂ、１９Ｃは夫々図１に示すサービス・モジュールと組合わせられたオブジェクト・ネットワークであり、１８Ａ、１８Ｂ、１８Ｃは夫々所定の処理分野であり、図示の場合１８Ｃはカラー画像生成・色付け処理（ Color Picture Processing and Painting)分野を表している。
【００３６】
ＷＥＬＬと仮称される機能言語に対して分野に対応するオブジェクト・ネットワークを与えると当該オブジェクト・ネットワークの処理がプログラムレスで実行が可能となる。また当該言語はウインドウ指向の言語であり、クライアントとのインターフェースはウインドウを介すことによって、クライアント・サーバ・モデルが実現される。
【００３７】
図３においては、ウエル・システム１１に対して、例えばカラー画像生成・色付け処理分野１８Ｃに対応して必要とされるウインドウと当該対応する処理を行うサービス・モジュール定義とで与えられるオブジェクト・ネットワーク１９Ｃを組合わせると、図示点線で示す如く当該ウエル・システムはカラー画像生成・色付け処理分野１８Ｃに対応するシステムとなる。言うまでもなく他の分野のオブジェクト・ネットワーク１９Ａや１９Ｂを組合わせると分野１８Ａや分野１８Ｂに対応するシステムとなる。
【００３８】
システムを構成する言語処理系に与えられるオブジェクト・ネットワークを変更すれば、システム機能は変化する。処理系は、対象とするオブジェクト・ネットワークの構成記述を入力データとして与えることにより、該当する分野処理を行うのであるから、ＷＥＬＬは元来グラフ構造エディタ１３を持っている。従ってシステムに、実行時にオブジェクト・ネットワークの変更機能を持たせることにより、システムの拡張性を持たせられる。特にインターフェースのために制約条件を名詞オブジェクトに持たせ、コモン・プラットフォーム中にあるメッセージ・ウインドウを利用できる。
【００３９】
互いに独立性のある多分野間の協調的統合のためにも拡張性は必要である。それは名詞オブジェクトについての制約関係の変更、動詞オブジェクトの実行制御についての同期性や排他性の動的変更など並行実行中のシステム環境への適応性がある。この場合、共通資財や計画修正などの管理の際に発生する役割転換を行う必要があり、得意機能に対応する対応処理機能を新しい共通の場の導入によって整合させる必要性が発生する。
【００４０】
図４は処理の整合を行う状況を概念的に示した図である。図示左端のクライアントが意図Ａないし意図Ｎをもって対応するサービスＡないしＮを並行して実行させようとするとき、各サービスを実行する上での制約が存在することが多い。このような制約には、時相制約的なものと形態制約的なものとが存在し、前者にって実行時の規制やサービス間時相調整制御が行われ、後者によってサービス間形態調整制御が行われる。そして、このような規制や制御が行われた上で実行された複合サービス結果内容についてのチェックが行われ、クライアントに対してウインドウを介して呈示され、クライアントが評価を行うこととなる。
【００４１】
図５と図６とは一緒になって１つのフローチャートを示すものであって、図１に示す構成が用いられる態様を表すフローチャートを示す。
（Ｓ１）：例えばカラー画像生成・色付け処理分野１８Ｃに対応する処理を行う場合、サーバが該当するオブジェクト・ネットワーク１９Ｃを呼び出す。
【００４２】
（Ｓ２）：これに応じて、グラフ構造エディタは、ウエル・カーネル１２上の作業領域上に当該オブジェクト・ネットワークを格納する。
（Ｓ３）：ウエル・カーネル１２によって、図１示すウインドウ・マネージャ１４やディスプレイ・マネージャ１５を起動しまたカーネル１２が当該各マネージャからの応答を受けるなどの処理をへて、コミュニケーション・マネージャ１０の仲介によって、オブジェクト・ネットワークがオペレーション・ウインドウ６に表示される。
【００４３】
（Ｓ４）：クライアント１は、オペレーション・ウインドウ６上のオブジェクト・ネットワークをみた上で、当該オブジェクト・ネットワーク上の全部または一部を特定して自己の意図を指示する。
【００４４】
（Ｓ５）：この状況をコミュニケーション・マネージャ１０が識別し、カーネル１２を介在させて、サーバに対して処理対象となる位置に該当するオブジェクトについてのテンプレートを呼出させる（サーバがテンプレートを呼出す）。
【００４５】
（Ｓ６）：サービス・モジュールは当該テンプレートに対応した領域準備を行う。
（Ｓ７）：コモン・プラットフォームにおいては、当該テンプレートに記述されていることのある制約データを抽出して、当該制約データをデータ・ウインドウ（II）９−２に表示する。
【００４６】
（Ｓ８）：クライアント１は当該制約データをみて、その中から所望する制約データを選択する。
（Ｓ９）：この状況をコミュニケーション・マネージャ１０が識別し、カーネル１２を介在させ、サーバに通知し、サーバが実行計画を実行する。
【００４７】
（Ｓ１０）：これにともなって、サービス・モジュールが所望される処理（例えば、線引きや色付けなどの処理）を実行する。
（Ｓ１１）：処理結果をデータ・ウインドウ（Ｉ）９−１に表示する。
【００４８】
（Ｓ１２）：クライアントはその処理結果を評価し、次の指示を行う。
図７はコミュニケーション・マネージャの働きを示す図である。図中の符号は図１に対応している。なお図７においてウインドウ４に対応して「コモン・プラットフォーム」というラベルを付しているが、図１に示すコモン・プラットフォーム２においてクライアント１から直接見える所がウインドウ４であってコモン・プラットフォーム２を代表しているとも考えられることから「コモン・プラットフォーム」とラベルを付しているだけであり、図１に対応するとウインドウ４に該当しているものである。
【００４９】
図７に示す如くクライアントの意図がウインドウ４を介してシステムに伝えられるときには、必ずコミュニケーション・マネージャ１０を経由してカーネル１２や各マネージャ１４，１５，１６更にはサービス・モジュール１７−ｉに伝えられる。このことから、コミュニケーション・マネージャ１０はウインドウ４に直結している唯一のマネージャとなり、対話プロセスを集中的に管理している。当該コミュニケーション・マネージャ１０の働きについては更に詳しく後述される。
【００５０】
上述の如くＷＥＬＬは分野を問わない拡張性のある言語である。それぞれの分野に対応するウインドウ定義やサービス・モジュール定義といったオブジェクト・ネットワークを与えると、ＷＥＬＬはその分野に対応する形で分野記述言語となる。このＷＥＬＬを用いたウエル・システムは、ウエル・カーネル１２と各種マネージャ１４，１５，１６など（ウエル・マネージャ）との２つの要素から構成される。
【００５１】
エキステンシブ・ウエル・カーネル１２は、以下の項目を行う。
（１）データ状態の把握（プロセスの把握を行い、次に実行するべき関数の選択）
（２）イベントの解析（各ウインドウから送られてくるイベントを判別し、その結果に対応するシステム内のプロシージャをコール）
（３）関数実行要求（総称的関数に制約条件を付加し、関数の実行をリクエスト）
また各マネージャは以下の４つに分けられる。
（１）コミュニケーション・マネージャ１０（テンプレート（データ）の間接的管理及びコモン・プラットフォームからの入力に対する各マネージャの制御）
（２）関数実行マネージャ１６（関数の実行管理）
（３）ウインドウ・マネージャ１４（ウインドウの管理）
（４）ディスプレイ・マネージャ１５（テンプレートの数値変換）
分野に依存しないＷＥＬＬと分野依存のサービス・モジュール１７−ｉとのデータ変換は、コミュニケーション・マネージャ１０が行う。このコミュニケーション・マネージャ１０を介すことによって、あらゆる分野のデータを扱うことが可能となり、ウエル・システム自体の汎用性は失われないこととなる。
【００５２】
ウインドウ４はクライアント１との間のインターフェースを行うものであり、以下の５つの個々のウインドウが存在する。
（１）ネットワーク・オペレーション・ウインドウ５（システム全体の制御）
（２）オペレーション・ウインドウ６（ネットワークのオペレーション表示及びその制御）
（３）コマンド・ウインドウ７（選択候補の表示及びキーボードからの入力）
（４）メッセージ・ウインドウ８（システム側からのメッセージ表示）
（５）データ・ウインド９−１，９−２（データの表示）
言うまでもなく、ある役割をプロセッサに導入する時、オブジェクト・ネットワーク中の個々のオブジェクトについての当該オブジェクトの表現方法は、役割依存でなければならない。人間に対しては、可視オブジェクトであり、計算機にとってはデータスキーマに則したデータ構造によって、オブジェクトが表現される必要がある。オブジェクト・ネットワークは個々のプロセッサで共有するが、データ構造は、テンプレート形式で定義されて、相互変換可能とされる。
【００５３】
オブジェクト・ネットワークを構成する各オブジェクトとしては、分野記述言語の枠組みに従って、名詞オブジェクトと動詞オブジェクトと制約オブジェクトとされ、制約オブジェクトは、被制約オブジェクトと制約条件とが属性として与えられ、そのための妥当性が各マネージャによって判定されて対応するオブジェクト処理を行いうるようにされる。
【００５４】
上述のウエル・システム１１にカラー画像生成・色付け処理分野をあてはめると上記ＷＥＬＬはいわばＷＥＬＬ−ＰＰＰ（Window-based Elaboration Language for Picture Processing and Painting ）となる。そしてウエル・システム１１はカラー画像生成・色付け処理システムとなる。この場合の１つのオブジェクト・ネットワークである要素ネットワークは、個別オブジェクトの外観を表しかつ領域を確保している輪郭（Outline)を生成する輪郭部（Frame Section)と、ラインとそれによって確保されている領域にしたがって属性値（Attribute value)を与えるカラー部（Color Section)とからなる。
【００５５】
図８は要素ネットワークの関係を示す図である。図８における左半分の「フレーム」２０は上述の輪郭部（Frame Section)に該当し、右半分の「カラー」２１は上述のカラー部（Color Section)に該当している。
【００５６】
輪郭部２０ではデータ自身を表す項目（Entity）を作成し、カラー部２１では輝度、色度などを表す属性（Attribute)を作成する。各クラスの状態は以下のようになる。
＜ＮＯＮＥ＞まだ処理の行われていない状態を表す
＜ＰＯＩＮＴ＞輪郭の基本となる点を示し、これを主要点（Principal Point)と呼ぶ
＜ＰＯＩＮＴ ＳＥＱＵＥＮＣＥ＞主要点に対し、その接続順序を示す
＜ＬＩＮＥ ＳＥＧＭＥＮＴ＞接続順序に基づいてスプライン関数で補間処理がされた状態
＜ＬＩＮＥ＞ＬＩＮＥ ＳＥＧＭＥＮＴを接続して１つのラインを完成した状態＜ＲＥＧＩＯＮ ＳＥＧＭＥＮＴ＞画像におけるその水平走査線１本分の領域を示す
＜ＲＥＧＩＯＮ＞ＲＥＧＩＯＮ ＳＥＧＭＥＮＴを画像に沿って上下方向に接続したものを示す
＜ＣＯＬＯＲＥＤ〜＞輝度、色度情報を示したそれぞれの項目を表す。また輪郭部とカラー部を結ぶＩＤＥＮＴＩＦＹは以下のように定義される。
〔ＩＤＥＮＴＩＦＹ〕処理の対象を特定する作業を示す。
【００５７】
図８に示す如きネットワークを利用してクライアントが絵を描く処理を行うことができる。当該処理の態様に関しては、本願発明と直接関連するものではないが、先に特許出願している特許第２８０１４５９号（特開平５−２３３６９０号公報）（オブジェクト・ネットワークによる言語処理システム）にも一部記述されている。
【００５８】
図９はコモン・プラットフォームをもつシステムにおいてカラー画像生成・色付け処理を行う態様を示している。図中の符号１，２，３は図１に対応している。
【００５９】
コモン・プラットフォームにおけるウインドウの表示によって、視覚的に要素ネットワークが組み込まれたことがクライアントにわかると、クライアントは描画するために必要な意図を選択する（クラス選択）。この例では点に輝度・色度を与えるＣＯＬＯＲＥＤ ＰＯＩＮＴを選択する。
【００６０】
点に色をのせたいというクライアントの要求に対して、サーバは情報を格納するためのテンプレートを準備し（ＤＥＦＩＮＩＮＧ ＰＲＯＣＥＳＳ）、どの点に対して色情報をのせたいのかクライアントに要求する。テンプレートについては後述される。
【００６１】
クライアントが点を指定すると（ＩＤＥＮＴＩＦＹ）、サーバはインデックスを参照することでその点を認識する。そしてその点にのせる輝度・色度データをクライアントに要求する。
【００６２】
クライアントからデータを応答として受け取るとＤＥＦＩＮＥ ＯＰＥＲＡＴＩＯＮとしてテンプレートにデータを入力し、その結果としてのカラー画像をウインドウに表示する。
【００６３】
この表示によってクライアントは、そのプロセスを認識し、それを評価し、次の意図選択へ移ることができる。このようにクライアントはサーバからの意図を可視化オブジェクトとして把握する。
【００６４】
上述の如く描かれる点や線は夫々上述の名詞オブジェクトの形で管理され、また個々の名詞オブジェクトに対して行われる処理態様は上述の動詞オブジェクトとして与えられる。
【００６５】
上述のコミュニケーション・マネージャ１０は、ＷＥＬＬの拡張性を維持するためにデータ相互関係を管理する。そのためにデータは、テンプレートとして一元的に管理され、そこに属性を自由に設定できるようにされている。
【００６６】
図１０はテンプレートのフォーマットの一例を示す。個々のテンプレート２２がその属するオブジェクトについての番号に対応するかを示すインデックスと、座標と、属性とをもつ。テンプレートは、サービス・モジュール１７−ｉ内では「インデックス」によって管理されるが、データ・ウインドウ９を通してクライアントから与えられるものは、データ・ウインドウ９上の座標値である。サービス・モジュール１７−ｉは、座標値からテンプレートのインデックス検索を行えないので、コミュニケーション・マネージャ１０は座標値をインデックスに変換し、それをサービス・モジュール１７−ｉに引き渡す。更に、コミュニケーション・マネージャ１０は、ウエル・システムの持つ対話プロセスを集中管理する。コモン・プラットフォームは、（ｉ）クライアントにオペレーションを伝えるオブジェクト・ネットワーク、（ii）メッセージや選択項目を伝えるメッセージ・ウインドウ、(iii）実際に描画などの作業を行い、画像データなどを表示するデータ・ウインドウなどを持つが、それらのウインドウを通して得られたクライアントの意図を実現するために、コミュニケーション・マネージャ１０は、その意図内容の入力に応じて、それを各マネージャやカーネルへ伝える。コミュニケーション・マネージャ１０のこのような対話プロセスの一元管理により、データが必ずここを通過することになり、テンプレートのチェックを行ったり、制約条件のチェックを行うことも可能になってくる。
【００６７】
図１１はコミュニケーション・マネージャの動作態様を示す。図中の符号１，３，５，８，９，１０，１２，１４，１５，１７は夫々図１中の符号に対応している。
【００６８】
ウインドウ上でのクライアントによる指示点（ｘ，ｙ）などがデータ・ウインドウ９からコミュニケーション・マネージャ１０に伝えられ、メッセージはメッセージ・ウインドウ８を介して伝えられ、オペレーションはオペレーション・ウインドウ５を介して伝えられる。そしてそれらは夫々コミュニケーション・マネージャ１０によって各種他のマネージャ１４，１５やカーネル１２やサービス・モジュール１７との間で情報の送受が行われる。
【００６９】
図１０に示す如きテンプレートは、点や線のデータ、図形／画像データなどに対応して用意されるものである。これは、点や線のデータ、図形／画像データなども、コモン・プラットフォームにおいて取り扱われるデータであることによる。それらは、オブジェクト・ネットワークの中でノードを形づくる名詞オブジェクトに属している。
【００７０】
したがって、データをクライアントが表示させあるいは参照しようとする場合、ウインドウ４上に表示されているデータの参照部分をマウスなどで示すと共に、名詞オブジェクトをオブジェクト・ネットワーク上で参照指示する。
【００７１】
このような参照指示機能は、クライアントが動詞オブジェクトの目的格としてのデータを指示することを主眼とするものである。これに対して、実体表示に当たっては、サーバが実行処理した結果をクライアントにみせるのに実際の点、線、図形、画像を実体としてウインドウ４上に見せるようにする。サーバ側ではデータを蓄積し、処理を行うに当たって、具体的なデータ構造（例えば、インデックス付加リスト構造、ラスタ構造など）に沿って蓄積したデータに対して処理を行う。
【００７２】
図１２はクライアントの指示に対応する動作を説明する図である。図中の符号１，４，１０，１２，１５，１７−ｉは夫々図１に対応し、２３はカーネル１２内にもうけられている作業用のバッファ、２３’はバッファ２３上の内容例、１９Ｃはオブジェクト・ネットワークを表している。
【００７３】
今、カラー画像生成・色付け処理がある程度進行しているとする。この場合、画像生成・色付け処理に対応するオブジェクト・ネットワーク１９Ｃから、該当するサービス・モジュール１７−ｉに対して、点や線などに対応するテンプレートがデータとして与えられ、当該サービス・モジュール１７−ｉからカーネル１２上（なお、バッファ２３はコミュニケーション・マネージャ１０上に位置していてもよい）のバッファ２３に対して、図示のバッファ内容２３’の如く、テンプレートのコピーが書き込まれている。即ち、例えば（ｉ）インデックス「１」で特定される点の座標が（５０，４０）であって色度や輝度（属性で示される）については未定（？で表している）であり、（ii）インデックス「２」で特定される点の座標が（８０，２５０）であって色度や輝度は未定であり、(iii）インデックス「３」で特定される点の座標が（２７０，４００）であって色度や輝度は未定であり、・・・の如き、各テンプレートのコピーがバッファ２３上に記述されている。
【００７４】
この状態の下で、いま、クライアント１がウインドウ４上で例えば座標（８０，２５０）を指示して１つの点を特定したとすると、コミュニケーション・マネージャはその動作を検出し、座標値についてウインドウ・マネージャ１４が検出してコミュニケーション・マネージャ１０に通知する。したがって、コミュニケーション・マネージャ１０は当該指示された点の座標値（８０，２５０）と対応するインデックス値を検索する。すなわちコミュニケーション・マネージャ１０はバッファ２３の内容にもとづいて座標（８０，２５０）をもつテンプレートに対応するものがインデックス「２」であることをコミュニケーション・マネージャ１０は知り、その後の処理に移る。
【００７５】
したがって、輪郭部で打たれた主要点の全座標を作業領域にコピーしたテンプレートと送られた座標との照合が行われる。一致もしくは近似の座標を検索するとそのインデックスを特定し、コミュニケーション・マネージャ１０はサービス・モジュール１７−ｉに送り制御を行う。サービス・モジュール１７−ｉはそのインデックスをもとにそのテンプレートの値を更新する。例えば座標位置を変更したり、属性上での輝度値を記述したりする。当該更新されたテンプレートはディスプレイ・マネージャ１５によって可視化オブジェクトに変換されウインドウ４に表示される。この場合は打たれた点がクライアントに認識できるように反転し浮き上がる。このようにエキステンシブ・ウエルは常にインデックスを中心に管理しているサービス・モジュール１７−ｉと情報交換をする。こうすることで特定の分野に依存しない拡張性の高いシステムが実現できるとともに、どのような分野に対してもクライアントはサーバの意図をディスプレイ・マネージャ１５によって変換された可視化オブジェクトをみて操作できる環境を提供する。
【００７６】
図１３は情報の交換動作を説明する図である。図中の符号１，４，６，９，１０，１２，１４，１６，１７は夫々図１に対応している。
クライアントがサーバと情報のやりとりを行う際、クライアントは常にウインドウを介して情報のやりとりを行う。そのためシステムは常にウインドウで待ち状態になっていなければならない。クライアントの意図によって駆動される駆動（Event Drivenという）にたいして、システムの制御をウインドウでの待ち状態にする駆動をData Driven という。Colored Point のクラスが選択されていてそれを駆動するのがEvent Drivenである。しかし輝度・色度のデータが与えられなければ、関数は実行できないのでウインドウにてクライアントの入力待ちとなる必要がある。この駆動がData Driven である。
【００７７】
図１３において、クライアント１が或る座標上の点を指示して上記イベント・ドリブン（Event Driven）を行ったとする。この状況の下で、「コミュニケーション・マネージャ１０によってウインドウ・マネージャ１４に通知された上でウインドウ・マネージャ１４が座標値（例えば８０，２５０）を報告し、対応するインデックス「２」が調べられてサービス・モジュール１７−ｉに通知される」ことは、図１２に関連して説明した通りである。
【００７８】
今、クライアント１が当該点に対して色付けを行おうとしているとすると、図８に示したクラス「 Colored Point」の状態分析をカーネル１２が行う。当該分析を行ったカーネル１２は関数実行マネージャ１６に対して関数実行要求を発する。これによって関数実行マネージャ１６は与えられる制約条件（Constraint）によって具体的関数を特定する。サービス・モジュール１７−ｉは特定された具体的関数にもとづいて処理が実行可能であるかを判別し、当該処理に必要なデータが不足していればカーネル１２を介して必要な作業を行う。例えば今、サービス・モジュールはクライアントに特定された点のテンプレートに輝度・色度情報を入力するようにしているとすると、輝度・色度データが未定であるため、関数の実行ができない。ここでData Driven が駆動され、この場合データ入力に必要なChrominance Diagram とLuminance Diagram が開かれ、輝度見本や色見本が表示され、クライアントの入力待ちとなる。
【００７９】
サービス・モジュール１７−ｉは必要なウインドウ（図１３に示すＤＩＡＧＲＡＭのためのウインドウ）を開いて、ユーザの応答を待つが、その応答以後そのウインドウが不要になる場合がある。またサービス・モジュールによっては多数のウインドウを必要とするものも考えられるため、表示されるウインドウは必要最小限にするべきである。そこでウインドウ・マネージャ１４内にウインドウの状態を示すテーブルを用意し、不要ウインドウの自動消去を行う。
【００８０】
図１４はチェック・モジュールの動作を説明する図である。図中の符号８はメッセージ・ウインドウ、９はデータ・ウインドウ、２２はテンプレート、２４はチェック・モジュール、２５は制約条件、２６はオブジェクト・ネットワークを表している。
【００８１】
クライアントは、オブジェクト・ネットワークに従った作業の流れの中で、自分がデータ・ウインドウ上に生成していったデータの正当性を確認したいと思うことがある。そのようなクライアントが確認したいと思う事柄を一つの制約条件として捉える。このような制約条件２５は、オブジェクト・ネットワーク２６のそれぞれの名詞オブジェクト（テンプレート２２で表されるデータの状態）に付属的なものとして課され、サーバ側では、その制約条件とテンプレートの内容とを比較することで確認作業を行う。ここで問題にされるのは、サーバが、処理対象とされるテンプレートの特定方法（Identify）をどのように持つべきかである。ウエル・システムでは、コミュニケーション・マネージャの機能を利用してこれを実現できる。コミュニケーション・マネージャ１０は、オブジェクト・ネットワークの持つテンプレートの内容データによってクライアントとサーバとの間のデータの整合性を管理しているので、クライアントがマウスでヒットした座標値（Ｘ，Ｙ）から上記図１２を参照して説明した如く処理対象を特定するための情報をテンプレート２２から引き出して、チェック・モジュール２４（具体的に制約条件をテンプレートに照らし合わせるサービス・モジュール）に渡すことが出来る。チェック・モジュールでは、その情報を頼りに、その制約条件が満足されているかどうかを確認し、その結果をメッセージ・ウインドウを通してクライアントに知らせる。このようなチェック・モジュール２４によるチェック動作は、図８において例えばクラス＜ＰＯＩＮＴ＞の状態からクラス＜ＣＯＬＯＲＥＤＰＯＩＮＴ＞の状態へ移行した際に、正しい形で移行が行われたか否かをチェックするためなどに利用される。更に他の制約動作も、他のサービス・モジュールと同様に対応するマネージャを用意することで実現される。
【００８２】
図１５は制約条件の表示態様を示す図である。図中の符号５，８，９，１０は図１に対応し、２５は図１４に示される制約条件、２７は名詞オブジェクトを表している。
【００８３】
図形描画の間に、例えば描かれたライン（線分）に対してどのような制約条件が付されているかをクライアントに知らせる必要があることがある。このような場合の各マネージャの動作が図１５によって説明される。
【００８４】
上記ライン（線分）は、それ自体がデータの状態を表していることから、名詞オブジェクト２７の１つとして捉えることができる。上記制約条件２５は名詞オブジェクト２７に対応して付されているが、ライン（線分）という状態に対して課され得る制約条件２５として考えられるのは「連続性（Continuity）」と「対称性（Symmetry）・・・（註）当該線分がある軸または点に対して対称な状態にあるか否か」といったものである。
【００８５】
名詞オブジェクト２７がもつこのような制約条件２５はコミュニケーション・マネージャ１０の介在の下でメッセージ・ウインドウ８に表示されてクライアントに知らされる。なお図１５において、メッセージ・ウインドウ８の内容に関して「Symmetry−Point,Axis」とあるのは「点対称」か「線対称」かを問う表示である。当該表示に対応して、クライアントは「Point 」か「Axis」かをピック・アップするようにして意図をサーバ側に通知する。
【００８６】
図１４に示すチェック・モジュール２４は、メッセージ・ウインドウ８を通しての起動要求をクライアントから受けるとファンクション・マネージャによって起動される。チェック・モジュール２４は、必要があればクライアントに対してアイデンティファイ作業の要求をメッセージ・ウインドウ８を用いて行う。クライアントは、それに対してマウスでデータ・ウインドウ上の可視化対象をヒットすることでコミュニケーション・マネージャ１０へその対象についてのデータ値の引き渡しを行う。このデータ値は、コミュニケーション・マネージャ１０によって図１２に示す如く対象に相当する項目データのインデックスに変換されるとチェック・モジュール２４へ送られ、このインデックスを使ってチェック・モジュール２４は、テンプレートから具体的な属性値を引き出してチェックを行う。チェックされた結果は、メッセージ・ウインドウによってクライアントに知らされる。
【００８７】
図１６はアイデンティファイ作業を説明する図である。図中の符号４，５，８，９，１０，１４，１７−ｉは夫々図１に対応している。
上述の如くチェック・モジュール２４がクライアントに対してアイデンティファイ作業の要求を行うと、クライアントはデータ・ウインドウ９上で、図１６に示す如く、例えばあるライン（線分）をヒットする。これに対応して図１２に示した如くウインドウ・マネージャ１４の働きによって関連しているデータがコミュニケーション・マネージャ１０に知らされ、コミュニケーション・マネージャ１０が、対応するインデックスを知り、当該インデックスをチェック・モジュール２４に通知する。これによって、図１４に示した如く、チェック・モジュール２４がチェックし、その結果がメッセージ・ウインドウ８において表示される。
【００８８】
なお、図形描画における点や線が名詞オブジェクトとしてデータの１つとして把握され、図９に示す「単位意図（要求）」などの要求が動詞オブジェクトとして対応づけられる。そしてそれらの名詞オブジェクトや動詞オブジェクトが夫々テンプレートの形で表現される。
【００８９】
上述した構成と動作とについて、より具体的に例を挙げつつ説明を補足する。図２において、クライアント１の意向に従ってサービス計画を準備するようにする。例えば、図１７に示す如き魚のうろこパターンのようなテキスチャを描画したいとの意図をクライアントが持つとき、テキスチャ描画の意図をサービス依頼（要求）としてエイジェント・ロール・サーバ３′に伝えると、エイジェント・ロール・サーバ３′は流れ線(flow lines)とセル画像(cell picture)とをクライアントと協力して描画するサービス計画を具体的に準備する。流れ線を書くには、図８の要素ネットワークがある要素画像を描くために利用できるので、それを利用する。すなわち、図８中でPOINT からLINEまでの部分ネットワークをまずオブジェクトネットワークとして表示する。
【００９０】
それは図２に示す役割サーバ検索（事項検索）が流れ線(flow lines)のlineの事項を検索すると、相当する単語が要素ネットワーク中に存在することを検索し、その部分オブジェクト・ネットワークを、コモン・プラットフォーム２に「flow line 」の表示と共に表示する。
【００９１】
クライアント１は当該表示に従って図１７（ａ）に示すように魚体を示す点線を沿う形で曲線ＡとＢとを描く。
次に図１７（ｂ）に示すように、線Ｃ，Ｄを描く。このとき、How many points do you divide on C and D ? の如き質問がエイジェントからメッセージ・ウインドウ８に表示され、それに対してクライアント１が値「４」とキーインして答えると、図１７（ｃ）に示すように、４個の補間曲線が引かれる。次のステップで質問How many points do you divide on A and B ?に対し値「１６」と答えると、各補間曲線上に図１７（ｄ）に示す如くうろこを描くための１６個の中心点が表示される。この場合、Flow linesについての制約条件として隣接するFlow linesとの間の距離に比例して中心点間距離が大きくなるような制約条件が与えられるとすると、即ち、Flow lines間隔が狭ければ、Cell Pictureとしての「うろこ」の寸法が小さくなければならないとすると、このため次のSatisfying文制約記述が与えられる。
Satisfying :
Every length between adjacent points along flow line is proportional having a fixed ratio with vertical length at the point between adjacent flow lines,
end.
それと同時に「cell picture」の表示と共にうろこパターンを画像を描くようにFlow linesと同時に要素ネットワークとしてのオブジェクト・ネットワークが表示され、クライアントはそれに従って図１８に示す如く、上記中心点（×印）を中心としてうろこのカラー画像を描く。
【００９２】
この処理は、図５の処理フロー（Ｉ）に従って実行される。
この実行をある特定のスペシフィック・ロール・サーバ３″に割り当てるために、図２に示すサービス役割割り当て計画（サービス仕様）によって実施すべき処理内容があるサーバに要求される。
【００９３】
それが図２に示すサービス役割機能（要求）として計画されたスペシフィック・ロール・サーバに実行要求が発行される。この発行はエイジェント・ロール・サーバ３′とスペシフィック・ロール・サーバ３″との間での共通の場を通じて機能する。
【００９４】
エイジェント・ロール・サーバ３′に依存した図２に示す従属表示的プロセスで所定の表示が行われて、エイジェント・ロール・サーバ３′とスペシフィック・ロール・サーバ３″との交信が行われ、当該従属表示的プロセスがコモン・プラットフォームとして、エイジェント・ロール・サーバ３′とスペシフィック・ロール・サーバ３″群との間の連絡通信の場を提供する。したがって、エイジェント・ロール・サーバ３′が複数のスペシフィック・ロール・サーバ３″に依頼した複数の処理内容、この例では「Flow lines」と「cell picture」との間に存在する整合性についての制約条件について規定し、実行する必要がある。
【００９５】
そのための前提条件として、予めテンプレートについての定義を行うことを必要とする。点についてのテンプレートは図１０のように定義され、そこでの属性値集合としてのattributes for point(s)(x,y)として、当該点に関する輝度、色度などの属性値を入れるべきデータ形式が示されている。Lineについては、走査線インデックスを"i" とすると、"i" についてのリスト構造として(x,yi ）の値が、図１９に示す如きLine用テンプレートが定義される。
【００９６】
即ち、当該Lineが走査線と交差する各点のうちの主要点No.1,No.2...No.nについてのテンプレート（図１０参照）上のattributes for point(s)(x,y)に、入口側のポインタｐと当該点の輝度と当該点の色度ベクトルと出口側のポインタｐとが記述され、上記夫々のポインタによって他を指示することによって、全体が１つのLineに対応するLine用テンプレートとして定義される。
なお、図１９に示す各点の属性値に輝度と色度ベクトルとを記述しているのは次の理由による。即ち、Point とColored point とがオブジェクト・ネットワーク中に定義されているような要素ネットワークでは、最初からPoint のテンプレート中に、Colored の修飾形容詞に対応した輝度値や色度ベクトル値を属性値として持たせることが望まれるからである。
【００９７】
FlowというLineを限定する形容詞節が付加されると、そのためにテンプレートに付加属性のためのスペースを必要とする。このスペースの設定は予め行われてもよいし、エクステンシブル WELL の機能の拡張機構としてのグラフ構造エディタを用いて必要時点で設定してもよい。
【００９８】
図１７（ｃ）に示した流れ線を示すようにする当該形容詞節で特定するデータ構成としては、図２０に示す如きものが用意される。図２０における符号３０はFlowという『Lineを限定する形容詞節』につけられたインデックスであり、符号３１は当該Flowに属するLineについてのインデックスであり、符号３２は当該Lineについてのデータ配列（図１９に示す如きもの）である。
【００９９】
Colored point についてFeature という形容詞をつけて、それをFeatured colored pointとすると、テンプレートの属性の所に、図２１に示す如く、Feature 名を付加する。Feature 名の所には、"edge","highlight"または"none"を記述するようにする。"edge"が記述されると、その点が輝度や色度ベクトルからエッジと識別されたことを示す。"highlight" が記述されると、その点がハイライトとして示されることを示す。また"none"が記述されると、その点にはFeature を持たないことが示される。
【０１００】
そのいずれにしても、Flow linesに対して図１７に示したようなＡ，Ｂ，ＣおよびＤの４個のLines に対応して、夫々のLine用テンプレートが準備される。次にクライアント１とコモン・プラットフォーム２中のメッセージ・ウインドウ８との通信によって更に４本のFlow linesのためのLine用テンプレートが設定される。次に"cell picture"を描画するために、オブジェクト・ネットワーク（図８に示す如き）に対応したオブジェクトに対応してテンプレートが設定され、最後のColred Region では輝度色度データをもつラスタ形式のテンプレートを持つようになる。
【０１０１】
このように設定された「うろこ」画像を、流れ線上に設定された中心点に「うろこ」の中心点を合わせ、サイズを選んで写像する。この際、制約条件を必要とする。
【０１０２】
この時点までにおいて、Interval between the adjacent center points on the flow lines が各center pointに定義されている。即ち、各flow line がもつ属性としてIntervalが定義されており、flow line のdrawing の実行後計算され、属性値として、各center points についてのテンプレート中にそのInterval値が格納されている。
【０１０３】
そして同様に、cell pictureのもつ属性としてscale をもち、そのscale 値とinterval値との間の制約関係として、
a scale of cell picture = the interval between the adjacent center points on the flow line
を設定する。そしてこれを満足するように、mapping を行うスペシフィック・ロール・サーバ３″にそのmapping を依頼する。
【０１０４】
図２２と図２３とは上下に組合されて１つの流れを表すテキスチャ描画の流れ図を示している。
クライアント１の意図する所が、図２２、図２３における左端に、上から下に向かう時系列で示される。またエイジェント・ロール・サーバ３′の処理が、図２２、図２３の左右中央部に、上から下に向かう時系列で示される。さらにスペシフィック・ロール・サーバ３″の処理が、図２２、図２３における右端に、上から下に向かう時系列で示される。また図２２、図２３における符号１，２−１，２−２，３′，３″は図２に対応している。更に図２２の下端における矢印（Ａ）は図２３に示す矢印（Ａ）につらなるものである。
【０１０５】
クライアント１がテキスチャ描画を意図してテキスチャ・サービスを要求すると、エイジェント・ロール・サーバ３′はテキスチャ描画サービス計画を準備し、統合サービス・プラットフォームを設定する。これにもとづいて、クライアントは図１７に示した如きFlow line を表示させようとして、Flow line 表示を要求する。
【０１０６】
エイジェント・ロール・サーバ３′はフローライン計画を検索し、スペシフィック・ロール・サーバ３″に対してフローライン実行サービス設定を要求する。スペシフィック・ロール・サーバ３″の設定した結果が、エイジェント・ロール・サーバ３′にて中継されて、クライアント１に示される。
【０１０７】
クライアント１がFlow line 描画を意図して、フローライン用画面を要求すると、エイジェント・ロール・サーバ３′からスペシフィック・ロール・サーバ３″に依頼されて、クライアント１に対してフローライン画面が表示されると共に制約条件の提示を要求する。
【０１０８】
制約条件について応答が了承されると、エイジェント・ロール・サーバ３′はフローラインとセンタ点とを表示する計算を行って、クライアント１に対して表示する。クライアント１は必要に応じて修正要求を行う。
【０１０９】
次いでクライアント１はCell pictureについての描画を意図し、図２３に示す如く、エイジェント・ロール・サーバ３′とスペシフィック・ロール・サーバ３″との処理によって、セル・ピクチャ用のコモン・プラットフォームが設定される。
【０１１０】
クライアント１がセル・ピクチャの描画を意図すると、同様に、セル・ピクチャの画面が表示されかつ制約条件の提示が要求される。
クライアント１が制約条件について応答すると、セル・ピクチャについての処理結果が統合サービス・プラットフォームに統合され、クライアント１の評価を待つようにされる。
【０１１１】
ここでは、フローライン描画とセルピクチャ描画との二つの仕事が並列に実行可能になっている。並列実行可能な動詞オブジェクトを検出するためのシステム構成は上記テキスチャ描画の例では、テキスチャを描くためのフローラインのための線を描くことと、フローライン上にセル画像を描くこととを並列に行い得るようにされる。そしてその結果がそろった所で、統合描画プロセスに移る。従ってスペシフィック・ロール・サーバ３″としてはフローライン用、セルピクチャ用、統合描画用の３個のサーバがエイジェント・ロール・サーバ３′に付属している。これらを制御するオブジェクト・ネットワークとしては図８の要素ネットワークを使用し、フローラインとしては図中右側のNoneからLineまでを使用する。これはFlow line のlineを描くことを目的としていることから、この部分のみがコモン・プラットフォームに図示され、表示的プロセス２−１中でクライアント１が使用する。Cell pictureと統合描画との両部はpicture を描画することから、図８全体がオブジェクト・ネットワークとしてクライアントに使用可能である。
【０１１２】
これら個々のスペシフィック・ロール・サーバ３″における実行結果は、エイジェント・ロール・サーバ３′を通じて、クライアント１とエイジェント・ロール・サーバ３′との間に存在するコモンプラットフォーム上にその実行結果としての画面表示される。
【０１１３】
得られた画像表示をクライアント１は観察しながら、エイジェント・ロール・サーバ３′はその仕事に関して必要とする属性もしくは制約についてクライアントに質問を行う。このための構成が図１４に示されている。図１４に示す如く実行され確認され、data identify の後に、コモン・プラットフォームのデータ・ウインドウ９に表示され、クライアントから応答された制約がチェックされ、その実行がValidity check２４によっておこなわれ、メッセージ・ウインドウ８でその実行が確認されて、結果がデータ・ウインドウ９に表示される。
【０１１４】
これらの特定サービスは、エイジェント・ロール・サーバ３′からスペシフィック・ロール・サーバ３″へ、その間に存在するコモン・プラットフォームを用いて依頼される。このコモン・プラットフォームが図２２、図２３においては従属表示的プロセス２−２として示され、エイジェント・ロール・サーバ３′に従属しているものとして示されている。この場合の態様は、ソフトウェアの仕様からオブジェクト・ネットワーク・データをはじめとするすべては、クライアント１とエイジェント・ロール・サーバ３′との間の場合と全く同じ形式をとる。それは、システム開発の際のユーザフレンドリ性を確保するためである。
【０１１５】
インタラクションの形態としては、
（ａ）エイジェント・ロール・サーバ３′のような抽象化サービスはジェネリック・オブジェクト・ネットワークとして抽象化されている。当該ジェネリック・オブジェクト・ネットワークは、パラメータあるいは制約条件によって具体化されたスペシフィック・オブジェクト・ネットワークと階層化される。なおスペシフィック・オブジェクト・ネットワークは特定の機能に対応したサービスを行うネットワークである。
（ｂ）個々のオブジェクト間の属性は、親の方から（例えばエイジェント・ロール・サーバ３′) から受け取り、それを用いてスペシフィック・ロール・サーバ３″は実行し、その結果は合成された属性(synthesized attribute) として、依頼した親の方に受け渡され、エイジェント・ロール・サーバ３′はそれらの属性値を用いて、制約条件を付し、新しいデータを得たり、チェック機構を動かす。
（ｃ）制約条件などは、図４に示す如く、形態的制約と時相的制約とが存在する。
【０１１６】
ジェネリック・オブジェクト・ネットワークは、図８に示す要素ネットワークの如きものでテキスチャ画像を図１７、図１８のように描くため、クライアントがテキスチャ描画の意図からその要求をエイジェント・ロール・サーバ３′に与えると、エイジェント・ロール・サーバ３′のもつジェネリック・オブジェクト・ネットワークを、統合サービスプラットフォームとして、クライアント１とエイジェント・ロール・サーバ３′との間の意志疎通のために設定する。そしてその上に上記図１７や図１８を表示するようにする。このようなネットワークは、エクステンシブル WELL のカーネル部の機能としてのグラフ構造エディタで行われる。
【０１１７】
図２４はオブジェクト・ネットワークの階層構造を示すものである。例えば数学において変数を一般化して与えて公式を用意しておくように、パラメータや制約条件などを一般化して（抽象化して）与えておいたジェネリック・オブジェクト・ネットワーク３３を用意しておく。そして、特定の処理を行わせるための特定のパラメータや制約条件３４を、ジェネリック・オブジェクト・ネットワーク３３中に組み込むことによって、当該特定の処理のためのスペシフィック・オブジェクト・ネットワーク３５がつくり上げられる。
【０１１８】
図２５はエイジェント・ロール・サーバ３′からスペシフィック・ロール・サーバ３″への処理の詳細化をテキスチャ描画の場合についてのジェネリック・オブジェクト・ネットワークを例示した図である。
【０１１９】
そして図２５中で四角形で示した名詞オブジェクトと関連したテンプレートがテキスチャ描画システムの設計を行ったエキスパートによって準備され、それをWELLの機能によってエイジェント・ロール・サーバ３′もジェネリック・オブジェクト・ネットワークとデータとに分けてもつようにされる。
【０１２０】
Flow line の名詞オブジェクトがクライアントにより指示されると、図８の要素ネットワークのうちLINE〜NONEの部分グラフがFlow line のための部分描画プロセスとして、フローライン用コモン・プラットフォームがスペシフィック・ロール・サーバ３″からエイジェント・ロール・サーバ３′を中継して、クライアント１に指示され、これを用いて図１７（ａ）（ｂ）（ｃ）（ｄ）のように描画プロセスが進行するようにされる。
【０１２１】
この際、テンプレートは、要素ネットワークのもつテンプレートがそのまま利用される。FlowというLINEについた修飾用形容詞は、LINEに新しい属性構造をテンプレートとしてもち、さらに、(i) 制約条件を付加すべきこと、および(ii)テキスチャ描画のためにはLINEが描画用データウインドに表示されるのではなくセルピクチャを写像する図２６に示すような点の位置のみが必要であること、を示している。
【０１２２】
以上のことから、Flow line を描画するためには、図１７（ｂ）をもとに図１７（ｄ）を描き、さらに図２６を描画するための制約条件、もしくはサブネットワークを与えるようにされる。
【０１２３】
したがってFlowという形容詞による修飾内容についての枠組みとして、前述したように、与えられた制約条件のもとに、
Length between adjacent points along flow line
Vertical Length between adjacent flow lines
について、エイジェント・ロール・サーバ３′はクライアントから定義してもらう。このために、メッセージ・ウインドウ８によって前述したような分割する点の数についての質問応答が行われる。その結果が図１４のConstraints on noun object２５に与えられ、Flowの修飾が行われ、図２６の結果が得られる。図中の点はCell pictureを写像する位置を知らせるためのもので、実際のTexture 画面には表示されない。これはTexture とFlow line の両者が与えられることから、Texture picture 表示の際、消去される。
【０１２４】
Cell pictureについても同様で、picture によって要素ネットワークによってカラー画像が描画される。この描画の後、図２６の点集合中の各点の周りに写像されるが、picture はCellによって修飾されており、その大きさをFlow line での隣接点間距離との関係によって規定する。そのためにCell pictureに付属する制約としてCell pictureの２つのlengths がFlow line について定義されているlengthと一致させる処理が行われて写像(mapping) 描画がTexture picture によって行われる。この際、Cell picture size とFlow line のlengthとの比を設定することが可能である。これは図４に示される制約意図の実現と考えられ、サービス間形態調整制御が実際に整合化を行う。
【０１２５】
以上のことを実行するために、Texture picture を描画対策としての要求は、Request to paint texture pictureがクライアントから意図として、図２２、図２３に示されているように、エイジェント・ロール・サーバ３′に与えられると、エイジェント・ロール・サーバ３′は、統合サービス・プラットフォームをサービス計画準備のプロセスとして設定し、その上に図２５で示されるジェネリック・オブジェクト・ネットワークをデータベース検索によって取り出し、それと同時にflow line とcell pictureとのためのスペシフィック・ロール・サーバが割り当てられる。
【０１２６】
以上のスペシフィック・ロール・サーバのなすべき仕事については、図２に示されるサービス計画準備で、役割サーバ検索（事項要求）が、エイジェント・ロール・サーバ３′を制御しているWELLシステムのカーネル部を介してデータベースサーバに検索依頼し、割り当てられたスペシフィック・ロール・サーバにその仕事を割り付ける。あるいは、元来その仕事を行っていたスペシフィック・ロール・サーバを事項検索を行って見出し、それに依頼する。
【０１２７】
スペシフィック・ロール・サーバが行う役割は基本的な名詞オブジェクトの実現を行うサービス実行と考えられ、その役割は具体的オブジェクトネットワークによって定義される。これに対しエイジェント・ロール・サーバは、それに制約条件や、他との整合化を行う仕事で、クライアントとの間でのインタラクティブな対話プロセスを伴うようなジェネリック・オブジェクト・ネットワークを含んだ仕事を分担する。
【０１２８】
以上述べたことを、インタラクションの形態について説明したオブジェクト指向の属性値についての継承および合成型の観点からシステムを考えると、
継承型データ：継承型データをもとにある処理を要求(Request) するエイジェント機能を行うサーバから具体的テンプレートを受け取る。即ちそのデータに対応したテンプレートの型として定まったデータ容器にデータ値が格納された具体的テンプレートを受け取る。この仕事を担当するスペシフィック・ロール・サーバもエクステンシブル WELL によって記述され、実行を行う。具体的実行は自身が行っても、他のサービスモジュールに依頼してもよい。
合成型データ：上記によりRequest されたデータをもとに依頼されたスペシフィック・ロール・サーバが実行処理を行う。その結果を格納すべきデータ型としてのテンプレート型式は、Request 時に受け取っており、それに格納して応答としてエイジェント・ロール・サーバに返す。この一連の仕事もエイジェント・ロール・サーバとの間に存在するコモン・プラットフォーム（これはスペシフィック・ロール・サーバがもっている）とそれを支援するコミュニケーション・マネージャが行う。
【０１２９】
以上のエイジェント・ロール・サーバ３′と、スペシフィック・ロール・サーバ３″との関係は、クライアントとServerとの間のエクステンシブル WELL の処理形態と全く同様である。しかしながらエイジェント・ロール・サーバが複数のデータをもとに継承型データとして複数個のスペシフィック・ロール・サーバに処理作業を依頼した時には、制約処理をエイジェント・ロール・サーバが行わなければならない。例として前述したTexture picture の描画を考えるとFlow linesとCell pictureとの描画を、それぞれ独立のスペシフィック・ロール・サーバに依頼し、その結果が返された時、Flow linesとCell pictureとの間の制約条件を満足させなければならないので、そのための制約条項が図２５のIntegrating Constraints についての属性値とSatisfying文によっての規定とを満足させる。
【０１３０】
この制約処理をコミュニケーション・マネージャに行わせる。したがって、コミュニケーション・マネージャは、
（１）テンプレート構造の役割に応じた変換を行う。（上記表１参照）
（２）テンプレート内容および複数個のテンプレート内容についての制約処理に関連した整合化のための通信管理作業を行う。
【０１３１】
この制約処理は形態制約である。それはFlow linesとCell pictureとの２個のサービス・オブジェクト相互に関連していることによる。このため、図２７のように制約処理の間での統合がはかられる。
【０１３２】
図２７において、
▲１▼ クライアント１は、ウインドウのデータを眺めながら、オブジェクト・ネットワークによって要求を発する。
【０１３３】
▲２▼ エイジェント・ロール・サーバ３′は、サービス計画用のデータを用意し、スペシフィック・ロール・サーバ３″に対して、即ち所望する処理を行うための各 Flow line 処理用のサーバや Cell picture 処理用のサーバや Texture picture 処理用のサーバに対して、要求を発しおよび／または処理の継承を指示する。
【０１３４】
▲３▼ スペシフィック・ロール・サーバ３″における各サーバは、夫々自己の処理を行い、処理結果にもとづいた反応を返しおよび／または処理を合成して、エイジェント・ロール・サーバ３′へ応答する。
【０１３５】
▲４▼ エイジェント・ロール・サーバ３′は、サービス内容をチェックし、制約条件があるか否かや現在の制約条件に追加や変更があるかなどを、クライアント１に尋ねるように処理する。
【０１３６】
このように図２７に示す如く、スペシフィック・ロール・サーバ３′中の各サーバが処理した結果あるいは所定の制約条件の下で処理した結果について、改めて、各処理結果の間で生じうる制約条件を新たに考慮してゆくようにする。即ち、制約処理の間での統合がはかられる。
【０１３７】
図２７に示すプロセスによって図２５で述べたAgent roleとSpecific role との差異が示されている。Flow line とCell pictureとについてもFlowとCellとの修飾に関連した制約処理はagent roleの働きと考え、要素ネットワークに対応する処理はspecific role の働きによって行われる。
【０１３８】
また画像処理と画像描画とを相互作用のある形で、コモン・プラットフォームを用いて対話的情報処理を行うことができる。例えば、エッジ線やハイライト線のような特徴抽出を行う画像処理を行い、抽出されたハイライト線を移動させる。すなわち、左目から見た左画像が与えられた時に視点を右目の位置に移動させて右画像を求めるようにして、立体画像を得たり、あるいは顔の目尻を上下させて表情変化をさせる時に目尻の位置を検出するような画像処理によって表情の特徴を得たりすることができる。
【０１３９】
しかし、これら特徴検出については、サーバがいつも完全な実行処理できるとは限らない。そこで明確な特徴を検出しうる箇所をクライアントが選び、そこである性質としての特徴名としての制約を示して特徴を表現する点の候補を求め、次いでその中から特徴点を確定するようにする。この操作は例えば図８の要素ネットワークにおいて、クライアント側の動作を時系列的にＣ１，Ｃ２・・・として示し、システム側の処理を時系列的にＳ１，Ｓ２・・・として示すと次の如く処理が進行される。即ち、
（Ｃ１−１）Colored Region Segmentの項目名を指定し、データ・ウインドウ上で抽出したい特徴の明らかな、
（Ｃ１−２）Region SegmentをIdentifyする。
（Ｃ１−３）ついで、Featuredをキーボードから入力し、Colored Point の項目を指定することにより、Featured Colored Pointを求めたことを、クライアントの意図として、システムに要求する。
（Ｓ１）システムはメッセージ・ウインドウによって意図を確認してSeek featured Colored Point を表示し、IdentifyされたColored Region Segmentを表示する。
（Ｃ２）Featuredの制約としてHighlight をキーボードから入力する。Highlight の性質はシステムに既に与えてあるとする。
（Ｓ２）Featured(Highlight) Colored Point を抽出する。
（Ｃ３〜Ｓ３）Featured(Highlight) の単語をコピーし、Colored Line SegmentをIdentifyする。これにより、システムは、クライアントがFeatured Colored Point Sequence を経てFeatured Colored Line Segment を作るべきことを、サービスとして実行する。
【０１４０】
以上によって、Highlight 線を構成し、クライアントはその確認を行った後、それを移動した上で新Highlight 線およびエッジ線を左右の眼の視差に対応して移動する。この際、Colored 属性を継承し、その上でHighlight 線の特徴を維持するように描画サービスをシステムが行う。このHighlight 線の移動差をmoved highlight 線として修飾を行い、moving vector diagram を用いて時間的な移動を行うようにする。
【０１４１】
またこれらの修飾を行うのに当たって、colored.... によって輝度や色度の属性用テンプレートを付加したのと同様に追加テンプレート部分が付加される。これらは名詞オブジェクトに対するものであったが、動詞オブジェクトについてもpoint からline segmentに至るdrawが継承される。したがって動詞オブジェクトについても実行開始時、実行中、実行終了時の制約条件が付加される。
【０１４２】
また実行要求と制約との関係としては、サービスとしての実行要求を行いうる条件を規定することが必要で、
（１）属性値処理のために、エイジェント・ロール・サーバ３′からの継承性属性のみが要求により実行可能で、結果は合成属性として上位エイジェント・ロール・サーバ３′へ応答するようにされる。
（２）実行要求は、クライアントによってオブジェクト・ネットワーク上の動詞オブジェクトを指定し、もしくは上述のような実行の単位(pointからlineへのdraw) によって実行系列を定めるようにして、委任発行される。
（３）ジェネリック・オブジェクト・ネットワーク上のジェネリックな動詞オブジェクトについても実行系列命令の生成を（２）と同様に行う。
【０１４３】
このために図４に関連して記述した時相的制約が満足されていることを制約処理によって調べる。
実行結果をエイジェント・ロール・サーバ３′に応答すると、エイジェント・ロール・サーバ３′は制約処理のプロセスに入る。制約条件を満足していない時には、合成データを応答してきたスペシフィック・ロール・サーバへ継承属性を変更させて再実行に移らせる。それでも不満足な時には合成ルートをたどって（図２２、図２３の中継などによって）最終的にクライアントの判断を仰ぐパスが設定される。
【０１４４】
これまでの説明は、クライアントが一人であったが、複数のクライアントの協調化も行いうる。それはクライアントの上位階層として協調化を行う協調化エイジェントが存在すると考えることによって、コモン・プラットフォームを協調化して実行する場として使用可能である。
【０１４５】
グラフ構造化エディタは、オブジェクト・ネットワークの定義を読み取り、それを可視化可能なオブジェクト・ネットワークに表示すると共に、各オブジェクトのテンプレート構造および制約条件を各オブジェクトの属性として管理している。したがってエクステンシブル WELL の機能によってエイジェント・ロール・サーバ, スペシフィック・ロール・サーバのソフトウェアが記述される。そしてオブジェクト・ネットワークとテンプレートの構造とは、システム設計の最初の段階で、開発担当のその分野を担当するエキスパートによって記述が行われる。
【０１４６】
サービス・モジュールが、できるだけ基本的なソフトウェア・モジュールとそれに対応する専門分野との組み合わせという考え方で、開発し用意される。
並行処理のためには、オブジェクト・ネットワークの構造を図２８のように、TOP を目的ゴール、BOTTOMを出発点として表現する。当該BOTTOMは上述の図８のNONEの如きものと考えてよい。
【０１４７】
図２８においては、現在実行中のタスクが今ＣとＥとであるとすると次に並行実行可能なタスクがＡとＤとであり、ＡとＤとの並行実行が終了した時には次にＡとＢとに移ることを可能とすることが示されている。このように、オブジェクト・ネットワークの構造を解析して、並行実行の進行と共に複数個のサーバの並行実行を動的に制御させるようにする。
【０１４８】
図２において、クライアント１とエイジェント・ロール・サーバ３′とスペシフィック・ロール・サーバ３″との関係を示し、クライアント１とエイジェントとの間に表示的プロセス２−１としてのコモン・プラットフォーム２が存在し、かつエイジェントと各サーバ＃ｉとの間に従属表示的プロセス２−２としてのコモン・プラットフォーム２が存在する態様を示した。
【０１４９】
図２においてクライアント１の存在を示しているが、当該クライアント１として、エイジェント・ロール・サーバ３′に対して処理を希望するユーザを考慮することは言うまでもないが、当該ユーザとエイジェント・ロール・サーバ３′との間の情報交換を援助するエキスパートを更に考慮することができる。
【０１５０】
図２９はエキスパートの存在を考慮したシステム構成を示す。図中の符号１，２−１，２−２，３′，３″は夫々図１や図２に対応している。そして、符号１−１は図１や図２に示すクライアントに相当するユーザ、１−２はエイジェント・エキスパートであってユーザ１−１とエイジェント・ロール・サーバ３′との間の情報交換を援助するもの、１−３はスペシフィック・エキスパートであってエイジェント・ロール・サーバ３′とスペシフィック・ロール・サーバ３″との間の情報交換を援助するものを表している。
【０１５１】
図示のユーザ１−１は人間であるが、エイジェント・エキスパート１−２やスペシフィック・エキスパート１−３は夫々人間に限られるものではなくインテリジェント機能をもつ処理ユニットであってもよい。
【０１５２】
図２９に示すように、エイジェントに対してユーザ１−１としてのクライアントは、ある局所的な特定の問題解決(problem resolution)を依頼する。すなわち、ある問題についてエイジェントの支援をたのみ満足する解を得る。
【０１５３】
これに対し、専門家としてのエイジェント・エキスパート１−２はエイジェントが担当する問題解決を行うための各種サービスの仲介実行を行う仕事を担当する。すなわち、ジェネリック・オブジェクト・ネットワークを構成し、それをエイジェント・ロール・サーバ３′に対して実際に実行するオブジェクト・ネットワーク群に分解し、図２２，図２３のような実行を可能とする方法を設計する。
【０１５４】
この際、ジェネリック・オブジェクト・ネットワークとそのためのテンプレート（これにはデータのみでなくサービスモジュール名を含む）と制約条項とをもっている。図２２，図２３に示したエイジェントの中継機能は、エイジェント・ロール・サーバ３′のもつウエル・システム１１の中核部に備えられている。制約条項の処理は、一般的形式で記述されている部分については制約処理サーバに依頼する。
【０１５５】
ジェネリック・オブジェクト・ネットワークとそれに関連するテンプレートをエイジェント・ロール・サーバ３′のウエル・システム１１の言語処理部に記憶し、それを抽象化サービスとして実現させるためには、ウエル・システム１１のグラフ構造化エディタの機能を用いてエイジェント・エキスパート１−２が行う。
【０１５６】
同様に，個々のスペシフィック・ロール・サーバ３″にも，対応するスペシフィック・エキスパート１−３が存在し、この場合のユーザに該当するエイジェントが分配したある特定のサービスを実現するための実際に実行するオブジェクト・ネットワークとそれに関連したテンプレートを設計し、それぞれのウエル・システム１１の言語処理に格納する。
【０１５７】
以上のようなジェネリック・オブジェクト・ネットワークおよび実際に実行するオブジェクト・ネットワークはウエル・システム１１の拡張機能を利用して動的変更を行うことが可能である。
【０１５８】
同様のことが制約条項についても行われる。すなわち制約条項をその時点での入力データと見なし、制約条項を拡張し、設計を行うような制約処理用オブジェクト・ネットワークをジェネリック・オブジェクト・ネットワークと実際に実行するオブジェクト・ネットワークとの両者を設計し、それによって制約条項変更サービスを行うようにシステムを動的に変化させる。これもそれぞれのエキスパートが計画し、方法を実現させる。
【０１５９】
以上のことは、表１に示したサービス機能の計画設計に関しており、エキスパートの役割となり、エキスパートは、ユーザ１−１とサーバとの間の問題解決手段を提供し、その評価によって動的設計を行う。
【０１６０】
データに関連する部分については、ユーザのもつ得意機能とサーバのもつ得意機能に対応して、それぞれデータを理解し参照指示する機能にもとづいて記述内容のもつ役割を分化させ、全体システムを効率化するようにさせている。
【０１６１】
上述の如く、ユーザ１−１は或る目的意図の下でシステムを使用して成果を得る役目を果たすものであり、これに対してエキスパート１−２（又は１−３）はシステムを計画し設計し実現させてユーザ１−１の使用のために提供する。当該エキスパート１−２（又は１−３）も，エイジェント・ロール・サーバ３′やスペシフィック・ロール・サーバ３″との間でのインタラクションを行う場としてコモン・プラットフォーム２が用いられる。
【０１６２】
ユーザ１−１は可視型のオブジェクト・ネットワークを用いデータを入力するなどして操作を行う。オブジェクト・ネットワークは、オブジェクトとして名詞型オブジェクトや動詞型オブジェクトを用いる。他動詞型のオブジェクトでは目的語データや補語データについても可視型として表現され操作される。名詞や動詞についての修飾語ではテキスト形式の文や語を用いることが許される。上記のウエル・システム１１（図３参照）はこの考え方にもとづいて実現されていると考えてよい。
【０１６３】
エキスパート１−２（又は１−３）は、ユーザ１−１が利用できるように、ウエル・システム１１の機能を用いてオブジェクト・ネットワークを設定し、名詞オブジェクトについてはデータ構造としてのテンプレートを用意するようにし、動詞オブジェクトについても同様にサービス名や制約処理のためのテンプレートを用意するようにする。またオブジェクト間に制約条項が存在する場合には、テンプレート内に制約条項へのポインタが設定される。このためにグラフ構造エディタが上記ウエル・システム１１における言語処理系に設けられてオブジェクト・ネットワークの変更や拡張が動的に行われる。この動的な処理は、ユーザ１−１の意図を実現する上での、キーワードにもとづいたデータベースに対する事項検索によって行われる。あるいは、エイジェント・ロール・サーバ３′の助けをかりてユーザ１−１自身がオブジェクト・ネットワークの書き下しや訂正を行う。勿論並行処理の下で行うこともできる。これらのサービス計画は、エイジェント・エキスパートによって設計され、ジェネリック・オブジェクト・ネットワークとしてコモン・プラットフォーム上に表示される。
【０１６４】
エイジェント・ロール・サーバ３′は、サービス計画として、ユーザ１−１の要求に対応したオブジェクト・ネットワークをユーザに提示し、その結果にもとづいてサービス役割の割当てを行い、個々のスペシフィック・ロール・サーバにサービス仕様を与えると共に、プロトコル仕様にもとづいて具体的に各割当てサービスを並行的に実行させる。
【０１６５】
【発明の効果】
以上説明した如く、本発明によれば、クライアントとサーバとの間に、可視的な表示をもってクライアントに通知しかつクライアントからの意図を受け取るコモン・プラットフォームがもうけられ、コミュニケーション・マネージャがクライアント側への可視的表示を用いた情報授受とサーバ側へのデータスキーマに則したデータ構造での情報授受とを仲介するようにしており、クライアントはディスプレイのウインドウに表示された画像と対話を行いながら、所望するオブジェクト・ネットワーク例えばカラー画像生成・色付け処理分野に対する処理を実行することが可能となる。
【図面の簡単な説明】
【図１】本発明の原理構成図を示す。
【図２】エイジェントをもつ構成を示す。
【図３】ウエル・システムとオブジェクト・ネットワークとの関係を説明する図である。
【図４】処理の整合を行う状況を概念的に示した図である。
【図５】処理フロー（Ｉ）を示す。
【図６】処理フロー（II）を示す。
【図７】コミュニケーション・マネージャの働きを示す図である。
【図８】要素ネットワークの関係を示す図である。
【図９】コモン・プラットフォームをもつシステムにおいてカラー画像生成・色付け処理を行う態様を示している。
【図１０】テンプレートのフォーマットを示す。
【図１１】コミュニケーション・マネージャの動作態様を示す。
【図１２】クライアントの指示に対応する動作を説明する図である。
【図１３】情報の交換動作を説明する図である。
【図１４】チェック・モジュールの動作を説明する図である。
【図１５】制約条件の表示態様を示す図である。
【図１６】アイデンティファイ作業を説明する図である。
【図１７】ＦＬＯＷ ＬＩＮＥＳの描画態様を示す図である。
【図１８】うろこパターンの画像を表す図である。
【図１９】ライン用のテンプレートのフォーマットを表す図である。
【図２０】ＬＩＮＥＳを限定する形容詞節を表す図である。
【図２１】属性にFeature 名を記述されたテンプレートを表す図である。
【図２２】テキスチャ描画の流れ(I) を表す図である。
【図２３】テキスチャ描画の流れ(II)を表す図である。
【図２４】オブジェクト・ネットワークに概念を説明する図である。
【図２５】サーバ３′とサーバ３″との処理例を表す図である。
【図２６】中心点を表示した図である。
【図２７】制約処理の統合を表す図である。
【図２８】並列処理を分析した図である。
【図２９】エキスパートの存在を表すシステムの図である。
【図３０】クライアント・サーバ間の対話モデルを表す図である。
【符号の説明】
１ クライアント
１−１ ユーザ
１−２ エイジェント・エキスパート
１−３ スペシフィック・エキスパート
２ コモン・プラットフォーム
３ サーバ
４ ウインドウ
５ ネットワーク・オペレーション・ウインドウ
６ オペレーション・ウインドウ
７ コマンド・ウインドウ
８ メッセージ・ウインドウ
９ データ・ウインドウ
１０ コミュニケーション・マネージャ
１１ ウエル・システム
１２ ウエル・カーネル
１３ グラフ構造エディタ
１４ ウインドウ・マネージャ
１５ ディスプレイ・マネージャ
１６ 関数実行・マネージャ
１７ サービス・モジュール
１８ 分野
１８Ｃ カラー画像生成・色付け処理分野
１９ オブジェクト・ネットワーク
２０ 輪郭部（Frame Section)
２１ カラー部（Color Section)
２２ テンプレート
２３ バッファ
２３’バッファの内容
２４ チェック・モジュール
２５ 制約条件
２７ 名詞オブジェクト
３３ ジェネリック・オブジェクト・ネットワーク
３４ 特定のパラメータや制約条件
３５ スペシフィック・オブジェクト・ネットワーク
【産業上の利用分野】
本発明は，クライアントがサーバと対話を行いながら、クライアントの意図にしたがったサービスを実行してゆく場としての各種ウインドウをもつコモン・プラットフォームを用意し、コモン・プラットフォーム内のコミュニケーション・マネージャが上記ウインドウを介在させて上記クライアントと上記サーバとの間でのデータ表記形式などの整合をとるなどの仲介を行うようにしたコモン・プラットフォーム機能による対話的情報処理装置に関する。
【０００２】
【従来の技術】
従来から情報処理装置の画面に向かって対話を行いつつ処理を実行することが行われる。そして、特開昭６３−１３８４３０号公報、特開昭６３−１３８４３１号公報に示すように、システムがオブジェクトや管理プログラムを意識することなく処理を実行するようにすることが知られている。
上記のオブジェクトに注目してプログラムを組立ててゆくことに関しては、一般に、オブジェクト指向と呼ばれている。諸々の処理を実行する上では、高頻度で利用される「処理対象」が存在する。
当該処理対象となるものは、名詞を示すものであったり、動詞を示すものであったり、あるいは処理に際して存在する制約条件であったりする。これらは夫々名詞オブジェクトとか動詞オブジェクトとか制約オブジェクトとかという表現で特定されている。
名詞オブジェクトをノードとし、動詞オブジェクトをあるノードに対して処理を行うブランチとして表すと、ノード間をブランチで結んだ、ひとかたまりの処理単位が成形されて１つのオブジェクト・ネットワークとみなされることもある。そのオブジェクト・ネットワークとしての処理単位も、高頻度で利用されるものであったとすると、例えば所定の処理を実行する単位としての名詞をつけて、名詞オブジェクトとして取り扱われることもあり、１つのオブジェクトとみなされることもある。
名詞オブジェクトや動詞オブジェクトや制約オブジェクトが所望する目的の処理を実行するものとして結合されたものがオブジェクト・ネットワークであって、オブジェクト・ネットワークは一般に多重階層的に把握されるものである。例えばカラー画像生成・色付け処理を行わせるためには、一般には、多くのオブジェクト（更には多くのオブジェクト・ネットワークを含めて）が組合されて、当該カラー画像生成・色付け処理を行うオブジェクト・ネットワークを構成することになる。例えば輪郭を描くためにオブジェクト・ネットワークと色付けをするためのオブジェクト・ネットワークとが組合わされる。夫々のオブジェクト・ネットワーク（即ち、下位階層のオブジェクト・ネットワークを含めて）は、当該オブジェクト・ネットワークに相当する処理を実行するためのプログラムとして、１つまたは複数のサービス・モジュールが対応づけられている。
クライアントの意図に合わせて所望する処理プログラムを形成して処理を実行させてゆくに当たっては、既存のオブジェクト（あるいはオブジェクト・ネットワーク）を当該目的のために組合わさせて、当該所望する処理プログラムが形成されて処理を実行させてゆくようにされる。換言すれば、既存のオブジェクト（あるいはオブジェクト・ネットワーク）に対応する処理を行う既存のサービス・モジュールを目的に合うように組立ててゆくようにする。
夫々のオブジェクト・ネットワークは、下位階層のオブジェクト・ネットワークや個々のオブジェクトが組立てられたものとして定義される。更に言えば、下位階層のオブジェクト・ネットワークに対応するサービス・モジュールが当該オブジェクト・ネットワークに対応する処理のために組立てられていることを示す情報（サービス・モジュール定義）をもって特定される。
【０００３】
ある課題を解決し処理結果を得るためには、好奇心から意図が発生し、その意図を満足させるようなサービス・システムが必要となる。このために図３０のようなクライアント・サーバ間の対話モデルを考えると、意図をグラフ構造によって表現したオブジェクト・ネットワークによって定義することが考えられる。そして、個々の意図が逐次あるいは並行的にサービスを行う対話図式によって、オブジェクト・ネットワークの内容が表現される。
【０００４】
図３０の左側はクライアントであって当該クライアントが行う意図についての内容記述作業を矩形の枠で示し、図示の右側はサーバであって当該サーバが行う処理を矩形の枠で示し、中央部に点線で囲ってディスプレイなどの表示機能を含む表示的プロセスが介在していることを表している。なお、クライアントが行う意図はクライアントからの指示および／またはデータを受取り、システム側において解読される。
【０００５】
クライアントは興味をもったサービス名によって意図として、表示的プロセスにサービスの要求を行う▲１▼。サーバは当該要求に対応して意図実現計画を実行して当該処理の対象となるオブジェクト・ネットワークを呈示する▲２▼。
【０００６】
当該呈示されたオブジェクト・ネットワークを画面でみながら、クライアントは単位意図の選択を行う▲３▼。この選択された単位意図はサーバ側に示されてそのときの処理を実行する上での制約データや条件や処理を実行する関数計画を実行して画面上で呈示する▲４▼。
【０００７】
クライアントは呈示されたデータや条件や関数を選択する▲５▼。サーバ側では選択されたデータや条件や関数にもとづいてサービス機能実行計画を実行してその実行結果を画面上で呈示する▲６▼。クライアントはその実行結果を評価して次の意図選択を行う▲７▼。
【０００８】
上記の如くクライアントおよびサーバが協調して意図を実現する。即ちクライアントは意図を選択する過程でサーバに単位意図を要求する。これに答えてサーバはサービス実行に必要な制約条項を計画し、クライアントに向けて、それの必要性を応答する。このようなインタラクションのための場が対話に有効である。
【０００９】
対話が円滑であるためには、対話プロセス意味論上の結束性が、意図駆動による意図内容の連接的整合性によって表現され、それはオブジェクト・ネットワークの妥当性を保証する。
【００１０】
【発明が解決しようとする課題】
対話プロセスを円滑に進行させるためには、サービス・プロセスに役割を特化させるのが効率的である。人間にとって表現シンボルとしては、画像・図形の方がテキスト文よりも一眼で直観的に理解されるのに対し、計算機は論理的記述が処理し易い。役割は、理解解読機能、実行処理機能などの諸機能、あるいは述語や表現スタイルなどの記述形式によって規定される。
【００１１】
本発明は、各種ウインドウをもつコモン・プラットフォームを用意し、コモン・プラットフォーム内のコミュニケーション・マネージャがクライアントとサーバとの間でのデータ表記形式などの整合をとるようにして、対話を効果的に進めうるようにすることを目的としている。
【００１２】
【課題を解決するための手段】
本発明は、上記の課題を達成するために、コモン・プラットフォームとテンプレートとを用いるようにしており、オブジェクト・ネットワークに対応した処理を実行する１つまたは複数のサービス・モジュールに対応して、当該サービス・モジュールに対して実行を指示しかつ当該実行結果を出力する処理を実行するサーバを１つまたは複数個そなえ、
クライアントからの指示および／または情報を受取って解読し、上記サーバに対して必要な処理の実行を依頼し、かつ当該サーバから受信した当該処理の結果を上記クライアントが識別できる情報として出力する処理を実行するコモン・プラットフォームをそなえた情報処理装置において、
上記コモン・プラットフォーム（２）が、
上記オブジェクト・ネットワーク（１９）に対応した構成と処理項目とを表す可視的表示項目を表示し、かつ上記クライアント（１）からの指示および／または情報が表示されると共に、上記サーバ（３）が実行した結果が表示されるウインドウ（４）、
クライアント（１）からの指示および／または情報にもとづいて選択された結果を、上記サーバ（３）に伝え、かつ当該サーバ（３）を介して上記サービス・モジュールの１つまたは複数個に処理を依頼した処理結果を上記ウインドウ（４）上に可視的に表示せしめるよう構成され、かつ上記サーバ（３）に指示を行って上記クライアント（１）からの指示および／または情報と上記サーバ（３）が送受する情報との間のデータ表記形式の違いについての翻訳を依頼するコミュニケーション・マネージャ（１０）、および
上記ウインドウ（４）上に可視的表示項目を表示する処理を行うディスプレイ・マネージャ（１５）と、上記ディスプレイ・マネージャ（１５）により上記ウインドウ（４）上に表示されている可視的表示項目を選択する処理を行うウインドウ・マネージャ（１４）と、処理を行うサービス・モジュールの処理に対応して関数処理を実行する関数実行マネージャ（１６）と、オブジェクト・ネットワーク（１９）を管理するグラフ構造エディタ（１３）と、上記コミュニケーション・マネージャ（１０）を介して変換された情報に基づき上記関数実行マネージャ（１６）および／またはグラフ構造エディタ（１３）による処理を制御するウエル・カーネル（１２）とを有するウエル・システム（１１）、
をそなえると共に、
上記オブジェクト・ネットワーク（１９）を構成する個々のオブジェクトに対応して、当該オブジェクトを特定しかつ当該オブジェクトに関する属性を記述したテンプレート（２２）が用意されており、
クライアントが入力したサービス要求情報にもとづいて、上記オブジェクト・ネットワークに対応した処理に対応する上記サービス・モジュールが選択され、
当該サービス・モジュールが処理に関連する個々のテンプレートを特定し、
クライアントからの情報が到来すると上記コミュニケーション・マネージャ（１０）が上記テンプレートを参照し、
当該情報を当該サービス・モジュールが処理できるデータ形式に変換が行われ、
対応するサービス・モジュールによって当該変換されたデータにもとづいた処理が行われ、当該処理結果が上記テンプレート上に格納されるようにされた
ことを特徴としている。
図１は本発明の原理構成図を示す。図中の符号１はクライアント、２はコモン・プラットフォーム、３はサーバを表している。コモン・プラットフォームにおいて、４はディスプレイなどの表示手段上に表示されるウインドウであり、大別して、ネットワーク・オペレーション・ウインドウ５とデータ・ウインドウ９とに分けられる。そして、６はオペレーション・ウインドウであって各種オペレーションを指示可能にする画像や文字を表示するもの、７はコマンド・ウインドウであって各種コマンドを指示可能にする画像や文字を表示するもの、８はメッセージ・ウインドウであって各種メッセージを表示可能にするものを表している。
【００１３】
またデータ・ウインドウ９は、処理結果を表すデータ・ウインドウ（Ｉ）９−１と、処理に必要な制約データなどを表すデータ・ウインドウ（II）９−２とからなる。
【００１４】
１０はコミュニケーション・マネージャであって、ウインドウ４を介して交換されるクライアント１とサーバ３との交信を仲介する。
１１はウエル・システム（各種のオブジェクト・ネットワークに対処できる拡張性をもっているという意味で、以下、エキステンシブ・ウエル・システムと呼ぶことがある）である。１２はウエル・カーネルであって上記コミュニケーション・マネージャ１０や以下の各種マネージャや、グラフ構造エディタを管理し、また作業領域をもっている。１３はグラフ構造エディタであってオブジェクト・ネットワークをも一種のデータと考えて、グラフ構造をテンプレートとして表現して処理を行う。
【００１５】
１４はウインドウ・マネージャであって、ウインドウ４の選択などを処理する機能をもつものである。１５はディスプレイ・マネージャであって、ウインドウを表示するディスプレイを制御する機能をもつものである。１６は関数実行マネージャであって、オブジェクト・ネットワークに対してクライアントの意図に沿った処理を行う上での関数を実行する上での処理を行う機能をもつものである。
【００１６】
１７−１，１７−２は夫々の目的に対応した処理を行うサービス・モジュールである。
【００１７】
【作用】
サーバ３はクライアントが処理対象にしようとしている意図内容を記述しているオブジェクト・ネットワークを呼び出して、グラフ構造エディタ１３はウエル・カーネル１２がもつ作業領域上に当該オブジェクト・ネットワークを記憶する。
【００１８】
この結果にもとづいて、ウインドウ・マネージャ１４などの働きによってかつコミュニケーション・マネージャ１０の仲介によってオブジェクト・ネットワークがオペレーション・ウインドウ６に表示される。
【００１９】
この状態の下で、クライアントは、表示されたオブジェクト・ネットワークにもとづいて、当該オブジェクト・ネットワーク上の全部または一部を特定して自己の意図を指示する。この指示に対応して、コミュニケーション・マネージャ１０が当該意図を解釈し、サーバに対して処理対象となる位置に該当するオブジェクト（名詞オブジェクト）についてのテンプレートを呼び出させる。そしてサービス・モジュールが当該テンプレートに対応した領域準備などを行い、ウインドウ４はそのときの制約データの存在をデータ・ウインドウ（II）９−２に表示する。
【００２０】
クライアントは、制約データをデータ・ウインドウ（II）９−２上で選択し、サーバが実行計画を実行し、サービス・モジュール１７が実行し、ウインドウ４が実行結果をデータ・ウインドウ（Ｉ）９−１に表示する。その結果をクライアントが評価し、次の指示を行う。
【００２１】
【実施例】
図３０に示した如きクライアントとサーバとの間の対話をより効果的に実現させるためには、クライアントと個々の処理を行うサーバとの間に、エイジェントの役割を行うエイジェント・ロール・サーバを介在させることが有効な場合がある。
【００２２】
コモン・プラットフォーム機能は、オブジェクト・ネットワークを表示するウインド５と、実行に伴って必要とするデータおよび実行結果のデータを可視画像として表示するデータ・ウインド９−ｉとを持ち、これらを支援するためのコミュニケーション・マネジャ１０などを有しており、これらの機能によりクライアント１としてのユーザに最も適した表示形式を使用可能にし、それをコモン・プラットフォーム２において、データ処理装置内部での処理用に変換するようにして、ユーザにとって使い易くしている。
【００２３】
一方、サーバ３にとっては、個々のデータなどはインデックス形式のタグが付いたテキスト形式で処理する必要がある。このようなクライアント１とサーバ３とはそれぞれ特有の役割をもっているので、コミュニケーション・マネージャ１０はそれらの役割に応じたデータ形式に変換する役割をもっている。このためのデータの型を規定するためにテンプレートで制御を行うようにする。
【００２４】
このテンプレートにもとづいて、変換が行われるが、この場合クライアント１とサーバ３との役割の差に対応して表記の形式が異なる。クライアントである人間にとっては、テキスト形式よりは、グラフのような図や画像の方が分かり易く、また指示も容易である。特に点や線についてはデータ・ウインド上で直接あるいはマウスによって参照指示が行えることが望ましい。一方、サーバとしての計算機にとっては、点については(x,y) の座標値として数値化され、線については始点から終点まで通過する画素点をリストの形式となっていなければ処理効率が悪い。このような観点から表１に示す如く役割機能に応じて表記形式が異なる必要がある。
【００２５】
【表１】
即ち、点や線を表すデータについては、クライアント１との間では、点や線を実体で表示しまたクライアント１がそれぞれの実体を参照しつつ指示できるようにし、サーバ３との間では、インデックス形式で特定しまた特定されたものについて一括転送したり連合して処理したりする。
【００２７】
図形や画像を表すデータについては、クライアント１との間では、画像や図形を実体表示しまたクライアント１が参照指示できるようにし、サーバ３との間ではリスト構造やラスタ構造で特定するようにする。
【００２８】
データ要素については、クライアント１との間では名前を指示し、サーバ３との間では名前ヘッダで特定するようにする。
サービス機能（エイジェントの抽象化サービス機能）については、クライアント１との間では、サービスをどのようなプログラムで行うかを明細にするサービス構造が先ずジェネリック・オブジェクト・ネットワーク形式で与えるようにする（クライアント１はこれにもとづいて所望するパラメータを与える）。そしてサービス実行の途中では、(i) サービス制約項目をパラメータとしてもつサービス項目や、(ii)サービス名をクライアント１が与え得るようにする。サーバ３との間では、(i) サービス構造表を与え、(ii)クライアント１からのサービス項目の指示に応じて、サービスを実行するサーバやサービスに当たって責任をもつサーバを指定するようにする。
【００２９】
図２はエイジェントをもつ構成を示している。図２に示すクライアント（Client）とサーバ（Specific role server）とが、図３０に示すクライアント１とサーバ３″とに対応している。そして、図２に示す場合には、エイジェント（Agent role server ）が中間において、例えて言えば旅行仲介業者の如き役割をはたすサーバ３′としてもうけられるようにされる。
【００３０】
図２に示す表示的プロセス２−１および従属表示的プロセス２−２は夫々図３０に示す表示的プロセスと同じ機能をもつものである。図２に示す場合には、クライアント１とエイジェント３′との間で表示的プロセス２−１に向かって、サービス要求と応答とが行われる。
【００３１】
エイジェント３′はクライアント１の意図にしたがったサービス計画を準備し、その役割を実行するサーバ（Specific role server）を検索し、サービス役割割当計画を行って、従属表示的プロセス２−２に向かって役割機能を実行すべく要求する。
【００３２】
サーバ（Specific role server）３″は割当サービス実行計画を実行し、実行結果を従属表示的プロセス２−２に呈示する。
エイジェント３′はサービス結果の内容をチェックして、サービス結果をクライアント１に呈示すべく表示的プロセス２−１に指示する。
【００３３】
図２に示す表示的プロセス２−１および従属表示的プロセス２−２は夫々、図１に示すコモン・プラットフォーム２によって実現される。そして図２に示すエイジェント３″は、図１に示すサービス・モジュール１７−ｉの１つとして与えられると考えてもよい。
【００３４】
図１に示すウエル・システム１１は、ＷＥＬＬ（Ｗindow-based Ｅ laborationＬanguage の略) と仮称される機能言語を取り扱う機能部であるとしているが、ＷＥＬＬと呼ばれる特別な言語を取り扱う機能部のみに限定して考えられるべきものではなく、ウインドウを用いて対話を行い得る、より広い意味の処理機能部が図１に示すウエル・システム１１であると考えるべきである。
【００３５】
図３はウエル・システムとオブジェクト・ネットワークとの関係を説明する図である。図中の符号１１は図１に示すウエル・システムに対応している。また１９Ａ、１９Ｂ、１９Ｃは夫々図１に示すサービス・モジュールと組合わせられたオブジェクト・ネットワークであり、１８Ａ、１８Ｂ、１８Ｃは夫々所定の処理分野であり、図示の場合１８Ｃはカラー画像生成・色付け処理（ Color Picture Processing and Painting)分野を表している。
【００３６】
ＷＥＬＬと仮称される機能言語に対して分野に対応するオブジェクト・ネットワークを与えると当該オブジェクト・ネットワークの処理がプログラムレスで実行が可能となる。また当該言語はウインドウ指向の言語であり、クライアントとのインターフェースはウインドウを介すことによって、クライアント・サーバ・モデルが実現される。
【００３７】
図３においては、ウエル・システム１１に対して、例えばカラー画像生成・色付け処理分野１８Ｃに対応して必要とされるウインドウと当該対応する処理を行うサービス・モジュール定義とで与えられるオブジェクト・ネットワーク１９Ｃを組合わせると、図示点線で示す如く当該ウエル・システムはカラー画像生成・色付け処理分野１８Ｃに対応するシステムとなる。言うまでもなく他の分野のオブジェクト・ネットワーク１９Ａや１９Ｂを組合わせると分野１８Ａや分野１８Ｂに対応するシステムとなる。
【００３８】
システムを構成する言語処理系に与えられるオブジェクト・ネットワークを変更すれば、システム機能は変化する。処理系は、対象とするオブジェクト・ネットワークの構成記述を入力データとして与えることにより、該当する分野処理を行うのであるから、ＷＥＬＬは元来グラフ構造エディタ１３を持っている。従ってシステムに、実行時にオブジェクト・ネットワークの変更機能を持たせることにより、システムの拡張性を持たせられる。特にインターフェースのために制約条件を名詞オブジェクトに持たせ、コモン・プラットフォーム中にあるメッセージ・ウインドウを利用できる。
【００３９】
互いに独立性のある多分野間の協調的統合のためにも拡張性は必要である。それは名詞オブジェクトについての制約関係の変更、動詞オブジェクトの実行制御についての同期性や排他性の動的変更など並行実行中のシステム環境への適応性がある。この場合、共通資財や計画修正などの管理の際に発生する役割転換を行う必要があり、得意機能に対応する対応処理機能を新しい共通の場の導入によって整合させる必要性が発生する。
【００４０】
図４は処理の整合を行う状況を概念的に示した図である。図示左端のクライアントが意図Ａないし意図Ｎをもって対応するサービスＡないしＮを並行して実行させようとするとき、各サービスを実行する上での制約が存在することが多い。このような制約には、時相制約的なものと形態制約的なものとが存在し、前者にって実行時の規制やサービス間時相調整制御が行われ、後者によってサービス間形態調整制御が行われる。そして、このような規制や制御が行われた上で実行された複合サービス結果内容についてのチェックが行われ、クライアントに対してウインドウを介して呈示され、クライアントが評価を行うこととなる。
【００４１】
図５と図６とは一緒になって１つのフローチャートを示すものであって、図１に示す構成が用いられる態様を表すフローチャートを示す。
（Ｓ１）：例えばカラー画像生成・色付け処理分野１８Ｃに対応する処理を行う場合、サーバが該当するオブジェクト・ネットワーク１９Ｃを呼び出す。
【００４２】
（Ｓ２）：これに応じて、グラフ構造エディタは、ウエル・カーネル１２上の作業領域上に当該オブジェクト・ネットワークを格納する。
（Ｓ３）：ウエル・カーネル１２によって、図１示すウインドウ・マネージャ１４やディスプレイ・マネージャ１５を起動しまたカーネル１２が当該各マネージャからの応答を受けるなどの処理をへて、コミュニケーション・マネージャ１０の仲介によって、オブジェクト・ネットワークがオペレーション・ウインドウ６に表示される。
【００４３】
（Ｓ４）：クライアント１は、オペレーション・ウインドウ６上のオブジェクト・ネットワークをみた上で、当該オブジェクト・ネットワーク上の全部または一部を特定して自己の意図を指示する。
【００４４】
（Ｓ５）：この状況をコミュニケーション・マネージャ１０が識別し、カーネル１２を介在させて、サーバに対して処理対象となる位置に該当するオブジェクトについてのテンプレートを呼出させる（サーバがテンプレートを呼出す）。
【００４５】
（Ｓ６）：サービス・モジュールは当該テンプレートに対応した領域準備を行う。
（Ｓ７）：コモン・プラットフォームにおいては、当該テンプレートに記述されていることのある制約データを抽出して、当該制約データをデータ・ウインドウ（II）９−２に表示する。
【００４６】
（Ｓ８）：クライアント１は当該制約データをみて、その中から所望する制約データを選択する。
（Ｓ９）：この状況をコミュニケーション・マネージャ１０が識別し、カーネル１２を介在させ、サーバに通知し、サーバが実行計画を実行する。
【００４７】
（Ｓ１０）：これにともなって、サービス・モジュールが所望される処理（例えば、線引きや色付けなどの処理）を実行する。
（Ｓ１１）：処理結果をデータ・ウインドウ（Ｉ）９−１に表示する。
【００４８】
（Ｓ１２）：クライアントはその処理結果を評価し、次の指示を行う。
図７はコミュニケーション・マネージャの働きを示す図である。図中の符号は図１に対応している。なお図７においてウインドウ４に対応して「コモン・プラットフォーム」というラベルを付しているが、図１に示すコモン・プラットフォーム２においてクライアント１から直接見える所がウインドウ４であってコモン・プラットフォーム２を代表しているとも考えられることから「コモン・プラットフォーム」とラベルを付しているだけであり、図１に対応するとウインドウ４に該当しているものである。
【００４９】
図７に示す如くクライアントの意図がウインドウ４を介してシステムに伝えられるときには、必ずコミュニケーション・マネージャ１０を経由してカーネル１２や各マネージャ１４，１５，１６更にはサービス・モジュール１７−ｉに伝えられる。このことから、コミュニケーション・マネージャ１０はウインドウ４に直結している唯一のマネージャとなり、対話プロセスを集中的に管理している。当該コミュニケーション・マネージャ１０の働きについては更に詳しく後述される。
【００５０】
上述の如くＷＥＬＬは分野を問わない拡張性のある言語である。それぞれの分野に対応するウインドウ定義やサービス・モジュール定義といったオブジェクト・ネットワークを与えると、ＷＥＬＬはその分野に対応する形で分野記述言語となる。このＷＥＬＬを用いたウエル・システムは、ウエル・カーネル１２と各種マネージャ１４，１５，１６など（ウエル・マネージャ）との２つの要素から構成される。
【００５１】
エキステンシブ・ウエル・カーネル１２は、以下の項目を行う。
（１）データ状態の把握（プロセスの把握を行い、次に実行するべき関数の選択）
（２）イベントの解析（各ウインドウから送られてくるイベントを判別し、その結果に対応するシステム内のプロシージャをコール）
（３）関数実行要求（総称的関数に制約条件を付加し、関数の実行をリクエスト）
また各マネージャは以下の４つに分けられる。
（１）コミュニケーション・マネージャ１０（テンプレート（データ）の間接的管理及びコモン・プラットフォームからの入力に対する各マネージャの制御）
（２）関数実行マネージャ１６（関数の実行管理）
（３）ウインドウ・マネージャ１４（ウインドウの管理）
（４）ディスプレイ・マネージャ１５（テンプレートの数値変換）
分野に依存しないＷＥＬＬと分野依存のサービス・モジュール１７−ｉとのデータ変換は、コミュニケーション・マネージャ１０が行う。このコミュニケーション・マネージャ１０を介すことによって、あらゆる分野のデータを扱うことが可能となり、ウエル・システム自体の汎用性は失われないこととなる。
【００５２】
ウインドウ４はクライアント１との間のインターフェースを行うものであり、以下の５つの個々のウインドウが存在する。
（１）ネットワーク・オペレーション・ウインドウ５（システム全体の制御）
（２）オペレーション・ウインドウ６（ネットワークのオペレーション表示及びその制御）
（３）コマンド・ウインドウ７（選択候補の表示及びキーボードからの入力）
（４）メッセージ・ウインドウ８（システム側からのメッセージ表示）
（５）データ・ウインド９−１，９−２（データの表示）
言うまでもなく、ある役割をプロセッサに導入する時、オブジェクト・ネットワーク中の個々のオブジェクトについての当該オブジェクトの表現方法は、役割依存でなければならない。人間に対しては、可視オブジェクトであり、計算機にとってはデータスキーマに則したデータ構造によって、オブジェクトが表現される必要がある。オブジェクト・ネットワークは個々のプロセッサで共有するが、データ構造は、テンプレート形式で定義されて、相互変換可能とされる。
【００５３】
オブジェクト・ネットワークを構成する各オブジェクトとしては、分野記述言語の枠組みに従って、名詞オブジェクトと動詞オブジェクトと制約オブジェクトとされ、制約オブジェクトは、被制約オブジェクトと制約条件とが属性として与えられ、そのための妥当性が各マネージャによって判定されて対応するオブジェクト処理を行いうるようにされる。
【００５４】
上述のウエル・システム１１にカラー画像生成・色付け処理分野をあてはめると上記ＷＥＬＬはいわばＷＥＬＬ−ＰＰＰ（Window-based Elaboration Language for Picture Processing and Painting ）となる。そしてウエル・システム１１はカラー画像生成・色付け処理システムとなる。この場合の１つのオブジェクト・ネットワークである要素ネットワークは、個別オブジェクトの外観を表しかつ領域を確保している輪郭（Outline)を生成する輪郭部（Frame Section)と、ラインとそれによって確保されている領域にしたがって属性値（Attribute value)を与えるカラー部（Color Section)とからなる。
【００５５】
図８は要素ネットワークの関係を示す図である。図８における左半分の「フレーム」２０は上述の輪郭部（Frame Section)に該当し、右半分の「カラー」２１は上述のカラー部（Color Section)に該当している。
【００５６】
輪郭部２０ではデータ自身を表す項目（Entity）を作成し、カラー部２１では輝度、色度などを表す属性（Attribute)を作成する。各クラスの状態は以下のようになる。
＜ＮＯＮＥ＞まだ処理の行われていない状態を表す
＜ＰＯＩＮＴ＞輪郭の基本となる点を示し、これを主要点（Principal Point)と呼ぶ
＜ＰＯＩＮＴ ＳＥＱＵＥＮＣＥ＞主要点に対し、その接続順序を示す
＜ＬＩＮＥ ＳＥＧＭＥＮＴ＞接続順序に基づいてスプライン関数で補間処理がされた状態
＜ＬＩＮＥ＞ＬＩＮＥ ＳＥＧＭＥＮＴを接続して１つのラインを完成した状態＜ＲＥＧＩＯＮ ＳＥＧＭＥＮＴ＞画像におけるその水平走査線１本分の領域を示す
＜ＲＥＧＩＯＮ＞ＲＥＧＩＯＮ ＳＥＧＭＥＮＴを画像に沿って上下方向に接続したものを示す
＜ＣＯＬＯＲＥＤ〜＞輝度、色度情報を示したそれぞれの項目を表す。また輪郭部とカラー部を結ぶＩＤＥＮＴＩＦＹは以下のように定義される。
〔ＩＤＥＮＴＩＦＹ〕処理の対象を特定する作業を示す。
【００５７】
図８に示す如きネットワークを利用してクライアントが絵を描く処理を行うことができる。当該処理の態様に関しては、本願発明と直接関連するものではないが、先に特許出願している特許第２８０１４５９号（特開平５−２３３６９０号公報）（オブジェクト・ネットワークによる言語処理システム）にも一部記述されている。
【００５８】
図９はコモン・プラットフォームをもつシステムにおいてカラー画像生成・色付け処理を行う態様を示している。図中の符号１，２，３は図１に対応している。
【００５９】
コモン・プラットフォームにおけるウインドウの表示によって、視覚的に要素ネットワークが組み込まれたことがクライアントにわかると、クライアントは描画するために必要な意図を選択する（クラス選択）。この例では点に輝度・色度を与えるＣＯＬＯＲＥＤ ＰＯＩＮＴを選択する。
【００６０】
点に色をのせたいというクライアントの要求に対して、サーバは情報を格納するためのテンプレートを準備し（ＤＥＦＩＮＩＮＧ ＰＲＯＣＥＳＳ）、どの点に対して色情報をのせたいのかクライアントに要求する。テンプレートについては後述される。
【００６１】
クライアントが点を指定すると（ＩＤＥＮＴＩＦＹ）、サーバはインデックスを参照することでその点を認識する。そしてその点にのせる輝度・色度データをクライアントに要求する。
【００６２】
クライアントからデータを応答として受け取るとＤＥＦＩＮＥ ＯＰＥＲＡＴＩＯＮとしてテンプレートにデータを入力し、その結果としてのカラー画像をウインドウに表示する。
【００６３】
この表示によってクライアントは、そのプロセスを認識し、それを評価し、次の意図選択へ移ることができる。このようにクライアントはサーバからの意図を可視化オブジェクトとして把握する。
【００６４】
上述の如く描かれる点や線は夫々上述の名詞オブジェクトの形で管理され、また個々の名詞オブジェクトに対して行われる処理態様は上述の動詞オブジェクトとして与えられる。
【００６５】
上述のコミュニケーション・マネージャ１０は、ＷＥＬＬの拡張性を維持するためにデータ相互関係を管理する。そのためにデータは、テンプレートとして一元的に管理され、そこに属性を自由に設定できるようにされている。
【００６６】
図１０はテンプレートのフォーマットの一例を示す。個々のテンプレート２２がその属するオブジェクトについての番号に対応するかを示すインデックスと、座標と、属性とをもつ。テンプレートは、サービス・モジュール１７−ｉ内では「インデックス」によって管理されるが、データ・ウインドウ９を通してクライアントから与えられるものは、データ・ウインドウ９上の座標値である。サービス・モジュール１７−ｉは、座標値からテンプレートのインデックス検索を行えないので、コミュニケーション・マネージャ１０は座標値をインデックスに変換し、それをサービス・モジュール１７−ｉに引き渡す。更に、コミュニケーション・マネージャ１０は、ウエル・システムの持つ対話プロセスを集中管理する。コモン・プラットフォームは、（ｉ）クライアントにオペレーションを伝えるオブジェクト・ネットワーク、（ii）メッセージや選択項目を伝えるメッセージ・ウインドウ、(iii）実際に描画などの作業を行い、画像データなどを表示するデータ・ウインドウなどを持つが、それらのウインドウを通して得られたクライアントの意図を実現するために、コミュニケーション・マネージャ１０は、その意図内容の入力に応じて、それを各マネージャやカーネルへ伝える。コミュニケーション・マネージャ１０のこのような対話プロセスの一元管理により、データが必ずここを通過することになり、テンプレートのチェックを行ったり、制約条件のチェックを行うことも可能になってくる。
【００６７】
図１１はコミュニケーション・マネージャの動作態様を示す。図中の符号１，３，５，８，９，１０，１２，１４，１５，１７は夫々図１中の符号に対応している。
【００６８】
ウインドウ上でのクライアントによる指示点（ｘ，ｙ）などがデータ・ウインドウ９からコミュニケーション・マネージャ１０に伝えられ、メッセージはメッセージ・ウインドウ８を介して伝えられ、オペレーションはオペレーション・ウインドウ５を介して伝えられる。そしてそれらは夫々コミュニケーション・マネージャ１０によって各種他のマネージャ１４，１５やカーネル１２やサービス・モジュール１７との間で情報の送受が行われる。
【００６９】
図１０に示す如きテンプレートは、点や線のデータ、図形／画像データなどに対応して用意されるものである。これは、点や線のデータ、図形／画像データなども、コモン・プラットフォームにおいて取り扱われるデータであることによる。それらは、オブジェクト・ネットワークの中でノードを形づくる名詞オブジェクトに属している。
【００７０】
したがって、データをクライアントが表示させあるいは参照しようとする場合、ウインドウ４上に表示されているデータの参照部分をマウスなどで示すと共に、名詞オブジェクトをオブジェクト・ネットワーク上で参照指示する。
【００７１】
このような参照指示機能は、クライアントが動詞オブジェクトの目的格としてのデータを指示することを主眼とするものである。これに対して、実体表示に当たっては、サーバが実行処理した結果をクライアントにみせるのに実際の点、線、図形、画像を実体としてウインドウ４上に見せるようにする。サーバ側ではデータを蓄積し、処理を行うに当たって、具体的なデータ構造（例えば、インデックス付加リスト構造、ラスタ構造など）に沿って蓄積したデータに対して処理を行う。
【００７２】
図１２はクライアントの指示に対応する動作を説明する図である。図中の符号１，４，１０，１２，１５，１７−ｉは夫々図１に対応し、２３はカーネル１２内にもうけられている作業用のバッファ、２３’はバッファ２３上の内容例、１９Ｃはオブジェクト・ネットワークを表している。
【００７３】
今、カラー画像生成・色付け処理がある程度進行しているとする。この場合、画像生成・色付け処理に対応するオブジェクト・ネットワーク１９Ｃから、該当するサービス・モジュール１７−ｉに対して、点や線などに対応するテンプレートがデータとして与えられ、当該サービス・モジュール１７−ｉからカーネル１２上（なお、バッファ２３はコミュニケーション・マネージャ１０上に位置していてもよい）のバッファ２３に対して、図示のバッファ内容２３’の如く、テンプレートのコピーが書き込まれている。即ち、例えば（ｉ）インデックス「１」で特定される点の座標が（５０，４０）であって色度や輝度（属性で示される）については未定（？で表している）であり、（ii）インデックス「２」で特定される点の座標が（８０，２５０）であって色度や輝度は未定であり、(iii）インデックス「３」で特定される点の座標が（２７０，４００）であって色度や輝度は未定であり、・・・の如き、各テンプレートのコピーがバッファ２３上に記述されている。
【００７４】
この状態の下で、いま、クライアント１がウインドウ４上で例えば座標（８０，２５０）を指示して１つの点を特定したとすると、コミュニケーション・マネージャはその動作を検出し、座標値についてウインドウ・マネージャ１４が検出してコミュニケーション・マネージャ１０に通知する。したがって、コミュニケーション・マネージャ１０は当該指示された点の座標値（８０，２５０）と対応するインデックス値を検索する。すなわちコミュニケーション・マネージャ１０はバッファ２３の内容にもとづいて座標（８０，２５０）をもつテンプレートに対応するものがインデックス「２」であることをコミュニケーション・マネージャ１０は知り、その後の処理に移る。
【００７５】
したがって、輪郭部で打たれた主要点の全座標を作業領域にコピーしたテンプレートと送られた座標との照合が行われる。一致もしくは近似の座標を検索するとそのインデックスを特定し、コミュニケーション・マネージャ１０はサービス・モジュール１７−ｉに送り制御を行う。サービス・モジュール１７−ｉはそのインデックスをもとにそのテンプレートの値を更新する。例えば座標位置を変更したり、属性上での輝度値を記述したりする。当該更新されたテンプレートはディスプレイ・マネージャ１５によって可視化オブジェクトに変換されウインドウ４に表示される。この場合は打たれた点がクライアントに認識できるように反転し浮き上がる。このようにエキステンシブ・ウエルは常にインデックスを中心に管理しているサービス・モジュール１７−ｉと情報交換をする。こうすることで特定の分野に依存しない拡張性の高いシステムが実現できるとともに、どのような分野に対してもクライアントはサーバの意図をディスプレイ・マネージャ１５によって変換された可視化オブジェクトをみて操作できる環境を提供する。
【００７６】
図１３は情報の交換動作を説明する図である。図中の符号１，４，６，９，１０，１２，１４，１６，１７は夫々図１に対応している。
クライアントがサーバと情報のやりとりを行う際、クライアントは常にウインドウを介して情報のやりとりを行う。そのためシステムは常にウインドウで待ち状態になっていなければならない。クライアントの意図によって駆動される駆動（Event Drivenという）にたいして、システムの制御をウインドウでの待ち状態にする駆動をData Driven という。Colored Point のクラスが選択されていてそれを駆動するのがEvent Drivenである。しかし輝度・色度のデータが与えられなければ、関数は実行できないのでウインドウにてクライアントの入力待ちとなる必要がある。この駆動がData Driven である。
【００７７】
図１３において、クライアント１が或る座標上の点を指示して上記イベント・ドリブン（Event Driven）を行ったとする。この状況の下で、「コミュニケーション・マネージャ１０によってウインドウ・マネージャ１４に通知された上でウインドウ・マネージャ１４が座標値（例えば８０，２５０）を報告し、対応するインデックス「２」が調べられてサービス・モジュール１７−ｉに通知される」ことは、図１２に関連して説明した通りである。
【００７８】
今、クライアント１が当該点に対して色付けを行おうとしているとすると、図８に示したクラス「 Colored Point」の状態分析をカーネル１２が行う。当該分析を行ったカーネル１２は関数実行マネージャ１６に対して関数実行要求を発する。これによって関数実行マネージャ１６は与えられる制約条件（Constraint）によって具体的関数を特定する。サービス・モジュール１７−ｉは特定された具体的関数にもとづいて処理が実行可能であるかを判別し、当該処理に必要なデータが不足していればカーネル１２を介して必要な作業を行う。例えば今、サービス・モジュールはクライアントに特定された点のテンプレートに輝度・色度情報を入力するようにしているとすると、輝度・色度データが未定であるため、関数の実行ができない。ここでData Driven が駆動され、この場合データ入力に必要なChrominance Diagram とLuminance Diagram が開かれ、輝度見本や色見本が表示され、クライアントの入力待ちとなる。
【００７９】
サービス・モジュール１７−ｉは必要なウインドウ（図１３に示すＤＩＡＧＲＡＭのためのウインドウ）を開いて、ユーザの応答を待つが、その応答以後そのウインドウが不要になる場合がある。またサービス・モジュールによっては多数のウインドウを必要とするものも考えられるため、表示されるウインドウは必要最小限にするべきである。そこでウインドウ・マネージャ１４内にウインドウの状態を示すテーブルを用意し、不要ウインドウの自動消去を行う。
【００８０】
図１４はチェック・モジュールの動作を説明する図である。図中の符号８はメッセージ・ウインドウ、９はデータ・ウインドウ、２２はテンプレート、２４はチェック・モジュール、２５は制約条件、２６はオブジェクト・ネットワークを表している。
【００８１】
クライアントは、オブジェクト・ネットワークに従った作業の流れの中で、自分がデータ・ウインドウ上に生成していったデータの正当性を確認したいと思うことがある。そのようなクライアントが確認したいと思う事柄を一つの制約条件として捉える。このような制約条件２５は、オブジェクト・ネットワーク２６のそれぞれの名詞オブジェクト（テンプレート２２で表されるデータの状態）に付属的なものとして課され、サーバ側では、その制約条件とテンプレートの内容とを比較することで確認作業を行う。ここで問題にされるのは、サーバが、処理対象とされるテンプレートの特定方法（Identify）をどのように持つべきかである。ウエル・システムでは、コミュニケーション・マネージャの機能を利用してこれを実現できる。コミュニケーション・マネージャ１０は、オブジェクト・ネットワークの持つテンプレートの内容データによってクライアントとサーバとの間のデータの整合性を管理しているので、クライアントがマウスでヒットした座標値（Ｘ，Ｙ）から上記図１２を参照して説明した如く処理対象を特定するための情報をテンプレート２２から引き出して、チェック・モジュール２４（具体的に制約条件をテンプレートに照らし合わせるサービス・モジュール）に渡すことが出来る。チェック・モジュールでは、その情報を頼りに、その制約条件が満足されているかどうかを確認し、その結果をメッセージ・ウインドウを通してクライアントに知らせる。このようなチェック・モジュール２４によるチェック動作は、図８において例えばクラス＜ＰＯＩＮＴ＞の状態からクラス＜ＣＯＬＯＲＥＤＰＯＩＮＴ＞の状態へ移行した際に、正しい形で移行が行われたか否かをチェックするためなどに利用される。更に他の制約動作も、他のサービス・モジュールと同様に対応するマネージャを用意することで実現される。
【００８２】
図１５は制約条件の表示態様を示す図である。図中の符号５，８，９，１０は図１に対応し、２５は図１４に示される制約条件、２７は名詞オブジェクトを表している。
【００８３】
図形描画の間に、例えば描かれたライン（線分）に対してどのような制約条件が付されているかをクライアントに知らせる必要があることがある。このような場合の各マネージャの動作が図１５によって説明される。
【００８４】
上記ライン（線分）は、それ自体がデータの状態を表していることから、名詞オブジェクト２７の１つとして捉えることができる。上記制約条件２５は名詞オブジェクト２７に対応して付されているが、ライン（線分）という状態に対して課され得る制約条件２５として考えられるのは「連続性（Continuity）」と「対称性（Symmetry）・・・（註）当該線分がある軸または点に対して対称な状態にあるか否か」といったものである。
【００８５】
名詞オブジェクト２７がもつこのような制約条件２５はコミュニケーション・マネージャ１０の介在の下でメッセージ・ウインドウ８に表示されてクライアントに知らされる。なお図１５において、メッセージ・ウインドウ８の内容に関して「Symmetry−Point,Axis」とあるのは「点対称」か「線対称」かを問う表示である。当該表示に対応して、クライアントは「Point 」か「Axis」かをピック・アップするようにして意図をサーバ側に通知する。
【００８６】
図１４に示すチェック・モジュール２４は、メッセージ・ウインドウ８を通しての起動要求をクライアントから受けるとファンクション・マネージャによって起動される。チェック・モジュール２４は、必要があればクライアントに対してアイデンティファイ作業の要求をメッセージ・ウインドウ８を用いて行う。クライアントは、それに対してマウスでデータ・ウインドウ上の可視化対象をヒットすることでコミュニケーション・マネージャ１０へその対象についてのデータ値の引き渡しを行う。このデータ値は、コミュニケーション・マネージャ１０によって図１２に示す如く対象に相当する項目データのインデックスに変換されるとチェック・モジュール２４へ送られ、このインデックスを使ってチェック・モジュール２４は、テンプレートから具体的な属性値を引き出してチェックを行う。チェックされた結果は、メッセージ・ウインドウによってクライアントに知らされる。
【００８７】
図１６はアイデンティファイ作業を説明する図である。図中の符号４，５，８，９，１０，１４，１７−ｉは夫々図１に対応している。
上述の如くチェック・モジュール２４がクライアントに対してアイデンティファイ作業の要求を行うと、クライアントはデータ・ウインドウ９上で、図１６に示す如く、例えばあるライン（線分）をヒットする。これに対応して図１２に示した如くウインドウ・マネージャ１４の働きによって関連しているデータがコミュニケーション・マネージャ１０に知らされ、コミュニケーション・マネージャ１０が、対応するインデックスを知り、当該インデックスをチェック・モジュール２４に通知する。これによって、図１４に示した如く、チェック・モジュール２４がチェックし、その結果がメッセージ・ウインドウ８において表示される。
【００８８】
なお、図形描画における点や線が名詞オブジェクトとしてデータの１つとして把握され、図９に示す「単位意図（要求）」などの要求が動詞オブジェクトとして対応づけられる。そしてそれらの名詞オブジェクトや動詞オブジェクトが夫々テンプレートの形で表現される。
【００８９】
上述した構成と動作とについて、より具体的に例を挙げつつ説明を補足する。図２において、クライアント１の意向に従ってサービス計画を準備するようにする。例えば、図１７に示す如き魚のうろこパターンのようなテキスチャを描画したいとの意図をクライアントが持つとき、テキスチャ描画の意図をサービス依頼（要求）としてエイジェント・ロール・サーバ３′に伝えると、エイジェント・ロール・サーバ３′は流れ線(flow lines)とセル画像(cell picture)とをクライアントと協力して描画するサービス計画を具体的に準備する。流れ線を書くには、図８の要素ネットワークがある要素画像を描くために利用できるので、それを利用する。すなわち、図８中でPOINT からLINEまでの部分ネットワークをまずオブジェクトネットワークとして表示する。
【００９０】
それは図２に示す役割サーバ検索（事項検索）が流れ線(flow lines)のlineの事項を検索すると、相当する単語が要素ネットワーク中に存在することを検索し、その部分オブジェクト・ネットワークを、コモン・プラットフォーム２に「flow line 」の表示と共に表示する。
【００９１】
クライアント１は当該表示に従って図１７（ａ）に示すように魚体を示す点線を沿う形で曲線ＡとＢとを描く。
次に図１７（ｂ）に示すように、線Ｃ，Ｄを描く。このとき、How many points do you divide on C and D ? の如き質問がエイジェントからメッセージ・ウインドウ８に表示され、それに対してクライアント１が値「４」とキーインして答えると、図１７（ｃ）に示すように、４個の補間曲線が引かれる。次のステップで質問How many points do you divide on A and B ?に対し値「１６」と答えると、各補間曲線上に図１７（ｄ）に示す如くうろこを描くための１６個の中心点が表示される。この場合、Flow linesについての制約条件として隣接するFlow linesとの間の距離に比例して中心点間距離が大きくなるような制約条件が与えられるとすると、即ち、Flow lines間隔が狭ければ、Cell Pictureとしての「うろこ」の寸法が小さくなければならないとすると、このため次のSatisfying文制約記述が与えられる。
Satisfying :
Every length between adjacent points along flow line is proportional having a fixed ratio with vertical length at the point between adjacent flow lines,
end.
それと同時に「cell picture」の表示と共にうろこパターンを画像を描くようにFlow linesと同時に要素ネットワークとしてのオブジェクト・ネットワークが表示され、クライアントはそれに従って図１８に示す如く、上記中心点（×印）を中心としてうろこのカラー画像を描く。
【００９２】
この処理は、図５の処理フロー（Ｉ）に従って実行される。
この実行をある特定のスペシフィック・ロール・サーバ３″に割り当てるために、図２に示すサービス役割割り当て計画（サービス仕様）によって実施すべき処理内容があるサーバに要求される。
【００９３】
それが図２に示すサービス役割機能（要求）として計画されたスペシフィック・ロール・サーバに実行要求が発行される。この発行はエイジェント・ロール・サーバ３′とスペシフィック・ロール・サーバ３″との間での共通の場を通じて機能する。
【００９４】
エイジェント・ロール・サーバ３′に依存した図２に示す従属表示的プロセスで所定の表示が行われて、エイジェント・ロール・サーバ３′とスペシフィック・ロール・サーバ３″との交信が行われ、当該従属表示的プロセスがコモン・プラットフォームとして、エイジェント・ロール・サーバ３′とスペシフィック・ロール・サーバ３″群との間の連絡通信の場を提供する。したがって、エイジェント・ロール・サーバ３′が複数のスペシフィック・ロール・サーバ３″に依頼した複数の処理内容、この例では「Flow lines」と「cell picture」との間に存在する整合性についての制約条件について規定し、実行する必要がある。
【００９５】
そのための前提条件として、予めテンプレートについての定義を行うことを必要とする。点についてのテンプレートは図１０のように定義され、そこでの属性値集合としてのattributes for point(s)(x,y)として、当該点に関する輝度、色度などの属性値を入れるべきデータ形式が示されている。Lineについては、走査線インデックスを"i" とすると、"i" についてのリスト構造として(x,yi ）の値が、図１９に示す如きLine用テンプレートが定義される。
【００９６】
即ち、当該Lineが走査線と交差する各点のうちの主要点No.1,No.2...No.nについてのテンプレート（図１０参照）上のattributes for point(s)(x,y)に、入口側のポインタｐと当該点の輝度と当該点の色度ベクトルと出口側のポインタｐとが記述され、上記夫々のポインタによって他を指示することによって、全体が１つのLineに対応するLine用テンプレートとして定義される。
なお、図１９に示す各点の属性値に輝度と色度ベクトルとを記述しているのは次の理由による。即ち、Point とColored point とがオブジェクト・ネットワーク中に定義されているような要素ネットワークでは、最初からPoint のテンプレート中に、Colored の修飾形容詞に対応した輝度値や色度ベクトル値を属性値として持たせることが望まれるからである。
【００９７】
FlowというLineを限定する形容詞節が付加されると、そのためにテンプレートに付加属性のためのスペースを必要とする。このスペースの設定は予め行われてもよいし、エクステンシブル WELL の機能の拡張機構としてのグラフ構造エディタを用いて必要時点で設定してもよい。
【００９８】
図１７（ｃ）に示した流れ線を示すようにする当該形容詞節で特定するデータ構成としては、図２０に示す如きものが用意される。図２０における符号３０はFlowという『Lineを限定する形容詞節』につけられたインデックスであり、符号３１は当該Flowに属するLineについてのインデックスであり、符号３２は当該Lineについてのデータ配列（図１９に示す如きもの）である。
【００９９】
Colored point についてFeature という形容詞をつけて、それをFeatured colored pointとすると、テンプレートの属性の所に、図２１に示す如く、Feature 名を付加する。Feature 名の所には、"edge","highlight"または"none"を記述するようにする。"edge"が記述されると、その点が輝度や色度ベクトルからエッジと識別されたことを示す。"highlight" が記述されると、その点がハイライトとして示されることを示す。また"none"が記述されると、その点にはFeature を持たないことが示される。
【０１００】
そのいずれにしても、Flow linesに対して図１７に示したようなＡ，Ｂ，ＣおよびＤの４個のLines に対応して、夫々のLine用テンプレートが準備される。次にクライアント１とコモン・プラットフォーム２中のメッセージ・ウインドウ８との通信によって更に４本のFlow linesのためのLine用テンプレートが設定される。次に"cell picture"を描画するために、オブジェクト・ネットワーク（図８に示す如き）に対応したオブジェクトに対応してテンプレートが設定され、最後のColred Region では輝度色度データをもつラスタ形式のテンプレートを持つようになる。
【０１０１】
このように設定された「うろこ」画像を、流れ線上に設定された中心点に「うろこ」の中心点を合わせ、サイズを選んで写像する。この際、制約条件を必要とする。
【０１０２】
この時点までにおいて、Interval between the adjacent center points on the flow lines が各center pointに定義されている。即ち、各flow line がもつ属性としてIntervalが定義されており、flow line のdrawing の実行後計算され、属性値として、各center points についてのテンプレート中にそのInterval値が格納されている。
【０１０３】
そして同様に、cell pictureのもつ属性としてscale をもち、そのscale 値とinterval値との間の制約関係として、
a scale of cell picture = the interval between the adjacent center points on the flow line
を設定する。そしてこれを満足するように、mapping を行うスペシフィック・ロール・サーバ３″にそのmapping を依頼する。
【０１０４】
図２２と図２３とは上下に組合されて１つの流れを表すテキスチャ描画の流れ図を示している。
クライアント１の意図する所が、図２２、図２３における左端に、上から下に向かう時系列で示される。またエイジェント・ロール・サーバ３′の処理が、図２２、図２３の左右中央部に、上から下に向かう時系列で示される。さらにスペシフィック・ロール・サーバ３″の処理が、図２２、図２３における右端に、上から下に向かう時系列で示される。また図２２、図２３における符号１，２−１，２−２，３′，３″は図２に対応している。更に図２２の下端における矢印（Ａ）は図２３に示す矢印（Ａ）につらなるものである。
【０１０５】
クライアント１がテキスチャ描画を意図してテキスチャ・サービスを要求すると、エイジェント・ロール・サーバ３′はテキスチャ描画サービス計画を準備し、統合サービス・プラットフォームを設定する。これにもとづいて、クライアントは図１７に示した如きFlow line を表示させようとして、Flow line 表示を要求する。
【０１０６】
エイジェント・ロール・サーバ３′はフローライン計画を検索し、スペシフィック・ロール・サーバ３″に対してフローライン実行サービス設定を要求する。スペシフィック・ロール・サーバ３″の設定した結果が、エイジェント・ロール・サーバ３′にて中継されて、クライアント１に示される。
【０１０７】
クライアント１がFlow line 描画を意図して、フローライン用画面を要求すると、エイジェント・ロール・サーバ３′からスペシフィック・ロール・サーバ３″に依頼されて、クライアント１に対してフローライン画面が表示されると共に制約条件の提示を要求する。
【０１０８】
制約条件について応答が了承されると、エイジェント・ロール・サーバ３′はフローラインとセンタ点とを表示する計算を行って、クライアント１に対して表示する。クライアント１は必要に応じて修正要求を行う。
【０１０９】
次いでクライアント１はCell pictureについての描画を意図し、図２３に示す如く、エイジェント・ロール・サーバ３′とスペシフィック・ロール・サーバ３″との処理によって、セル・ピクチャ用のコモン・プラットフォームが設定される。
【０１１０】
クライアント１がセル・ピクチャの描画を意図すると、同様に、セル・ピクチャの画面が表示されかつ制約条件の提示が要求される。
クライアント１が制約条件について応答すると、セル・ピクチャについての処理結果が統合サービス・プラットフォームに統合され、クライアント１の評価を待つようにされる。
【０１１１】
ここでは、フローライン描画とセルピクチャ描画との二つの仕事が並列に実行可能になっている。並列実行可能な動詞オブジェクトを検出するためのシステム構成は上記テキスチャ描画の例では、テキスチャを描くためのフローラインのための線を描くことと、フローライン上にセル画像を描くこととを並列に行い得るようにされる。そしてその結果がそろった所で、統合描画プロセスに移る。従ってスペシフィック・ロール・サーバ３″としてはフローライン用、セルピクチャ用、統合描画用の３個のサーバがエイジェント・ロール・サーバ３′に付属している。これらを制御するオブジェクト・ネットワークとしては図８の要素ネットワークを使用し、フローラインとしては図中右側のNoneからLineまでを使用する。これはFlow line のlineを描くことを目的としていることから、この部分のみがコモン・プラットフォームに図示され、表示的プロセス２−１中でクライアント１が使用する。Cell pictureと統合描画との両部はpicture を描画することから、図８全体がオブジェクト・ネットワークとしてクライアントに使用可能である。
【０１１２】
これら個々のスペシフィック・ロール・サーバ３″における実行結果は、エイジェント・ロール・サーバ３′を通じて、クライアント１とエイジェント・ロール・サーバ３′との間に存在するコモンプラットフォーム上にその実行結果としての画面表示される。
【０１１３】
得られた画像表示をクライアント１は観察しながら、エイジェント・ロール・サーバ３′はその仕事に関して必要とする属性もしくは制約についてクライアントに質問を行う。このための構成が図１４に示されている。図１４に示す如く実行され確認され、data identify の後に、コモン・プラットフォームのデータ・ウインドウ９に表示され、クライアントから応答された制約がチェックされ、その実行がValidity check２４によっておこなわれ、メッセージ・ウインドウ８でその実行が確認されて、結果がデータ・ウインドウ９に表示される。
【０１１４】
これらの特定サービスは、エイジェント・ロール・サーバ３′からスペシフィック・ロール・サーバ３″へ、その間に存在するコモン・プラットフォームを用いて依頼される。このコモン・プラットフォームが図２２、図２３においては従属表示的プロセス２−２として示され、エイジェント・ロール・サーバ３′に従属しているものとして示されている。この場合の態様は、ソフトウェアの仕様からオブジェクト・ネットワーク・データをはじめとするすべては、クライアント１とエイジェント・ロール・サーバ３′との間の場合と全く同じ形式をとる。それは、システム開発の際のユーザフレンドリ性を確保するためである。
【０１１５】
インタラクションの形態としては、
（ａ）エイジェント・ロール・サーバ３′のような抽象化サービスはジェネリック・オブジェクト・ネットワークとして抽象化されている。当該ジェネリック・オブジェクト・ネットワークは、パラメータあるいは制約条件によって具体化されたスペシフィック・オブジェクト・ネットワークと階層化される。なおスペシフィック・オブジェクト・ネットワークは特定の機能に対応したサービスを行うネットワークである。
（ｂ）個々のオブジェクト間の属性は、親の方から（例えばエイジェント・ロール・サーバ３′) から受け取り、それを用いてスペシフィック・ロール・サーバ３″は実行し、その結果は合成された属性(synthesized attribute) として、依頼した親の方に受け渡され、エイジェント・ロール・サーバ３′はそれらの属性値を用いて、制約条件を付し、新しいデータを得たり、チェック機構を動かす。
（ｃ）制約条件などは、図４に示す如く、形態的制約と時相的制約とが存在する。
【０１１６】
ジェネリック・オブジェクト・ネットワークは、図８に示す要素ネットワークの如きものでテキスチャ画像を図１７、図１８のように描くため、クライアントがテキスチャ描画の意図からその要求をエイジェント・ロール・サーバ３′に与えると、エイジェント・ロール・サーバ３′のもつジェネリック・オブジェクト・ネットワークを、統合サービスプラットフォームとして、クライアント１とエイジェント・ロール・サーバ３′との間の意志疎通のために設定する。そしてその上に上記図１７や図１８を表示するようにする。このようなネットワークは、エクステンシブル WELL のカーネル部の機能としてのグラフ構造エディタで行われる。
【０１１７】
図２４はオブジェクト・ネットワークの階層構造を示すものである。例えば数学において変数を一般化して与えて公式を用意しておくように、パラメータや制約条件などを一般化して（抽象化して）与えておいたジェネリック・オブジェクト・ネットワーク３３を用意しておく。そして、特定の処理を行わせるための特定のパラメータや制約条件３４を、ジェネリック・オブジェクト・ネットワーク３３中に組み込むことによって、当該特定の処理のためのスペシフィック・オブジェクト・ネットワーク３５がつくり上げられる。
【０１１８】
図２５はエイジェント・ロール・サーバ３′からスペシフィック・ロール・サーバ３″への処理の詳細化をテキスチャ描画の場合についてのジェネリック・オブジェクト・ネットワークを例示した図である。
【０１１９】
そして図２５中で四角形で示した名詞オブジェクトと関連したテンプレートがテキスチャ描画システムの設計を行ったエキスパートによって準備され、それをWELLの機能によってエイジェント・ロール・サーバ３′もジェネリック・オブジェクト・ネットワークとデータとに分けてもつようにされる。
【０１２０】
Flow line の名詞オブジェクトがクライアントにより指示されると、図８の要素ネットワークのうちLINE〜NONEの部分グラフがFlow line のための部分描画プロセスとして、フローライン用コモン・プラットフォームがスペシフィック・ロール・サーバ３″からエイジェント・ロール・サーバ３′を中継して、クライアント１に指示され、これを用いて図１７（ａ）（ｂ）（ｃ）（ｄ）のように描画プロセスが進行するようにされる。
【０１２１】
この際、テンプレートは、要素ネットワークのもつテンプレートがそのまま利用される。FlowというLINEについた修飾用形容詞は、LINEに新しい属性構造をテンプレートとしてもち、さらに、(i) 制約条件を付加すべきこと、および(ii)テキスチャ描画のためにはLINEが描画用データウインドに表示されるのではなくセルピクチャを写像する図２６に示すような点の位置のみが必要であること、を示している。
【０１２２】
以上のことから、Flow line を描画するためには、図１７（ｂ）をもとに図１７（ｄ）を描き、さらに図２６を描画するための制約条件、もしくはサブネットワークを与えるようにされる。
【０１２３】
したがってFlowという形容詞による修飾内容についての枠組みとして、前述したように、与えられた制約条件のもとに、
Length between adjacent points along flow line
Vertical Length between adjacent flow lines
について、エイジェント・ロール・サーバ３′はクライアントから定義してもらう。このために、メッセージ・ウインドウ８によって前述したような分割する点の数についての質問応答が行われる。その結果が図１４のConstraints on noun object２５に与えられ、Flowの修飾が行われ、図２６の結果が得られる。図中の点はCell pictureを写像する位置を知らせるためのもので、実際のTexture 画面には表示されない。これはTexture とFlow line の両者が与えられることから、Texture picture 表示の際、消去される。
【０１２４】
Cell pictureについても同様で、picture によって要素ネットワークによってカラー画像が描画される。この描画の後、図２６の点集合中の各点の周りに写像されるが、picture はCellによって修飾されており、その大きさをFlow line での隣接点間距離との関係によって規定する。そのためにCell pictureに付属する制約としてCell pictureの２つのlengths がFlow line について定義されているlengthと一致させる処理が行われて写像(mapping) 描画がTexture picture によって行われる。この際、Cell picture size とFlow line のlengthとの比を設定することが可能である。これは図４に示される制約意図の実現と考えられ、サービス間形態調整制御が実際に整合化を行う。
【０１２５】
以上のことを実行するために、Texture picture を描画対策としての要求は、Request to paint texture pictureがクライアントから意図として、図２２、図２３に示されているように、エイジェント・ロール・サーバ３′に与えられると、エイジェント・ロール・サーバ３′は、統合サービス・プラットフォームをサービス計画準備のプロセスとして設定し、その上に図２５で示されるジェネリック・オブジェクト・ネットワークをデータベース検索によって取り出し、それと同時にflow line とcell pictureとのためのスペシフィック・ロール・サーバが割り当てられる。
【０１２６】
以上のスペシフィック・ロール・サーバのなすべき仕事については、図２に示されるサービス計画準備で、役割サーバ検索（事項要求）が、エイジェント・ロール・サーバ３′を制御しているWELLシステムのカーネル部を介してデータベースサーバに検索依頼し、割り当てられたスペシフィック・ロール・サーバにその仕事を割り付ける。あるいは、元来その仕事を行っていたスペシフィック・ロール・サーバを事項検索を行って見出し、それに依頼する。
【０１２７】
スペシフィック・ロール・サーバが行う役割は基本的な名詞オブジェクトの実現を行うサービス実行と考えられ、その役割は具体的オブジェクトネットワークによって定義される。これに対しエイジェント・ロール・サーバは、それに制約条件や、他との整合化を行う仕事で、クライアントとの間でのインタラクティブな対話プロセスを伴うようなジェネリック・オブジェクト・ネットワークを含んだ仕事を分担する。
【０１２８】
以上述べたことを、インタラクションの形態について説明したオブジェクト指向の属性値についての継承および合成型の観点からシステムを考えると、
継承型データ：継承型データをもとにある処理を要求(Request) するエイジェント機能を行うサーバから具体的テンプレートを受け取る。即ちそのデータに対応したテンプレートの型として定まったデータ容器にデータ値が格納された具体的テンプレートを受け取る。この仕事を担当するスペシフィック・ロール・サーバもエクステンシブル WELL によって記述され、実行を行う。具体的実行は自身が行っても、他のサービスモジュールに依頼してもよい。
合成型データ：上記によりRequest されたデータをもとに依頼されたスペシフィック・ロール・サーバが実行処理を行う。その結果を格納すべきデータ型としてのテンプレート型式は、Request 時に受け取っており、それに格納して応答としてエイジェント・ロール・サーバに返す。この一連の仕事もエイジェント・ロール・サーバとの間に存在するコモン・プラットフォーム（これはスペシフィック・ロール・サーバがもっている）とそれを支援するコミュニケーション・マネージャが行う。
【０１２９】
以上のエイジェント・ロール・サーバ３′と、スペシフィック・ロール・サーバ３″との関係は、クライアントとServerとの間のエクステンシブル WELL の処理形態と全く同様である。しかしながらエイジェント・ロール・サーバが複数のデータをもとに継承型データとして複数個のスペシフィック・ロール・サーバに処理作業を依頼した時には、制約処理をエイジェント・ロール・サーバが行わなければならない。例として前述したTexture picture の描画を考えるとFlow linesとCell pictureとの描画を、それぞれ独立のスペシフィック・ロール・サーバに依頼し、その結果が返された時、Flow linesとCell pictureとの間の制約条件を満足させなければならないので、そのための制約条項が図２５のIntegrating Constraints についての属性値とSatisfying文によっての規定とを満足させる。
【０１３０】
この制約処理をコミュニケーション・マネージャに行わせる。したがって、コミュニケーション・マネージャは、
（１）テンプレート構造の役割に応じた変換を行う。（上記表１参照）
（２）テンプレート内容および複数個のテンプレート内容についての制約処理に関連した整合化のための通信管理作業を行う。
【０１３１】
この制約処理は形態制約である。それはFlow linesとCell pictureとの２個のサービス・オブジェクト相互に関連していることによる。このため、図２７のように制約処理の間での統合がはかられる。
【０１３２】
図２７において、
▲１▼ クライアント１は、ウインドウのデータを眺めながら、オブジェクト・ネットワークによって要求を発する。
【０１３３】
▲２▼ エイジェント・ロール・サーバ３′は、サービス計画用のデータを用意し、スペシフィック・ロール・サーバ３″に対して、即ち所望する処理を行うための各 Flow line 処理用のサーバや Cell picture 処理用のサーバや Texture picture 処理用のサーバに対して、要求を発しおよび／または処理の継承を指示する。
【０１３４】
▲３▼ スペシフィック・ロール・サーバ３″における各サーバは、夫々自己の処理を行い、処理結果にもとづいた反応を返しおよび／または処理を合成して、エイジェント・ロール・サーバ３′へ応答する。
【０１３５】
▲４▼ エイジェント・ロール・サーバ３′は、サービス内容をチェックし、制約条件があるか否かや現在の制約条件に追加や変更があるかなどを、クライアント１に尋ねるように処理する。
【０１３６】
このように図２７に示す如く、スペシフィック・ロール・サーバ３′中の各サーバが処理した結果あるいは所定の制約条件の下で処理した結果について、改めて、各処理結果の間で生じうる制約条件を新たに考慮してゆくようにする。即ち、制約処理の間での統合がはかられる。
【０１３７】
図２７に示すプロセスによって図２５で述べたAgent roleとSpecific role との差異が示されている。Flow line とCell pictureとについてもFlowとCellとの修飾に関連した制約処理はagent roleの働きと考え、要素ネットワークに対応する処理はspecific role の働きによって行われる。
【０１３８】
また画像処理と画像描画とを相互作用のある形で、コモン・プラットフォームを用いて対話的情報処理を行うことができる。例えば、エッジ線やハイライト線のような特徴抽出を行う画像処理を行い、抽出されたハイライト線を移動させる。すなわち、左目から見た左画像が与えられた時に視点を右目の位置に移動させて右画像を求めるようにして、立体画像を得たり、あるいは顔の目尻を上下させて表情変化をさせる時に目尻の位置を検出するような画像処理によって表情の特徴を得たりすることができる。
【０１３９】
しかし、これら特徴検出については、サーバがいつも完全な実行処理できるとは限らない。そこで明確な特徴を検出しうる箇所をクライアントが選び、そこである性質としての特徴名としての制約を示して特徴を表現する点の候補を求め、次いでその中から特徴点を確定するようにする。この操作は例えば図８の要素ネットワークにおいて、クライアント側の動作を時系列的にＣ１，Ｃ２・・・として示し、システム側の処理を時系列的にＳ１，Ｓ２・・・として示すと次の如く処理が進行される。即ち、
（Ｃ１−１）Colored Region Segmentの項目名を指定し、データ・ウインドウ上で抽出したい特徴の明らかな、
（Ｃ１−２）Region SegmentをIdentifyする。
（Ｃ１−３）ついで、Featuredをキーボードから入力し、Colored Point の項目を指定することにより、Featured Colored Pointを求めたことを、クライアントの意図として、システムに要求する。
（Ｓ１）システムはメッセージ・ウインドウによって意図を確認してSeek featured Colored Point を表示し、IdentifyされたColored Region Segmentを表示する。
（Ｃ２）Featuredの制約としてHighlight をキーボードから入力する。Highlight の性質はシステムに既に与えてあるとする。
（Ｓ２）Featured(Highlight) Colored Point を抽出する。
（Ｃ３〜Ｓ３）Featured(Highlight) の単語をコピーし、Colored Line SegmentをIdentifyする。これにより、システムは、クライアントがFeatured Colored Point Sequence を経てFeatured Colored Line Segment を作るべきことを、サービスとして実行する。
【０１４０】
以上によって、Highlight 線を構成し、クライアントはその確認を行った後、それを移動した上で新Highlight 線およびエッジ線を左右の眼の視差に対応して移動する。この際、Colored 属性を継承し、その上でHighlight 線の特徴を維持するように描画サービスをシステムが行う。このHighlight 線の移動差をmoved highlight 線として修飾を行い、moving vector diagram を用いて時間的な移動を行うようにする。
【０１４１】
またこれらの修飾を行うのに当たって、colored.... によって輝度や色度の属性用テンプレートを付加したのと同様に追加テンプレート部分が付加される。これらは名詞オブジェクトに対するものであったが、動詞オブジェクトについてもpoint からline segmentに至るdrawが継承される。したがって動詞オブジェクトについても実行開始時、実行中、実行終了時の制約条件が付加される。
【０１４２】
また実行要求と制約との関係としては、サービスとしての実行要求を行いうる条件を規定することが必要で、
（１）属性値処理のために、エイジェント・ロール・サーバ３′からの継承性属性のみが要求により実行可能で、結果は合成属性として上位エイジェント・ロール・サーバ３′へ応答するようにされる。
（２）実行要求は、クライアントによってオブジェクト・ネットワーク上の動詞オブジェクトを指定し、もしくは上述のような実行の単位(pointからlineへのdraw) によって実行系列を定めるようにして、委任発行される。
（３）ジェネリック・オブジェクト・ネットワーク上のジェネリックな動詞オブジェクトについても実行系列命令の生成を（２）と同様に行う。
【０１４３】
このために図４に関連して記述した時相的制約が満足されていることを制約処理によって調べる。
実行結果をエイジェント・ロール・サーバ３′に応答すると、エイジェント・ロール・サーバ３′は制約処理のプロセスに入る。制約条件を満足していない時には、合成データを応答してきたスペシフィック・ロール・サーバへ継承属性を変更させて再実行に移らせる。それでも不満足な時には合成ルートをたどって（図２２、図２３の中継などによって）最終的にクライアントの判断を仰ぐパスが設定される。
【０１４４】
これまでの説明は、クライアントが一人であったが、複数のクライアントの協調化も行いうる。それはクライアントの上位階層として協調化を行う協調化エイジェントが存在すると考えることによって、コモン・プラットフォームを協調化して実行する場として使用可能である。
【０１４５】
グラフ構造化エディタは、オブジェクト・ネットワークの定義を読み取り、それを可視化可能なオブジェクト・ネットワークに表示すると共に、各オブジェクトのテンプレート構造および制約条件を各オブジェクトの属性として管理している。したがってエクステンシブル WELL の機能によってエイジェント・ロール・サーバ, スペシフィック・ロール・サーバのソフトウェアが記述される。そしてオブジェクト・ネットワークとテンプレートの構造とは、システム設計の最初の段階で、開発担当のその分野を担当するエキスパートによって記述が行われる。
【０１４６】
サービス・モジュールが、できるだけ基本的なソフトウェア・モジュールとそれに対応する専門分野との組み合わせという考え方で、開発し用意される。
並行処理のためには、オブジェクト・ネットワークの構造を図２８のように、TOP を目的ゴール、BOTTOMを出発点として表現する。当該BOTTOMは上述の図８のNONEの如きものと考えてよい。
【０１４７】
図２８においては、現在実行中のタスクが今ＣとＥとであるとすると次に並行実行可能なタスクがＡとＤとであり、ＡとＤとの並行実行が終了した時には次にＡとＢとに移ることを可能とすることが示されている。このように、オブジェクト・ネットワークの構造を解析して、並行実行の進行と共に複数個のサーバの並行実行を動的に制御させるようにする。
【０１４８】
図２において、クライアント１とエイジェント・ロール・サーバ３′とスペシフィック・ロール・サーバ３″との関係を示し、クライアント１とエイジェントとの間に表示的プロセス２−１としてのコモン・プラットフォーム２が存在し、かつエイジェントと各サーバ＃ｉとの間に従属表示的プロセス２−２としてのコモン・プラットフォーム２が存在する態様を示した。
【０１４９】
図２においてクライアント１の存在を示しているが、当該クライアント１として、エイジェント・ロール・サーバ３′に対して処理を希望するユーザを考慮することは言うまでもないが、当該ユーザとエイジェント・ロール・サーバ３′との間の情報交換を援助するエキスパートを更に考慮することができる。
【０１５０】
図２９はエキスパートの存在を考慮したシステム構成を示す。図中の符号１，２−１，２−２，３′，３″は夫々図１や図２に対応している。そして、符号１−１は図１や図２に示すクライアントに相当するユーザ、１−２はエイジェント・エキスパートであってユーザ１−１とエイジェント・ロール・サーバ３′との間の情報交換を援助するもの、１−３はスペシフィック・エキスパートであってエイジェント・ロール・サーバ３′とスペシフィック・ロール・サーバ３″との間の情報交換を援助するものを表している。
【０１５１】
図示のユーザ１−１は人間であるが、エイジェント・エキスパート１−２やスペシフィック・エキスパート１−３は夫々人間に限られるものではなくインテリジェント機能をもつ処理ユニットであってもよい。
【０１５２】
図２９に示すように、エイジェントに対してユーザ１−１としてのクライアントは、ある局所的な特定の問題解決(problem resolution)を依頼する。すなわち、ある問題についてエイジェントの支援をたのみ満足する解を得る。
【０１５３】
これに対し、専門家としてのエイジェント・エキスパート１−２はエイジェントが担当する問題解決を行うための各種サービスの仲介実行を行う仕事を担当する。すなわち、ジェネリック・オブジェクト・ネットワークを構成し、それをエイジェント・ロール・サーバ３′に対して実際に実行するオブジェクト・ネットワーク群に分解し、図２２，図２３のような実行を可能とする方法を設計する。
【０１５４】
この際、ジェネリック・オブジェクト・ネットワークとそのためのテンプレート（これにはデータのみでなくサービスモジュール名を含む）と制約条項とをもっている。図２２，図２３に示したエイジェントの中継機能は、エイジェント・ロール・サーバ３′のもつウエル・システム１１の中核部に備えられている。制約条項の処理は、一般的形式で記述されている部分については制約処理サーバに依頼する。
【０１５５】
ジェネリック・オブジェクト・ネットワークとそれに関連するテンプレートをエイジェント・ロール・サーバ３′のウエル・システム１１の言語処理部に記憶し、それを抽象化サービスとして実現させるためには、ウエル・システム１１のグラフ構造化エディタの機能を用いてエイジェント・エキスパート１−２が行う。
【０１５６】
同様に，個々のスペシフィック・ロール・サーバ３″にも，対応するスペシフィック・エキスパート１−３が存在し、この場合のユーザに該当するエイジェントが分配したある特定のサービスを実現するための実際に実行するオブジェクト・ネットワークとそれに関連したテンプレートを設計し、それぞれのウエル・システム１１の言語処理に格納する。
【０１５７】
以上のようなジェネリック・オブジェクト・ネットワークおよび実際に実行するオブジェクト・ネットワークはウエル・システム１１の拡張機能を利用して動的変更を行うことが可能である。
【０１５８】
同様のことが制約条項についても行われる。すなわち制約条項をその時点での入力データと見なし、制約条項を拡張し、設計を行うような制約処理用オブジェクト・ネットワークをジェネリック・オブジェクト・ネットワークと実際に実行するオブジェクト・ネットワークとの両者を設計し、それによって制約条項変更サービスを行うようにシステムを動的に変化させる。これもそれぞれのエキスパートが計画し、方法を実現させる。
【０１５９】
以上のことは、表１に示したサービス機能の計画設計に関しており、エキスパートの役割となり、エキスパートは、ユーザ１−１とサーバとの間の問題解決手段を提供し、その評価によって動的設計を行う。
【０１６０】
データに関連する部分については、ユーザのもつ得意機能とサーバのもつ得意機能に対応して、それぞれデータを理解し参照指示する機能にもとづいて記述内容のもつ役割を分化させ、全体システムを効率化するようにさせている。
【０１６１】
上述の如く、ユーザ１−１は或る目的意図の下でシステムを使用して成果を得る役目を果たすものであり、これに対してエキスパート１−２（又は１−３）はシステムを計画し設計し実現させてユーザ１−１の使用のために提供する。当該エキスパート１−２（又は１−３）も，エイジェント・ロール・サーバ３′やスペシフィック・ロール・サーバ３″との間でのインタラクションを行う場としてコモン・プラットフォーム２が用いられる。
【０１６２】
ユーザ１−１は可視型のオブジェクト・ネットワークを用いデータを入力するなどして操作を行う。オブジェクト・ネットワークは、オブジェクトとして名詞型オブジェクトや動詞型オブジェクトを用いる。他動詞型のオブジェクトでは目的語データや補語データについても可視型として表現され操作される。名詞や動詞についての修飾語ではテキスト形式の文や語を用いることが許される。上記のウエル・システム１１（図３参照）はこの考え方にもとづいて実現されていると考えてよい。
【０１６３】
エキスパート１−２（又は１−３）は、ユーザ１−１が利用できるように、ウエル・システム１１の機能を用いてオブジェクト・ネットワークを設定し、名詞オブジェクトについてはデータ構造としてのテンプレートを用意するようにし、動詞オブジェクトについても同様にサービス名や制約処理のためのテンプレートを用意するようにする。またオブジェクト間に制約条項が存在する場合には、テンプレート内に制約条項へのポインタが設定される。このためにグラフ構造エディタが上記ウエル・システム１１における言語処理系に設けられてオブジェクト・ネットワークの変更や拡張が動的に行われる。この動的な処理は、ユーザ１−１の意図を実現する上での、キーワードにもとづいたデータベースに対する事項検索によって行われる。あるいは、エイジェント・ロール・サーバ３′の助けをかりてユーザ１−１自身がオブジェクト・ネットワークの書き下しや訂正を行う。勿論並行処理の下で行うこともできる。これらのサービス計画は、エイジェント・エキスパートによって設計され、ジェネリック・オブジェクト・ネットワークとしてコモン・プラットフォーム上に表示される。
【０１６４】
エイジェント・ロール・サーバ３′は、サービス計画として、ユーザ１−１の要求に対応したオブジェクト・ネットワークをユーザに提示し、その結果にもとづいてサービス役割の割当てを行い、個々のスペシフィック・ロール・サーバにサービス仕様を与えると共に、プロトコル仕様にもとづいて具体的に各割当てサービスを並行的に実行させる。
【０１６５】
【発明の効果】
以上説明した如く、本発明によれば、クライアントとサーバとの間に、可視的な表示をもってクライアントに通知しかつクライアントからの意図を受け取るコモン・プラットフォームがもうけられ、コミュニケーション・マネージャがクライアント側への可視的表示を用いた情報授受とサーバ側へのデータスキーマに則したデータ構造での情報授受とを仲介するようにしており、クライアントはディスプレイのウインドウに表示された画像と対話を行いながら、所望するオブジェクト・ネットワーク例えばカラー画像生成・色付け処理分野に対する処理を実行することが可能となる。
【図面の簡単な説明】
【図１】本発明の原理構成図を示す。
【図２】エイジェントをもつ構成を示す。
【図３】ウエル・システムとオブジェクト・ネットワークとの関係を説明する図である。
【図４】処理の整合を行う状況を概念的に示した図である。
【図５】処理フロー（Ｉ）を示す。
【図６】処理フロー（II）を示す。
【図７】コミュニケーション・マネージャの働きを示す図である。
【図８】要素ネットワークの関係を示す図である。
【図９】コモン・プラットフォームをもつシステムにおいてカラー画像生成・色付け処理を行う態様を示している。
【図１０】テンプレートのフォーマットを示す。
【図１１】コミュニケーション・マネージャの動作態様を示す。
【図１２】クライアントの指示に対応する動作を説明する図である。
【図１３】情報の交換動作を説明する図である。
【図１４】チェック・モジュールの動作を説明する図である。
【図１５】制約条件の表示態様を示す図である。
【図１６】アイデンティファイ作業を説明する図である。
【図１７】ＦＬＯＷ ＬＩＮＥＳの描画態様を示す図である。
【図１８】うろこパターンの画像を表す図である。
【図１９】ライン用のテンプレートのフォーマットを表す図である。
【図２０】ＬＩＮＥＳを限定する形容詞節を表す図である。
【図２１】属性にFeature 名を記述されたテンプレートを表す図である。
【図２２】テキスチャ描画の流れ(I) を表す図である。
【図２３】テキスチャ描画の流れ(II)を表す図である。
【図２４】オブジェクト・ネットワークに概念を説明する図である。
【図２５】サーバ３′とサーバ３″との処理例を表す図である。
【図２６】中心点を表示した図である。
【図２７】制約処理の統合を表す図である。
【図２８】並列処理を分析した図である。
【図２９】エキスパートの存在を表すシステムの図である。
【図３０】クライアント・サーバ間の対話モデルを表す図である。
【符号の説明】
１ クライアント
１−１ ユーザ
１−２ エイジェント・エキスパート
１−３ スペシフィック・エキスパート
２ コモン・プラットフォーム
３ サーバ
４ ウインドウ
５ ネットワーク・オペレーション・ウインドウ
６ オペレーション・ウインドウ
７ コマンド・ウインドウ
８ メッセージ・ウインドウ
９ データ・ウインドウ
１０ コミュニケーション・マネージャ
１１ ウエル・システム
１２ ウエル・カーネル
１３ グラフ構造エディタ
１４ ウインドウ・マネージャ
１５ ディスプレイ・マネージャ
１６ 関数実行・マネージャ
１７ サービス・モジュール
１８ 分野
１８Ｃ カラー画像生成・色付け処理分野
１９ オブジェクト・ネットワーク
２０ 輪郭部（Frame Section)
２１ カラー部（Color Section)
２２ テンプレート
２３ バッファ
２３’バッファの内容
２４ チェック・モジュール
２５ 制約条件
２７ 名詞オブジェクト
３３ ジェネリック・オブジェクト・ネットワーク
３４ 特定のパラメータや制約条件
３５ スペシフィック・オブジェクト・ネットワーク
Claims (1)
- オブジェクト・ネットワークに対応した処理を実行する１つまたは複数のサービス・モジュールに対応して、当該サービス・モジュールに対して実行を指示しかつ当該実行結果を出力する処理を実行するサーバを１つまたは複数個そなえ、
クライアントからの指示および／または情報を受取って解読し、上記サーバに対して必要な処理の実行を依頼し、かつ当該サーバから受信した当該処理の結果を上記クライアントが識別できる情報として出力する処理を実行するコモン・プラットフォームをそなえた情報処理装置において、
上記コモン・プラットフォーム（２）が、
上記オブジェクト・ネットワーク（１９）に対応した構成と処理項目とを表す可視的表示項目を表示し、かつ上記クライアント（１）からの指示および／または情報が表示されると共に、上記サーバ（３）が実行した結果が表示されるウインドウ（４）、
クライアント（１）からの指示および／または情報にもとづいて選択された結果を、上記サーバ（３）に伝え、かつ当該サーバ（３）を介して上記サービス・モジュールの１つまたは複数個に処理を依頼した処理結果を上記ウインドウ（４）上に可視的に表示せしめるよう構成され、かつ上記サーバ（３）に指示を行って上記クライアント（１）からの指示および／または情報と上記サーバ（３）が送受する情報との間のデータ表記形式の違いについての翻訳を依頼するコミュニケーション・マネージャ（１０）、および
上記ウインドウ（４）上に可視的表示項目を表示する処理を行うディスプレイ・マネージャ（１５）と、上記ディスプレイ・マネージャ（１５）により上記ウインドウ（４）上に表示されている可視的表示項目を選択する処理を行うウインドウ・マネージャ（１４）と、処理を行うサービス・モジュールの処理に対応して関数処理を実行する関数実行マネージャ（１６）と、オブジェクト・ネットワーク（１９）を管理するグラフ構造エディタ（１３）と、上記コミュニケーション・マネージャ（１０）を介して変換された情報に基づき上記関数実行マネージャ（１６）および／またはグラフ構造エディタ（１３）による処理を制御するウエル・カーネル（１２）とを有するウエル・システム（１１）、
をそなえると共に、
上記オブジェクト・ネットワーク（１９）を構成する個々のオブジェクトに対応して、当該オブジェクトを特定しかつ当該オブジェクトに関する属性を記述したテンプレート（２２）が用意されており、
クライアントが入力したサービス要求情報にもとづいて、上記オブジェクト・ネットワークに対応した処理に対応する上記サービス・モジュールが選択され、
当該サービス・モジュールが処理に関連する個々のテンプレートを特定し、
クライアントからの情報が到来すると上記コミュニケーション・マネージャ（１０）が上記テンプレートを参照し、
当該情報を当該サービス・モジュールが処理できるデータ形式に変換が行われ、
対応するサービス・モジュールによって当該変換されたデータにもとづいた処理が行われ、当該処理結果が上記テンプレート上に格納されるようにされた
ことを特徴とするコモン・プラットフォーム機能による対話的情報処理装置。
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP04157295A JP3979504B2 (ja) | 1994-03-04 | 1995-03-01 | コモン・プラットフォーム機能による対話的情報処理装置 |
| EP05001974A EP1536331A3 (en) | 1994-03-04 | 1995-03-02 | Interactive information processing system |
| EP95103004A EP0670544A3 (en) | 1994-03-04 | 1995-03-02 | Interactive data processing system. |
| CA002143914A CA2143914C (en) | 1994-03-04 | 1995-03-03 | Interactive information processing system |
| US08/929,087 US6237045B1 (en) | 1994-03-04 | 1997-09-15 | Interactive information processing system |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP3470194 | 1994-03-04 | ||
| JP6-34701 | 1994-03-04 | ||
| JP04157295A JP3979504B2 (ja) | 1994-03-04 | 1995-03-01 | コモン・プラットフォーム機能による対話的情報処理装置 |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003198160A Division JP2004054942A (ja) | 1994-03-04 | 2003-07-17 | 情報処理装置および情報処理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH07295929A JPH07295929A (ja) | 1995-11-10 |
| JP3979504B2 true JP3979504B2 (ja) | 2007-09-19 |
Family
ID=26373540
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP04157295A Expired - Lifetime JP3979504B2 (ja) | 1994-03-04 | 1995-03-01 | コモン・プラットフォーム機能による対話的情報処理装置 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US6237045B1 (ja) |
| EP (2) | EP1536331A3 (ja) |
| JP (1) | JP3979504B2 (ja) |
| CA (1) | CA2143914C (ja) |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH09297684A (ja) * | 1996-03-05 | 1997-11-18 | Fujitsu Ltd | オブジェクト・ネットワークによる情報処理装置 |
| TW406238B (en) * | 1997-07-30 | 2000-09-21 | Naretsuji Moderingu Kenkyosho | Apparatus for automatically applying and preparing software, and recording medium for preparing software |
| JPH1185524A (ja) * | 1997-09-05 | 1999-03-30 | Toshiba Corp | 情報処理装置及び方法並びに情報処理プログラムを記録した記録媒体 |
| US6745168B1 (en) | 1998-01-28 | 2004-06-01 | Fujitsu Limited | Intention achievement information processing apparatus |
| US6477563B1 (en) * | 1998-04-13 | 2002-11-05 | Kabushiki Kaisha Toshiba | Agent system and information processing method for same |
| JP3478172B2 (ja) * | 1999-05-18 | 2003-12-15 | 日本電気株式会社 | マルチウィンドウ表示システム及びウインドウの表示と消去方法 |
| US6791572B1 (en) * | 1999-06-18 | 2004-09-14 | Phoenix Technologies Ltd. | Generating media output during BIOS boot-up |
| US6681043B1 (en) * | 1999-08-16 | 2004-01-20 | University Of Washington | Interactive video object processing environment which visually distinguishes segmented video object |
| JP2001056766A (ja) * | 1999-08-18 | 2001-02-27 | Denso Corp | マルチモジュールシステム及び対話システム |
| JP2002055820A (ja) | 2000-08-09 | 2002-02-20 | Fujitsu Ltd | 情報処理装置 |
| JP2002290708A (ja) | 2001-03-27 | 2002-10-04 | Fujitsu Ltd | サービス機能実行システムにおける安全性確保方式 |
| US7587705B2 (en) | 2005-04-29 | 2009-09-08 | Sap (Ag) | Calls and return calls using client interfaces |
| US7634771B2 (en) | 2005-04-29 | 2009-12-15 | Sap (Ag) | Object generation in packages |
| US7669181B2 (en) | 2005-04-29 | 2010-02-23 | Sap (Ag) | Client interfaces for packages |
| WO2019138335A1 (en) * | 2018-01-09 | 2019-07-18 | Cleartrail Technologies Private Limited | Platform to control one or more systems and explore data across one or more systems |
| CN113821278B (zh) * | 2021-09-06 | 2024-05-03 | 挂号网（杭州）科技有限公司 | 调用图像尺寸方法、装置、电子设备及存储介质 |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5013245A (en) * | 1988-04-29 | 1991-05-07 | Benedict Morgan D | Information shapes |
| US5002491A (en) * | 1989-04-28 | 1991-03-26 | Comtek | Electronic classroom system enabling interactive self-paced learning |
| US5092544A (en) | 1989-12-22 | 1992-03-03 | General Railway Signal Corp. | Highway crossing control system for railroads utilizing a communications link between the train locomotive and the crossing protection equipment |
| EP0443768A3 (en) * | 1990-02-22 | 1993-01-27 | Hewlett-Packard Company | Programming escape from an iconic system |
| AU631749B2 (en) * | 1990-09-14 | 1992-12-03 | Digital Equipment Corporation | System and method for communication between windowing environments |
| WO1992007331A1 (en) * | 1990-10-16 | 1992-04-30 | Consilium, Inc. | Object-oriented architecture for factory floor management |
| JP3055970B2 (ja) * | 1991-06-20 | 2000-06-26 | 富士通株式会社 | オブジェクト指向言語間インタフェース実現方法および装置 |
| JP2801459B2 (ja) * | 1992-02-21 | 1998-09-21 | 富士通株式会社 | オブジェクトネットワークによる言語処理システム |
| US5511193A (en) * | 1993-02-19 | 1996-04-23 | Apple Computer, Inc. | Text services manager providing multiple instances of input methods for text language processing and automatic synchronization between met hods |
| JP2938739B2 (ja) * | 1993-02-26 | 1999-08-25 | 富士通株式会社 | 動画像処理装置 |
-
1995
- 1995-03-01 JP JP04157295A patent/JP3979504B2/ja not_active Expired - Lifetime
- 1995-03-02 EP EP05001974A patent/EP1536331A3/en not_active Withdrawn
- 1995-03-02 EP EP95103004A patent/EP0670544A3/en not_active Withdrawn
- 1995-03-03 CA CA002143914A patent/CA2143914C/en not_active Expired - Fee Related
-
1997
- 1997-09-15 US US08/929,087 patent/US6237045B1/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CA2143914A1 (en) | 1995-09-05 |
| EP1536331A2 (en) | 2005-06-01 |
| EP0670544A3 (en) | 1996-07-10 |
| EP0670544A2 (en) | 1995-09-06 |
| EP1536331A3 (en) | 2006-11-02 |
| CA2143914C (en) | 2002-08-13 |
| JPH07295929A (ja) | 1995-11-10 |
| US6237045B1 (en) | 2001-05-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3979504B2 (ja) | コモン・プラットフォーム機能による対話的情報処理装置 | |
| US5930512A (en) | Method and apparatus for building and running workflow process models using a hypertext markup language | |
| Eriksson et al. | Business modeling with UML | |
| Shaw et al. | Decoupled simulation in virtual reality with the MR toolkit | |
| JP3507302B2 (ja) | システム構成提案支援方法およびツール | |
| JPH09297684A (ja) | オブジェクト・ネットワークによる情報処理装置 | |
| Chao | Human-computer interaction: process and principles of human-computer interface design | |
| US20030101291A1 (en) | Application programming interface for provision of DICOM services | |
| Grønmo et al. | Towards Modeling Web Service Composition in UML. | |
| CA2089842C (en) | Language processing system using object networks | |
| Carvalho et al. | Toward the design of transitional interfaces: an exploratory study on a semi-immersive hybrid user interface | |
| JP2002055820A (ja) | 情報処理装置 | |
| JP2004054942A (ja) | 情報処理装置および情報処理方法 | |
| JP2000268084A (ja) | 統合業務パッケージソフト導入計画立案支援システム | |
| Cruz et al. | As you like it: Personalized database visualization using a visual language | |
| JP2002503842A (ja) | 動的インタフェースシンセサイザ | |
| US5617548A (en) | Method of interacting with computer graphics | |
| US20050210281A1 (en) | Service system based on sensibility information | |
| Jacobs et al. | Software process representation to support multiple views | |
| JPH09251432A (ja) | ワークフローマップ表示方法 | |
| Lenzmann et al. | An intelligent interface for a virtual environment | |
| JP2009157538A (ja) | 活動管理装置、活動管理システムおよび活動管理プログラム | |
| JPH06110636A (ja) | 電子オフイスシステム | |
| Wein et al. | Visual support for version management | |
| Moncarz et al. | Effective communication platforms |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20030617 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070409 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070517 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070621 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100706 Year of fee payment: 3 |