JP6944838B2 - 変換装置および変換方法 - Google Patents

Description

本発明は、変換装置および変換方法に関する。

現行システムから新システムへのシステム移行において、例えば、プログラムのコンバージョン開発という作業がある。コンバージョン開発では、現行システムに用いられる現行プログラムソース（変換元ソース）のプログラム言語（例：ＣＯＢＯＬ（COmmon Business Oriented Language））を別のプログラム言語（例：ＪＡＶＡ（登録商標））に置き換えて、新システムに用いられる新プログラムソース（変換後ソース）を作成する。

従来のコンバージョン開発では、例えば、言語文法上の命令単位や構文単位で言語変換を行う変換ツールを複数種類用意し、変換元ソースに対して各変換ツールを順次実行することで、言語変換がなされた変換後ソースを作成していた。このとき、費用対コストの理由等で、変換元ソースの一部に対しては変換ツールを実行できない場合がある。この場合、手修正で当該一部に対して言語変換を行い、言語変換が完全になされた変換後ソースを得る。

また、コンバージョン開発では、得られた変換後ソースに不良があるか否かを確認するための確認テスト（実機確認）が行われる。具体的には、変換元ソースおよび変換後ソースに同じ入力値を入力し、両者間で同じ出力値が得られれば不良なし、異なる出力値が得られれば不良ありと判定する。コンバージョン開発では、変換後ソースに不良がある場合、不良原因を作り込んだ変換ツールまたは手修正を特定し、特定した変換ツールまたは手修正を修正して不良原因を取り除くことになる。

一般的に、変換後ソースについて、不良原因となる行を特定することはできる。しかし、変換ツールの順次実行と手修正との組合せによる従来の言語変換では、不良原因を作り込んだ変換ツールまたは手修正を特定することは、有識者による検討が必要となるほど困難であり、大きな不良対応コストを必要とする。結果的に、従来のコンバージョン開発における不良対応コストは大きい。

特許文献１には、「メインフレーム系のデータをオープン系のデータに変換する変換手段と、入力データのバイトごとに色を割り当てる割り当て手段と、前記割り当て手段によりバイトごとに色を割り当てられた前記入力データを表示する表示手段と、を有し、前記メインフレーム系のデータが入力データとして入力された場合、前記割り当て手段は、前記メインフレーム系のデータのバイトごとに色を割り当て、前記表示手段は、前記割り当て手段によりバイトごとに色を割り当てられた前記メインフレーム系のデータを表示し、前記オープン系のデータが入力データとして入力された場合、前記割り当て手段は、前記オープン系のデータごとに色を割り当て、前記表示手段は、前記割り当て手段によりバイトごとに色を割り当てられた前記オープン系のデータを表示する情報処理装置。」について開示されている。

特開２０１６−１９１９７７号公報（請求項１）

特許文献１によれば、メインフレーム系のデータに相当する変換元ソースから、オープン系のデータに相当する変換後ソースへの変換が適切に行われたか否かを概略的に確認可能とし、変換後ソースについて、不良原因となる行を表示することは可能と思われる。しかし、特許文献１には、不良原因を作り込んだデータの変換を特定することについては記載も示唆もされていない。そのため、特許文献１では、コンバージョン開発における不良対応コストを削減することはできない。

本発明は、このような事情に鑑みて、コンバージョン開発等のシステム移行における不良対応コストを削減することを課題とする。

前記課題を解決するために、本発明は、
変換元ソースを変換後ソースに変換する変換装置であって、
前記変換元ソースの一部を前記変換後ソースの一部に変換して生成される変換途中ソースの集合について、前記変換途中ソースの各々への変換に関するメタ情報を管理するメタ情報管理部と、
前記変換後ソースの確認テストで不良があった場合、前記メタ情報を参照して、前記不良の不良原因を作り込んだ変換を特定するテスト部と、を備える、
ことを特徴とする。
その他の発明については、後記する。

本発明によれば、コンバージョン開発等のシステム移行における不良対応コストを削減することができる。

本実施形態の変換装置の機能構成図である。 異言語変換処理を示すフローチャートである。 手修正結果流用の説明図である。 片方優先３方向マージの説明図である。 追いつき作業前に行われた異言語変換の手順を示す説明図である。 追いつき作業の手順を示す説明図である。

続いて、本発明の実施形態について、図面を参照して説明する。本実施形態の変換装置は、入力部、出力部、制御部、および記憶部といったハードウェアを含むコンピュータである。例えば、制御部がＣＰＵ（Central Processing Unit）から構成される場合、その制御部を含むコンピュータによる情報処理は、ＣＰＵによるプログラム実行処理で実現される。また、そのコンピュータが含む記憶部は、ＣＰＵの指令により、そのコンピュータの機能を実現するためのさまざまなプログラムを記憶する。これによりソフトウェアとハードウェアの協働が実現される。前記プログラムは、記録媒体に記録したり、ネットワークを経由したりすることで提供することができる。

≪構成≫
図１に示すように、本実施形態の変換装置１は、コンバータｃ１〜ｃｎと、コンバータ別変換結果リポジトリｒ１１〜ｒ１ｎと、バージョン管理ツール１０と、メタ情報ＤＢ（DataBase）１１と、マージツールｍ１と、機械変換結果リポジトリｒ２と、手修正管理ツール２０と、手修正実施用ワークスペース２１と、手修正結果リポジトリｒ３と、マージツールｍ２と、変換結果リポジトリｒ４と、テストツール３０と、を備える。

図１中の変換元ＣＯＢＯＬソースｓ１は、ＣＯＢＯＬで記述されたＣＯＢＯＬコード（「ＣＯＢＯＬ１」、「ＣＯＢＯＬ２」、・・・、「ＣＯＢＯＬＮ」、「ＣＯＢＯＬＸ」）を記録したソースコードであり、顧客が現行システムを運用するために実行される。
また、図１中の変換後Ｊａｖａソースｓ２は、ＪＡＶＡで記述されたＪＡＶＡコード（「Ｊａｖａ１」、「Ｊａｖａ２」、・・・、「ＪａｖａＮ」、「ＪａｖａＸ」）を記録したソースコードであり、顧客が新システムを運用するために実行される。
図１中の各種の変換途中ソースｓ３１〜ｓ３ｎ，ｓ４，ｓ５については後記する。

