JP4911594B2

JP4911594B2 - 対話形式処理における入力値及び入力操作の提示・制限方法、並びにその装置

Info

Publication number: JP4911594B2
Application number: JP2006302754A
Authority: JP
Inventors: 健増田; 中島　　一; 晴夫大石; 晴久野末
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2006-11-08
Filing date: 2006-11-08
Publication date: 2012-04-04
Anticipated expiration: 2026-11-08
Also published as: JP2008123022A

Description

本発明は、オペレータが計算機端末を介した対話（形式）処理によって複数種類のデータ項目の値を入力・変更するシステムにおいて、複数のデータ項目の値同士が既定の整合性を維持すること等を目的として、入力・変更される値及び入力・変更する操作の実行順序を該対話処理の中で適切に提示・制限する技術に関する。

業務システムのＩＴ化に伴い、オペレータの業務習熟度に対する要件は急速に厳しくなりつつある。ここでの要件とは、オペレータの対応能力（対象業務の複雑化・多様化への適応性、作業自体の迅速性・正確性、臨機応変なフロー変更の許容性、他の部署との連携の綿密性など）を指す。その一方で、社会的要因により、オペレータの習熟度向上に際しての外部状況（規模の増大による良質な人材確保の困難化、研修期間・雇用期間の短期化など）は一層厳しくなりつつある。このような状勢下において、業務システムの対話処理上でオペレータの負荷を軽減し、能力を支援する機能は特に重要である。このような観点から、代表的な背景技術として４件（ミドルウェア分野から２件、問題解決器分野から２件）を挙げる。

（ミドルウェア・ワークフローエンジン）
従来より、ワークフローエンジンやそれを適用して開発されたワークフロー管理システム（ＷＦＭＳ）において、条件分岐や合流などを含むワークフロー記述として予め指定した通りに対話処理を実行する機能が実現されている。一般に、データ項目の値同士が既定の整合性を維持するような入力操作を複数段階に亘って行う際、無駄なやり直しを少なくするという観点でヒューリスティック（経験則的）に最適とされる入力順序が存在する。上記対話機能によって、このような最適な順序に従った進め方となるように、システムがオペレータに対して次の操作を提示・制限する処理（公知例１）が実現されている（非特許文献１参照）。

（ミドルウェア・ビジネスルールエンジン）
また、従来より、ビジネスルールエンジンやそれを適用して開発されたビジネスルール管理システム（ＢＲＭＳ）において、複数のデータ項目の値に対するＩＦ−ＴＨＥＮルールを実行する機能が実現されている。この機能によって、値の整合性をチェックする、あるいは整合性を維持するための値の伝播を行う、あるいは所定の操作の実行を禁止する、あるいは当該の対話処理場面で推奨される操作を提示する、等の処理が一般に実現されている（非特許文献２参照）。

（問題解決器・制約ソルバ）
また、従来より、複数のデータ項目の値同士が満たすべき整合性を、制約条件として予め定義しておき、データ項目が取り得る値の侯補を指定することで、それら候補の中から整合性を満たす値の組み合わせを列挙するコンピュータプログラムとして「制約ソルバ（または制約充足ソルバ）」と呼ばれるものが、一般に実現されている。

制約ソルバは、前掲の対話処理への適用はまだ一般的ではないが、処理対象領域が整合性に関して複雑な構造を有する場合については既に広く用いられている。なお、制約ソルバとしては、フリーで利用可能なものや商用で利用可能なものなど複数存在し、例えば、Ｃｒｅａｍ、ｉＺ−Ｃ（非特許文献３参照）、ＩＬＯＧＳｏｌｖｅｒ、Ｃｈｏｃｏなどがある。

（問題解決器・プランナー）
また、従来より、ある操作を実行するに際しての事前条件と事後条件を、操作の種類毎に予め定義しておき、それら操作の対象領域について初期状態と目標状態を指定することで、初期状態から目標状態に至る操作の順序を求めるコンピュータプログラムとして「プランナー」と呼ばれるものが、一般に実現されている（非特許文献４参照）。

プランナーは、実用的なシステムへの適用技術として、まだ一般的ではないが、専門性の高い問題領域の計画立案システムや、複数のサービスの連携処理の技術分野における動作原理の検証やプロトタイプシステムの開発等の手段として、既に使われ始めている。
K.Tayama, T.Maruyama, H.Uno, and T.Inoue, "An Operation Support System Architecture for Network Provisioning of Optical Access Networks", IEEE NOMS2002, Florence Italy, S24.1, April 2002, pp.829-842 "ＩＬＯＧＪＲｕｌｅｓ６"、［ｏｎｌｉｎｅ］、アイログ株式会社、［平成１８年１０月２６日検索］、インターネット＜ＵＲＬ：http://www.ilog.co.jp./products/jrules/whatsnew/index.cfm＞ "iZ:Constraint Programing 制約プログラミング入門"、［ｏｎｌｉｎｅ］、株式会社ＮＴＴデータセキスイシステムズ、［平成１８年５月２９日検索］、インターネット＜ＵＲＬ：http://www.isac.co.jp/iz/tutorial.html＞ A.Gerevini and D.Long, "Plan Constraints and Preference in PDDL3", Technical Report, Department of Electronics for Automation, University of Brescia, Italy, Augsut 2005 ＜ＵＲＬ：http://cs-www.cs.yale.edu/homes/dvm/papers/pddl-ipc5.pdf＞増田健、他「柔軟なシステムを実現するプロセス制御技術」ＮＴＴ技術ジャーナル、第１８巻、第９号、２００６年９月、ｐｐ．５０−５４ H.Oishi, T.Nakatani, K.Tayama, S.Ogasawara, T.Yamamura, "OSS Architecture for Flexible and Efficient Process Control", IEEE NOMS2006, April 2006, pp.1-13

（ミドルウェア・ワークフローエンジンの問題）
一般に、オペレータとの複数段階に及ぶ対話処理を経て、トランザクション単位で処理を遂行する業務システムが多く存在する。対話処理の流れが単純な場合、即ちシステム開発時に処理の流れの分岐を全て列挙することが容易で、フロー記述として定義できる場合は、ワークフローエンジンが有効である。

しかしながら、対話処理の流れが複雑な場合には、処理の流れの分岐数が指数関数的に多くなるために全て列挙することが困難で、フロー記述として定義することが現実的でなくなってしまうという問題がある。近年、業務システムの多様化に従い、このような場合が増えており、特に、データ項目の値同士が既定の整合性を維持するような入力操作を複数段階に亘って行うような業務、例えば、設備選定、旅行予約、人員配置計画、スケジューリング、などのリソース割り当て問題（＝制約充足問題）を扱う業務では、この傾向が顕著である。

また、リソース割り当て問題に限らず、処理順序の自由度が本来的に高い業務システムでは、外部的要因により処理の実行順序に部分的に制限がつく場合がある。例えば、変数Ｖ１が予め定められた値以上になるならば、処理Ａ１を実行しなければならないという制限がつく場合、あるいはまた、処理Ａ２を実行するためには、別の処理Ａ３を先行して実行していなければならない場合、等である。このような場合に、本来の処理順序の自由度を失うことなく、これら部分的制限を満足するような順序を、ワークフロー記述として予めシステムに与えることは、同じようにパターン数が指数関数的に多くなるために現実的ではないという問題がある。

