川村渇真の「知性の泉」

知識ベースと連動したシミュレーション機能


シミュレーション機能は、最もコンピュータらしい利用方法の1つである。しかし、現在あるシミュレーション機能は、既存OSの制約を受けているため、十分な使いやすさを達成できていない。情報中心システムでは、基本構造がよくつくられているため、より使いやすく実現可能だ。どのような形になるのかを、簡単に解説しよう。


シミュレーション機能も情報中心で分析

 既存OSのシミュレーション機能は、1つのアプリケーションとして独立している。シミュレーションに必要な元データが表計算ソフトや会計ソフトに入っていた場合、ソフトが違うので簡単には持ってこれない。ユーザーが手作業でデータをコピーし、シミュレーションを実行する。シミュレーション結果をほかのソフトで利用する場合も同様で、やはりデータ移動に手間がかかる。アプリケーションやファイルという区切りが、無駄な手間や使いにくさを生じさせている。
 この点では、今後登場するエージェント指向技術つきのオブジェクト指向OSも、さほど変わりはない。ファイルという閉鎖的なデータの区切りを持っている以上、データの本格的な有効利用は望めない(表1)。

表1、シミュレーション機能の実現方法と内容を、OS別に比較した結果。アプリケーションとファイルが中心となるオブジェクト指向OSまでは、ほかの機能から閉じた形での実現となる。情報中心システムでは、基本機能を拡張する形で実現し、ほかの機能と可能なかぎり連動する

               OSの進歩 =================>

表1

 情報中心システムで実現する場合は、シミュレーション機能であっても、情報中心の考え方が適応される。シミュレーション機能を、情報中心で分析することが最初の作業だ。
 シミュレーション機能で作成するデータは、「シミュレーション内容」と「シミュレーション結果」の2つに分けられる。これに合わせる形で機能を求める、「シミュレーション内容の作成」と「シミュレーションの実行」の2つだ。これらデータと機能の関係は、「シミュレーション内容の作成」機能で「シミュレーション内容」データをつくり、それをもとに「シミュレーションの実行」機能を用いて「シミュレーション結果」データをつくると整理できる(図1)。これこそ、情報中心システムでのシミュレーションの基本構造である。

図1、シミュレーション機能の実現方法を決めるために、情報中心で分析した結果。データはシミュレーション内容と実行結果の2つに分けられ、それに合わせる形で機能も2つに分割する

図1

知識ベースの定義と専用プログラムで実現

 基本構造がわかれば、情報中心システム上での実現方法が決まる。同システムでは、どんな新機能でも、基本機能であるObject First機能とAuto Expression機能を拡張する形で組み込む。シミュレーションもモーフィングなどの追加処理の1つであり、データ入力や実行などを、Object First機能から呼び出す。
 そのためには、項目定義や処理定義を知識ベースへ登録する必要がある。先に分析した「シミュレーション内容」と「シミュレーション結果」が構造体定義に、「シミュレーション内容の作成」と「シミュレーションの実行」が処理定義になる。「シミュレーションの実行」処理の場合は、入力が「シミュレーション内容」構造体であり、出力が「シミュレーション結果」構造体となる。もう1つの「シミュレーション内容の作成」処理の場合は、出力は「シミュレーション内容」構造体だが、入力データはユーザーが使用時に指定する。つまり、入力機能として処理定義されることになる。
 シミュレーション機能の処理定義は、数式として表現できるタイプではなく、専用のプログラムを呼び出す形になる。モーフィング機能などの実現方法と同じだ。このプログラムこそ、シミュレーション機能の実体である。「シミュレーション内容の作成」と「シミュレーションの実行」の2つの処理があるので、それぞれに対応したプログラムを、システムへ組み込むことになる。このような実現方法は、情報中心システムにおける機能追加の1つの手段だ。
 組み込むプログラムは、2つ以上に分かれていてもかまわない。2つの処理定義から呼び出されるのは2つのプログラムだが、そこから別なプログラムを呼び出して、処理を進めることも可能だ。
 シミュレーション機能のような構造体定義は、専用のデータ構造を持つ。そのデータをほかの処理で勝手に更新されたのでは、あとで矛盾が生じて、処理が不可能になる。それを防ぐために、作成した処理以外での変更を禁止する属性を構造体定義へ加える。内容の変更はシミュレーション機能でしかできないものの、ほかの機能から読むことだけは可能なので、データ利用の制限は最小限ですませられる。