［コンバータｃ１〜ｃｎ］
コンバータｃ１〜ｃｎは、変換元ＣＯＢＯＬソースｓ１のＣＯＢＯＬコードの一部をＪＡＶＡコードに機械的に変換する。コンバータｃ１〜ｃｎの各々が変換するＣＯＢＯＬコードとしての文字列は予め決められており、例えば、命令語単位で用意することができる（例：ＣＯＢＯＬコードの「ＭＯＶＥ」をＪＡＶＡコードの「ｓｅｔ」に変換するコンバータ）。また、コンバータｃ１〜ｃｎは、構文単位で用意することもでき、言語文法上のさまざまな粒度で設計することができる。

なお、コンバータｃ１〜ｃｎの各々は、変換元ＣＯＢＯＬソースｓ１の同じ行を重複して変換することが無いように設計されている。図１に示すように、コンバータｃ１が変換元ＣＯＢＯＬソースｓ１の「ＣＯＢＯＬ１」を「Ｊａｖａ１」に変換するが、コンバータｃ２などが同じ変換をすることは無い。同様にして、コンバータｃ２〜ｃｎの各々は、変換元ＣＯＢＯＬソースｓ１の「ＣＯＢＯＬ２」〜「ＣＯＢＯＬＮ」の各々を、「Ｊａｖａ２」〜「ＪａｖａＮ」に変換する。変換元ＣＯＢＯＬソースｓ１の「ＣＯＢＯＬＸ」は、手修正されるＣＯＢＯＬコードであるが、詳細は、後記する。

［コンバータ別変換結果リポジトリｒ１１〜ｒ１ｎ］
コンバータ別変換結果リポジトリｒ１１〜ｒ１ｎの各々は、変換元ＣＯＢＯＬソースｓ１に対してコンバータｃ１〜ｃｎの各々を実行することでＣＯＢＯＬコードの一部がＪＡＶＡコードに変換された変換途中ソースｓ３１〜ｓ３ｎの各々を格納する。

［バージョン管理ツール１０］
バージョン管理ツール１０は、コンバータｃ１〜ｃｎの各々が変換元ＣＯＢＯＬソースｓ１から変換途中ソースｓ３１〜ｓ３ｎの各々に変換したときの変換に関する情報をメタ情報として取得して管理する。メタ情報は、例えば、変換ごとに、変換元ＣＯＢＯＬコードと変換後ＪＡＶＡコードとの対応、変換を実行したコンバータのＩＤ（Identifier）、変換の内容（例：「ＭＯＶＥ」→「ｓｅｔ」）、変換設計のＩＤ、変換の実行の日時、補足説明としてのコメントを含むが、これらに限定されない。本実施形態のバージョン管理ツール１０は、Ｇｉｔなどの分散型バージョン管理ツールとして実装することができる。

［メタ情報ＤＢ１１］
メタ情報ＤＢ１１は、バージョン管理ツール１０が取得したメタ情報を格納する。なお、本実施形態の変換装置１に、ＴｏｒｔｏｉｓｅＧｉｔなどのＧＵＩ（Graphic User Interface）を備え、メタ情報や変換途中ソースｓ３１〜ｓ３ｎを視覚的に追跡可能としてもよい。

［マージツールｍ１］
マージツールｍ１は、コンバータ別変換結果リポジトリｒ１１〜ｒ１ｎが格納する変換途中ソースｓ３１〜ｓ３ｎに対してマージ処理をする。マージ処理は、例えば、分散型バージョン管理ツールで用いられる３方向マージ（周知であり、詳細な説明は省略）を用いることができる。

例えば、マージツールｍ１は、変換元ＣＯＢＯＬソースｓ１を親とし、親から派生した変換途中ソースｓ３１〜ｓ３ｎのいずれか２つを子として３方向マージをし、２つの子の変換箇所を親に反映した結果物（変換がより進んだ変換途中ソース）を得る。２つの子の変換箇所が同じ行であれば３方向マージは失敗するが（コリジョン）、本実施形態のコンバータｃ１〜ｃｎは、変換箇所が唯一となるように設計されているため、２つの子の変換箇所が同じ行になることはない。

例えば、マージツールｍ１は、まず、変換元ＣＯＢＯＬソースｓ１を親とし、変換途中ソースｓ３１，ｓ３２を第１の子、第２の子として３方向マージをし、第１の結果物を得る。次に、マージツールｍ１は、変換元ＣＯＢＯＬソースｓ１を親とし、第１の結果物を第１の子、変換途中ソースｓ３３を第２の子として３方向マージをし、第２の結果物を得る。上記のように３方向マージを多段的に実行することで、コンバータｃ１〜ｃｎによる機械的な変換がすべて実行された変換途中ソースｓ４（「Ｊａｖａ１」、「Ｊａｖａ２」、・・・、「ＪａｖａＮ」、「ＣＯＢＯＬＸ」）を得ることができる。
また、マージツールｍ１は、マージ処理として、変換途中ソースｓ３１〜ｓ３ｎを一括してマージし、変換途中ソースｓ４を得ることもできる。

［機械変換結果リポジトリｒ２］
機械変換結果リポジトリｒ２は、マージツールｍ１によって、機械的な変換の結果がすべてマージされた変換途中ソースｓ４を格納する。

［手修正管理ツール２０］
手修正管理ツール２０は、変換元ＣＯＢＯＬソースｓ１の一部から変換後Ｊａｖａソースｓ２の一部への変換を行うための手修正を管理する。具体的には、手修正管理ツール２０は、変換元ＣＯＢＯＬソースｓ１のＣＯＢＯＬコード「ＣＯＢＯＬＸ」を、変換後Ｊａｖａソースｓ２のＪＡＶＡコード「ＪａｖａＸ」に手修正で変換する。
また、手修正管理ツール２０は、バージョン管理ツール１０に対して、手修正の変換に関する情報をメタ情報として出力する。

なお、ＣＯＢＯＬコードからＪＡＶＡコードへの変換を手修正で行う場合とは、言語仕様の相違に起因して、同じＣＯＢＯＬコードであれば同じ機械変換を行うというルールがあてはまらない場合である。具体的には、以下の手修正必要例１〜３に該当する場合である。
手修正必要例１：複数の同じデータ項目名の存在
手修正必要例２：明確なデッドコード（到達不能コード）の存在
手修正必要例３：複数の同じ分岐条件の存在