一方、一般に、リソース割り当てに際し、無駄なやり直しを少なくするという観点でヒューリスティック（経験則的）に最適とされる入力順序が存在する。実際的観点から、トランザクションのうちの多くの割合がこれらの順序で実行されるようにワークフローを作成し、例外的なフローのトランザクションをシステムで扱わない形で開発する方針が考えられるが、意図したような効率化を達成できない場合がある。なぜならば、これらヒューリスティックは処理対象となるリソースの種類と量の配分、並びに制約の内容に大きく依存するため、想定した条件から外れると有効に働かないからである。そのため、処理対象が多様で長期間・複数回に亘って業務が行われる場合には、例外的なフローの発生は避けられないという問題がある。特に、部門問のシステム連携が広く行われる等により、フローのステップ数やリードタイムが長く、やり直しコストが高いなどの状況が広まると、この問題によって起こる非効率性が、全体の業務の効率を平均的に落としてしまうため、システム運用上の大きな障害となる。

（ミドルウェア・ビジネスルールエンジンの問題）
上記問題を解決する手段として、ビジネスルールエンジンを使用することが考えられる。ビジネスルールエンジンはワークフロー記述と異なり、複雑な条件判断に基づいた変数値の変更や処理の起動が可能となる。

しかしながら、ビジネスルールエンジンにおけるＩＦ−ＴＨＥＮルールの処理内容が、意図した通りの整合性維持を行うかどうか確認・修正する作業は、一般に複雑で膨大になる。特に、システムが大規模になるとルールの間違いが生じ易い。その要因は、データ項目の値が他のルールによって、対話処理中の任意の時点で別の値に上書きされる可能性があること、並びにルールの優先順位によって、上書きの発生する順序が異なってくるために、最終的な結果も異なってくる等、ＩＦ−ＴＨＥＮルールの処理動作の特徴に由来している。即ち、当該処理動作を整合性保証のしくみとしてみた場合、ルール記述上に表現された通りに、最終的なデータの整合性が担保されないために、動作の確認・修正の作業が複雑になる。また、ルールの実行順序の全ての順列組み合わせについて実際に動作をシミュレートする必要があり、考慮すべき場合の数が指数関数的に増大するために、動作の確認・修正の作業が膨大になる。以上の理由により、ルールの作成とデバッグが難しいという問題がある。

（問題解決器・制約ソルバの問題）
上記問題を解決する手段として、制約ソルバを使用することが考えられる。制約ソルバはＩＦ−ＴＨＥＮルールと異なり、制約条件として与えた整合性が、途中の処理経過に関係なく、最終的に得られる解において満たされることが保証される。但し、制約ソルバの基本的な動作は、制約条件と変数を一括して与えるとそれを満足する解を列挙する形の関数型動作であるために、対話処理にそのまま適用することはできない。そこで、例えば、対話処理においてオペレータから入力された値を、同値制約や非同値制約や不等号制約等の形で順次追加し、入力段階毎に制約ソルバに制約充足問題を解かせる方法（公知例２）が考えられる（非特許文献５，６参照）。得られた解は、次の入力画面においてオペレータに対する他のデータ項目の値の選択候補の提示あるいは値の範囲チェックによる制限等に使用することができる。

しかしながら、この方法は操作の実行順序に関する提示・制限については何も機能していない。即ち、制約条件を追加する順序は、最終的な解の内容に影響しないため、値を入力・修正する操作の実行順序は完全に自由である。そしてまた同時に、何の推奨情報も提示しない。一見するとこれは、当該システム上での業務に習熟したオペレータにとって良いことであるが、無駄なやり直しを少なくするという観点では、システム側では何もせず、単にオペレータに全ての処理を委譲しているにすぎない。つまり、業務に習熟していないオペレータにとって操作が事実上不可能になるのはもちろんのこと、状況が複雑になると、習熟オペレータにとっても業務の遂行が困難になる場合があることを意味する。公知例２では、このような課題に対して、前述した公知例１にある、非習熟オペレータ向けワークフローを提示する機能（推奨フロー提示機能）を付加することで、一応の解決を図っている。しかし、前記ワークフローから外れる状況（例外フロー）になった場合には効果がない。即ち、公知例２は値の内容について適切に提示・制限する技術を実現してはいるが、操作の実行順序に関する技術の面では、公知例１と同等の効果しかない（公知例２では、実行時に動的に２つのモードを切り替えられるが、問題の本質は依然として解決されない）。

以上のように、制約ソルバの処理動作を対話処理の中で利用する場合、操作の実行順序に関する制御を全く行わないため、非習熟オペレータに対して、もしくは複雑な状況下においては、業務遂行が著しく困難になるという問題がある。あるいはまた、推奨フロー提示機能を適用した場合でも、従来通りの固定的順序による制御しか行わないため、従来のワークフロー管理システムと同様、例外フローに対応不可能になるという問題がある。

以上は、制約ソルバを対話処理に適用する場合の処理方式上の問題であったが、公知例２においては、他にも処理効率上の問題がある。

前記処理方式では、入力段階毎に制約ソルバに制約充足問題を解かせる必要があるが、これには大きな計算コストがかかる。ここで、注意すべきなのは、ただ単に入力済みの変数の値を確定し（値についての制約を追加するか、もしくは値ドメインを入力値に変更する）、未入力の変数への制約伝播を発生させて値ドメインを絞り込むだけでは、データ項目の値の選択候補を得られたことにはならない点である。これによって得られる値ドメインは、ある制約に着目した場合の局所的整合性を保証しているだけで、全ての値を確定した時の大域的整合性までは保証しない。つまり、ある場面における入力値として、「その値を採用した後の最終的な解が少なくとも１つ存在するもの」を全て列挙したり、「その値を採用した解が１つも存在せず、途中で選択肢なしとなることが論理的に明らかなもの」を全て列挙したり、といったことは直接的にはできない。そのため、入力済みの変数がまだ少ない状態、即ち解が十分絞り込まれない状態であっても、最終的に全ての変数が入力済みとなった場合の全ての解（膨大な数に上る）を列挙しなければならない。このように、値ドメインの範囲が大きい場合や、制約による矛盾が発生し難い場合は、値の提示・制限を行う際、非常に大きい計算コストがかかるという問題がある。

（問題解決器・プランナーの問題）
上記、制約ソルバの処理方式上の問題を解決する手段として、プランナーを使用することが考えられる。プランナーは、目標状態に至る実行順序を、任意の時点での状態と各種操作毎の事前条件／事後条件の情報をもとに計算し、いずれか１つを提示する機能を有する。即ち、プランナーの出力を利用することにより、対話処理上で適切な実行順序を提示することができる。

しかしながら一方で、オペレータが次に実行する操作を対話処理上で提示・制限することは、プランナーの機能をもってしても直接的にはできない。つまり、ある場面における次の操作として、目標状態に至る実行順序が少なくとも１つ存在するものを全て列挙したり、そのような実行手順が１つも存在せず途中で手詰まりとなることが論理的に明らかなものを全て列挙したりすることは直接的にはできないという問題がある。これは、現在提案されているプランナーのいずれにおいても、ある場面から目標状態に至る実行順序をいずれか１つ挙げるか、もしくは目標状態に至る実行順序が１つも存在しないと回答する機能を基本としており、全ての実行順序を調べようとすると、実行時間が指数関数的なオーダーとなることから実質的に処理が不可能になることに起因する。

この問題が解決できなければ、最終的に目標状態に到達できるかどうかという大域的観点において、次に実行すべきではない操作を判別し、オペレータが対話処理上でそれと気づかずに実行することのないよう制限をかけることができない。特に大規模なシステムにおいて、操作の多様性や状態の複雑性が増大すると、大域的な状況の把握が困難になる。即ち、プランナーを用いたとしても、オペレータの負荷を軽減し、能力を支援する機能を提供するという観点での効果が、相対的に小さくなってしまう。

