JP2000122859A

JP2000122859A - 並列プログラミングの開発支援装置及びその開発支援方法

Info

Publication number: JP2000122859A
Application number: JP10297833A
Authority: JP
Inventors: Hirobumi Araya; 博文新家
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1998-10-20
Filing date: 1998-10-20
Publication date: 2000-04-28

Abstract

(57)【要約】【課題】オブジェクト指向プログラミング言語を用いた
開発において、並列プログラムの実装時に必要となる、
スケジューラ導入時のオブジェクトモデルの変更及び、
実装を支援する。【解決手段】指定したクラスに対して、これと同じイン
タフェースをもったスタブクラス、及びメソッドの呼び
出し情報を格納しスケジュールされるまで実行を保留す
るコマンドクラス、指定したクラスの元々の処理を実装
する実装クラス、の3つのクラスを生成し、これをもと
に開発者が対象クラス以外の部分の設計を変更すること
無く、開発者がこれを元にスケジュール機構を容易に実
装することができるようにする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、並列に実行される
プログラムの開発支援環境に関し、さらにオブジェクト
指向プログラミング言語を用いる開発支援環境に関す
る。

【０００２】

【従来の技術】計算機資源の効率的な利用を図るため、
さらにはプログラミングのモデルを簡潔にする為に、近
代的な計算機のプラットフォームは、処理を並列に実行
する為のアーキテクチャを備えている。近年のネットワ
ーク技術の発展や、マルチスレッドをサポートするプラ
ットフォームの普及により、並列処理はますます一般化
している。

【０００３】並列処理を行うプログラムは、制御を持っ
た複数のスレッドとこれらにアクセスされる静的なデー
タによってモデル化することが出来る。或いは、オブジ
ェクト指向環境においては、スレッドを伴ったアクティ
ブなオブジェクトとこの操作の対象となるパッシブなオ
ブジェクトによってモデル化される。

【０００４】並列処理を有効に利用する為に、オブジェ
クトへ優先順位の高い要求、例えば、処理時間の短い参
照処理などにスレッドを優先的に割り当て、優先順位の
低い処理を後回しにするようなスケジューリングの仕組
みが必要となる。このような、スケジューリングのしく
みは、オブジェクトの内部に設けてもよいし、外部に設
けても良いが、外部にスケジューラを設ける方法は、ア
プリケーションのロジックを実現するコードとスケジュ
ーリングを実装するコードが分離できること、複数のオ
ブジェクト間でのスケジューリングを行うことができる
こと、等の点で有利である。このような仕組みは、オブ
ジェクトに対する要求をプールし、このプールから優先
順位の高い要求を取り出して実行するスレッドを設ける
ことで実現することが出来る。

【０００５】

【発明が解決しようとする課題】しかし、プログラムに
このような構造を設けるには、時としてプログラムの構
造の変更を行わなければならない。ここで述べるプログ
ラム構造の変更は、典型的には、図1の左側のようなモ
デルを、図1の右側のようなモデルに変更するものであ
る。図1のモデルでは、10に示したアクティブなオブジ
ェクトが、40に示したパッシブなオブジェクトにアクセ
スしている。これに対して図1左のモデルは、11に示し
たアクティブなオブジェクトが、21に直接要求を出す代
わりに、要求をプール40に入れ、これを読み出す役割を
もったアクティブなオブジェクト41が、プールに格納さ
れた要求の内から適切なものを取り出して、これを実行
する。（アクティブなオブジェクトとは、スレッドを伴
った「能動的な」オブジェクトであり、パッシブなオブ
ジェクトとは、呼び出しを受けて動作する「受動的な」
オブジェクトである。）このようなモデルの変更が必要となるのは、以下のよう
な場合である。

【０００６】例えば、多くの場合、分析段階では、モデ
ルの作成はこれを実装するプラットフォームを意識せず
に行われる。これは、最終的な実行環境が未定であった
り、設計を再利用する為にプラットフォームに依存しな
いモデルを作成する為である。分析段階では、実装の詳
細に依存するスレッドスケジューリングのような事項
は、考慮されないことが多い。この為、分析段階で作成
されるのは、多くの場合、図1左のような「パッシブな
サーバ」モデルである。このようなモデルの実装を詳細
化するにあたって、性能要件を課したとき、スケジュー
リングが必要になることが多い。