手修正必要例１に関しては、例えば、
〔ＣＯＢＯＬコード〕
01 D1 PICTURE X(2) VALUES ‘AZ’.
01 D1 PICTURE 9(2) VALUES 10.
を機械変換した場合には、
〔ＪＡＶＡコード〕
String d1 = “AZ”
int d1 10;
が作成される。上記のＣＯＢＯＬコードは、ＣＯＢＯＬの文法上問題はないが、上記のＪＡＶＡコードは、ＪＡＶＡでは変数名重複によるコンパイルエラーとなってしまう。

手修正必要例２に関しては、例えば、
〔ＣＯＢＯＬコード〕
EXIT.
MOVE A TO B.
を機械変換した場合には、
〔ＪＡＶＡコード〕
return;
b.set(a);
が作成される。上記のＣＯＢＯＬコードは、ＣＯＢＯＬの文法上問題はないが、上記のＪＡＶＡコードは、ＪＡＶＡでは明確なデッドコードによるコンパイルエラーとなってしまう。

手修正必要例３に関しては、例えば、
〔ＣＯＢＯＬコード〕
EVALUATE A
WHEN 0
〜〜
CONTINUE
WHEN 0
〜〜
END EVALUATE.
を機械変換した場合には、
〔ＪＡＶＡコード〕
switch(a){
case 0:
〜〜〜;
break;
case 0:
〜〜〜;
:
}
が作成される。上記のＣＯＢＯＬコードは、ＣＯＢＯＬの文法上問題はないが、上記のＪＡＶＡコードは、ＪＡＶＡでは分岐条件の重複によるコンパイルエラーとなってしまう。

手修正必要例１〜３に該当する場合には、同じＣＯＢＯＬコードであっても、ＪＡＶＡコードにおいて同じ動作をするように、異なる手修正結果を作成する。

［手修正実施用ワークスペース２１］
手修正実施用ワークスペース２１は、手修正管理ツール２０による手修正を実行するための作業領域である。

［手修正結果リポジトリｒ３］
手修正結果リポジトリｒ３は、変換元ＣＯＢＯＬソースｓ１に対して手修正管理ツール２０による手修正を実行することでＣＯＢＯＬコードの一部がＪＡＶＡコードに変換した変換途中ソースｓ５を格納する。

［マージツールｍ２］
マージツールｍ２は、機械変換結果リポジトリｒ２に格納された変換途中ソースｓ４と、手修正結果リポジトリｒ３に格納された変換途中ソースｓ５とをマージする。具体的には、マージツールｍ２は、変換元ＣＯＢＯＬソースｓ１を親とし、変換途中ソースｓ４を第１の子、変換途中ソースｓ５を第２の子として３方向マージをし、変換後Ｊａｖａソースｓ２を得る。
また、マージツールｍ１およびマージツールｍ２が、マージ処理として、変換途中ソースｓ３１〜ｓ３ｎ、および、変換途中ソースｓ５を一括してマージし、変換後Ｊａｖａソースｓ２を得ることもできる。

［変換結果リポジトリｒ４］
変換結果リポジトリｒ４は、マージツールｍ２によって、機械的な変換、および、手修正の変換がなされ、ＪＡＶＡコードのみを記録した変換後Ｊａｖａソースｓ２を格納する。

［テストツール３０］
テストツール３０は、変換後Ｊａｖａソースｓ２の確認テスト（実機確認）を行う。確認テストでは、例えば、変換元ＣＯＢＯＬソースｓ１および変換後Ｊａｖａソースｓ２に同じ入力値を入力し、両者間で同じ出力値が得られれば不良なし、異なる出力値が得られれば不良ありと判定する。テストツール３０は、不良があった場合、不良箇所情報を元に、メタ情報ＤＢ１１を参照して、不良を作り込んだ変換を特定する。

例えば、図１に示すように、テストツール３０が確認テストを実行した結果、不良ありと判定し、変換後Ｊａｖａソースｓ２のＪＡＶＡコード「Ｊａｖａ２」が不良原因であったと判明したとする。具体的には、コンバージョン開発者にとっては予め智得している、「Ｊａｖａ２」の行の動作を正常にする正しいコードと、マージツールｍ２が出力した変換後Ｊａｖａソースｓ２内に記述されているＪＡＶＡコード「Ｊａｖａ２」との相違点が判明したとする。この場合、テストツール３０は、メタ情報ＤＢ１１を参照して、ＣＯＢＯＬコード「ＣＯＢＯＬ２」からＪＡＶＡコード「Ｊａｖａ２」への変換に関するメタ情報を取得する。テストツール３０は、取得したメタ情報を解析することで、ＪＡＶＡコード「Ｊａｖａ２」への変換を実行したコンバータｃ２自体に問題がある、ＪＡＶＡコード「Ｊａｖａ２」への変換に係る変換設計に問題がある、などの不良原因の詳細を特定することができる。

≪処理≫
次に、本実施形態の変換装置１が実行する処理として、ＣＯＢＯＬからＪＡＶＡへの異言語変換処理について、図２を参照して説明する。説明の際、図１も適宜参照する。

まず、変換装置１は、変換元ＣＯＢＯＬソースｓ１に対して、フォーマット整形を行う（ステップＳ１）。具体的には、変換装置１は、変換元ＣＯＢＯＬソースｓ１のＣＯＢＯＬコードについて、分かち書きの１行化、大文字小文字の統一など、コンバータｃ１〜ｃｎでの変換を容易にする整形を行う。

次に、変換装置１は、変換元ＣＯＢＯＬソースｓ１に対して、定義部ＤＢ化をする（ステップＳ２）。具体的には、変換装置１は、変換元ＣＯＢＯＬソースｓ１のＣＯＢＯＬコードを解析し、データ項目の定義情報をＤＢ（図１には図示しない記憶部）へ格納する。

次に、変換装置１は、変換元ＣＯＢＯＬソースｓ１に対して、文法上整形を行う（ステップＳ３）。具体的には、変換装置１は、糖衣構文を正規記法に統一するなど、変換元ＣＯＢＯＬソースｓ１の構文を、コンバータｃ１〜ｃｎへの入力を前提とする構文へ整形する。