さらにまた他方で、プランナーと制約ソルバ（２つは問題解決器と総称される）は、扱う問題をどのように内部表現するか、あるいはどのようなイベントによってどのように処理を進めるか、という観点で本来的に異なる動作方式である。これら２つの問題解決器を、特定の問題領域についてハードコーディングされたプログラムから呼び出し利用するシステムは容易に実現できるが、汎用的な方法で連携させることができないという問題がある。特に、データ内部表現、並びにイベント処理の両面について連携動作を実現することが重要である。

例えば内部表現について言えば、プランナーにおける内部表現は、プランニング対象となる外部世界における行動を「アクション」というデータで表し、外部世界の「状態」や「アクションの事前条件／事後条件」を述語論理上の式の集合で表す。実際にオペレータから入力された値はデータ項目（の種類）とその値に関する述語として内部表現される。一方、制約ソルバにおける内部表現は、制約変数、値ドメイン、制約条件によって表し、ある操作画面でオペレータが入力することのできる値の候補（実際には、前述の通り大域的な整合性を満足できない値も含まれる）は、制約変数がとる値ドメインとして表す。実際にオペレータから入力された値は、制約変数を当該値に束縛する制約条件として内部表現される。このように、同じ値に対して、計算機内部でのデータ表現方法に差異があるために、２つの間の相互変換を行う必要がある。

そのほか、例えばイベントについて言えば、プランナーでは、オペレータによるデータの入力（より具体的には入力画面の「ＯＫ（確定）」ボタン押下に相当）がアクションの実行に相当し、データの値の変化が「状態（述語集合）」の変化に相当する。これによって、次に実行可能なアクションを再計算する必要が生じる。一方、制約ソルバでは、オペレータによるデータの入力が制約条件の追加に相当し、データの値の変化が値ドメインの変化に相当する。これによって、他の変数の値ドメインの変化を再計算する必要が生じる。このように同じイベントに対して、計算機内部での動作内容に差異があるために、２つの間の相互伝達を行う必要がある。

（本発明の課題）
以上説明したように、「入力・変更される値の内容」と「入力・変更する操作の実行順序」のどちらか一方を提示・制限する技術は、従来の技術（即ち、前者は制約ソルバ、後者は汎用プランナー）を応用することによって実現可能であるが、２つの問題解決器を同時に利用して、両方の要件を満足する技術はまだ存在しない。

前記の課題を解決するために、制約ソルバとプランナーを連携動作させる手段を提供する。

（基本構成）
図１は本発明の対話形式処理を実行する装置の概要を示す。図中、１は電子計算機（コンピュータ，サーバ）、２は操作端末、３はディスプレイ（表示装置）、４はキーボード、５はポインティングデバイス（マウス）であり、これらはハードウェアを構成する。なお、電子計算機１と操作端末２との間はＬＡＮ６等の通信回線によって接続されている。また、電子計算機１と操作端末２は同一のコンピュータでも良い。また、キーボード４及びマウス５は合わせて入力装置を構成する。

また、ソフトウェア構成は以下の通りである。即ち、１０は本発明の対話形式処理実行プログラムであり、リレーションマネージャ１１、データマネージャ１２、プランマネージャ１３から構成され、相互にメソッドの呼び出しを行う。また、リレーションマネージャ１１は内部に後述する関係表１４を有し、データマネージャ１２は公知の汎用制約ソルバ（プログラム）１５を有し、プランマネージャ１３は公知の汎用プランナー（プログラム）１６を有する。なお、対話形式処理実行プログラム１０は、所定のアプリケーションプログラム内に組み込まれる形で実現しても良く、また、所定のアプリケーションプログラムとは別個の単体の形で実現しても良い。

図２は本発明を実行する装置のソフトウェア構成の詳細を示すもので、図中、１１はリレーションマネージャ、１７はデータベースマネージャ、２０はアプリケーション（プログラム）である。また、１２１はデータコントローラ、１２２はベリファイアであり、これらは前述したデータマネージャ１２を構成する。また、１３１はプランコントローラ、１３２はプランナーであり、これらは前述したプランマネージャ１３を構成する。なお、これらの各ソフトウェアの詳細については後述する。

前述した各ソフトウェア要素は、適切な通信路で相互に接続された複数のハードウェア上に分散して存在し、相互に通信し合いながら実行することもできる。例えば、アプリケーション２０は、他のソフトウェアと同じ電子計算機１上で実行し、操作端末２へはＷｅｂサービスを介してＷＷＷブラウザプログラムの形態でオペレータに画面と入出力手段を提供しても良いし、アプリケーション２０だけ操作端末２上で実行し、電子計算機１上で実行される他のソフトウェアとの間でＬＡＮ６を介して連携動作しても良い。

（制約ソルバとプランナーを連携させる手段の概要）
［入力からデータコントローラ・プランコントローラへの値の内容の変換・実行イベントの伝達］
適切に「入力・変更される値」と「入力操作の実行順序」の提示・制限を行うため、データコントローラ１２１が保持する制約充足問題（とその解）及びプランコントローラ１３１が保持するプランニング問題を、オペレータの入力操作に応じて変更する。つまり、入力操作の実行によりオペレータが入力した値をもとに、制約充足問題の制約の追加・削除を行い、また、プランニング問題の状態を表す述語集合の追加・削除を行う。

例えば、オペレータがアプリケーション２０のデータ投入画面で、投入欄Ａに０という値を入力する操作を考える。この場合、これに対応する制約として、投入欄Ａに対応する制約充足問題の変数がαなら、「α＝０」という制約を制約充足問題に付加し、更新された制約充足問題を制約ソルバに解かせて、保持している解を更新する。また、対応する述語が、「（ａｉｎｐｕｔｅｄ）」であるならば、それまでのプランニング問題の状態にこの述語「（ａｉｎｐｕｔｅｄ）」を追加し、新しいプランニング問題に更新する。

［データコントローラからプランコントローラへの値の内容の変換・実行イベントの伝達］
さらに、制約充足問題の更新により保持している解が変化した場合、それによって連鎖的にプランニング問題の更新を行う。ここでの解とは、当該制約充足問題が複数の解を有する場合、解集合のことを意味する。解が変化した場合とは、制約変数が解として取り得る値の侯補が変化した場合に相当する。

例えば、制約充足問題として変数がｘとｙ、ドメインがともに｛０，１｝、制約がｘ≠ｙを有するものを考える（このときの充足解は、（ｘ＝０，ｙ＝１）もしくは（ｘ＝１，ｙ＝０）である。）。ここで、アプリケーション２０から値投入の操作が起こり、「ｘ＝０」という制約が付加されたとすると、充足解はｘ＝０，ｙ＝１となる。もし、ｙの値が１つに定まって、その値が確定したということに対応する（ｙｉｎｐｕｔｅｄ）という述語としてプランニング問題で内部表現される場合は、これをプランニング問題の状態を表す述語集合に追加する。

（制約ソルバとプランナーを連携させる手段の具体的実現方法）
［連携のための値／イベントの対応関係表］
以上の問題更新機能は、データコントローラ１２１、プランコントローラ１３１及びリレーションマネージャ１１が連携して行う。データコントローラ１２１は、制約充足問題とその解を保持し、さらに入力操作の内容とそれに対応する制約追加・削除の関係を保持する。同様に、プランコントローラ１３１は、プランニング問題を保持し、入力操作の内容と対応する述語との関係及びデータコントローラ１２１が保持する制約充足問題の解と対応する述語との関係を保持する。

注意されたいのは、データコントローラ１２１及びプランコントローラ１３１が保持する関係は、あらゆる操作に対して制約の追加・削除や述語の追加・削除が定義されている必要はない。また同様に、あらゆる制約充足問題の解に対して述語の追加・削除を定義する必要もない。