「シミュレーション機能のような構造体定義は、 
            専門のデータ構造を持つ」

通常データと同じ操作で検索&作成

 既存のシミュレーション内容を呼び出すときは、Object First機能を用いる。検索するデータタイプとして「シミュレーション内容」を指定すれば、作成ずみの「シミュレーション内容」を一覧表形式で表示するので、目的のデータを選べる。もし新しいシミュレーション内容を作成したいときは、Object First機能から入力機能を呼び出す。すると「シミュレーション内容の作成」に対応するプログラムが動いて、専用の編集画面が現れる。
 「シミュレーション結果」を見たい場合も、Object First機能を用いる。データタイプとして「シミュレーション結果」を指定すれば、これまで作成した「シミュレーション結果」を一覧表で表示する。見たい結果を選べば、それをAuto Expression機能が表示する。
 シミュレーション内容を作成したら、続けて実行することが多い。また逆に、シミュレーション結果を見ているとき、もととなったシミュレーション内容を呼び出したいこともあるだろう。ところが、Object First機能だけでは、関連する機能を呼び出すのに手間がかかる。操作性を向上するには、関係する機能を素早く呼び出すための仕組みが必要だ。リンクするデータを呼び出す機能と同じように、関連する機能を呼び出す機能を加える。どの機能が関係するかは、知識ベース内の処理定義の1属性として加えればよい。シミュレーションのように2つに分かれている機能では必須であり、ほかの機能を実現する際にも同じ方法を用いる。

基本機能を有効活用して自動化

 シミュレーション機能の中身については、既存のものと大きく変わるわけではないが、簡単に説明する。
 「シミュレーション内容の作成」処理では、4つの基本機能を持つ(図2)。時間軸や終了条件や記録内容などを指定する「環境設定」、シミュレーションの処理内容を指定する「処理内容設定」、画面上に表示するレイアウトを決める「表示レイアウト設定」、複数の実行条件を定める「実行条件設定」の4つだ。これら全部を設定して、1つのシミュレーション内容ができあがる。

図2、分割したシミュレーション機能とほかの機能の関係を、簡単に表したもの。2つの機能はどちらも、Object First機能から呼び出される

図2

 対話型の画面表示には、ボリュームやメーターなどの部品を用いる。その中には、ボタンやボリュームのように、ユーザーが操作する入力タイプの部品もある。これらは別の機能でも利用可能なので、シミュレーション機能の一部ではなく、システム側の部品として組み込む。
 レイアウト設定では、処理内容設定で決めた各項目に表示部品を割り当てたあと、表示画面をAuto Expression機能が自動生成する。その際に、ユーザーが見やすいような部品の配置を、表現ルールに照らし合わせて自動的に決める。気に入らない場合だけ、あとから修正すればよい。レイアウト設定を実際に表示するときも、Auto Expression機能が使われる。
 自動生成するレイアウトは、2種類から選べる。1つは、入力と出力の関係をブロック図で表した機能重視のレイアウトで、内容を理解しながら操作したい場合に適する。各ブロックには処理定義の名前をつけ、どんな内容なのかを明確に伝える(図3)。毎年1回だけ実行するとか、使うときに内容を忘れがちなシミュレーションで役立つ。

図3、シミュレーション機能で作成する2種類のデータの大まかな内容。知識ベースやユーザーデータを参照する形でシミュレーション内容を作成し、実際の定義や値は実行時に読み込む

図3

 もう1つは、デザイン優先でレイアウトを生成するタイプだ。内容を気にせず第三者に使わせるといった目的に適する。入力と出力の並び方などに表現ルールを適用するので、操作しやすいレイアウトになる。