次に、変換装置１は、変換元ＣＯＢＯＬソースｓ１に対して、ＪＡＶＡ言語への共通的変換を行う（ステップＳ４）。具体的には、変換装置１は、ＪＡＶＡのｉｍｐｏｒｔ文やｍａｉｎメソッドの記述など、変換設計の特性に関係なく、コンバータｃ１〜ｃｎ間で共通で必要となる変換設計を適用する。ステップＳ４によれば、コンバータｃ１〜ｃｎの各々の変換設計には、コンバータｃ１〜ｃｎ間で共通の変換設計を含ませないようにすることができ、コンバータｃ１〜ｃｎ各々の変換設計を簡易にすることができる。

次に、変換装置１は、変換元ＣＯＢＯＬソースｓ１に対して、ＪＡＶＡ言語への順序依存変換を行う（ステップＳ５）。具体的には、変換装置１は、変換元ＣＯＢＯＬソースｓ１から変換後Ｊａｖａソースｓ２への変換に関する複数種類の変換設計について、１つの変換設計の実行結果が、他の変換設計の実行結果に依存する場合には、その依存に関係する変換設計を適用し、実行順序依存性を持つ変換を行う。ステップＳ５によれば、実行順序依存性を持つ変換を予め実行することで、コンバータｃ１〜ｃｎの各々による変換の間で、実行順序依存性を持たせないようにすることができ、コンバータｃ１〜ｃｎ各々の変換設計を簡易にすることができる。

次に、変換装置１は、変換元ＣＯＢＯＬソースｓ１に対して、ＪＡＶＡ言語へのパラレル変換を行う（ステップＳ６）。具体的には、変換装置１は、コンバータｃ１〜ｃｎの各々の変換設計を適用するとともに、コンバータｃ１〜ｃｎによる変換で対処しない、または、対処できない変換については、手修正管理ツール２０による手修正の変換設計を適用する。

図２に示すように、ステップＳ６は、例えば、コンバータｃ１〜ｃｎの各々に対応する個別命令語変換（１）〜（Ｎ）（ステップＳ６−１〜Ｓ６−Ｎ）、および、手修正に対応する手修正変換（ステップＳ６−Ｘ）に分けることができる。個別命令語変換（１）〜（Ｎ）は、ＣＯＢＯＬの命令語の種類ごとに、ＪＡＶＡへの機械的な変換を行う処理である（例：「ＭＯＶＥ」→「ｓｅｔ」）。コンバータｃ１〜ｃｎ間の変換が他の変換に影響を及ぼすことの無いように設計されているため、個別命令語変換（１）〜（Ｎ）は、機械的、かつ、並行に行うことができる。なお、個別命令語変換（１）〜（Ｎ）のように命令語単位で変換を行うのではなく、例えば、構文単位で個別に機械的な変換を行ってもよい。手修正変換（Ｓ６−Ｘ）は、手修正管理ツール２０による変換である。

ステップＳ６において、バージョン管理ツール１０は、コンバータｃ１〜ｃｎの各々に対応する個別命令語変換（１）〜（Ｎ）に関するメタ情報、および、手修正に対応する手修正変換に関するメタ情報を取得し、メタ情報ＤＢ１１に格納する。

次に、変換装置１は、ステップＳ６のパラレル変換の変換結果をマージする（ステップＳ７）。具体的には、変換装置１は、マージツールｍ１，ｍ２によって、コンバータｃ１〜ｃｎによって変換された変換途中ソースｓ３１〜ｓ３ｎ（または変換途中ソースｓ４）、および、手修正管理ツール２０によって変換された変換途中ソースｓ５に対してマージ処理をし、変換後Ｊａｖａソースｓ２を生成する。

次に、変換装置１は、テストツール３０によって、変換後Ｊａｖａソースｓ２の確認テストを行う（ステップＳ８）。テストツール３０は、確認テストで不良があった場合、不良箇所情報を元に、メタ情報ＤＢ１１に格納された該当のメタ情報を参照して、不良の不良原因を作り込んだ変換を特定する。

コンバージョン開発では、不良原因を作り込んだ変換を行うコンバータを修正した後、図２の異言語変換処理を再度行う。このとき、各コンバータ間の変換が他のコンバータの変換に影響を及ぼすことはないので、ステップＳ６のパラレル変換では、修正したコンバータに対応する個別命令語変換を行いさえすれば良く、他の個別命令語変換を行う必要はない。よって、ステップＳ７のマージでは、修正していないコンバータに対応する個別命令語変換済みの変換結果を流用することができ、不良対応後の再変換工数の削減に寄与し、図２の処理に要する負担を低減させたり、時間を短縮させたりすることができる。

図２の処理によれば、変換元ＣＯＢＯＬソースｓ１を変換後Ｊａｖａソースｓ２に変換する際、バージョン管理ツール１０がメタ情報を管理することによって、変換の履歴を辿ることができる。その結果、変換後Ｊａｖａソースｓ２に不良があったときの不良原因の特定は、メタ情報の参照で十分に達成することができ、従来のような有識者の検討を必要とせず、容易となる。
したがって、コンバージョン開発における不良対応コストを削減することができる。

≪追いつき作業での手修正結果流用≫
顧客が提供する変換元ソースを変換後ソースに変換するコンバージョン開発では、不良対応や法改正対応などの保守開発上の理由から、コンバージョン開発の進捗とは無関係に、顧客が変換元ソースを修正し仕様変更を行う場合がある。その場合、初回のコンバージョン開発の完了後に、再度のコンバージョン開発を実施し、変換後ソースに仕様変更を取り込む必要がある。初回のコンバージョン開発の完了とは、変換後ソースの確認テストにおける不良なしでの完了を意味し、「凍結」と呼ぶ場合がある。また、再度のコンバージョン開発における凍結後の仕様変更対応作業を「追いつき作業」と呼ぶ場合がある。

