JP2002342078A - プログラム開発システム及び方法 - Google Patents

Abstract

(57)【要約】 【課題】クライアントプログラム又はサーバプログラム
をＣＯＢＯＬなどの手続き型言語で実装する場合には，
プログラム言語で記述したデータと、動的データとの間
の変換処理を記述する必要があった。 【解決手段】プログラム記述言語で定義されているデー
タ型と，実際にプログラム間で通信する際に使用するデ
ータ型とを比較し、アプリケーションプログラムと通信
基盤との仲介を行うプログラム中に適切な変換処理を自
動生成するプログラム開発システム。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、既存のプログラム
をその一部として利用するソフトウェアシステムの構築
を支援するプログラム開発システム、特に、分散オブジ
ェクト技術を利用してソフトウェアシステムを構築する
ためのプログラム開発システムに関する。

【０００２】

【従来の技術】ネットワークを介して複数のコンピュー
タを接続した並行分散システム上で動作するユーザプロ
グラムをコンパイルする際に用いられるプログラム変換
方法に関して、プログラマの負担を軽減するものとして
特開２０００−９９３４５号公報に開示された技術があ
る。ここでは、プログラムに含まれるネットワークを介
した通信に係わる記述を、予め決められた識別用字句を
キーとして検索して特定し、この特定した記述を予め決
められた記述に翻訳し、先のプログラムに含まれるネッ
トワークを介した通信に係わる記述以外の記述と、翻訳
された記述とをコンパイルすることが開示されている。

【０００３】

【発明が解決しようとする課題】オブジェクトマネジメ
ントグループによるソフトウェアの共通仕様であるＣＯ
ＲＢＡ（Common Object Request Broker Architectur）
を使用して、既存のプログラム資産を再利用すること
で、ソフトウェアの生産効率を改善することができ、品
質の確保されたプログラムをＣＯＲＢＡの仕様に則った
形で実装することにより、当該プログラムを部品として
利用することができる。

【０００４】実際に提供されるプログラム部品は、その
汎用性を指向するあまり、プログラムの実行時に動的に
型が決定されるデータ型（動的データ型）を使用するこ
とがある。例えば、上記ＣＯＲＢＡの仕様で定められて
いるａｎｙ型は、ＣＯＲＢＡで定義されている任意のデ
ータ型として使用することができる。前述のＣＯＲＢＡ
仕様でも述べられているように，ａｎｙ型はデータ、及
びそのデータの型情報（ＴｙｐｅＣｏｄｅ）をあわせ持
つオブジェクトとして実装される。このようなデータ型
を使用することで，さまざまなデータ型を使用するプロ
グラムから利用可能なプログラム部品を作成することが
出来る。

【０００５】演算子の再定義の機能を言語仕様として備
えた、Ｃ＋＋などのオブジェクト指向言語で新規にアプ
リケーションを実装する場合には、動的データ型を操作
することは比較的容易である。しかし、プログラム言語
ＣＯＢＯＬ（ＪＩＳ Ｘ ３００２−１９９２ 電子計算
機プログラム言語ＣＯＢＯＬ）など、演算子の再定義を
言語仕様として持たないプログラム言語で、動的データ
型を扱うプログラム部品を使用するアプリケーションを
開発する場合は、言語仕様で使用しているデータ型と、
プログラム部品で使用する動的データ型との間のデータ
型の変換処理を新たに作成する必要がある。 多くの場合、ラッパープログラムと呼ばれる変換専用ル
ーチンを新たに作成し、アプリケーションプログラム中
からラッパープログラムを呼び出すことにより、データ
型の変換を行う。あるいは、アプリケーションプログラ
ムを呼び出す前後で、変換処理を施す場合もある。いず
れの場合も、アプリケーションプログラムのプログラマ
にはなじみがないデータ型を扱うプログラムを新たに作
成するため、学習及びプログラム品質の確保には困難が
ともなう。

【０００６】本発明の目的は、アプリケーションプログ
ラムで使用するデータ型と，プログラム部品で使用する
データ型との変換処理を自動生成することにより，プロ
グラマの負担を軽減することにある。