これらの関係を管理するため、リレーションマネージャ１１は、データコントローラ１２１やプランコントローラ１３１が対象とする入力操作名（アクション名）を含む関係表１４を保持する。問題の更新処理では、始めにリレーションマネージャ１１がアプリケーション２０から、入力操作が行われたことを表すイベント通知を受け取る。このイベント通知にはアクション名が含まれている。リレーションマネージャ１１は、関係表１４中の入力操作名と受けとったアクション名とを比較し、制約充足問題とプランニング問題のそれぞれについて更新すべきか否かを決定する。

図３に基本的な関係表を示す。関係表１４は、イベントの内容を表すアクション名が格納されたカラムと、制約充足問題（制約ソルバ）への変更内容を表すカラムと、プランニング問題（プランナー）への変更内容を表すカラムとで構成される。

関係表１４から、イベントに応じた動作の伝達方法、問題解決器間の値の内部表現の変換方法を述べる。図４に入力操作の内容に対応する動作を示す。

まず、オペレータによって入力された入力欄のＩＤ（データ項目の種類を表す）と関係表の「入力操作の内容」カラムの値とが一致する行を検索する（２０１）。次に当該行の「制約充足問題への変更」カラムを参照し、制約変数ＩＤに対応する変数の値を当該入力欄の値と同値であるとする制約条件を制約充足問題に追加する（２０２）。次に当該行の「プランニング問題への変更」カラムを参照し、そこに保持されている述語をプランニング問題の状態（述語集合）として追加する（２０３）。

なお、この過程において、制約伝播により他の変数の値が確定した場合、それに対応するプランニング問題の状態追加が行われる。図５に制約伝播による二次的なプランニング問題変更の動作を示す。まず、制約伝播によって値が確定した変数を抽出する（２０４）。その後、当該行の「プランニング問題への変更」カラムを参照し、そこに保持されている述語をプランニング問題の状態（述語集合）として追加する（２０５）。

［伝達パターン（３通り存在する）に応じた動作の切り替えとそれぞれの流れ］
以上示した方法により、リレーションマネージャ１１は、データコントローラ１２１とプランコントローラ１３１のそれぞれにおける値の内部表現とイベント毎の動作の関係を知ることができる。その結果、更新すべき問題の組み合わせによって処理手順が３つに分岐する。各々の処理の流れを図６から図８に示す。

（パターン１）
更新すべき問題が制約充足問題のみの場合（図６）、リレーションマネージャ１１は、入力操作の内容をデータコントローラ１２１に送信する（図６−(2)）。データコントローラ１２１は、保持している操作内容と制約との関係をもとに受け取った操作内容を変換し、制約の追加または削除を行い、制約充足問題を更新する（図６−(3)）。最後に、データコントローラ１２１は、更新した制約充足問題を汎用制約ソルバ１５へ送信し、その解を汎用制約ソルバ１５から取得する（図６−(4)(5)(6)）。

（パターン２）
更新すべき問題がプランニング問題のみの場合（図７）、リレーションマネージャ１１は、操作内容をプランコントローラ１３１に送信する（図７−(2)）。プランコントローラ１３１は、保持している操作内容と事後条件との関係をもとに受け取った操作内容を変換し、事後条件を状態に反映させ、保持していたプランニング問題を更新する（図７−(3)）。

（パターン３）
更新すべき問題が、制約充足問題・プランニング問題両方の場合（図８）、このとき、リレーションマネージャ１１は、始めに操作内容をデータコントローラ１２１に送信する。受け取ったデータコントローラ１２１は上記１の処理を行う（図８−(2)(3)(4)(5)(6)）。その後、リレーションマネージャ１１は、更新された制約充足問題の解もしくは解の一部を取得し、プランコントローラ１３１に送信する（図８−(7)(8)）。プランコントローラ１３１は、受け取った解もしくは解の一部を事後条件に変換し、それを状態に反映させ、保持していたプランニング問題を更新する（図８−(9)）。

以上の処理を行うことによって、入力・変更される値や操作の実行順序に関する、提示や制限が動的に行われ、オペレータを適切に支援することが可能になる。

前述した分岐処理を含む本発明による対話形式処理全体のフローチャートを図９に示す。

（入力・制限する際の値の候補を提示・制限する手段の詳細な説明）
前述の「問題解決器・制約ソルバの問題」でも指摘したが、対話処理上の操作画面における入力値の候補を提示・制限することは、単純に制約ソルバの機能からは実現できない。そこで、データコントローラ１３１は、制約ソルバ１５と連携をとることでこれを達成する。この機能は、対応する制約変数の値ドメインの中から、他の変数に対応する値ドメインの範囲、並びにそのステップまでに入力された他の変数の値に対して不整合が起きないような値を抽出することで実現する。データコントローラ１３１は、アプリケーション２０の要求に応じて、この機能を実行し、入力データ項目毎にその操作画面において入力できる（推奨される）値をアプリケーション２０に提示する。

図１０、図１１にこの機能を実現する具体的なフローチャートを示す。当該機能は処理上の性質が異なる２つの方法がある。

図１０はそのうちの一方の方法を示す。データコントローラ１３１は、まず、初期化処理として、操作画面を表示しようとしている時点において保持している制約充足問題（その時点までにオペレータが入力した値が値制約として追加されているもの）を基に全ての解を求める（３０１）。そして、始めに推奨値を求めたい制約変数を外部から受け取る（なお、この時、リストや配列などの引数として外部から求めたい制約変数を一度に受け取り、その中から１つを選び出すという方法でも本質的に違いはない。）（３０２）。次に、集合Ａを空集合とし、解集合の各要素について以下の処理を繰り返す（３０３）。
１．前記解において前記変数がとる値を集合Ａに重複を避けて加える（３０４，３０５）。
その後、集合Ａの内容を推奨値集合として外部へ提示する（なお、この時、リストや配列などの返却用一時変数に対して、外部へ返したい制約変数を一旦蓄積しても本質的な違いはない。）（３０６）。操作画面で表示しようとする制約変数の全てについて、以上の処理を繰り返し実行する（３０７）。

この方法を手法Ａと呼ぶ、手法Ａは、全ての解を求めるため計算コストが大きいが、調べたい変数が多数ある場合でも、１回制約充足問題を解けば済むという特徴がある。

図１１は他の方法を示す。データコントローラ１３１は、始めに、操作画面において表示したい変数を外部から受け取る（４０１）。次に、集合Ａを空集合とし、前記変数の値ドメインのそれぞれの値について以下の処理を繰り返す（４０２）。
１．前記値の値制約を追加し（あるいは新たな値ドメインとし）制約充足問題を解き、解が１つ以上有る場合、当該値を集合Ａに加える（４０３，４０４）。
その後、集合Ａの内容を推奨値集合として外部へ提示する（４０５）。操作画面で表示しようとする制約変数の全てについて、以上の処理を繰り返し実行する（４０６）。

この方法を手法Ｂと呼ぶ、手法Ｂは、調べたい変数毎に制約充足問題を解かなければならないが、解が１つ発見できれば制約ソルバでの計算を中断して良いので、１回当たりの計算コストは小さく抑えられるという特徴がある。

以上２つの方法について、対象とする制約充足問題の傾向を考慮すると、手法Ａは、問題の大きさに対する解の数が比較的少ない場合、並びに保持する制約充足問題の変更頻度に対する推奨値の問い合わせ頻度が比較的多い場合に有効であり、また、手法Ｂは、問題の大きさに対する解の数が比較的多い場合、並びに保持する制約充足問題の変更頻度に対する推奨値の問い合わせ頻度が比較的少ない場合に有効である、と考えられる。

このように、手法Ａは、調べたい変数が多数ある場合について、小さい計算コストで値候補を求めることができる。また、手法Ｂは、制約による解の絞り込みが緩やかで矛盾が発生し難く、最終的な解の数が膨大になる場合について、小さい計算コストで値候補を求めることができる。