追いつき作業は、必須であるとはいえ、コンバージョン開発の作業量を増大させ、システム移行の遅延化を招くので、作業工数を低減化し早期に終了させたいという要望がある。しかし、従来では、変換元ソースに対して、例えば、先述した手修正必要例１〜３に該当し、初回のコンバージョン開発で該当行の手修正をした場合には、追いつき作業でも同じ行を手修正しなければならず、非効率であった。
また、従来では、変換後ソースのうち手修正による変換箇所については、凍結前に確認テストを行っていたとしても、追いつき作業ではほぼ同様の確認テストを再度行う必要があり、追いつき作業のテスト工数を低減させることができなかった。

つまり、一般的には、顧客側の保守開発では、仕様変更のコード修正が機能単位で済む場合が多いため、コード修正による新システムへの影響は大抵は局所的で済む。一方、コンバージョン開発では、（機械的であっても手修正であっても）変換が変換観点単位（構文単位）であるため、変換による新システムへの影響は全体的に及ぶ。このため、手修正による変換に対する確認テストの確認項目が新システム全体に分散する傾向がある。その結果、手修正が少量であったとしても、手修正による変換に対する確認テストの確認項目の数が少量となるわけではなく、凍結前のテスト工数とほぼ同程度のテスト工数が要求される。このような事情は、手修正による変換箇所が、顧客側の修正の影響が及ぶ箇所であるか否かにかかわらず存在する。

本実施形態の変換装置１は、マージツールｍ１，ｍ２が行った３方向マージを用いて、追いつき作業において、顧客側の仕様変更の修正とは無関係となる、凍結前の手修正結果を機械的に流用する。本実施形態では、手修正結果を対象にした３方向マージは、マージツールｍ２が行い、以下の説明でもマージツールｍ２による３方向マージとして説明するが、マージツールｍ１でも同様に行うことができる。

図３に示すように、変換元ソースｓｐと、修正版変換元ソースｓｃ１と、手修正ソースｓｃ２とを用意する。
変換元ソースｓｐは、ＣＯＢＯＬで記述されたＣＯＢＯＬコード（１行目「ＣＯＢＯＬ１」、２行目「ＣＯＢＯＬ２」、３行目「ＣＯＢＯＬ３」）を記録したソースコードである。変換元ソースｓｐは、コンバージョン開発側が顧客から元々提供されたコンバージョン開発対象である。変換元ソースｓｐは、図１の変換元ＣＯＢＯＬソースｓ１に相当する。

修正版変換元ソースｓｃ１は、ＣＯＢＯＬで記述されたＣＯＢＯＬコード（１行目「ＣＯＢＯＬ１」、２行目「ＣＯＢＯＬ２」、３行目「ＣＯＢＯＬＡ」）を記録したソースコードである。修正版変換元ソースｓｃ１は、変換元ソースｓｐに対し、顧客側の仕様変更の修正分（「ＣＯＢＯＬ３」（特定行）→「ＣＯＢＯＬＡ」）が反映されたものに等しい。修正版変換元ソースｓｃ１は、追いつき作業の際、つまり凍結後に顧客から提供される。

手修正ソースｓｃ２は、手修正管理ツール２０によって変換元ソースｓｐのＣＯＢＯＬコードの一部をＪＡＶＡコード（「ＣＯＢＯＬ２」→「Ｊａｖａ２」）に変換したソースコードである。手修正ソースｓｃ２は、初回のコンバージョン開発において、つまり凍結前に作成されたものである。

バージョン管理ツール１０は、変換元ソースｓｐと、修正版変換元ソースｓｃ１と、手修正ソースｓｃ２に関するメタ情報を管理し、変換元ソースｓｐと、修正版変換元ソースｓｃ１と、手修正ソースｓｃ２の内容を管理することができる。

マージツールｍ２は、変換元ソースｓｐをマージの親、修正版変換元ソースｓｃ１をマージの子（第１の子）、手修正ソースｓｃ２をマージの子（第２の子）とした３方向マージを行う。結果的に、図３に示す手修正流用ソースｓｄを得る。バージョン管理ツール１０は、手修正流用ソースｓｄに関するメタ情報を取得して管理する。

修正版変換元ソースｓｃ１と手修正流用ソースｓｄとを比較すると、２行目「ＣＯＢＯＬ２」のコードは、３行目「ＣＯＢＯＬ３」に対する顧客の修正の影響を受けることなく、「Ｊａｖａ２」に変換されており、修正版変換元ソースｓｃ１に対して、手修正ソースｓｃ２による手修正結果を流用できているといえる。従来では、追いつき作業にて、修正版変換元ソースｓｃ１に対して、手修正で「ＣＯＢＯＬ２」→「Ｊａｖａ２」という変換をしていたが、本発明では、その変換の手間を省くことができる。結果的に、追いつき作業での手修正の対象は、凍結前に手修正がなされたＣＯＢＯＬコードのうち、顧客側の仕様変更の修正がなされたＣＯＢＯＬコードに絞られる。

また、手修正ソースｓｃ２による手修正結果を含む変換後ソースに対する凍結前の確認テストはすでに済んでおり、その手修正結果を流用している。このため、追いつき作業において、手修正流用ソースｓｄを用いてマージ処理をした変換後ソース（顧客修正反映済み）の確認テストを行う際、流用した手修正による変換に対する確認テストの確認項目は省略することができる。その結果、追いつき作業のテスト工数を低減させることができる。

なお、３方向マージで得られた手修正流用ソースｓｄの３行目「ＣＯＢＯＬＡ」のＪＡＶＡコードへの変換については、「ＣＯＢＯＬＡ」が機械変換可能なＣＯＢＯＬコードである場合は、コンバータｃ１〜ｃｎのいずれかによって変換され、結果物が機械変換結果リポジトリｒ２に格納される。一方、「ＣＯＢＯＬＡ」が、手修正が必要なＣＯＢＯＬコードである場合は、手修正流用ソースｓｄを対象にして手修正管理ツール２０によって手修正を行い、結果物が手修正結果リポジトリｒ３に格納される。その後は、すでに説明した手順（図２のステップＳ７など）に従う。

≪片方優先３方向マージ≫
追いつき作業において、変換元ソースに対する顧客側の修正箇所（特定行）と、変換元ソースに対する凍結前の手修正が行われた箇所（手修正行）とが重複している場合がある。この場合、手修正結果流用の３方向マージを行うと、コンフリクトが発生してしまい、マージすることができない。