【０００７】

【課題を解決するための手段】上記目的を達成するため
に、本発明によるプログラム開発環境は、アプリケーシ
ョンプログラムで使用するデータ型と、プログラム部品
のインタフェース情報との差分を解析する機能を備える
ことにより、必要に応じてアプリケーションプログラム
で使用するデータ型と、プログラム部品で使用するデー
タ型との変換プログラムを自動生成するようにしたもの
である。

【０００８】

【発明の実施の形態】本発明の実施形態のプログラム開
発システムは、ＣＯＢＯＬ言語で作成したプログラム
と、ＣＯＲＢＡの仕様に則って実装されたＣ＋＋などの
他言語により実装されたプログラム部品とを使用してシ
ステムを構築する場合に適用するものである。 図１は、本発明を適用したプログラム開発システムの構
成図である。以下では，プログラマが作成したアプリケ
ーションプログラムから，プログラム部品を呼び出すケ
ースについて説明するが，プログラム部品から呼ばれる
プログラムをプログラマが作成する場合も同様な手順で
本発明を適用できる。

【０００９】プログラム部品の呼び出し名、引数、戻り
値などの情報（以下，インタフェースと総称する）は、
ＣＯＲＢＡの仕様に則したＩＤＬの形式で与えられる
（１０１）。このプログラム部品を利用するために，プ
ログラマが作成するアプリケーションソースプログラム
には、プログラム部品を呼び出すための外部プログラム
の呼び出し処理が記述される。

【００１０】アプリケーションソースプログラムから
は，適当なアプリケーションプログラム開発ツールを使
用することにより，そのアプリケーションプログラム自
身のインタフェース情報と，アプリケーションプログラ
ムが呼び出す外部プログラムの呼び出しインタフェース
（以下、ＡＰインタフェース情報と総称する）を抽出す
ることができる。この抽出過程は公知の技術で実現可能
である。１例として，アプリケーションプログラム記述
言語の言語処理系の１部を使用して、ＡＰインタフェー
ス情報を取得する手順を図１４に示す。ＡＰインタフェ
ース情報作成部１４０２は、ＡＰソースプログラム１４
０１を読み込んで，構文解析部１４０３により、プログ
ラム言語の文法に従って構文を解析して，トークン列１
４０４を抽出する。意味解析部１４０５は、プログラム
言語の文法に従ってトークン列１４０４の意味解析を行
い，辞書テーブル１４０６を作成する。インタフェース
情報生成部１４０７は、辞書１４０６より、インタフェ
ースに関連する情報のみを抽出し，ＡＰインタフェース
情報ファイル１４０８を出力する。 本発明を適用するプログラム開発システムは、プログラ
ム部品が提供するＩＤＬ（１０１）を読み込むＩＤＬ読
み込み部（１０３）と、読み込んだＩＤＬの構文を解析
するＩＤＬ構文解析部（１０４）とにより、ＩＤＬに定
義された情報を一旦プログラム間インタフェース内部情
報として蓄積する（１０５）。また、ＡＰインタフェー
ス情報読み込み部（１０６）、ＡＰインタフェース解析
部（１０７）とにより、ＡＰインタフェース内部情報を
も蓄積する（１０８）。インタフェースマッチング判定
部（１０９）は、１０５、１０８のそれぞれの内部情報
を解析、比較し、拡張スタブ・スケルトン出力部（１１
０）は、内部情報の差分についての変換処理を含んだス
タブ・スケルトンを出力する。

【００１１】スタブ・スケルトンの位置付けについて、
図２、図３、図４を使用して説明する。