【０００７】また、近年一般的になってきた分散オブジ
ェクト環境において、サーバ側スレッドの構造は、「パ
ッシブなサーバ」のモデルが一般的である。クライアン
トの個々の要求に応じてサーバ側ではスレッドが並列に
起動され、これがサーバ処理を実装したクラスのメソッ
ドを呼ぶ。ここでは、スレッドの起動と処理への割り当
ては、分散オブジェクト環境のサーバ側ライブラリが行
っている。環境が提供する以上のスレッド制御、例え
ば、オペレーションの実行に優先順位をつける等、を行
いたい場合、やはり、スケジューラを設けて対応する必
要がある。

【０００８】本発明が解決しようとする課題は、スレッ
ド処理の効率化を考慮した設計を行なう際のこのような
オブジェクトモデルの変更を支援し、スケジューラを用
いたプログラム構造の設計を支援することである。

【０００９】

【課題を解決するための手段】スケジューリング機能を
付加するクラスのインタフェース（サーバオブジェクト
の持つメソッド（関数）の集合のこと）は、IDL等のイ
ンタフェース記述言語で記述することができる他、プロ
グラミング言語のソースファイルや実行形式から直接読
み出すことが出来る。これらより読み出したインタフェ
ース情報をもとに、このインタフェースに属するメソッ
ドの呼び出し情報をカプセル化するコマンドクラスと、
呼び出しの度にこのコマンドクラスのインスタンスを生
成しスケジューラのプールに入れるスタブクラスと、元
のクラスのインタフェースの処理を実装した実装クラス
を自動的に生成することにより、対象クラス以外の部分
の設計を変更すること無く、開発者がこれを元にスケジ
ュール機構を容易に実装することができるようにする。

【００１０】

【発明の実施の形態】本発明の実施の形態を以下に説明
する。まず、図2に本発明の開発支援装置の構成図を挙
げる。50はクラスの最初の設計を格納した原始モデルリ
ポジトリであり、52はスタブクラス、コマンドクラス生
成の際に使用されるテンプレートリポジトリ、60はリポ
ジトリ情報より、スタブクラスを生成するスタブクラス
ジェネレータ、65はリポジトリ情報より、コマンドクラ
スを生成するコマンドクラスジェネレータ、66は実装ク
ラス或いは実装クラスのテンプレートを生成する実装ク
ラスジェネレータである。生成されたスタブクラス、コ
マンドクラス、実装クラスは、55のソースファイルリポ
ジトリに格納される。

【００１１】原始モデルリポジトリの内容は、単にIDL
（インタフェース定義言語: Interface Definition La
nguage）の集合であったり（分散オブジェクト環境の場
合）、ソース及びヘッダファイルの集合であったり（C+
+他多くのプログラミング言語の場合）、実行ファイル
の集合（Javaバイトコードなどの場合）である。

【００１２】図3に、本発明による開発方式の概念図を
示した。原始モデルを元に、スタブクラスジェネレータ
60がスタブクラス80を生成し、コマンドクラスジェネレ
ータ65がコマンドクラス81、実装クラスジェネレータ66
が実装クラスあるいは実装クラスのテンプレート82を生
成する。スタブクラステンプレート56及びコマンドクラ
ステンプレート57は、スタブクラス、コマンドクラスの
特定クラスによらない共通の構造を抜き出したもので、
それぞれスタブクラスジェネレータ、コマンドクラスジ
ェネレータが使用する。

【００１３】実装クラスジェネレータの働きは、原始モ
デルリポジトリの内容が実装を含んだクラスの集合であ
る場合と、単にインタフェース定義の集合の場合で異な
る。前者の場合、実装クラスジェネレータはメソッドの
処理の実装を含んだ実装クラスを生成するが、後者の場
合は実装クラスのテンプレートを生成する。実装クラス
のテンプレートは、これに開発者がメソッドの実装を追
加して実装クラスを作成するための型紙となるものであ
る。開発者は生成したこれらのクラスに加えて、スケジ
ューラの実装、（必要ならば）サーバ処理の実装、クラ
イアントクラスの実装を行いアプリケーションを作成す
る。