知識ベースを参照して内容作成する

 情報中心システムで実現するシミュレーション機能の最大の特徴は、知識ベースやユーザーの一般データと連動するという点だ。知識ベースには、各分野の項目定義や処理定義が数多く入っている。これを利用すれば、シミュレーション機能の側で処理定義を持つ必要はない。
 また、最初に入力項目と出力項目を選ぶと、それを結ぶための処理定義を自動的に検索する機能が、Object First機能の内部には組み込まれている。これを利用することで、入出力項目のあいだの処理設定を自動化できる。
 ユーザーの一般データの利用も非常に重要な点だ。経営分析のためにシミュレーションを実行する場合、自社の財務データを持っていたら、それを用いたいはずだ。情報中心システムでは、各データに意味づけ名がついているので、該当する元データを簡単に取り込める。実際には、取り込む以外にリンクも張れるので、元データと連動したシミュレーションも可能だ。このように、シミュレーション機能であっても、入力は最小限ですませられる。
 シミュレーション結果も、ユーザーが作成した一般データと同じ扱いになる。「シミュレーション結果」というタイプの構造体データだが、その中には、通常と同じタイプのデータが含まれる。経営シミュレーションの結果なら、財務関連の各データが入ることになる。これらのデータも、システム内の各機能で利用可能だ。
 ただし、シミュレーション結果のデータは、本当のデータとまちがえて処理しては困る。それを防止するために、特別な属性を持たせ、通常の検索では候補として現れないようにする。特別なデータとして検索したときだけ、検索対象として扱われる。この属性を指定するのは、シミュレーション結果に含まれるデータであって、シミュレーション結果の一番上の構造体は含まれない。つまり、中に入っている個々のデータだけが通常検索の対象外になり、シミュレーション結果としての検索では現れる。

「シミュレーション機能であっても、 
     入力は最小限ですませられる」

知識ベースにテンプレートを入れる

 経営分析などの特定分野でのシミュレーションは、どの値を変化させて、どの値を読みとるのかが、ある程度決まっている。その分野の専門家なら簡単にわかる内容だが、初心者は知らないことが多い。
 この種の決まり切ったシミュレーションは、テンプレートとして知識ベースに入れるべきだ。単純なテンプレートではなく、値の意味や変更幅などの説明を加えることで、専門家以外でも簡単に使える。また、勉強用の資料としても役立つ。
 テンプレートが利用できれば、シミュレーション内容の作成が効率的になる。加えて、元データも簡単に取り込めるため、ユーザーが操作する部分は極端に少ない。全体として見れば、かなりの自動化を達成したことになる。テンプレートを増やすことで、シミュレーションの利用回数はかなり増えるだろう。
 テンプレートの作成を容易にするために、ユーザーが作成したシミュレーション内容をテンプレートに変換するツールを加える。変換後のテンプレートは、ユーザー作成の定義として知識ベースに入れる。
 そのほかにも、シミュレーション機能で実現したい機能がいくつかある。その第1番は、シミュレーション上でのユーザー動作の標準化だ。今後のシミュレーション機能では、実験のように動作を含む内容にも対応する必要がある。化学の実験などで、フラスコを持って操作するような動作が対象だ。これらのユーザー動作は、システム側で標準的に用意し、シミュレーション機能をそれに対応させる。いろいろな動作を組み込めれば、より複雑なシミュレーションも簡単につくれる環境になるはずだ。

「これらのユーザー動作は、システム側で標準に用意し、 
       シミュレーション機能をそれに対応させる」

操作&表示用の部品はほかでも利用可能

 表示用レイアウトに用いる部品は、前述のように、シミュレーション機能ではなくシステム側に入れる。この理由も、かなり重要だ。
 シミュレーション機能として実現する対話型の表示は、一般のデータ入力でも必要なものである。ネットワーク上でアンケートをとるとか、第三者に入力してもらう場合にも、表示用のレイアウトを用意する。このとき、ボリューム部品で入力させるような使い方もするだろう。
 このような観点で考えると、操作&表示用の部品は、すべてのインタフェースに使えるものだ。利用分野の1つがシミュレーションであって、すべてではない。すべてのソフトウェア部品が、できるだけ多くの場面で利用できるように、システム全体を設計すべき時期に来ている。しかし既存OSは、そうなってはいない。
 今回はシミュレーション機能の実現方法を紹介した。シミュレーションに限らず、情報中心システムに新しい機能を追加する場合、情報中心で分析した結果を重視する。既存OS上でアプリケーションとして実現している全部の機能は、情報中心システム上で実現するとき、情報中心の考え方を適用する。知識ベースやほかのユーザーデータと連動するとともに、基本機能であるObject First機能やAuto Expression機能の拡張機能として動かす。その結果、ユーザーからは基本機能の一部として見え、新しい使い方を覚える手間は最小限に抑えられる。ソフトの操作が中心である既存OSとは違い、あくまで情報を扱うことがシステムの中心だからだ。


下の飾り