【００１２】図２は、ＣＯＲＢＡの仕様に則して作成さ
れたクライアント―サーバシステムの論理的な構成図で
ある。ＣＯＲＢＡのクライアントプログラムは，プログ
ラマが作成し、クライアントコンピュータ（２０１）で
実行されるクライアントプログラム（２０２）と、クラ
イアントコンピュータ（２０１）の通信処理インタフェ
ースに対応した，クライアント側通信基盤（２０４）
と、クライアントプログラム（２０２）のデータをクラ
イアント側通信基盤（２０４）が定める形式に変換した
り、逆にクライアント側通信基盤（２０４）が定める形
式のデータからクライアントプログラムで操作可能なデ
ータに変換する処理を行う，スタブ（２０３）と呼ばれ
るプログラムから構成される。ＣＯＲＢＡのサーバプロ
グラムは，プログラマが作成し，サーバコンピュータ
（２０５）で実行されるサーバプログラム（２０６）
と、サーバコンピュータ（２０５）の通信処理インタフ
ェースに対応した，サーバ側通信基盤（２０８）と、サ
ーバプログラム（２０６）のデータをサーバ側通信基盤
（２０８）が定めるデータ型に変換したり，逆にサーバ
側通信基盤（２０８）が定める形式のデータからサーバ
プログラムで操作が可能なデータに変換する処理を行
う，スケルトン（２０７）と呼ばれるプログラムから構
成される。

【００１３】スタブ及びスケルトンは，サーバプログラ
ム（２０５）のインタフェースを記述したＩＤＬから、
ＩＤＬコンパイラと呼ばれるプログラムを使用して生成
する。

【００１４】スタブは，クライアント側通信基盤と、ク
ライアントプログラムとの仲立ちを行うプログラムとし
て，クライアントプログラムの記述言語で記述されたプ
ログラムとして生成される。スタブは，引数として受け
取ったデータを通信基盤が定める形式で通信バッファに
格納し，サーバへの送信処理を行う。また、通信基盤を
介して戻されたサーバの戻り値、及び出力引数のデータ
を通信バッファから取り出し，あたかもスタブプログラ
ム自身の戻り値、及び出力引数として設定する。このよ
うな処理により，クライアントプログラムは，スタブの
プログラムを、あたかもサブプログラムを呼び出すかの
ように呼び出すことで、サーバプログラムの処理の呼び
出しを実現できる。

【００１５】また，スケルトンは，サーバ側通信基盤
と、サーバプログラムとの仲立ちを行うプログラムとし
て，サーバプログラムの記述言語で記述されたプログラ
ムとして生成される。スケルトンは，通信基盤から受け
取った通信バッファからデータを取り出し，サーバプロ
グラムの引数に設定してサーバプログラムを呼び出す。
また、サーバプログラム実行後，その戻り値、及び出力
引数を通信バッファに設定し、通信基盤に送り返す。こ
のような処理により、サーバプログラムはあたかも１つ
のサブプログラムであるかのように記述することで，別
のコンピュータから発行されたリクエストを処理するこ
とが出来る。

【００１６】なお、図２では、クライアントコンピュー
タ（２０１）と、サーバコンピュータ（２０５）とが、
インターネットなどの通信回線を介して接続している例
を示しているが，ＣＯＲＢＡのクライアント―サーバシ
ステムはこのような例にとどまるものではなく，特にク
ライアントコンピュータとサーバコンピュータは同一ハ
ードウェアであってもよい。