汎用性を高めるため、上記２つの方法を、扱う制約充足問題の性質に従って切り替える方法が考えられる。最も簡単な方法としては、システムプログラム起動時の引数や、コンフィギュレーションファイルによって、手動で切り替える方法である。

一方、自動的に切り替える方法として、制約充足問題の解の数を見積もる方法がある。具体的には、制約充足問題を構成する変数の個数、制約条件の数、値ドメインの範囲から、問題の大きさ（解の数に比例するとみなす）の見積もりを計算し、別途、事前に設定した値を超えるかどうかで判定する。解を求める必要はないため、この計算にかかるコストが対話処理に支障を与えることはない。

一般に、制約充足問題の解は、各変数の値ドメインの大きさや変数の数が大きければ多くなり、制約条件の数が多ければ少なくなる傾向にある。従って、問題の大きさを見積もるために、各変数の値ドメインの大きさと変数の数が大きいほど大きくなり、制約条件の数が多いほど小さくなるような値を定義し、その値に応じて適切に閾値を定義すれば良い。

例えば、具体的には、問題の大きさの見積値（Ｅｄ）として、以下の数式を使用する。絞り込み係数Ｃｒは、０から１までの実数であって、問題に応じて、制約が強いために解の絞り込みが大きい場合に小さな値を設定する。制約条件の個数が０の場合は、Ｅｄは変数の値の組み合わせ数を表す。この見積値が設定値を超えない場合には全ての解を求める計算コストが基準を超えないと判断して手法Ａを適用し、超える場合には手法Ｂを適用する。

制約変数の数：Ｎｖ
制約条件の数：Ｎｃ
値ドメインの要素の平均個数：Ｎｄ
絞り込み係数：Ｃｒ
問題の大きさの見積値：Ｅｄ＝Ｃｒ^Nc・Ｎｄ^Nv
なお、この数式を基本に、１つの制約条件が拘束する変数の平均個数や、個々の制約条件が解を絞り込む強度などを考慮することにより、見積モデルの詳細化が可能である。

さらに、操作画面毎の特性によって自動的に切り替える方法として、操作画面における入力データ項目の集合について調査する方法がある。具体的には、入力データ項目数と値ドメインの大きさから、問い合わせ回数の見積もりを計算し、別途、事前に設定した値を超えるかどうかで判定する。操作画面について予めわかっている数値をもとにした簡易な処理であるため、この計算にかかるコストは対話処理に支障を与えることがない。

具体的には、問い合わせ回数の見積値（Ｒｆ）として、以下の数式を使用する。

当該操作画面の入力データ項目の個数：Ｎｉ
値ドメインの要素の平均個数：Ｎｄ
問い合わせ回数の見積値：Ｒｆ＝Ｎｉ・Ｎｄ
この見積値が設定した閾値を超える問題には手法Ａを適用し、超えない場合には手法Ｂを適用する。閾値としては、全ての解を列挙する計算（手法Ａに相当）が、解の有無を判定する計算（手法Ｂの内側ループ１回に相当）の何回に相当するか、の回数を設定する。問題領域に応じて、後者の計算コストが小さいと予想される場合には、大きな値を設定する。

以上、手法Ａと手法Ｂの併用方法として、制約充足問題の大きさ・性質や、操作画面の内容に応じて適応的に処理内容を切り替えることで、幅広い性質の制約充足問題に対して偏りなく計算コストを抑えることができる。

（入力操作の実行順序を提示・制限する手段の詳細な説明）
前述の「問題解決器・プランナーの問題」でも指摘したが、端末における操作（プランナーの内部表現で言うところの「アクション」に相当）の対話処理上の実行順序を提示・制限することは、単純に汎用プランナー１６の機能からは実現できない。そこでプランコントローラ１３１は、プランナー１３２と連携をとることで課題を解決する。この機能は、現在の状態で事前条件が満たされ実行可能な操作の中から、その操作の実行後、目標状態へ達する実行順序が存在するものを抽出することで実現する。プランコントローラ１３１は、アプリケーション２０の要求に応じて、この機能を実行し、次に実行すべきアクションをアプリケーション２０に提示する。

図１２にこの機能を実現する具体的なフローチャートを示す。始めに、求めるアクションの集合をＡＣＴとし、初期値に空集合を設定する（５０１）。ついで、以下の処理をプランコントローラ１３１は保持しているアクション全体集合Ｏの各アクションに対して行う（５０２）。

１．未処理の操作をＯから取り出し、それをｏとする（５０３）。

２．操作ｏの事前条件が現在の状態で満たされているか判定し、満たしているなら３．へ処理を進める。満たしていないなら１．へ戻り、他の未処理の操作に対して処理を行う（５０４）。

３．操作ｏの事後条件を現在の状態に適用し、状態を更新する。この更新された状態をｓとする（５０５）。

４．状態ｓから目標状態への操作順序をプランナー１３２で求める（５０６）。

５．実行順序が存在すれば、６．へ処理を進める。存在しないなら１．へ戻り、他の未処理の操作に対して処理を行う（５０７）。

６．ＡＣＴに操作ｏを加える。１．へ戻る（５０８）。

このように、１．から６．の処理を各入力操作に対して施すことで、ＡＣＴに次に実行すべき操作が加えられていくことになる。

本発明によれば、リレーションマネージャを介してプランナーと制約ソルバを連携させることにより、対話処理上の各場面で入力されたデータ項目の値に応じ、予め定義されたアクション集合の各要素について、次アクションとしての可否を動的に計算することができ、次に選択可能な操作をオペレータに提示・制限できるという効果を生じる。また、制約ソルバにおける制約伝播によって制約変数の値が絞り込まれた場合についても、必要に応じて次アクションとしての可否を動的に計算することができ、次に選択可能な操作をオペレータに提示・制限できるという効果を生じる。

以上示したように、「入力・変更される値」と「入力・変更する操作の実行順序」の両方について、問題解決器としての汎用性を維持しつつ、内部表現や動作の違いを吸収し、プランナーと制約ソルバを連携させることができる。

また、本発明により、業務上の目的（値の整合性を確保すること、無駄なやり直しを少なくすること、の両方を指す）を達成するという観点で、対話処理上発生しうる全ての場面において適切にオペレータを支援することができる。これによって、例外的フローの発生が不可避であるという、ワークフローエンジンの問題を解決することができる。

また、本発明により、対話処理上発生し得る場面の指数関数的な増大に関係なく、最終的に必要な値の整合性の内容や、ある操作についてどの場面でも常に成立する事前条件・事後条件として、直接的表現によって記述し、所望の支援内容を実行させることができる。これによって、ワークフロー・ビジネスルールの作成およびデバッグが難しいという、ワークフローエンジンやビジネスルールエンジンの問題を解決することができる。

また、本発明により、制約ソルバに問題を解かせて推薦値を求めるアルゴリズムをデータコントローラ上に２通り用意し、問題に応じて使い分けることができる。これによって、幅広い性質の問題に対し計算コストを偏りなく抑えることができ、ある性質の問題に対して計算コストが増大するという、制約ソルバーの問題を解決することができる。

また、本発明により、目標状態に至る操作や手詰まりになる操作の列挙を、プランコントローラが主体となり、プランナーに適した計算（順序をいずれか１つ挙げる）を複数回呼び出すことで計算できる。これによって、全ての順序を列挙しようとすると実行時間が指数関数的オーダーになるという、プランナーの問題を解決することができる。

以上示したように、ワークフローエンジン、ビジネスルールエンジン、制約ソルバー、プランナーが抱えるそれぞれの問題を解決し、業務システムの対話処理上でオペレータの負荷を軽減し、能力を支援する機能を提供することができる。

前述した図２を用いて本発明の対話形式処理を実行する装置の実施の形態について説明する。