【００１４】スタブクラス、コマンドクラス、実装クラ
スの構造と働きを図によって説明する。例えば、処理の
対象となるクラスは、原始リポジトリ中のC++言語で実
装された原始クラスであるとする。

【００１５】クラスAの構造を図4に示した。クラスAは
公開された2つのメソッド、int A::foo(int)、void A::
goo(string,B *)と非公開のメソッドvoid hoo(int)の実
装を持つ（夫々、81，82，83）。本発明の開発支援シス
テムは、クラスAより図5に示した92、96、99のスタブク
ラス、コマンドクラス、実装クラスを生成する。スタブ
クラスのオブジェクトの夫々は、実装クラスのオブジェ
クトと共にメモリ上に実体化する。そしてスタブクラス
は実装クラスの代理となる為にピア313として実装オブ
ジェクトへの参照を記憶する。また、スタブクラスオブ
ジェクトは、コマンドオブジェクトを登録する為のスケ
ジューラのプールへの参照310を持つ。

【００１６】プールは、インスタンス毎に設けても良い
し、クラス毎あるいは、プロセス内のすべてのオブジェ
クトで共有しても良い。スタブクラスのオブジェクト
は、原始クラスのオブジェクトの公開されたインタフェ
ースと同じインタフェースを持つ。即ち、int A::foo(i
nt)、void A::goo(string,B *)の実装を保持する。スタ
ブが非公開のメソッドを実装しないのは、元々これらの
メソッドはアクティブなクライアントクラスのような他
のクラスから呼び出されないからである。公開インタフ
ェースが原始クラスと変わらない為、クライアントクラ
ス90からオブジェクトにアクセスするプログラムは修正
する必要がない。

【００１７】スタブクラスのメソッド実装94の処理を図
6に表す。スタブクラスのメソッドの実装では、実際に
目的の処理が行われるのではなく、まず、目的の処理を
行う為の情報をカプセル化したコマンドクラスのインス
タンス96を生成し(ステップ101)、次に、カレントスレ
ッドのスレッドIDを取得してコマンドクラスのインスタ
ンスに格納し（ステップ102）、これをスケジューラの
プールに入れ（ステップ103）、このコマンドの処理が
実際に終了するのを待つ（ステップ105）。元々のメソ
ッドに戻り値がある場合は、コマンドクラスより、戻り
値を取得し（ステップ107）、これを戻り値として終了
する（ステップ109）。

【００１８】クライアントが要求した処理を行う為にコ
マンドクラスが、保持すべきデータ項目を図中315〜327
に示した。例としてint A::foo(int)の呼び出しで生成
されるコマンドオブジェクトを示す。ターゲット315は
対象の実装クラスオブジェクトへの参照（ポインタ）で
ある。このフィールドには、スタブオブジェクトがコマ
ンドクラスオブジェクトを生成する際、ピア313に保持
している、スタブオブジェクトが代理となっているオブ
ジェクトへの参照が設定される。メソッド識別子317は
目的のメソッドを特定する為に用いるものである。これ
は、C++言語のようなメソッド名のオーバロードを許す
言語ではfoo(int)のように、メソッド名称と引数リスト
の組となる。

【００１９】また、引数319はメソッドを呼び出す引数
を格納するもので、戻り値321はメソッドの戻り値を格
納する為の領域である。同期変数323、状態変数325は、
ステップ105の同期処理に用いる。状態変数325は、メソ
ッドの実際的な処理が終わったときのシグナルを拾う為
のものである。要求スレッドID 326は、コマンドオブジ
ェクトを作成したスレッドのIDを記録するのに用いる。
また処理スレッドID 327は、スケジューラがスレッドを
コマンドに割り当てるときに設定する。引数要求スレッ
ドID 326及び、処理スレッドID 327を用いて、ネストし
たインタフェースAの呼び出し(コマンドを処理するスレ
ッドが同じインタフェースへのコマンドを生成する)時
のスレッド資源の効率化を図ることが出来る。