【００１７】図３は、本発明により作成されるスタブの
処理の流れを示したものである。スタブは，必要ならば
通信バッファの確保や呼び出し先メソッドの設定などの
初期化処理（３０１）を行った後，クライアントプログ
ラムから渡された引数データを入力パラメタとして通信
バッファに格納し（３０２）、通信基盤に介して通信バ
ッファの内容をサーバに送信する（３０３）。ここで、
クライアントのデータ型とＩＤＬのデータ型が一致して
いない場合は、入力パラメータの変換処理３１１が、初
期化処理３０１と通信バッファへの格納処理３０２との
間で行われる。サーバの処理後，通信基盤はサーバの処
理結果を通信バッファ内に格納して、再びスタブに処理
を戻す。スタブは，通信バッファの内容が例外情報であ
ればクライアントプログラムに例外を通知する（３０
４、３０５）。ここで、ＩＤＬの例外データ型がクライ
アントのデータ型と一致していない場合は、データ型の
変換処理３１３が、処理３０５の前に行われる。通信バ
ッファの内容が正常ケースのサーバの戻り値の場合は通
信バッファの内容を出力パラメタと戻り値に設定してク
ライアントプログラムに処理を戻す（３０６）。ここ
で、ＩＤＬの例外データ型とクライアントの例外データ
型が一致していない場合は、本発明の効果により挿入さ
れるところの，データ型の変換処理３１２が処理３０６
の前に行われる。図４は、スケルトンの処理の流れを示
したものである。スケルトンは，通信バッファの情報か
ら呼び出し先のメソッドを判定するなどの初期処理（４
０１）を行った後、バッファから入力パラメタを取り出
してサーバプログラムのパラメタに設定し（４０２）、
サーバメソッドを呼び出す（４０３）。ここで、サーバ
のデータ型とＩＤＬのデータ型が一致していない場合
は、初期化処理４０１と、パラメタへのデータ設定処理
４０２との間に，データ変換処理４１１が挿入される。
サーバメソッド呼び出し中に例外が発生した場合は例外
情報を通信バッファに格納する（４０６）。ここで、サ
ーバの例外データ型とＩＤＬの例外データ型とが一致し
ていない場合は、データ型の変換処理４１３が行われ
る。サーバメソッドが正常に終了した場合は、サーバの
出力パラメタと戻り値を通信バッファに設定して（４０
５）通信基盤に処理を戻す。通信基盤はそのバッファを
クライアント側の通信基盤に送信する。ここで、ＩＤＬ
のデータ型とサーバのデータ型が一致していない場合
は、データ変換処理４１２が行われる。 なお、引数や戻り値がないインタフェースが指定された
場合は、図３、図４の説明の対応する処理は省略され
る。

【００１８】本発明は、ＩＤＬに記載されたデータ構造
と、クライアント又はサーバで使用しているデータ構造
との相違を分析し，データ変換処理をスタブ中に出力す
ることで，プログラマがデータの変換処理を記述する労
力を軽減する事を目的とする。

【００１９】なお、ＣＯＲＢＡでは、引数・戻り値のほ
かに付加情報（コンテキストなど）を送受信することも
でき、本発明はこれらの付加情報に対しても同様に適用
できるが、発明の実現方式，実施形態として本質的な相
違はないため，以後，引数及び戻り値を例として説明す
る。

【００２０】図５は、図１のＩＤＬ（１０１）の例であ
る。ここでは，プログラム部品のインタフェースを定義
するＩＤＬとして説明する。５０１では、ＩＤＬの「ａ
ｎｙ型」を使用している。ａｎｙ型は，ＩＤＬの任意の
データ型に対応可能なデータ型である。ａｎｙ型に対応
するデータは、オブジェクト指向言語で実装されたプロ
グラムにおいては、型の情報と値の情報をもつオブジェ
クトとして実装され，実行時に型の情報を参照してそれ
ぞれの型に応じて適切な処理を行う。ＣＯＢＯＬ言語な
どの手続き型言語では、ａｎｙ型に含まれるデータ構造
は処理系によって隠蔽され，プログラマが作成するアプ
リケーションプログラムでは、ａｎｙ型のデータを指す
ポインタを介して，処理系が提供する関数群を使用して
操作する必要がある。この場合、プログラマは，処理系
が提供する関数群を使用して，データの変換処理を記述
する必要がある。

【００２１】図６は、ＣＯＢＯＬで作成したアプリケー
ションプログラムが使用するデータ型の例である。ここ
で，データ６０１は、数値データ６０２と、文字列デー
タ６０３とからなる構造型データであることを示してい
る。図５に示したインタフェースを持つプログラム部品
を使用する場合，６０１で示したデータを、５０１の動
的データであるａｎｙ型に変換する必要がある。