そこで、顧客側の修正行と手修正行とが重複している場合、マージツールｍ２は、顧客側の修正行を優先する片方優先３方向マージを行う。
図４に示すように、変換元ソースｓｐと、修正版変換元ソースｓｃ１ａと、手修正ソースｓｃ２とを用意した場合について説明する。図４の変換元ソースｓｐおよび手修正ソースｓｃ２は、図３に示す変換元ソースｓｐおよび手修正ソースｓｃ２と同じである。

修正版変換元ソースｓｃ１ａは、ＣＯＢＯＬで記述されたＣＯＢＯＬコード（１行目「ＣＯＢＯＬ１」、２行目「ＣＯＢＯＬＡ」、３行目「ＣＯＢＯＬ３」）を記録したソースコードである。修正版変換元ソースｓｃ１ａは、変換元ソースｓｐに対し、顧客側の仕様変更の修正分（「ＣＯＢＯＬ２」→「ＣＯＢＯＬＡ」）が反映されたものに等しい。修正版変換元ソースｓｃ１ａは、追いつき作業の際、つまり凍結後に顧客から提供される。
バージョン管理ツール１０は、修正版変換元ソースｓｃ１ａに関するメタ情報を管理し、修正版変換元ソースｓｃ１ａの内容を管理することができる。

変換元ソースｓｐと、修正版変換元ソースｓｃ１ａと、手修正ソースｓｃ２に対して、図３の３方向マージを仮に行った場合、変換元ソースｓｐの２行目「ＣＯＢＯＬ２」に対する顧客修正（「ＣＯＢＯＬＡ」（特定行））と、手修正（「Ｊａｖａ２」（手修正行））とがコンフリクト（重複）しマージ不可となる。

そこで、図４に示すように、マージツールｍ２は、変換元ソースｓｐをマージの親、修正版変換元ソースｓｃ１ａをマージの子（第１の子）、手修正ソースｓｃ２をマージの子（第２の子）とした片方優先３方向マージを行う。結果的に、手修正結果（「Ｊａｖａ２」）を含まず、顧客修正（「ＣＯＢＯＬＡ」）を含む顧客修正優先ソースｓｄａ（１行目「ＣＯＢＯＬ１」、２行目「ＣＯＢＯＬＡ」、３行目「ＣＯＢＯＬ３」）を得る。バージョン管理ツール１０は、顧客修正優先ソースｓｄａに関するメタ情報を取得して管理する。

本実施形態の片方優先３方向マージによれば、手修正と顧客修正とがコンフリクトするとしても、３方向マージの結果物に顧客修正を確実に反映させることができ。顧客の本来的な要求を確実に満たすことができる。

なお、片方優先３方向マージで得られた顧客修正優先ソースｓｄａの２行目「ＣＯＢＯＬＡ」のＪＡＶＡコードへの変換については、「ＣＯＢＯＬＡ」が機械変換可能なＣＯＢＯＬコードである場合は、コンバータｃ１〜ｃｎのいずれかによって変換され、結果物が機械変換結果リポジトリｒ２に格納される。一方、「ＣＯＢＯＬＡ」が、手修正が必要なＣＯＢＯＬコードである場合は、顧客修正優先ソースｓｄａを対象にして手修正管理ツール２０によって手修正を行い、結果物が手修正結果リポジトリｒ３に格納される。その後は、すでに説明した手順（図２のステップＳ７など）に従う。

≪追いつき作業におけるテスト作業工数削減≫
追いつき作業は、本質的には、変換元ソースに対して顧客が行った（概ね小規模の）修正分に対して再度のコンバージョン開発を行えば十分である。追いつき作業で行う必要があるテストの確認項目の大部分は、追いつき作業前の初回コンバージョン開発ですでに行ったテストの確認項目と重複する。よって、初回コンバージョン開発でのテストの確認結果を流用して、追いつき作業でのテスト作業工数を削減する、というアイデアが成立し、以下、その方法について具体的に説明する。

図５に示すように、追いつき作業前の異言語変換では、つまり、初回コンバージョン開発では、本実施形態の変換装置１が、変換元ソースｓｐ（例えば、ＣＯＢＯＬ）を変換後ソースｓｑ（例えば、ＪＡＶＡ）に変換する際に、変換設計設定（ステップＳ１１）と、コンバータ生成（ステップＳ１２）と、機械変換＋手修正（ステップＳ１３）と、３方向マージ（ステップＳ１４）とが実行される。

変換設計設定（ステップＳ１１）は、コンバージョン開発側で変換元ソースｓｐを解析し、変換元ソースｓｐに対して、変換後ソースｓｑの作成に必要となる変換設計を１または複数種類設定するステップである。変換設計とは、変換対象のコード文字列をどのように書き換えるかを規定する枠組みである。必要となる変換設計の種類については、例えば、コンバージョン開発側で適宜決定してもよいが、決定の方法はこれに限らない。

図５の例では、変換元ソースｓｐに対して、変換対象ごとに変換設計Ａ１〜Ｅ１の５種類が設定されたとする。変換設計Ａ１〜Ｃ１は、コンバータ（図１のコンバータｃ１〜ｃｎに相当）による機械変換に係る変換設計である。変換設計Ｄ１、Ｅ１は、手修正（図１の手修正管理ツール２０が行う手修正に相当）による変換に係る変換設計である。

コンバータ生成（ステップＳ１２）は、設定された変換設計のうち、機械変換に係る変換設計に関連付けられるコンバータを生成するステップである。図５では、機械変換に係る変換設計Ａ１〜Ｃ１の各々に対し、変換設計Ａ１向けコンバータＡ２と、変換設計Ｂ１向けコンバータＢ２と、変換設計Ｃ１向けコンバータＣ２とが生成される。変換設計Ａ１向けコンバータＡ２、変換設計Ｂ１向けコンバータＢ２、変換設計Ｃ１向けコンバータＣ２は、図１のコンバータｃ１〜ｃｎと同じ機能を有する。

機械変換＋手修正（ステップＳ１３）は、変換設計に従う機械変換および手修正を実行するステップである。図５では、コンバータＡ２〜Ｃ２の各々が、変換元ソースｓｐ中の変換対象の各々に対して、変換設計Ａ１〜Ｃ１に従う機械変換を実行し、変換結果Ａ３〜Ｃ３を出力する。また、手修正管理ツール２０（図１）が、変換元ソースｓｐ中の変換対象の各々に対して、変換設計Ｄ１，Ｅ１に従う手修正を実行し、変換結果Ｄ３，Ｅ３を出力する。変換結果Ａ３〜Ｅ３は、図１に示す変換途中ソースｓ３１〜ｓ３ｎ，ｓ４，ｓ５に相当する。