まず、図２における各ソフトウェア要素の機能について説明する。

リレーションマネージャ１１は、アプリケーション２０においてオペレータが行った操作を受け付け、その内容をデータコントローラ１２１やプランコントローラ１３１に送信する機能を有する。また、リレーションマネージャ１１は、連携動作を規程する関係表１４をファイルシステム等から読み込み、これに基づいて処理を行う。

データコントローラ１２１は、制約充足問題（変数、制約、変数のドメインの集合）とその解を保持する。また、データコントローラ１２１は、アプリケーション２０で行われた操作の内容に応じて、制約を更新する機能を有する。また、データコントローラ１２１は、保持している制約充足問題を汎用制約ソルバ１５に解かせて解を取得することにより、アプリケーション２０に対して、入力・変更される値の内容を提示・制限する機能を提供する。

ベリファイア１２２は、汎用制約ソルバ１５のラッパー（あるいはアダプター）である。汎用制約ソルバ１５としては、市中にフリーで公開されている汎用目的のソフトウェアが存在する。これを利用する場合に、ベリファイア１２２はデータコントローラ１２１からの処理依頼を受け取り、当該汎用制約ソルバ１５のインターフェイスや機能に適合した形で、依頼内容の変換や補足的な処理を行う。汎用制約ソルバ１５に与える定義１２３は、制約充足問題を内部表現したものである。この定義１２３の内容に従って、制約変数や値ドメインをデータベースマネージャ１７から読み込み、制約充足ネットワークが作成される。

処理に必要なデータを直接、制約充足問題として定義・付与する通常の方法は、特定の最適化問題を解く設計業務には十分である。しかし、本発明で解決しようとする業務システムのように、複数のトランザクションを扱う場合には、トランザクション毎に定義を用意することは現実的ではなく、別途、技術的解決を図る必要がある。本実施の形態のようにデータベースを参照し、動的に制約充足問題を付与する形態をとることで、本発明の適用領域が広がり、大きな効果を発揮できる。

プランコントローラ１３１は、プランニング問題（現在の状態・操作全体の集合・目標状態）を保持する。また、プランコントローラ１３１は、アプリケーション２０で行われた操作の内容に応じて、現在の状態を更新する機能を有する。また、プランコントローラ１３１は、保持しているプランニング問題を汎用プランナー１６に解かせることで、アプリケーション２０に対して、操作の実行順序を提示・制限する機能を提供する。

プランナー１３２は、汎用プランナー１６のラッパー（あるいはアダプター）である。汎用プランナー１６としては、市中にフリーで公開されている汎用目的のソフトウェアが存在する。これを利用する場合に、プランナー１３２はプランコントローラ１３１からの処理依頼を受け取り、当該汎用プランナー１６のインターフェイスや機能に適合した形で、依頼内容の変換や補足的な処理を行う。汎用プランナー１６に与える定義１３３は、プランニング問題を内部表現したものである。この定義１３３の内容に従って、プランニング問題の内部表現が作成される。

次に、図１３に関係表の実施の形態を示す。図３からの拡張部分として、以下２点がある。

（拡張１）
ある入力欄について入力された値の内容により動作を変えたい場合は、値の内容に対する条件式を記述することで実現する。この場合、「入力操作の内容」カラムの入力欄から「制約充足問題への変更」カラムの変数への値の確定は、前者が真の場合、後者が真となるように制約条件が追加される意味となる。

（拡張２）
上記条件式が、ブール値を返すメソッド名や任意の値を返すメソッド名を含むことができるように拡張する。これによって、アプリケーション内の任意の処理を呼び出してアプリケーションの様々な状態を取得できるため、高い拡張性が得られる。なお、この実現に当たっては、当該の条件式やメソッド名を解釈・実行する機能をリレーションマネージャ１１が具備するものとする。

（アプリケーションの実施例）
対話処理における入力値および入力操作の提示・制限の機能を備えたアプリケーションを実行した場合の動作を説明する。

図１４は画面の構成例を示すもので、同図（ａ）は入力操作画面の一例を示す。１つの入力操作画面上に表示された２以上のデータ項目については、その操作順序に制限はなく、画面上から複数のデータ項目を同時に入力できる。ＧＵＩ上で入力した値をシステムに反映させるために「ＯＫ」ボタンを押す。入力された値を無視して前画面に戻るために「キャンセル（戻る）」ボタンを押す。図１４（ｂ）は次操作選択画面を示すもので、画面には次に実行可能な操作に遷移するためのボタンが複数配置され、例えば「入力操作０２」ボタンを押すことにより当該入力操作画面に遷移する。図１４（ｃ）は入力と選択を順次行うことにより発生する画面遷移履歴を示すもので、入力操作画面と次操作選択画面は交互に遷移する。

図１５は図１４（ａ）（ｂ）に示した二種類の画面を１つの画面に統合し、オペレータが次の操作選択肢を確認しながらデータの入力を可能とする拡張を行った応用例である（この場合の遷移履歴は図１４（ｃ）のように交互にはならず、図１５と同じ構成でデータ項目の種類や操作選択ボタンの異なる画面が連なる形になる。）。

一方、アプリケーションの内部構成は、図２のアプリケーションとリレーションマネージャ、プランコントローラ、データコントローラの構成に従う。

アプリケーション２０は、プランコントローラ１３１から、次に実行可能（目標状態に到達可能）な入力画面の種類を問い合わせる。これをもとに、図１４（ｂ）もしくは図１５下部のボタンを表示する。なお、実行しても目標状態に到達できないことが明らかな入力画面へは遷移しないように（遷移を制限）、当該のボタンは表示しない。このように、操作に関して、対話処理の場面に応じたオペレータ支援を行う。

また、アプリケーション２０は、プランコントローラ１３１へＯＫボタンが押下されたことを通知する。プランコントローラ１３１は、直前の（これまで表示されていた）入力画面にて操作を実行したことを記憶する。この情報は、図１２の５０２の条件分岐で、ある操作が処理を行ったかどうかを判定する際に参照される。

アプリケーション２０は、データコントローラ１２１から、データ項目に入力可能（最終的に値の整合性を満足可能）な値を問い合わせる。これをもとに、図１４（ａ）もしくは図１５のデータ項目毎の入力用コンボボックスの選択肢を表示する。なお、入力しても値の整合性を満足できないことが明らかな値は入力できないように（値を制限）、当該の選択肢は表示しない。このように、入力値に関して、対話処理の場面に応じたオペレータ支援を行う。

また、アプリケーション２０は、リレーションマネージャ１１へＯＫボタンが押下されたことを通知する。同時に、オペレータによって入力された値とデータ項目の名前（入力欄を表すＩＤ）の組がリレーションマネージャ１１に送付される。リレーションマネージャ１１は、図３の関係表と図４、図５のフローチャートと基づいて処理を行う。

（制約充足問題、プランニング問題の具体例）
上記で示した装置ならびにアプリケーションにおいて、制約充足問題・プランニング問題についての具体的な動作例を説明する。

図１６は６個以上の変数からなる制約充足問題である。各変数は「１〜４」等の値ドメインを有する。変数の間には３個以上の制約条件が存在する。図１７は４個以上の入力操作をアクションとして表現したプランニング問題である。初期状態として述語が何もない状態を指定し、目標状態として変数の全てが“inputed”となる状態を指定する。

Ｖ１，Ｖ２，Ｖ３の部分について説明を行う。Ａ１はＶ１の入力画面である。同様にＡ２はＶ２、Ａ３はＶ３、Ａ４はＶ４の入力画面である。対話処理の最初の段階ではＶ１〜Ｖ３は「inputed」ではないため、図１２の処理によって、目標状態に至るためにＡ１〜Ａ３の実行が必要であることが計算される。Ａ４は事前条件が存在し、「（Ｖ３ｉｎｐｕｔｅｄ）」がまだ成立していないため、次の操作としては実行できないことが計算される。これによって、最初の段階ではＶ１〜Ｖ３のいずれの入力操作も選択でき、一方でＶ４の入力操作はまだ選択できない状態になる。