【００２２】図７は、図５のＩＤＬデータ型に，図６の
データを対応付けるために記述した，データ変換処理の
例である。ａｎｙ型へのデータの格納のためには，デー
タの型の情報を示す「ＴｙｐｅＣｏｄｅ」と呼ばれるオ
ブジェクトを作成する必要があるため，処理系が提供す
る関数群を使用して７０１から７０５に示すような処理
を記述しなければならない。７０１では、構造型に対応
するＴｙｐｅＣｏｄｅオブジェクトを確保するための関
数を呼び出す。７０２、７０３では、それぞれ６０２、
６０３に対応するＴｙｐｅＣｏｄｅオブジェクトを取得
するための関数を呼び出す。７０４、７０５では、７０
１で確保した６０１に対応するＴｙｐｅＣｏｄｅオブジ
ェクトに，６０２、６０３に対応するＴｙｐｅＣｏｄｅ
オブジェクト、すなわち，７０４、７０５の関数呼び出
しの戻り値を格納するための関数を呼び出す。７０１か
ら７０５の処理により、６０１に対応するＴｙｐｅＣｏ
ｄｅオブジェクトが作成できたので，７０６では、Ｔｙ
ｐｅＣｏｄｅオブジェクトとともに６０１の値をａｎｙ
型のオブジェクトに格納する。 図８は図５に示すＩＤＬのデータ型に対応するＣＯＢＯ
Ｌのデータの例である。アプリケーションプログラムで
実際に使用するデータ型が図６に示すものであっても，
図５のＩＤＬで定義されたデータ型に合致するために，
プログラマは図７の処理を記述して，図６のデータから
図８のデータへのデータ変換を行わなければならない。
本発明により、従来プログラマが記述してきたデータ変
換処理をスタブ・スケルトン中で行うことが可能となる
ため，プログラマは変換処理を記述することなく、業務
処理の実装に専念できる。以下，本発明の詳細な処理手
順を説明する。

【００２３】まず、本発明では，前述した図１の１０
３、１０４の処理により，ＩＤＬなどの形で示されるプ
ログラム部品のインタフェース情報から，プログラム部
品で使用するデータの構造を取得する。例えば，図５に
示すＩＤＬからは、ＩＤＬのデータ構造は概念的に図９
に示す木構造として表すことができる。

【００２４】また、所与のＡＰインタフェース情報か
ら，前述した図１の１０６、１０７に示す処理により、
アプリケーションプログラムで使用するデータの構造を
取得する。例えば，図６に示すアプリケーションプログ
ラムのデータ構造は、概念的に図１０に示す木構造とし
て表すことができる。インタフェースマッチング判定部
（１０９）は，これらの構造を比較し，データ型の変換
処理を出力する。

【００２５】図１１は、インタフェースマッチング判定
部（１０９）の処理の流れを示したものである。

【００２６】インタフェースマッチング判定部は，必要
な作業領域の確保などの初期処理（１１０１）を行った
後，プログラム間インタフェース内部情報（１０５）、
すなわち，図９に示すようなデータと、ＡＰインタフェ
ース内部情報（１０８）、すなわち，図１０に示すよう
なデータを順に走査し、比較する。以下，プログラム間
インタフェース内部情報をＩＤＬデータ、ＡＰインタフ
ェース内部情報をＡＰデータと呼ぶ。

【００２７】まず、ＩＤＬデータ、ＡＰデータを１つづ
つ読み込む（１１０２）。ＩＤＬデータがａｎｙ型か否
かを判定し（１１０４）、ａｎｙ型でなければ，単純デ
ータ型として、ＩＤＬデータとＡＰデータとの間の転記
処理を出力する（１１０６）。

【００２８】ａｎｙ型の場合は，図１２のａｎｙ型転記
処理出力処理を行う。

【００２９】図１２は、インタフェースマッチング判定
部の処理の一部の流れであり，動的データ型であるａｎ
ｙ型に対応する処理の流れを示したものである。