【００２０】図7のようにプール中のコマンドクラスの
処理スレッドID→要求スレッドIDの関連をたどって、プ
ールに追加されたコマンドに新たにスレッド資源を割り
当てて良いかどうかを判断する。例えば、コマンドオブ
ジェクト415を生成したスレッドID=00010のスレッド
は、コマンド415の処理が実際に終了するまで待ち状態
を続ける筈なので、その分、余剰のスレッド資源をコマ
ンド415を処理するスレッドに割り当てて処理を続けさ
せることが出来る。もしも、このような配慮が無く、例
えば、スケジューラがコマンドに割り当てるスレッドの
総数の上限が設定されていたら、このようなネストした
インタフェースの呼び出し処理はデッドロックに陥る可
能性を持っている。

【００２１】コマンドクラスの実装において、メソッド
識別子は文字列で示すことも出来るし、関数へのポイン
タを用いることもできる。或いは、静的に関数のリンク
を行うC++言語のような場合の簡単な実装は、コマンド
クラス中にメソッドの呼び出しをハードコードすること
もできる。この場合、コマンドクラスが異なる実装クラ
スのメソッドを起動する為には、スタブクラスの各メソ
ッド毎に異なるコマンドクラスを生成しなければならな
い。

【００２２】また、引数と戻り値の型や数は、型の制限
が緩やかなSmalltalkのような言語では、オブジェクト
のリストで実現することもできるが、型の制限のきつい
C++言語のような言語での簡単な実装は、引数、引数の
数、戻り値は各メソッド毎に生成したコマンドクラスの
属性としてハードコードする。例えば、引数119はメソ
ッドを呼び出す引数を格納するもので、今の場合 int型
の変数１つから成る領域である。戻り値121はメソッド
の戻り値を格納する為の領域で、今の場合、int型の領
域である。

【００２３】実装クラスオブジェクト99の構造は、原始
クラスのオブジェクトの構造と同じである。例えば、メ
ソッド実装98は、原始クラスオブジェクトのメソッド実
装81、82、83と同一のものである。これらの処理は、ス
ケジューラの提供するスレッドによりコマンドオブジェ
クトの情報を元に呼び出される。特に、この時、メソッ
ド実装中に含まれる可能性のある、非公開のメソッドvo
id hoo(int)を呼び出すコードは変更の必要が無いこと
に注意せよ。

【００２４】以下に、C++言語を用いて実装したスタブ
クラス、コマンドクラス、実装クラスのより具体的な例
を示す。上で述べたように、メソッドの識別子や、メソ
ッドの引数、戻り値は、コマンドクラスの中にハードコ
ードする形で作成し、スタブクラスのメソッド毎に異な
るコマンドクラスを作成する形で実装を行った。

【００２５】対象クラスAに対する、スタブクラスは以
下のような内容となる。