ここで、ユーザが入力操作Ａ１を選択したとする。制約充足問題に図１０又は図１１の処理を適用することで、制約条件Ｃ１２から解がないことが明らかな値ドメインＤ１の要素「４」が除去され、「１，２，３」が入力値の選択肢となる。これによって、値の提示・制限が実現される。

ここで仮に、Ａ１でＶ１＝１を入力したとする。図９の処理ｓ１において関係表が参照され、処理ｓ２，ｓ３によって、制約充足問題に「Ｖ１＝１」の制約条件が追加される。図９の処理ｓ４，ｓ５によって、制約伝播が発生しＶ２＝１，Ｖ３＝１が確定する。図９の処理ｓ６によって、関係表が再び参照され、プランニング問題の状態に「（Ｖ２ｉｎｐｕｔｅｄ）」、「（Ｖ３ｉｎｐｕｔｅｄ）」が追加される。次に、図９の処理ｓ８，ｓ９によって、図１２の処理が実行される。既に目標状態の「（Ｖ２ｉｎｐｕｔｅｄ）」「（Ｖ３ｉｎｐｕｔｅｄ）」の部分は満足されているため、次に選択できる操作としてＡ２，Ａ３は表示されなくなる。一方で、Ａ４の事前条件が満足されるため、Ａ４が新たに表示される。

ここで他の可能性として、Ａ１でＶ１＝２を入力したとする。制約伝播によりＶ２＝２は確定する。Ｖ３は「２もしくは３」に絞り込まれるが確定はしない。その結果、次に実行可能な操作としてＡ２は表示されなくなり、Ａ３は依然として表示され、新たにＡ４が表示される。

このように、入力する値によって対話処理の動的な適応が実現される。最初にＡ２やＡ３を実行した場合も、上記同様に値が確定した場合は操作画面が割愛され、あるいは事前条件が満足されたときに操作画面が表示される。

以上の説明は、１つのアクションで１つの変数を入力する場合を仮定している。しかし、実際の操作画面では多数の変数を一括して入力させる操作画面も必要である。また、値ドメインとしても数個の値候補しかとらない場合を仮定している。しかし、値ドメインが「１〜１００」のように非常に多い値候補から入力させる操作画面も必要である。このような操作画面に対しては図１１の手法Ｂの処理は計算コストが大きい。そこで、手法Ａを適宜用いることでこの問題を解決することができる。

また、以上の説明は、処理上の操作対象として入力データ項目を扱い、処理上の特定の状態として入力済みか否か（“ｉｎｐｕｔｅｄ”）を扱っている。ここで、拡張２、拡張３を実施した図１３の関係表を用いることでアプリケーションの様々な状態を表す内部変数“ａｌｐｈａ”や、値の内容を表す“ｏｎｅ”，“ｇｒｅａｔｅｒ−ｔｈａｎ−ｏｎｅ”などの別の状態を扱うことができる。

また、以上の説明は、目標状態として全てのデータ項目の入力完了を扱っているが、上記拡張により、多用な目標状態を扱うことができる。例えば、必須項目を限定したり、あるデータ項目の値によって必須項目を変えたり、データ項目以外の操作対象の特定の状態を条件とする、などの実際的な応用が考えられる。

本発明における効果、即ちデータ項目の値の内容及び入力・変更する操作の実行順序を対話処理の中で適切に提示・制限するという機能は、システムがオペレータに対して実施する支援機能を仮定している。しかしながら、システム同士の連携、あるいは１対多の連携においても容易に適用可能である。即ち、本発明はＥＡＩ、ＳＯＡなどの技術分野で利用が可能である。

本発明を実行する装置の概要を示す構成図本発明を実行する装置のソフトウェア構成の詳細を示す構成図基本的な問題変更対応関係表の一例を示す説明図入力操作の内容を制約充足問題及びプランニング問題の変更内容に変換する処理のフローチャート制約伝播をプランニング問題の変更内容に変換する処理のフローチャート入力操作に伴う問題の更新手順の一例を示す説明図入力操作に伴う問題の更新手順の他の例を示す説明図入力操作に伴う問題の更新手順の更に他の例を示す説明図本発明による対話形式処理全体のフローチャート入力・変更値の候補を提示・制限する一の処理のフローチャート入力・変更値の候補を提示・制限する他の処理のフローチャート入力操作の実行順序を提示・制限する処理のフローチャート問題変更対応関係表の実施の形態の一例を示す説明図アプリケーションにおける画面構成の一例を示す説明図アプリケーションにおける画面構成の他の例を示す説明図制約充足問題の具体例を示す説明図プランニング問題の具体例を示す説明図

符号の説明

１：電子計算機、２：操作端末、３：ディスプレイ、４：キーボード、５：ポインティングデバイス（マウス）、６：ＬＡＮ、１０：対話形式処理実行プログラム、１１：リレーションマネージャ、１２：データマネージャ、１３：プランマネージャ、１４：関係表、１５：汎用制約ソルバ、１６：汎用プランナー、１７：データベースマネージャ、２０：アプリケーションプログラム、１２１：データコントローラ、１２２：ベリファイア、１３１：プランコントローラ、１３２：プランナー、１２３，１３３：定義。

Claims