【００３０】ａｎｙ型のデータをやり取りするために
は，前述のとおり，値とともにＴｙｐｅＣｏｄｅと呼ば
れる型の情報を作成する必要がある。ＴｙｐｅＣｏｄｅ
は、ａｎｙ型に格納するデータがさらに従属したデータ
を持っている場合、すなわち、データが構造をもってい
る場合とそうでない場合とで作成方法が異なる。このた
め、ａｎｙ型転記処理では、ＡＰデータが構造をもって
いるかどうかを判定する（１２０１）。構造をもってい
る場合には，構造を持ったデータに対応するＴｙｐｅＣ
ｏｄｅを格納するためのＴｙｐｅＣｏｄｅ（構造型Ｔｙ
ｐｅＣｏｄｅ）を生成する処理を出力する（１２０
２）。

【００３１】図１３は、構造型ＴｙｐｅＣｏｄｅ生成処
理出力の流れである。ステップ１３０１で、構造型Ｔｙ
ｐｅＣｏｄｅオブジェクト「ＳＴＲＴＣ」を確保する処
理を生成する。なお、「ＳＴＲＴＣ」及び以下で使用す
る変数名は、説明の便宜上命名したものであり，実際の
生成過程では，名称の衝突が発生しないよう重複しない
名称が付与される。この処理により、例えば７０１に示
す関数呼び出しが出力される。ＡＰデータの従属データ
をＡＰデータとして代入し（１３０２）、ＡＰデータが
さらに下位の構造を持つか否か判定する。 ＡＰデータが下位の構造をもたない場合，ＡＰデータに
対応するＴｙｐｅＣｏｄｅ「ＡＰＴＣ」を生成する処理
を出力し（１３０４）、「ＡＰＴＣ」を「ＳＴＲＴＣ」
に代入する処理を出力する（１３０５）。１３０４、１
３０５によって生成される処理は、それぞれ処理系が提
供する関数呼び出しの形で生成される。例えば１３０４
によって７０２が、１３０５によって７０３がそれぞれ
出力される。 ＡＰデータが下位の構造を持つ場合は，構造型Ｔｙｐｅ
Ｃｏｄｅ生成処理出力を再帰的に呼び出し、下位の構造
についてのＴｙｐｅＣｏｄｅ生成処理を出力した後（１
３０６），再帰呼び出しによって生成されたＴｙｐｅＣ
ｏｄｅ生成処理の最後の生成処理の結果を「ＳＴＲＴ
Ｃ」に代入する処理を出力する（１３０７）。構造型Ｔ
ｙｐｅＣｏｄｅ出力処理に渡されたＡＰデータが複数の
データを含む場合、全てのデータについてＴｙｐｅＣｏ
ｄｅを生成しなければならない。１３０９で、次のＡＰ
データが存在するか否かを判定し，存在する場合はＡＰ
データに次のＡＰデータを代入して１３０３以降の処理
を繰り返す。この繰り返し処理によって、例えば，図７
の７０４、７０５の処理が生成される。 以上の処理により、図１２における構造型ＴｙｐｅＣｏ
ｄｅ生成処理が出力された。 構造型ＴｙｐｅＣｏｄｅ生成処理を出力した後、ａｎｙ
型オブジェクトにＴｙｐｅＣｏｄｅと値を代入する処理
を出力する（１２０３）。

【００３２】ａｎｙオブジェクトに対して、一時領域に
退避していたＡＰデータと、構造型ＴｙｐｅＣｏｄｅを
代入する処理を出力する（１２０９）。例えば，７０６
の処理がこれにあたる。

【００３３】一方、ＡＰデータが単独のデータであった
場合には，ＡＰデータに対応するＴｙｐｅＣｏｄｅの生
成処理を出力し（１２０４）ＴｙｐｅＣｏｄｅとＡＰデ
ータをａｎｙオブジェクトに代入する処理を出力する
（１２０５）。最後に、ａｎｙオブジェクトを通信バッ
ファに格納する処理を出力する（１２０６）。

【００３４】図１１、図１２、及び図１３に示した処理
により，ＩＤＬとＡＰデータとでデータ型が異なる場合
に適当な変換処理を行うスタブ・スケルトンを生成する
ことが可能となる。