なお、図１に示すように、本実施形態の変換装置１は、コンバータｃ１〜ｃｎによる変換結果を、コンバータごとにリポジトリ内で管理し（図１のコンバータ別変換結果リポジトリｒ１１〜ｒ１ｎ）、手修正による変換結果を、１つのリポジトリ内にまとめて管理した（図１の手修正結果リポジトリｒ３）。しかし、リポジトリによる管理単位は任意に設定することができる。そこで、図５、図６を参照する説明については、本実施形態の変換装置１は、変換設計ごとに、変換結果をリポジトリ内で管理することにする。つまり、図５に示す変換結果Ａ３〜Ｅ３は、変換設計Ａ１〜Ｅ１の各々に対して用意したリポジトリ（図５中図示せず）内に管理される。なお、リポジトリとして、変換設計ごとに用意したリポジトリではなく、複数の変換設計をまとめたものに対するリポジトリを用意してもよい。

コンバージョン開発側は、変換結果Ａ３〜Ｅ３に対して机上確認を行う。机上確認は、周知の手法であり説明は省略する。本実施形態では、変換結果Ａ３〜Ｅ３に対する机上確認の結果は良好であったとする。

３方向マージ（ステップＳ１４）は、機械変換＋手修正（ステップＳ１３）で得られた変換結果に対して３方向マージを行うステップである。３方向マージ（ステップＳ１４）は、図１に示すマージツールｍ１、ｍ２が実行する。図５では、変換結果Ａ３〜Ｅ３に対して３方向マージを実行することで変換後ソースｓｑが得られる。

コンバージョン開発側は、変換後ソースｓｑに対して実機確認を行う。実機確認は、図１に示すテストツール３０の確認テストに相当する。以上で、初回コンバージョン開発が完了する。

初回コンバージョン開発の完了後、顧客が変換元ソースを修正したため、追いつき作業を実行する。図６に示すように、追いつき作業では、本実施形態の変換装置１が、顧客の修正分ｓｐａ１を含む変換元ソースｓｐａ（修正版変換元ソースに相当）を、修正分ｓｐａ１に対応する修正分ｓｑａ１を含む変換後ソースｓｑａに変換する。この変換の際、図６に示す変換設計設定（ステップＳ２１）と、コンバータ生成（ステップＳ２２）と、機械変換＋手修正（ステップＳ２３）と、３方向マージ（ステップＳ２４）とが実行される。

変換設計設定（ステップＳ２１）は、図５の変換設計設定（ステップＳ１１）と同じステップである。図６に示すように、変換設計設定（ステップＳ２１）では、変換元ソースｓｐａに修正分ｓｐａ１が含まれたことに応じて、変換設計Ｂ１，Ｄ１（図５）をそれぞれ、変換設計Ｂ１１，Ｄ１１に代え、変換元ソースｓｐａに対して、変換対象ごとに変換設計Ａ１，Ｂ１１，Ｃ１，Ｄ１１，Ｅ１の５種類が設定されたとする。変換設計Ｂ１１は、機械変換に係る変換設計である。変換設計Ｄ１１は、手修正による変換に係る変換設計である。

コンバータ生成（ステップＳ２２）は、図５のコンバータ生成（ステップＳ１２）と同じステップである。図６に示すように、すでに生成された変換設計Ａ１向けコンバータＡ２（図５）と、変換設計Ｃ１向けコンバータＣ２（図５）に加え、新たに設定された変換設計Ｂ１１に対し、変換設計Ｂ１１向けコンバータＢ２１が新たに生成される。変換設計Ｂ１１向けコンバータＢ２１は、図１のコンバータｃ１〜ｃｎと同じ機能を有する。

機械変換＋手修正（ステップＳ２３）は、図５の機械変換＋手修正（ステップＳ１３）と同じステップである。図６では、機械変換ですでに生成された変換結果Ａ３，Ｃ３（図５）に加え、変換設計Ｂ１１向けコンバータＢ２１が、変換元ソースｓｐ中の変換対象に対して、変換設計Ｂ１１に従う機械変換を実行し、変換結果Ｂ３１を新たに出力する。また、図６では、手修正ですでに生成された変換結果Ｅ３（図５）に加え、手修正管理ツール２０（図１）が、変換元ソースｓｐ中の変換対象に対して、変換設計Ｄ１１に従う手修正を実行し、変換結果Ｄ３１を新たに出力する。変換結果Ｂ３１，Ｄ３１は、図１に示す変換途中ソースｓ３１〜ｓ３ｎ，ｓ４，ｓ５に相当する。

コンバージョン開発側は、新たな変換結果Ｂ３１，Ｄ３１に対して机上確認を行う。すでに生成した変換結果Ａ３，Ｃ３，Ｅ３については、机上確認が済んでいるため（図５）、追いつき作業では省略する。よって、変換設計ごとに変換結果を管理することで、追いつき作業における机上確認のテスト工数を削減することができる。また、本実施形態では、変換結果Ｂ３１，Ｄ３１に対する机上確認の結果は良好であったとする。

３方向マージ（ステップＳ２４）は、図５の３方向マージ（ステップＳ１４）と同じステップである。図６では、変換結果Ａ３，Ｂ３１，Ｃ３，Ｄ３１，Ｅ３に対して３方向マージを実行することで、修正分ｓｐａ１に対応する修正分ｓｑａ１を含む変換後ソースｓｑａが得られる。

コンバージョン開発側は、変換後ソースｓｑａに対して実機確認を行う。この実機確認においては、すべての確認項目のうち、修正分ｓｑａ１が影響しない確認項目（修正分ｓｐａ１に応じて変更した変換設計Ｂ１１、Ｄ１１以外の変換設計Ａ１，Ｃ１，Ｅ１に関係する確認項目）は、追いつき作業前にすでに確認済みであるため（図５）、追いつき作業では省略しても差し支えない。よって、図５、図６の例に示すように、変換設計ごとに変換結果を管理することで、実機確認のすべての確認項目のうち、修正分ｓｑａ１が影響する確認項目についてのみ確認すればよい。その結果、追いつき作業における実機確認のテスト工数を削減することができる。

