| 平成８年度 委託研究ソフトウェアの提案 |
現在、並列プログラミングをとりまく状況は急激に変化しつつある。並列プログラミングに関する研究は長年にわたり行われてきたが、実際に並列プログラミングにたずさわるプログラマの数は、つい最近までごくわずかであった。しかし、近い将来、その数は急速に増加することが予想される。この予想は、以下のような要因に基づく。
以上のような状況から、並列／分散／ネットワーク型のアプリケーションを手軽に開発できる環境が、今後ますます重要となることが予想される。このような環境の核となる言語として KL1 を利用するのは妥当な選択であろう。さらに、ビジュアルな並列プログラミング環境を提供することにより、初心者プログラマの心理的な抵抗を抑え込むことができるのではないかと期待している。
並列プログラミングのパターンを、ビジュアルな部品として定義する機能と、パターンをドラッグ＆ドロップにより利用する機能については、既に試作を行っている。この機能をさらに洗練するとともに、図式トレーサにも表示のパターンなどを導入する予定である。
本研究では、昨年度開発した KLIEG システムを改良し、さまざまな形態のビジュアルなパターンの機構を設計および実装する。そのために、まず、並列プログラミングのさまざまな局面でどのようなパターンが存在するか検討し、その定義および利用が容易なユーザインタフェースを設計する。
現時点で、予備的に検討を進めているパターンに関する研究には以下のようなものがある。ただし、最終的なパターンの設計は、今後の研究の進展により変化する可能性がある。
＜1. ビジュアルなプログラムデザインのパターン＞
最近、デザインパターンという考え方が注目を集めている。このデザインパターンの考え方のエッセンスをビジュアルな並列プログラミング環境に取り入れたいと考えている。
このような意味でのパターンの中で、もっとも単純かつ原始的なものとして、静的なプロセスネットワークの形状を表現するパターンが考えられる。このような静的パターンを再利用する機構の設計は既に完了しており、α版の実装がほぼ完了している。また、一列に並べられた均質なプロセスよりなる動的なプロセスネットワークのパターンに関しても、設計と予備的な実装がほぼ完了している。
このようなプロセスネットワークの形状を再利用する機能をさらに強化し、記号処理問題を解決する場合によく現われる木構造などの形状を持ったプロセスネットワークの再利用機構の設計と実装を本研究では行う予定である。また、ネットワークの形状だけではなく、ネットワークを流れるメッセージプロトコルの再利用のための機構についても、現在検討中である。このような機構の設計と実装も行う予定である。
＜2. 表示のパターン＞
プログラム自体が図式情報を含むビジュアルプログラミング環境では、通常のテクスト言語のプログラミング環境に比べ、ユーザからより多くの図形的情報が与えられている。そのため、プログラムの実行の状況を表示する場合にも、ユーザの意図にあった表示が比較的容易に行える可能性が高い。
ただし、プログラムとして与えられた情報だけでは、不十分な場合も多い。たとえば、１次的に並べられた均質なプロセスの列に、プログラマがどのような意味を込めるか、自動的に把握するのは必ずしも容易ではない。この問題を解決するために、どのような表示をプログラマが欲しているかという情報をパターン化し、適切なパターンを選択することにより適切な表示を可能とする機構の設計と実現を行う予定である。また、このようなパターンをユーザが定義する方法についても検討を行い、可能なら設計と実装を行う予定である。
表示に関しては、現在までのところ、図式エディタで入力された図形情報に基づき図式トレーサが表示を行う方式を基本としている。一方、図式トレーサによる表示の形式を、実行時にユーザが変更した場合には、プログラム自体の図形的形状や以降の表示の形式を変えてしまうことも考えられる。図式トレーサに対するデモンストレーションから適切な図形情報を取得する可能性とそのパターン化についても検討を行う予定である。
＜3. プロセッサへのプロセス割り当てのためのパターン＞
実行時に起動されるプロセスやプロセスが利用するデータを、並列コンピュータのプロセッサやメモリに割り当てる方式の選択は、並列処理の効率化のために非常に重要である。この作業は、実は、図式トレーサの作業−実行時に起動されるプロセスを、画面という２次元メッシュ状の空間に割り当てる作業−と抽象的なレベルでは相似なものである。異なるのは、人間にとっての視認性を重視するか、並列コンピュータの実行効率を重視するかという目的関数の違いだけである。したがって、この２つの問題を解決するためにビジュアルなパターンを導入する場合、パターンの機構自体は類似のものを利用できるが、具体的なパターンとしては異なったものが必要になると予想される。プロセス割り当てなどの指定に関しても、図式トレーサの表示方式の指定と同様のビジュアルなパターン機構を利用する方式を検討する。
＜4. 図式エディタと図式トレーサの連携の強化＞
現在の版の KLIEG では、基本的に、図式エディタが取得した情報を図式トレーサの表示に反映させるだけで、その逆向きの情報の流れはない。このような方式を採用する理由は、ユーザの意図を図形情報として取得するには、図形エディタの段階の方が容易だからである。一方、図式トレーサが表示のためのパターンをはじめとする何らかの情報をユーザから取得できるなら、逆向きの情報の流れにも意味が出てくるかもしれない。たとえば、図式トレーサがフォーカスを当てた部分は、現在デバッグ中の部分である可能性が高い。したがって、図式エディタを次にユーザが利用するときには、その同じ部分にフォーカスがあたっていると便利な可能性が高い。このような連携を可能とするためには、図形情報の収集機構および表示機構を、図式エディタと図式トレーサで共通化し、統一的なインタフェースを構築する必要がある。
KLIEG システム
本ソフトウェアは、プロセスとストリームを図式として入力し、並列プログラムの開発を可能とするビジュアルプログラミング環境である。また、開発された並列プログラムをKLIC 言語に翻訳し、実行することができる。さらに、KLIC 処理系が生成したトレース情報をもとに、実行の過程を視覚化する機能も持つ。
KLIEG システムは、プロセスやストリームを組み込みの抽象として持つ点が、KL1 などの並列論理型言語と大きく異なる。論理型言語の特徴も有するが、どちらかと言えば、並列オブジェクト指向言語の一種と考えた方が妥当であろう。なお、論理型言語に慣れたプログラマのために mode づけ可能な flat GHC の節に相当する図式を記述することも可能としている。このような図式をひとまず用意することにより、KLIC のプログラマは、比較的容易に KLIEG 環境に移行することが可能となる。初心者にとっては、このような機能を利用するより、KLIEG 独自の抽象を活用した方がプログラミングは容易である。
一般的なテクストベースの並列プログラミング言語と比較した場合、プロセスやストリームなどの抽象が、ビジュアルな表現を持つユーザインタフェースコンポーネントとして実現されている点が、根本的に異なる。この特徴から、「設計図」を直接描画することによるプログラミング方式が可能となる。また、プログラムとして与えられた図形情報を反映した、プログラム実行の可視化が可能となる。
既存のビジュアルプログラミング言語と比較した場合の最大の特徴は、並列プログラミング環境に必要なさまざまな側面をパターン化し、パターンの定義と利用を容易に行いうるユーザフレンドリなインターフェイスを持つ点にある。また、トレーサによる表示方式にも continuous zoom アルゴリズムの動的な適用などの特徴がある。
KLIEG システムは、次のような構成要素からなる。
KLIEG により作成された並列プログラムは、KLIC のプログラムに変換され実行される。
KLIEG 自身も昨年度の IFS 委託研究の成果として公開されている。今年度および来年度は、これをもとに改良を行う。
KLIEG システムのユーザインタフェース部分は、Amulet(フリーな GUI ライブラリ)を用いてC++ で記述する。当面、SparcStation の Solaris 2.X 上で稼働するシステムを作成する予定である。移植に関しては、Amulet と C++ が稼働する環境であれば、比較的容易であると思われる。
KLIEG システムにより作成したプログラムを翻訳実行するためには、C/C++ とKLIC の稼働する環境が必要である。
新規に作成するソフトウェアは、C++ で10,000行程度を予定している。
KLIC のプログラミングは、基本的にテクストエディタを用いて行われている。KLIEG を用いると、このような KLIC によるプログラミングをビジュアルな環境で行うことが可能となる。ただし、KLIEG は KLIC に比べ、データフローの向きに関する記述が厳密である。したがって、より正確に言うと、モードづけ可能な flat GHC 相当の記述力を KLIEG のベース言語は有する。
KLIC のビジュアルプログラミング環境として見たとき、KLIC に比べ、次のような点がよりユーザフレンドリになっている。
木構造パターンと表示のパターンに関する改良を施した KLIEG の新版が今年度末に完成の予定。
www-admin@icot.or.jp