【００３５】なお、処理系によっては、ＩＤＬのｓｔｒ
ｉｎｇ型や、ｓｅｑｕｅｎｃｅ型など、他のデータ型に
ついてもデータ変換処理が必要な場合がある。これらの
データ型についてデータ変換処理をスタブ、スケルトン
中に生成するためには，以下に述べる処理の変更によ
り、容易に実現可能である。 すなわち、図１１の１１０４における判定処理におい
て、該当するデータ型の判定処理を追加するとともに、
１１０５を各データ型に対応するデータ変換処理を出力
する処理の呼び出しに置き換える。また、図１２におい
て，１２０３、１２０５、及び１２０６を該当するデー
タ型に対応する出力処理に置き換える。さらに、変換処
理においてＴｙｐｅＣｏｄｅが不要なデータ型について
は１２０２、１２０４の処理を削除する。

【００３６】本実施例によれば、アプリケーションプロ
グラム中での変換処理の記述を行うことなく，汎用的な
プログラム部品を使用したシステムを構築することが出
来るため，プログラマの負担を軽減する効果がある。

【００３７】

【発明の効果】本発明によれば，プログラミングの負担
を減らすことが出来るとともに、プログラム不良を作り
込む機会を少なくすることができる。

【図面の簡単な説明】

【図１】プログラム開発システムの構成を示すブロック
図である。

【図２】クライアント―サーバプログラムの構成を示す
ブロック図である。

【図３】スタブが行う処理を示したフローチャートであ
る。

【図４】スケルトンが行う処理を示したフローチャート
である。

【図５】ＩＤＬの例である。

【図６】ＣＯＢＯＬで作成したアプリケーションプログ
ラムが使用するデータ型の例である。

【図７】データ変換処理の例である。

【図８】ＩＤＬのデータ型に対応するＣＯＢＯＬのデー
タの例である。

【図９】ＩＤＬのデータ構造を概念的に表した木構造で
ある。

【図１０】アプリケーションプログラムのデータ構造を
概念的に表した木構造である。

【図１１】インタフェースマッチング判定部の処理の流
れを示したものである。

【図１２】ａｎｙ型転記処理出力の処理の流れを示した
ものである。

【図１３】構造型ＴｙｐｅＣｏｄｅ出力処理の処理の流
れを示したものである。

【図１４】ソースファイルからインタフェース情報を取
り出す処理の流れを示したものである。

【符号の説明】

１０１ ＩＤＬ １０２ インタフェース情報 １０３ ＩＤＬの読み込み部 １０４ ＩＤＬ構文解析部 １０５ プログラム間インタフェース内部情報 １０６ アプリケーションプログラムインタフェース読
み込み部 １０７ アプリケーションプログラムインタフェース解
析部 １０８ アプリケーションプログラムインタフェース内
部情報 １０９ インタフェースマッチング判定部 １１０拡張スタブ・スケルトン出力部 １１２ プログラム開発システム １１１ 拡張スタブ・スケルトン

───────────────────────────────────────────────────── フロントページの続き (72)発明者 佐原 宏史 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア事業部内 Ｆターム(参考） 5B076 DD04 DD08

Claims (3)

【特許請求の範囲】
1. 【請求項１】プログラムで使用するデータ型を解析した
   結果と、該プログラムを呼び出すプログラムで使用する
   データ型を解析した結果との比較を行う手段と、該比較
   の結果、差分が存在する場合には該差分について、デー
   タ型変換処理を自動的に生成する手段とを有するプログ
   ラム開発システム。
2. 【請求項２】プログラムで使用するデータ型を解析した
   結果と、該プログラムを呼び出すプログラムで使用する
   データ型を解析した結果との比較を行う手段と、該比較
   の結果、差分が存在する場合には該差分について、デー
   タ型変換処理を自動的に生成する手段とを有するプログ
   ラム開発方法。
3. 【請求項３】プログラムで使用するデータ型を解析した
   結果と、該プログラムを呼び出すプログラムで使用する
   データ型を解析した結果との比較を行う手段と、該比較
   の結果、差分が存在する場合には該差分について、デー
   タ型変換処理を自動的に生成する手段とを有するプログ
   ラム。