≪変形例≫
以上、本発明の実施形態について説明したが、本発明は前記実施形態に限定されず、本発明の要旨を逸脱しない範囲で適宜変更可能である。例えば、コンバージョン開発における変換元ソースのプログラム言語は、ＣＯＢＯＬに限らず、他のプログラム言語でもよい。また、コンバージョン開発における変換後ソースのプログラム言語は、ＪＡＶＡに限らず、他のプログラム言語でもよい。

また、コンバージョン開発における言語変換は、本実施形態で採り上げたＣＯＢＯＬからＪＡＶＡへの変換といった異なる種類のプログラム言語への変換に限らず、ホスト系ＣＯＢＯＬからオープン系ＣＯＢＯＬへの変換といった同じ種類のプログラム言語への変換でもよい。

また、本発明は、プログラム言語の変換に関するコンバージョン開発に限らず、現行アプリケーションが処理するデータを新アプリケーションに移行するデータマイグレーション開発など、システム移行に伴う種々のマイグレーション開発に適用することができる。

また、本発明は、従来のように、変換元ソースに対して複数種類用意した変換ツールを順次実行する方法に対しても適用することができる。また、従来では、プログラム言語を機械的に変換するツールとして、コードをパース（構文木解釈）して置き換えるツールがある。このツールは、ほぼすべての言語の変換に対応可能となる１つの（または少数の）ツールとして構成され、概して大規模かつ複雑である。本発明は、このようなツールに対しても適用することができ、不良原因の特定や、追いつき作業でのテスト工数削減などに資する。

本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
本実施形態で説明したソフトウェアをハードウェアとして実現することもでき、ハードウェアをソフトウェアとして実現することもできる。
その他、ハードウェア、ソフトウェア、フローチャートなどについて、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。

１ 変換装置
ｃ１〜ｃｎ コンバータ
１０ バージョン管理ツール（メタ情報管理部）
１１ メタ情報ＤＢ
２０ 手修正管理ツール（手修正管理部）
２１ 手修正実施用ワークスペース
３０ テストツール（テスト部）
ｍ１，ｍ２ マージツール（マージ部）
ｒ１１〜ｒ１ｎ コンバータ別変換結果リポジトリ
ｒ２ 機械変換結果リポジトリ
ｒ３ 手修正結果リポジトリ
ｒ４ 変換結果リポジトリ
ｓ１ 変換元ＣＯＢＯＬソース（変換元ソース）
ｓ２ 変換後Ｊａｖａソース（変換後ソース）
ｓ３１〜ｓ３ｎ，ｓ４，ｓ５ 変換途中ソース
ｓｃ１，ｓｃ１ａ 修正版変換元ソース
ｓｐ，ｓｐａ 変換元ソース
ｓｑ，ｓｑａ 変換後ソース
Ａ１〜Ｅ１，Ｂ１１，Ｄ１１ 変換設計
Ａ２ 変換設計Ａ１向けコンバータ
Ｂ２ 変換設計Ｂ１向けコンバータ
Ｂ２１ 変換設計Ｂ１１向けコンバータ
Ｃ２ 変換設計Ｃ１向けコンバータ
Ａ３〜Ｅ３，Ｂ３１，Ｄ３１ 変換結果

Claims (8)

1. 変換元ソースを変換後ソースに変換する変換装置であって、
   前記変換元ソースの一部を前記変換後ソースの一部に変換して生成される変換途中ソースの集合について、前記変換途中ソースの各々への変換に関するメタ情報を管理するメタ情報管理部と、
   前記変換後ソースの確認テストで不良があった場合、前記メタ情報を参照して、前記不良の不良原因を作り込んだ変換を特定するテスト部と、を備える、
   ことを特徴とする変換装置。
2. 前記変換元ソース内の文字列ごとに用意され、前記変換元ソースの一部から前記変換後ソースの一部への変換を、機械的、かつ、並行に行う複数種類のコンバータと、
   前記変換元ソースの一部から前記変換後ソースの一部への変換を行うための手修正を管理する手修正管理部と、
   前記変換途中ソースの集合に対してマージ処理をするマージ部と、をさらに備える、
   ことを特徴とする請求項１に記載の変換装置。
3. 前記変換元ソースの特定行が修正されていた修正版変換元ソースがあった場合、
   前記マージ部は、
   前記変換元ソースを親とし、前記修正版変換元ソースを第１の子とし、前記変換途中ソースのうち前記手修正による変換が行われたものを第２の子とする３方向マージをする、
   ことを特徴とする請求項２に記載の変換装置。
4. 前記マージ部は、
   前記修正版変換元ソースにおいて修正されていた前記特定行と、前記手修正による変換が行われた前記変換途中ソースにおいて前記手修正がなされた手修正行とが重複する場合、前記３方向マージにおいて、前記特定行を優先する、
   ことを特徴とする請求項３に記載の変換装置。
5. 前記変換元ソースに対して設定した変換設計ごとに、前記変換途中ソースを生成した場合、前記変換設計のうち、前記修正版変換元ソースの修正分に応じて変更した変換設計について、新たな変換途中ソースを生成する、
   ことを特徴とする請求項３または請求項４に記載の変換装置。
6. 前記変換元ソースから前記変換後ソースへの変換は、プログラム言語変換である、
   ことを特徴とする請求項１から請求項５のいずれか１項に記載の変換装置。
7. 前記プログラム言語変換は、
   異なる種類のプログラム言語への変換、または、同じ種類のプログラム言語への変換である、
   ことを特徴とする請求項６に記載の変換装置。
8. 変換元ソースを変換後ソースに変換する変換装置における変換方法であって、
   前記変換元ソースの一部を前記変換後ソースの一部に変換して生成される変換途中ソースの集合について、前記変換途中ソースの各々への変換に関するメタ情報を登録するステップと、
   前記変換後ソースの確認テストを行い、不良があった場合、前記メタ情報を参照して前記不良の不良原因を作り込んだ変換を特定するステップと、を備える、
   ことを特徴とする変換方法。

Images