【００２６】 class A{ //(0) Pool *pool;//(1) A_impl *peer;//(2) public: int foo(int ｘ){//(3) A_foo_int_Cmd c(peer,x); //(4) c.setRequestThreadID(getCurrentThreadID());//(5) pool->entry（c);//(6) c.wait();//(7) return（c.ret）;//(8) } void goo（．．．）{ // 省略 }//(9) A(){//(10) peer=new A_Impl();//(11) pool=getPool(this)//(12);} }; (0)に示すように、スタブクラスのクラス名は原始クラ
スと同様Aである。この為、Aにアクセスするクライアン
トクラスの修正は必要が無い。

【００２７】ピア及びスケジューラプールへの参照は夫
々、これらを表すオブジェクトへのポインタとして実装
する。A_Impl及びPoolは、本発明の装置が定めたAに対
応する実装クラス、及びプールクラスの識別子である
（(1)、(2)）。図5と同様、原始クラスの公開メソッド
だけが、スタブクラスのメソッドとして実装されている
((3)(9))。

【００２８】foo(int)の実装では、A::foo(int)メソッ
ドに固有のコマンドクラスであるA_foo_int_Cmdのイン
スタンスを生成し((4))、スレッドIDを設定し((5))、こ
れをスケジューラのプールに入れ((6))、処理の終了を
待ち（(7)）、コマンドクラスに格納された処理の出力
を戻り値として復帰する((8))。(10)はコンストラクタ
で、Aのインスタンス生成と同時にピアを生成し((1
1))、同時にgetPoolでプールへの参照を取得する((1
2))。getPoolは、スタブクラスのオブジェクトに何らか
のロジックでプールを割り当てる環境が用意する関数で
ある。コンストラクタ10は、原始クラスのコンストラク
タA()と同じインタフェースで使用することができる。

【００２９】また、対象クラスAに対するコマンドクラ
スの内容は例えば次のようなものとする。

【００３０】 class A_foo_int_Cmd :public Cmd{ //(0) A_Impl *target;//(1) int x; //(2) int ret; //(3) void exec(){//(4) ret=target->foo(x); //(5) finished = true;//(6) c.notify();//(7) } A_foo_int_Cmd(A_Impl*peer,int x) {this->target=peer; this->x=x;}//(8) } A_foo_int_Cmdコマンドクラスは、全コマンドでの共通
処理を持ったCmdクラスを継承しており((0))、コマンド
固有の部分だけを実装している。

【００３１】コマンドのターゲットは実装クラスである
A_Implクラスへのポインタとして実装される((1))。実
装クラスの識別子A_Impや、コマンドクラスの識別子A_f
oo_int_Cmdは、クラスA及びメソッドA::foo(int)に一意
に対応するものとして本発明の開発支援装置が生成した
ものである。A_foo_int_Cmdには、実装クラスのメソッ
ドを呼び出すときの引数を格納する為の、int型xという
属性が設けられている((2))。さらに、オペレーション
の結果を格納する為のret((3))がある。

【００３２】exec((4))は、コマンドオブジェクトの情
報を使って実装オブジェクトにコマンド固有の処理を行
わせるメソッドである。execは、実装クラスのメソッド
を呼び出し戻り値を格納する((5))。execはスケジュー
ラが割り当てたスレッドで実行される。目的の処理を終
えた後、終了したことを示すブール値finishedを真にし
((6))、条件変数を合図する((7))。次に、全コマンドで
の共通処理を実装したCmdクラスの示す。Cmdクラスは、
本発明の開発支援装置があらかじめ用意するものであ
る。

【００３３】 l((9))は同期変数、cnd((11))は条件変数であり、プラ
ットフォーム固有の同期プリミティブから構成される。

【００３４】この実施例では、同期変数には変数をロッ
クする操作（lock）と開放する操作（unlock）、条件変
数には変数の合図を待つ操作（wait）と変数を合図する
操作(notify)のみを仮定する。このようなプリミティブ
は並列処理をサポートした環境では、一般的なものであ
る。(10)は処理が終了したかどうかを示すブール値であ
り、(11)と組合わせて用いられる((16))。メソッドwait
(14)は、コマンドオブジェクトを生成するクライアント
スレッドから呼ばれ、スケジューラスレッドの処理の終
了を待ち合わせるのに用いる。

【００３５】条件変数(11)への合図は、コマンドクラス
のexecメソッドの中で行われる。尚、Cmdクラス自身はe
xecの実装を提供せず、その為に仮想クラス（抽象クラ
ス）である。

【００３６】最後に実装クラス自身のソースコードを挙
げる。

【００３７】メソッドの内容は、原始クラスと同じで単にクラスの識
別子が、AからA_Implに変わっただけである。

【００３８】次に本発明の開発支援装置を構成するスタ
ブクラスジェネレータ、コマンドクラスジェネレータの
働きを説明する。これらのいずれのモジュールも、原始
クラスの解析結果とテンプレートから目的の成果物を出
力する。

【００３９】図8にスタブクラステンプレートを挙げ、
図9にスタブクラスジェネレータの働きを示す処理フロ
ーを挙げる。ステップ130でまず、ユーザから処理の対
象とするクラスの指示を受ける。ステップ131で対象ク
ラスの名称からスタブクラス、実装クラスの名称を生成
する。先の例のように、対象クラスの名前、例えばAか
ら、決められたルール、例えばスタブクラス名=<対象ク
ラス名>、実装クラス名=<対象クラス名>_Impl等のルー
ルに従って、スタブクラス名=A、実装クラス名=A_Impl
等のようにする。これらの名称をテンプレートの変数、
CLASSNAME 200及びIMPL_CLASSNAME 202に夫々格納す
る。また、対象クラスにもし、スーパクラスがあれば、
テンプレートの変数SUPERCLASSNAME 201にスーパクラス
名を設定する（ステップ132）。

【００４０】次に、対象クラスのメソッドを1つとりこ
れを変数Mに入れて（ステップ133）、スタブクラスのメ
ソッド生成処理に移る。スタブクラスのメソッドは、メ
ソッドMが公開メソッドであり（ステップ134）かつ、ス
ーパクラスのメソッドを上書きしたもので無いとき（ス
テップ135）に限り生成する。先に述べた理由で、メソ
ッドMが非公開のメソッドであるときにはこれを生成す
る必要が無く、またスーパクラスに対応しては、スーパ
クラスがこのメソッドを実装している時にはスーパクラ
スのメソッドを使えば良いのでやはり生成する必要がな
い。スタブクラスのメソッド名とメソッド引数リスト
は、原始クラスのものと同じなので、対象クラスのもの
をコピーすればよい。

【００４１】例えば、メソッドint foo(int x)はそのま
ま、変数METHOD_HEADER 205に代入する（ステップ13
6）。、メソッド毎にコマンドクラスを生成する本実施
例では、適当なルール、例えば、<対象クラス名>_<メソ
ッド名>_<引数型1>_<引数型2>..._Cmdのようなルールで
コマンドクラスの名称を生成し、これをCMD_CLASSNAME2
06に代入する（ステップ137）。例えば、Aクラスのメソ
ッドint foo(int x)の場合、A_foo_int_Cmdのようなク
ラス名称となる。次に、メソッドMの引数を、CMD_ARGLI
ST 208にコピーする（ステップ138）。

【００４２】先に挙げた例の場合 CMD_ARGLIST='int x'
である。これは、コマンドクラスコンストラクタの引数
となる。ステップ139で、これまでに得たMETHOD_HEADE
R、CMD_CLASSNAME、CMD_ARGLISTをメソッドテンプレー
ト210に代入してメソッドMに相当するメソッドを生成
し、スタブクラスに追加する。この処理は、すべてのメ
ソッドについて繰り返す(ステップ140)。次に、対象ク
ラスのすべてのコンストラクタについて以下の処理行
う。対象クラスのコンストラクタの引数のリストをとっ
てこれを変数ARGLISTに入れ(ステップ142)、CLASSNAM
E、IMPL_CLASSNAME、ARGLISTをコンストラクタのテンプ
レート211に代入してコンストラクタを生成し、これを
スタブクラスのコンストラクタとして追加する（ステッ
プ143）。すべてのコンストラクタを処理し終わったら
（ステップ144）、生成したスタブクラスをリポジトリ
に格納して（ステップ145）、処理を終える。

【００４３】次にコマンドクラスジェネレータの働きを
説明する。

【００４４】図10にコマンドクラステンプレートを挙
げ、図11にコマンドクラスジェネレータの働きを示す処
理フローを挙げる。

【００４５】ステップ150でまず、ユーザから処理の対
象とするクラスの指示を受ける。ステップ151で対象ク
ラスの名称から実装クラスの名称を生成する。スタブク
ラス生成の場合と同様にこれを生成して、テンプレート
の変数IMPL_CLASSNAMEに代入する。次に、対象クラスの
メソッドを1つとりこれを変数Mに入れて（ステップ15
2）、このメソッドMに対するコマンドクラスを生成す
る。スタブクラスの説明で述べたと同じ理由で、コマン
ドクラスは、メソッドMが公開メソッドであり（ステッ
プ153）かつ、スーパクラスのメソッドを上書きしたも
ので無いとき（ステップ134）に限り生成する。スタブ
クラスの時と同様に、コマンドクラスの名称を生成し
（ステップ155）、テンプレート変数CMD_CLASSNAME 220
に設定する。

【００４６】また、メソッドの引数を格納する為に、CM
D_ARGMEMBER 222をテンプレートに追加する（ステップ1
55）。これは例えば先に述べたint foo(int x）の場
合、整数型の１つのメンバ "int x;" が追加される。同
様に、メソッドの戻り値を格納する為に、RETVAL_MEMBE
R 223をテンプレートに追加する。先の例の場合これ
は、整数型の戻り値を格納する為の変数、"int ret;"と
なる（ステップ157）。

【００４７】次に、変数 METHOD 224及び、METHODARG 2
25を、メソッドMのメソッド名称と、引数リストから設
定する（ステップ158）。先の例の場合、METHOD=foo、M
ETHODARG=xである。最後に、やはり引数のリストからCM
D_ARGLIST 228を生成してテンプレートに設定する(ステ
ップ159)。先の例では、CMD_ARGLIST="int x"である。
テンプレートの変数が全部埋まったところで、コマンド
クラスを生成して、リポジトリに格納する（ステップ16
0）。すべてのメソッドについて処理をし終わったら
（ステップ161）、コマンドクラス生成処理を終了す
る。

【００４８】最後に、実装クラスジェネレータの働きを
示す処理フローを図12に示す。実装クラスは比較的単純
な、文字列の置換操作で生成することが出来る。前と同
様、ユーザから対象クラスの指定を受けた（ステップ15
0）後、実装クラスの名称を生成し(ステップ151)、対象
クラスをコピーして基になるソースファイルを生成し
（ステップ152）、クラス名を実装クラスのものに置換
して（ステップ153）、出来た実装クラスをリポジトリ
に格納する（ステップ154）。尚、実装クラス名の置換
作業は、もし対象クラスにスーパクラスがある場合に
は、スーパクラスに関してもやはり、実装クラス名に置
き換える。

【００４９】以上で本発明の開発支援装置の実施例の説
明を終わる。

【００５０】

【発明の効果】以上に述べた装置によって、IDL等のイ
ンタフェース記述言語や、プログラミング言語のソース
ファイルや実行形式から直接読み出したインタフェース
情報より、このインタフェースを利用するクライアント
クラスとインタフェースするスタブクラスと、このイン
タフェースの処理を実装する実装クラスを生成し、開発
者がこの間にスレッド制御機構を組み込みことを支援す
ることができる。

【図面の簡単な説明】

【図１】本発明の並列処理を行うプログラムの構造を示
す模式図である。

【図２】本発明による開発支援装置の構成図である。

【図３】本発明による開発支援装置を用いるプログラム
開発作業の流れを示す概要図である。

【図４】オブジェクト指向プログラミング言語における
クラスの概念図である。

【図５】本発明による開発支援装置が生成するスタブク
ラス92、コマンドクラス96、実装クラス99の構造と働き
を示す図である。

【図６】スタブクラスが実装するメソッドの処理を記述
したフローチャートである。

【図７】デッドロックを防ぐ為にコマンドクラス中に設
ける要求スレッドIDフィールドの働きを示す図である。

【図８】スタブクラステンプレートの概念図である。

【図９】スタブクラスジェネレータの処理を示すフロー
チャートである。

【図１０】コマンドクラステンプレートの概念図であ
る。

【図１１】コマンドクラスジェネレータの処理を示すフ
ローチャートである。

【図１２】実装クラスジェネレータの処理を示すフロー
チャートである。

【符号の説明】

５０…原始モデルリポジトリ、５２…テンプレー
トボジトリ、６０…スタブクラスジェネレータ。

Claims

【特許請求の範囲】

【請求項１】並列処理をサポートしたオブジェクト指向
のソフトウェア開発環境において、ユーザが指定したク
ラスに対して、ソースファイル或いはインタフェース定
義言語或いは実行形式より解析したこのクラスのインタ
フェース情報を元に、このクラスのインタフェースの各
メソッドの呼び出し情報を格納してスケジューラの要求
を受けるまでこの実行を保留するコマンドクラスと、前
記ユーザが指定したクラスと同じ外部インタフェースを
持ちこのインタフェースの各メソッドの呼び出しの度に
前記コマンドクラスのインスタンスを生成してスケジュ
ーラのプールに追加するスタブクラスと、前記ユーザが
指定したクラスを同じインタフェースと同じメソッドの
実装を持った実装クラスを生成することを特徴とする並
列プログラムの開発支援装置。