研究の成果

研究上の成果

アニメーション作成のモデルの構築

アニメーションを、実際のプログラムの実行を基に作成するためのモデルを構 築した。

  
図 --1: アニメーションのための視覚化モデル

図--1のように、各アプリケーションデータ(AR)は、ASR、VSR, PR と下向きに変換され絵の列となる(図中PR(t)→PR(t+1)という 横の列)。この絵の列をなめらかにつないでいくものがアニメーションである。 アニメーション作成者は、このつなぎかた(遷移操作)をアプリケーション内の 動作と関連付けて指定することができる。

ユーザは以下の3つを記述することでアニメーションを作成できる。

• (a) visual mapping rule : アプリケーション内のデータをどのように絵にす るかを指定する変換ルール。
• (b) transition mapping rule : 変換された絵から絵へのアニメーションをど う行うかを指定するルール。
• (c) アニメーション化の対象となるプログラムから、データを取り出し、ASR の形式に変換する部分。

非同期的動作のアニメーション化への対応

上記のモデルでは、基本的に逐次的なものを対象としているため、ある絵から 絵へのアニメーションは、一つのアプリケーションの操作に相当し、その間、 他のアプリケーションの操作が実行されないということを仮定している。

これでは、並列プログラムのアニメーション動作には問題がある。そこで、複 数の状態を越えて、ある状態からある状態まで動作することを示す from(where, id)/to(where,id)という遷移操作を用意することにより、ある物 体が遷移中に別な物体が動作を始める、といった並行性を視覚化することを可 能にした。

from(where1, id) と to(where2, id) とは対になって使われるもので 、where1 から where2 まで動くとい う操作を示している。例えば、非同期的なメッセージの送受信を表現するため には、

rule(send(Mess, Id, From), Result) :-
        Result = [move(Mess, [from(From, Id)])].
rule(recv(Mess, Id, To), Result) :-
        Result = [move(Mess, [to(To Id)])].

ソフトウエアの成果

本システムは大きく分けてmapper と viewer との2つの部分からなる(図 --2)。

  
図 --2: システムの構成

Mapper

ユーザの定義した ASR データ列を受けとり、アニメーションを表現する絵の 差分の列を出力するプログラム。ユーザの書いた ASR を VSR に変換するルー ル及び遷移操作の指定のルールと、本システムで提供しているKLICで書かれた visual mappping module や C で書かれた制約解消部と合わせてコンパイルす ることにより作成して、アニメーションの作成に用いる。

この部分は、KLIC 及び C で実装されているため、KLICの動作する環境ならば 動作すると思われる。なお、KLIC に C プログラムとのインターフェースが用 意されていたため、KLICで書かれた部分と C で書かれた制約解消系の部分と は容易に結合することができた。

Mapper に渡す ASR データは KLIC での項のtext表現の列である。そのため、 アプリケーション側では C における printf 文のようなものを使用して、ロ グを出力でき、アプリケーションプログラムを記述する言語はあまり選ばない。

Viewer

Mapper からの出力を読み取り、実際に画面にアニメーションを表示するプロ グラム。SGI上で OpenInventor を用いて作成したもの、Windows上でOpenGL を用いて作成したもの、また GUI ツールキットである amulet を用いて作成 した2次元版(Z軸を無視する)の三種類がある。

viewer の実装は、画面出力部分が環境に依存するため、移植性は高くない。 しかし、viewer の入力は画面に表示される図形に対する基本的な操作のみが 書かれているので、viewer を他の環境で実現することはそれほど困難ではな い。

図--3は実際に本システムを用いて作成したアニメーションのスナッ プショットである(SGI上でOpenInventorを用いたバージョン)。

  
図 --3: 3次元アニメーションの例

プログラムサイズとドキュメントの種類

Mapper

サンプルルールを含めて 4000行程度 (C 及び KLIC)

Viewer

SGI版が約4600行、OpenGL版が約3000行、X 版(2次元版)が約3000行程度

マニュアル

• インストールマニュアル
• チュートリアル
• Mapper におけるルールに関する説明書
• Viewer の受けつけるログについての説明書

残された課題

並列動作の記述方法の充実

from()/to()はかなりプリミティブなものであり、一般的な並列プログラムの 動作のアニメーションの記述をこれだけで行うのは、困難である場合が多いと 思われる。並列プログラムの動作を表現するのにどのようにすれば良いか、遷 移操作やモデル、変換の方式から再考し、表現力が高く、しかも記述の容易な 方式を考える必要がある。

スケーラビリティ

より大きなプログラムや長い実行を視覚化するためには、様々な面で改善が必 要である。例えば、現在の方式では、ASR や viewer への入力の format は、 テキスト形式で人が理解できるようなものとなっているが、そのため、これら をログとして取っておくとかなり巨大になってしまう。また、各状態での絵の 生成は、その状態全体からの変換という形式を取っているため、大きな図の生 成をする場合には速度的に問題がある。インクリメンタルな方式を採用するな どの改善が必要であろう。

記述方式の検討

現在は KLIC でモジュールを直接書くという方式でルールの記述を行なってい るが、より使いやすくするためには、専用の言語を設計するとか、例示的にルー ルを指定できる方式を実現するなどの改善が必要である。また、記述を楽にす るためには、より多種類の高度な制約を扱えるようにすることも必要である。

並列動作の把握

これは、本研究の範囲を少し外れるが、対象となるプログラムやアルゴリズム のデータや実行の様子をどのように取り出すかは非常に難しい問題である。 並列言語のデバッガなどを参考に、実行を妨げずに実行の様子を容易に抽出す る方式を考えてみたい。

自己評価

並列動作への対応やスケーラビリティに問題があるものの、2次元や3次元のア ニメーションを比較的容易に作成できるシステムが実現できたと思われる。

ただ、アニメーション化の対象となる並列プログラム自体の作成や、その実行 の様子の取り出しに手間をとられたため、まだあまり多くのプログラムの視覚 化を試みていない。今後はより多くのプログラムの実行の視覚化を行うことで 問題点を洗いだし、改善をしていきたいと思う。