任意のコンピュータ上で動作する所定のアプリケーションプログラムに対し、当該任意のコンピュータもしくは当該任意のコンピュータにネットワークを介して接続された他のコンピュータの表示装置にデータ項目に対する入力・変更欄を少なくとも１つ含む入力操作画面を表示するとともに、前記任意のコンピュータもしくは当該任意のコンピュータにネットワークを介して接続された他のコンピュータの入力装置からオペレータの操作に基づいて前記入力・変更欄におけるデータ項目の値を入力・変更し、これを種類の異なるデータ項目に対応する入力・変更欄を含む２以上の入力操作画面について当該画面を切り替えて行うことにより、対話形式で複数種類のデータ項目の値を入力・変更する際、各データ項目の値同士が既定の整合性を満たすように、前記入力・変更欄に入力・変更される値と、前記入力操作画面を通じて入力・変更する操作の実行順序とを提示・制限する方法であって、
前記任意のコンピュータもしくは当該任意のコンピュータにネットワークを介して接続された他のコンピュータ上で動作する制約ソルバ及びプランナーと、
前記任意のコンピュータもしくは当該任意のコンピュータにネットワークを介して接続された他のコンピュータの記憶装置に記憶された、変数と当該変数の値ドメインと制約条件とからなり、前記複数種類のデータ項目の値を変数とし該複数種類のデータ項目の値同士が満たすべき既定の整合性を制約条件とする制約充足問題と、目標状態と現在の状態と事前条件及び事後条件を含む操作の集合とからなり、処理上の操作対象と当該操作対象に対する処理上の特定の状態との組よりなる集合を目標状態とし、前記処理上の操作対象を特定する主部とその状態を示す述部とよりなる述語により現在の状態と事前条件及び事後条件を表すプランニング問題と、入力・変更されたデータ項目の種類とその値に対応する制約充足問題における制約条件の変更内容及びプランニング問題における述語の変更内容を記述してなる関係表とを用い、
前記任意のコンピュータもしくは当該任意のコンピュータにネットワークを介して接続された他のコンピュータが、
入力装置から入力・変更されたデータ項目の種類とその値を、前記関係表を参照して前記制約充足問題における制約条件の変更内容、または前記プランニング問題における述語の変更内容に変換し、
制約条件の変更内容に従って制約条件の追加・削除を行い、前記制約充足問題を更新し、または述語の変更内容に従って述語の追加・削除を行い、前記プランニング問題を更新し、
更新した制約充足問題を制約ソルバに送信してその解を取得し、または更新したプランニング問題をプランナーに送信してその解を取得し、
更新した制約充足問題の解から前記入力・変更欄に入力・変更可能な値を決定し、または更新したプランニング問題の解から前記入力操作画面を通じて入力・変更可能な操作を決定する
ことを特徴とする対話形式処理における入力値及び入力操作の提示・制限方法。
請求項１に記載の対話形式処理における入力値及び入力操作の提示・制限方法において、
前記プランニング問題の目標状態は、前記複数種類のデータ項目を処理上の操作対象とし、前記複数種類のデータ項目のうち必須項目が入力された状態を処理上の特定の状態とする
ことを特徴とする対話形式処理における入力値及び入力操作の提示・制限方法。
請求項１に記載の対話形式処理における入力値及び入力操作の提示・制限方法において、
前記制約ソルバは、一のデータ項目に対する入力・変更可能な値として、該一のデータ項目に対応する変数の値ドメインの中から、他のデータ項目に対応する値ドメインの範囲、並びにそれまでに入力された他のデータ項目に対応する変数の値に対して不整合が起きないような値を抽出する
ことを特徴とする対話形式処理における入力値及び入力操作の提示・制限方法。
請求項３に記載の対話形式処理における入力値及び入力操作の提示・制限方法において、
制約充足問題の全ての解を制約ソルバによって計算し、各々の解の中で前記変数がとる値を要素とする集合を生成する第１のアルゴリズムと、前記変数の値ドメインの各値について、当該変数が当該値をとる新たな制約充足問題を生成し、制約ソルバによって解を有すると判定できた値を抽出対象とし、そうでない値を除去する第２のアルゴリズムとを用意し、
入力操作画面および操作対象データ項目の定量的特徴から、当該入力操作画面における入力値の提示・制限の計算量の指標を計算し、この計算値を予め指定した基準値と比較することによって、前記第１または第２のアルゴリズムのうち計算量が低いと期待される方を選択して実行する
ことを特徴とする対話形式処理における入力値及び入力操作の提示・制限方法。
請求項１に記載の対話形式処理における入力値及び入力操作の提示・制限方法において、
前記プランナーは、その時点で入力操作画面を通じて入力・変更可能な操作として、現在の状態で事前条件が満たされ実行可能な入力操作の中から、その操作を実行し、事後条件に従って状態が更新された後に、目標状態に達する実行順序が存在する操作を抽出する
ことを特徴とする対話形式処理における入力値及び入力操作の提示・制限方法。
任意のコンピュータ上で動作する所定のアプリケーションプログラムに対し、当該任意のコンピュータもしくは当該任意のコンピュータにネットワークを介して接続された他のコンピュータの表示装置にデータ項目に対する入力・変更欄を少なくとも１つ含む入力操作画面を表示するとともに、前記任意のコンピュータもしくは当該任意のコンピュータにネットワークを介して接続された他のコンピュータの入力装置からオペレータの操作に基づいて前記入力・変更欄におけるデータ項目の値を入力・変更し、これを種類の異なるデータ項目に対応する入力・変更欄を含む２以上の入力操作画面について当該画面を切り替えて行うことにより、対話形式で複数種類のデータ項目の値を入力・変更する際、各データ項目の値同士が既定の整合性を満たすように、前記入力・変更欄に入力・変更される値と、前記入力操作画面を通じて入力・変更する操作の実行順序とを提示・制限する装置であって、
前記任意のコンピュータもしくは当該任意のコンピュータにネットワークを介して接続された他のコンピュータ上で動作する制約ソルバ及びプランナーと、
変数と当該変数の値ドメインと制約条件とからなり、前記複数種類のデータ項目の値を変数とし該複数種類のデータ項目の値同士が満たすべき既定の整合性を制約条件とする制約充足問題と、目標状態と現在の状態と事前条件及び事後条件を含む操作の集合とからなり、処理上の操作対象と当該操作対象に対する処理上の特定の状態との組よりなる集合を目標状態とし、前記処理上の操作対象を特定する主部とその状態を示す述部とよりなる述語により現在の状態と事前条件及び事後条件を表すプランニング問題と、入力・変更されたデータ項目の種類とその値に対応する制約充足問題における制約条件の変更内容及びプランニング問題における述語の変更内容を記述してなる関係表とを記憶した前記任意のコンピュータもしくは当該任意のコンピュータにネットワークを介して接続された他のコンピュータの記憶装置とともに、
前記任意のコンピュータもしくは当該任意のコンピュータにネットワークを介して接続された他のコンピュータ上に設けられた次の手段、即ち、
入力装置から入力・変更されたデータ項目の種類とその値を、前記関係表を参照して前記制約充足問題における制約条件の変更内容、または前記プランニング問題における述語の変更内容に変換する手段と、
制約条件の変更内容に従って制約条件の追加・削除を行い、前記制約充足問題を更新し、または述語の変更内容に従って述語の追加・削除を行い、前記プランニング問題を更新する手段と、
更新した制約充足問題を制約ソルバに送信してその解を取得し、または更新したプランニング問題をプランナーに送信してその解を取得する手段と、
更新した制約充足問題の解から前記入力・変更欄に入力・変更可能な値を決定し、あるいは更新したプランニング問題の解から前記入力操作画面を通じて入力・変更可能な操作を決定する手段とからなる
ことを特徴とする対話形式処理における入力値及び入力操作の提示・制限装置。
請求項６に記載の対話形式処理における入力値及び入力操作の提示・制限装置において、
前記プランニング問題の目標状態は、前記複数種類のデータ項目を処理上の操作対象とし、前記複数種類のデータ項目のうち必須項目が入力された状態を処理上の特定の状態とする
ことを特徴とする対話形式処理における入力値及び入力操作の提示・制限装置。
請求項６に記載の対話形式処理における入力値及び入力操作の提示・制限装置において、
前記制約ソルバは、一のデータ項目に対する入力・変更可能な値として、該一のデータ項目に対応する変数の値ドメインの中から、他のデータ項目に対応する値ドメインの範囲、並びにそれまでに入力された他のデータ項目に対応する変数の値に対して不整合が起きないような値を抽出する
ことを特徴とする対話形式処理における入力値及び入力操作の提示・制限装置。
請求項８に記載の対話形式処理における入力値及び入力操作の提示・制限装置において、
制約充足問題の全ての解を制約ソルバによって計算し、各々の解の中で前記変数がとる値を要素とする集合を生成する第１のアルゴリズムと、前記変数の値ドメインの各値について、当該変数が当該値をとる新たな制約充足問題を生成し、制約ソルバによって解を有すると判定できた値を抽出対象とし、そうでない値を除去する第２のアルゴリズムとを用意し、
入力操作画面および操作対象データ項目の定量的特徴から、当該入力操作画面における入力値の提示・制限の計算量の指標を計算し、この計算値を予め指定した基準値と比較することによって、前記第１または第２のアルゴリズムのうち計算量が低いと期待される方を選択して実行する
ことを特徴とする対話形式処理における入力値及び入力操作の提示・制限装置。
請求項６に記載の対話形式処理における入力値及び入力操作の提示・制限装置において、
前記プランナーは、その時点で入力操作画面を通じて入力・変更可能な操作として、現在の状態で事前条件が満たされ実行可能な入力操作の中から、その操作を実行し、事後条件に従って状態が更新された後に、目標状態に達する実行順序が存在する操作を抽出する
ことを特徴とする対話形式処理における入力値及び入力操作の提示・制限装置。