JP5208635B2 - プログラミングを支援するための情報処理装置、情報処理システム、プログラミング支援方法およびプログラム - Google Patents

Description

本発明は、プログラミング支援技術に関し、より詳細には、複数の開発者による連携したプログラミングを支援するための情報処理装置、情報処理システム、プログラミング支援方法およびプログラムに関する。

現在、特定の業務を実行するためのアプリケーションを提供するソフトウェアは、膨大な量のソースコードから構成されている。また、ソースコードについても、アプリケーション本体を構成するプログラムの他、ダイナミックリンク・ライブラリ、プラグイン・プログラムなどランタイムに呼出された後アプリケーションにより制御されるプログラムなど、その属性も多岐にわたっている。このようなアプリケーション開発において、機能に対応するソースコードの特定コードを識別する作業は、機能の理解や、ソースコードのバグ修正に先立つ作業として、重要な作業となっている。

従来型のソフトウェア開発では、アプリケーションについての仕様書と機能との対応付けが重視されているので、要求追加などの仕様変更の際には、仕様書とソースコードとの間の同期を保つために、ソースコード間の対応付けを容易に認識させるツール（例えば、インターナショナル・ビジネスマシーンズ・コーポレーション社製のRational（登録商標） Requisite Pro（商標））などを使用して、ユニット間の対応付けを管理する。

しかしながら、アプリケーションに要求される機能がますます多種多様になり、また製品サイクルも短期間化する傾向にあるので、アプリケーションの開発効率をより高める目的で、近年、ＸＰ(エクストリーム・プログラミング：eXtreme Programming)などに代表されるように、多数の開発者が連携してプログラム作成を行う、アジャイルなソフトウェア開発が普及してきている。ＸＰに代表されるアジャイルなソフトウェア開発においては、コーディングと、テストとが重要となり、また仕様変更に対応したソースコードは、元の仕様書に記述されていない新しいソースコードが存在する場合も発生する。このため、最新の機能に対応するソースコードを特定しようとすると、仕様書を参照するのみでは追加された新規な機能に関連するソースコードを特定することに多大な時間を要し、またＸＰ環境におけるプログラム開発の管理は、ますます困難になる。

ソースコード間のコードの相違を識別する問題に対応するために、従来から、ＵＮＩＸ（登録商標）などでシェル・コマンドとして用意されているｄｉｆｆコマンド（http://www.gnu.org/software/diffutils/diffutils.html：非特許文献１）が用いられている。ｄｉｆｆコマンドは、２つのファイルを指定し、２つのファイル間で追加・削除・変更された行を判別する処理を実行するシェル・コマンドであり、バージョンの異なる２つのソースコードについて追加された、ソースコードのコード・セットを特定することが可能である。多くのバージョン管理システムにおいてもｄｉｆｆコマンドは、内部的に使用されており、ｄｉｆｆコマンドは、プログラムの２つのバージョン間での編集箇所を抽出するなど編集内容を確認することに関し、その有効性が認識されている。

また、同様な機能を有するＯＳレベルでのコマンドとしては例えば、ＭＳ−ＤＯＳ（登録商標）におけるｃｏｍｐコマンドを挙げることができ、ｃｏｍｐコマンドもＭＤ−ＤＯＳシェルから実行させることで、テキストなどで記述されたソースコードの相違を検出することができる。その他、アプリケーション・レベルでファイル比較を実行するプログラムも知られている。

上述したように、２つのソースコード間で相違するコードを検出するプログラムは知られている。しかしながら、アジャイルなプログラム開発環境では、２つのソースコード・バージョンの間で、複数の特定機能ユニットにわたって追加変更され、これらが同時にテストされる場合があり、上述したｄｉｆｆコマンドなどでは、特定機能ユニットに関連付けられるソースコードのうちの追加・修正などの変更を受けたコード・セットを特定することは困難であった。図１３に従来のｄｉｆｆコマンドを使用するソースコードの概略的な変更検査手順１３００を示す。

ソースコードは、図１３に示すように、機能モジュールを提供する各ユニットの変更に対応して、異なるバージョン名を付してチェンジセット１３１０〜チェンジセット１３４０として進化してゆく。図１３に示した従来例では、１つのチェンジセット、例えばチェンジセット１３２０は、それぞれ「Ａ．ｃｌａｓｓ＿ｖ１」、「Ｂ．ｃｌａｓｓ＿ｖ０」、「Ｃ．ｃｌａｓｓ＿ｖ０」といったバージョン名が付されたユニット１３２２、１３２４、１３２６から構成されている。

チェンジセット１３２０では、ユニット１３２２が、それ以前のチェンジセット１３１０の対応するバージョン名「Ａ．ｃｌａｓｓ＿ｖ０」のユニット１３１２から機能αが修正されている。さらにチェンジセット１３３０では、ユニット１３２４およびユニット１３２６に、それぞれ機能βの変更が行われている。そして、その結果、各修正を受けたチェンジセット１３３０は、それぞれバージョン名「Ｂ．ｃｌａｓｓ＿ｖ１」、「Ｃ．ｃｌａｓｓ＿ｖ１」が付されたユニット１３３４、１３３６を含むものとされている。

さらにチェンジセット１３４０では、プログラマによるユニットの変更を受け、機能γおよび機能ωが修正される変更を受けている。この結果、チェンジセット１３４０は、バージョン名「Ａ．ｃｌａｓｓ＿ｖ２」、「Ｂ．ｃｌａｓｓ＿ｖ１」、「Ｃ．ｃｌａｓｓ＿ｖ２」とされたユニット１３４２、１３４４、１３４６を含んだ構成とされている。

図１３に示した変更検査手順１３００を使用して、従来のｄｉｆｆプログラムを適用するソースコード変更検査手順について検討する。図１３に示した各特定機能ユニットの検査についてみれば、チェンジセット１３１０からチェンジセット１３２０の間は、単一の特定機能に関連するユニット１３１２およびユニット１３２２だけが変更されている。このため、ｄｉｆｆコマンドを使用しても同一の機能ユニットに関連するコードが抽出でき、ｄｉｆｆプログラムでも複数の特定機能ユニットにまたがったコード・セットが並列的に抽出されないので、混乱は少ないということができる。

また、チェンジセット１３２０からチェンジセット１３３０の間では、機能βに関連する複数のユニットが変更されている。この場合、機能βに関連するユニットが特定のプログラマまたはプログラマ・グループにより作成されている場合不都合は少ないということができる。一方で、機能βに関連するユニット１３３４およびユニット１３３６が異なるプログラマまたはプログラマ・グループにより作成されている場合、機能βに関連するコードであっても、別々に検査を実行することが好ましい場合がある。

上述した従来例は、プログラミングがある程度ストリームライン化されており、テスト間で複数の特定機能の追加が想定されない場合や、特定機能に関連するユニットが複数にまたがらない場合には、充分有効である。

しかしながら、複数のプログラマが分散してプログラミングを行うプログラミング環境では、別の問題が発生する。例えば図１３で、チェンジセット１３２０からチェンジセット１３３０への変更で、単独の機能が複数のユニットにまたがっているような場合、ｄｉｆｆコマンドで一括して相違するコードを出力しても、プログラマが異なる場合もある。このような場合、プログラマは、自己が関与していないコードと自己が関与するコードとの間の関連性を解釈し、理解するための時間を浪費する。

さらに、チェンジセット１３３０からチェンジセット１３４０の間について行われた変更について検討する。チェンジセット１３３０からチェンジセット１３４０の間では、機能γおよび機能ωが同時に追加されている。さらに機能γおよび機能ωの変更を行ったプログラマは、同一ではない場合が発生する。このような場合、単にｄｉｆｆプログラムを使用してソースコードの相違を抽出するだけでは、各特定機能ユニットごとに変更内容を特定できないという問題が発生する。また、ｄｉｆｆコマンドなどでソースコードの変更を検査した場合、当該ソースコードの変更に全く関連しない特定ユニットのコード・セットまで抽出されてしまい、プログラマによるデバッグ処理や、コード・セットの理解に対し、混乱を生じさせることにもなる。

２つのプログラムバージョン間で機能の相違を無視して単に差分を抽出するソースコード解析システムは、例えば特開２００４−３２６３３７号公報（特許文献１）に記載されている。特許文献１では、２つのバージョン間での差分を検出することは可能とするが、差分に関連づけられる機能特有のコードを識別せずに、単純に静的な差分を抽出する。そして、抽出された差分情報に基づいて、ソースコードの解析結果の絞込みを行うものである。しかしながら、絞り込みは、前回バージョンと現行バージョンとの間の差分しか識別することができず、特定機能に依存したプログラムの差分を抽出することを可能とするものではない。

さらに特許文献１に記載された方法は、各機能を提供するためのユニットをオブジェクトとして構成する、所謂オブジェクト指向プログラミングにより構成されるアプリケーションについて、単に差分しか抽出しないので、各オブジェクトに固有のソースコードの差分を識別できず、オブジェクト指向プログラミング技術を使用して作成されるソースコードの変更検証および実行検査に適したものということができなかった。

また、特開２００７−４２５５号公報（特許文献２）では、２つソースコードのバージョンを比較して比較結果情報を生成し、現行バージョンを実行形式に変換してテストケースにより試験を行い、試験を行った時刻と、現行ソースコードが格納された時刻とを使用して試験結果情報に対応する比較結果情報を取得し、出力するプログラムを開示する。特許文献２に記載された処理のフローチャートを図１４に示す。図１４に示す処理は、リポジトリに登録されているうち、テストをＰＡＳＳしたファイルを特定し、テストをＰＡＳＳしたファイルとそれよりも新しいファイルとの差分コードを出力する処理を実行する。そして、テストをＰＡＳＳしたファイルよりも新しいファイルで非正常な結果が得られた場合に、当該非正常な実行結果を、差分コードに対応付けて出力させている。

特許文献２に記載されたデバッグ支援方法も、旧ファイルと新ファイルとの差を識別し、当該差分コードに対応付けて実行結果を表示させることは可能である。しかしながら、新旧ファイルの差分コードに関連付けて実行結果を表示させるだけでは、当該差分コードがどの機能に対応しているのかについては、新ファイルのスクリプトを参照して当該コードのコーディング位置などを判断しなければ判断できず、プログラマは、新ファイルをトレースし、そのコーディング上の機能的な意味を判断しなければならず、ソースコードの全体的な検討を必要とする点で非効率であり、アジャイルなプログラミング環境にそのまま適用することは困難である。

また、特許文献２では、予めテストスクリプトの一覧に登録されたコード部分しかテスト対象とすることができず、仕様書に記載されていないものの、仕様変更に対応して新たに追加されたコード領域がある場合、全くテストされず、ＸＰなどのアジャイルなプログラミング技術には適していないという問題点がある。

加えて近年のプログラミング技術は、オブジェクト指向プログラミングが普及しており、各機能ごとに機能ブロックとしてコーディングされる場合が多い。このような場合、予め予定したテスト項目を設定し、テストを実行するのでは、仕様変更に迅速な対応を行うことができず、複数の変更が加えられたり、以前のソースコードには記述されていなかったコード・セットが出現する可能性のあるＸＰなどのプログラム開発環境に対応することができないという問題点は、依然として残されたままであった。
http://www.gnu.org/software/diffutils/diffutils.html 特開２００４−３２６３３７号公報 特開２００７−４２５５号公報

以上のように、ソースコードの変更を検出し、ソースコードの変更を検査する手法は、これまで種々知られているものの、特定機能ユニットに関連するソースコードの変更を検出し、特定機能ユニットに関連して相違するコードの差を抽出することにより、プログラミング支援を可能とするものではない。

すなわち、これまで、テストケースによるテストを繰り返すことでソースコードが進化的に完成されて行くアジャイルなソフトウェア開発環境に対し、適切、かつ効率的に適用することができるプログラミング支援技術が必要とされていた。

さらに、これまで、ソースコードに対して新規な機能が追加された場合にでも、ソースコードの解析から新規な機能を効率的に抽出して技術的な解釈を容易にし、さらにバグの存在元をユニットごとに識別することで、ソースコード上での問題コードを特定する効率を向上するプログラミング支援技術が必要とされていた。

加えて、ソースコードの進化に対応したテストケースを実行させることにより単に最新の機能に対応するソースコードの中でも、古くから実装されていた部分ではなく、その時点でソースコード上でしか存在しないソースコード上の新規なソースコード・セットであってもこれらを特定し、効果的な実行検査を可能とするプログラミング支援技術が必要とされていた。

本発明は、上述した従来技術の問題点に鑑みてなされたものであり、本発明の情報処理装置は、ソースコードの変更があった場合、当該変更に関連するコードを網羅的に実行するテストケースを作成し、適切なテストケース識別子を付して、変更したソースコードの機能ユニットに対応付けて登録する。

ソースコードの実行検査を実行する場合、ソースコードの新バージョンと、新バージョン以前に作成されたソースコードである旧バージョンとの間の差分コードを抽出する。抽出された差分コードは、複数の機能に対応して旧バージョンから新バージョンの登録までの間にソースコードの複数の特定機能ユニットが変更されている可能性がある。

本発明では、旧バージョンが登録された後に追加登録されたテストケースを検索して抽出し、抽出されたテストケースを使用して新バージョンの実行検査を行う。さらにテストケースは、旧バージョンが登録された後、新バージョンが登録されるまでに登録されたものから検索して抽出することがソースコードの変更検証の同期性を確保する上で好ましい。テストケースは、プログラマが変更したソースコード部分を実行させる最小単位のスクリプトまたはプログラムとして提供される。

そして、ソースコードの実行検査は、ソースコードの行と実行命令とを対応付けて管理され、命令の実行に対応する行の識別を、行単位で処理することにより、当該テストケースにおいて実行されたコードを抽出した実行済コード集合が作成される。この実行済コード集合は、要素コードの実行順にソートされて、実行トレースを提供する。

本発明の情報処理装置は、ソースコード変更検査処理において、旧バージョンから新バージョンの登録までの間に登録されたテストケースを、順次実行させ、旧バージョンと新バージョンとの間で差分コードとして抽出されたコード・セットを特定機能ユニットごとに分類して、特定機能ごとに特定差分コードとして出力する。この結果、差分コードとして抽出された新バージョンのコードは、特定機能ユニットごとに分類された後、以後の処理のために提供される。この結果、プログラマは、ソースコード全体に立ち戻って変更箇所の解釈および理解を行う労力を回避することができ、より効率的なプログラミング開発が可能となる。

さらに、本発明では、命令の実行をソースコードの行に対応付けて管理することにより、ソースコードについて変更された特定機能ごとのデバッグ処理を可能する。このため、ＸＰなどにより他のプログラマが別途変更したコード・セットに煩わされることなく、自己の作成した、または特定機能ユニットに関連する変更についての実行検査に専念でき、効率的にバグに対応することが可能となる。

さらには、テストケースの実行トレースを調べることで、最新の機能に対応するソースコードの中から、仕様書に記載されておらず、ソースコード上のみでしか存在しないソースコードのコード・セットを特定することが可能となり、特定のソリューション開発において、ユーザニーズへの対応状況の検査およびそのコードに特化したデバッグ処理が可能となる。

本発明によれば、ソースコードに対して複数の機能に対応して複数の変更がなされている場合であっても効率的に差分コードとソースコードが提供しようとする機能との対応付けを可能とし、さらに機能ごとのデバッグを可能とするので、より効率的なプログラム開発が可能な、プログラミングを支援するための情報処理装置、情報処理システム、プログラミング支援方法、およびプログラムが提供できる。

以下、本発明を実施形態をもって説明するが、本発明は後述する実施形態に限定されるものではない。図１は、本実施形態の情報処理システム１００の実施形態を示す。図１に示す情報処理システム１００は、ソースコードのプログラミングにおけるソースコードへの変更を検証するための検証サーバ１１０と、検証サーバ１１０がソースコードをテストするために使用するテストケースを格納するテストケース・サーバ１２０とを含んで構成されている。

検証サーバ１１０は、検証対象となるソースコードを格納したソースコード・データベース１４０（以下、ソースコードＤＢとして参照する。）を管理しており、定期的または管理者などの外部指令に応答して、蓄積されたソースコードの検証を実行する。ソースコードＤＢ１４０は、例えばＳ＿ｖ１、Ｓ＿ｖ２、…、Ｓ＿ｖ４などのバージョン名が付され、またテストケースＤＢに登録された時刻に対応するタイムスタンプなどが付され、複数のソースコード１６０が登録されている。

ソースコードを作成するための言語は、特に制限はなく、例えば、フォートラン、ＣＯＢＯＬ、ＰＡＳＣＡＬ、ＰＬ−１、ＢＡＳＩＣ、Ｃ、Ｃ＋＋、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｂｅａｎｓ、Ｊａｖａ（登録商標）Ａｐｐｌｅｔ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、Ｐｅｒｌ、Ｒｕｂｙなどを挙げることができる。また、ソースコードは、コンパイラにより実行オブジェクトを作成して命令を実行させる実行形式でもよいし、インタプリタなどを介して行単位で実行される実行形式でもよい。

また、テストケース・サーバ１２０は、ソースコードの変更に関連するテストケース１７０を格納するテストケース・データベース１５０（以下、テストケースＤＢとして参照する。）を管理している。説明する実施形態では、検証サーバ１１０は、検証処理を実行するタイミングが到来すると、テストケースＤＢ１５０に登録され、ＴＣ＿１、ＴＣ＿２、…、ＴＣ＿４などとの識別子が付された複数のテストケース１７０から特定のテストケースを抽出する。検証サーバ１１０は、テストケース・サーバ１２０から、テストするべきテストケース１７０を取得し、ソースコードの検証を開始する。

図１に示した実施形態では、検証サーバ１１０と、テストケース・サーバ１２０とは、ＬＡＮ、ＷＡＮ、インターネットなどのネットワーク１３０を介して相互接続されていて、ＴＣＰ／ＩＰプロトコルの下で、ファイル送受信を行っている。テストケース・サーバ１２０は、検証サーバ１１０からテストケース１７０の照会要求を受領すると、テストケース・サーバ１２０は、照会に対応するテストケース１７０を検索する。テストケース・サーバ１２０は、テストケースが検索されると、検索されたテストケースを検証サーバ１１０に送付することで、検証サーバ１１０にテストケースを取得させて、検証処理を可能とする。

また、ネットワーク１３０には、複数のネットワーク・クライアント１１２〜１１８（以下、単にクライアントとして参照する。）が接続されている。クライアント１１２〜１１８は、プログラマがソースコードの特定の機能ユニットまたは特定のコード・セットを変更しており、不定期的、または定期的に検証サーバ１１０にソースコードを送付している。なお、本実施形態では、ソースコードの変更とは、ソースコードに対するコード・セットの追加およびコード・セットの修正・削除の処理を含む。

特定の実施形態では、検証サーバ１１０は、新たな変更ユニットを受領すると、適切な記憶領域に一定期間蓄積しておく。その後、ソースコードをバージョンアップするタイミングの到来に対応して検証サーバ１１０は、変更ユニットに対応する旧ユニットのコード領域を、変更ユニットで上書きし、新たなバージョン名を付してソースコードをソースコード・データベース１４０に登録する。この際、検証サーバ１１０は、ソースコードを固有に識別するバージョン名やタイムスタンプを付してソースコードＤＢ１４０にソースコードを登録する。

以下、ソースコードＤＢ１４０に格納されているソースコードのうち、最新のバージョンを新バージョンとして参照し、それよりも古いソースコードを旧バージョンとして参照する。なお、検証サーバ１１０は、バージョン名の他、作成したタイムスタンプ、作成者コードなどを登録し、以後の変更履歴ログなどとして参照可能としてもよい。

さらにクライアント１１２〜１１８にアクセスするプログラマは、ソースコードの変更を行うと、テストケースを作成し、図１の実施形態では、テストケース・サーバ１２０に送付する。テストケース１７０は、ソースコードのうち、変更に関連する特定機能ユニットを構成するコード・セットを実行させることが可能であって、かつテストケース自体で検証サーバ１１０が実行可能な形式のスクリプトまたはプログラムとして記述される。

さらに、テストケース１７０には、テストケース名、テストケースが対象とする特定機能ユニット名、タイムスタンプ、プログラマ名などのテストケース識別子を記述しておくことがでる。これらのテストケース識別子は、検証サーバ１１０の検証処理に先立って検証サーバ１１０が検証するべきテストケースを検索する際のインデックスとして使用することができる。

図１に示した情報処理システム１００では、検証サーバ１１０と、テストケース・サーバ１２０とは、分離した構成として説明されている。しかしながら、情報処理システム１００の他の実施形態では、検証サーバ１１０と、テストケース・サーバ１２０とを機能的に統合して、単一の検証サーバとして構成することもできる。当該他の実施形態では、情報処理システム１００は、プログラマは、クライアント１１２〜１１８を介して変更したユニットとともに当該変更に対応するテストケースを検証サーバ１１０に送付する構成として実装される。当該他の実施形態では、検証サーバ１１０は、変更に関連する特定機能ユニットの変更バージョンと、テストケースとを受領する。

検証サーバ１１０は、適切なタイミングの到来に対応してソースコードの新バージョンを生成し、ソースコードＤＢ１４０に登録する。その後、受領したテストケースを検索して取得し、取得したテストケースを実行させて、新バージョンの検証を実行する。検証結果は、検証サーバ１１０の検証結果ログとして検証サーバ１１０が管理することもできるし、検証結果をデバッグ結果に加工した後、クライアント１１２〜１１８に返す構成とすることができる。クライアント１１２〜１１８は、当該検証結果を受領し、異常がない場合には、次のユニットの開発に着手する。

また、異常がある場合には、当該異常の箇所を解析し、対応付ける追加・変更を実行し、再度検証サーバ１１０に送付する。この場合、テストケースも送付することになるが、デバッグの結果を反映させる箇所についてのテストケースはすでに作成済みであるので、既製のテストケースを、再度検証サーバ１１０またはテストケース・サーバ１２０に送付することで対応することができる。また、デバッグのため、検証サーバ１１０に対して使用するテストケースを明示的に指定してデバッグ処理を依頼することもできる。

変更箇所に異常がある場合に、検証サーバ１１０に対して明示的にデバッグ処理を依頼する実施形態を採用する場合でも、検証サーバ１１０は、他のプログラマが作成したコード領域のデバッグ結果を送付することなく、プログラマ自身が作成した特定機能ユニットに関連するデバッグ結果を受領することができる。この結果、他のプログラマが作成した機能またはコード領域と切り離してユニットのデバッグおよび開発が可能となり、開発効率が向上する。また、本実施形態では、特定のプログラマがどの領域のコーディングを行っているかを相互に知ることなく、プログラム開発に専念することが可能となるとともに、プログラム内容に関する情報管理が容易となる。

検証サーバ１１０またはテストケース・サーバ１２０は、汎用サーバ装置を使用して実装することができる。上述した汎用サーバ装置は、ＰＥＮＴＩＵＭ（登録商標）、ＰＥＮＴＩＵＭ（登録商標）互換チップ、などのＣＩＳＣアーキテクチャのマイクロプロセッサ、または、ＰＯＷＥＲ ＰＣ（登録商標）などのＲＩＳＣアーキテクチャのマイクロプロセッサを実装することができ、マイクロプロセッサは、シングルコアでもマルチコアでもかまわない。

また、汎用サーバ装置は、ＷＩＮＤＯＷＳ（登録商標）２００Ｘ、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）、ＡＩＸ（登録商標）などのオペレーティング・システムにより制御されており、Ｃ＋＋、ＪＡＶＡ（登録商標）、ＪＡＶＡ（登録商標）ＳＣＲＩＰＴ、ＰＥＲＬ、ＲＵＢＹなどのプログラミング言語を使用して実装される、ＣＧＩ、サーブレット、ＡＰＡＣＨＥなどのサーバ・プログラムを実行し、クライアント１１２〜１１８との間でトランザクションを行っている。この他、汎用サーバは、ＲＡＭ、Ｌ２、Ｌ３キャッシュ、ハードディスク装置などを実装し、各種の処理を可能としている。なお、検証サーバ１１０、テストケース・サーバ１２０を一体として構成する実施形態では、各サーバの機能は、汎用コンピュータとして統合した実装形式とすることもできる。

クライアント１１２〜１１８は、本実施形態では、プログラマがコーディングし、各サーバ１１０、１２０にアクセスするために使用される。この目的から、クライアント１１２〜１１８は、パーソナル・コンピュータ、ワークステーション、またはサーバなどを使用して構成することができる。また、クライアント１１２〜１１８は、特定機能ユニットを変更し、検証サーバ１１０、テストケース・サーバ１２０との間でＴＣＰ／ＩＰなどのトランザクション・プロトコルに基づき、ＨＴＴＰ、ＦＴＰなどのファイル転送プロトコルを使用して変更ユニットおよびテストケースを転送することができる限り、本実施形態では、その実装形式に特に限定はない。

図２は、本実施形態の検証サーバ１１０のソフトウェア・ブロック２００を示す。検証サーバ１１０は、ソースコードＤＢ１４０から新バージョンのソースコードと、新バージョンのソースコード以前に作成された旧バージョンとを読込んで、新バージョンと旧バージョンのコードを比較し、新バージョンと旧バージョンの差分コードを取得する。本実施形態で、差分コードとは、新バージョンと、旧バージョンとの間で例えばｄｉｆｆコマンドにより検出された不一致のコードであって、新バージョンに存在し、旧バージョンに存在していないコード、そして旧バージョンに存在し、新バージョンに存在していないコードとして定義される。

検証サーバ１１０は、さらにテストケースＤＢ１５０などを検索してテストケースを取得した後、テストケースを実行させ、差分コードのうち、特定機能ユニットに関連するコード・セットを抽出し、特定差分コード集合２８０として出力させている。本実施形態では、特定差分コードとは、特定機能ユニット自体または特定機能ユニット内で、テストケースの実行により単独で実行させることができる特定機能ユニット内の特定のコード・セットを意味する。なお、図２に示した各ソフトウェア・ブロック２００は、情報処理装置がＲＡＭなどのプログラム実行空間に本実施形態のプログラムおよびデータを読込んで、マイクロプロセッサがプログラムを実行することにより情報処理装置上の機能手段として実現されている。

上述した処理を実行するため、図２に示す実施形態の検証サーバ１１０は、ソースコード読取部２１０と、ソースコード比較部２２０と、差分コード登録部２３０とを含んでいる。ソースコード読取部２１０は、ソースコードＤＢ１４０から、例えばソースコードのバージョン名、タイムスタンプなどを参照して、最新のソースコード、すなわち新バージョンを読込む。また、ソースコード読取部２１０は、好ましい実施形態では、最新のバージョンの直前のバージョン名またはタイムスタンプなどで指定される、以前に作成されたソースコード、すなわち旧バージョンとを読出し、バッファメモリなど適切な記憶領域に、新バージョン２１０ａおよび旧バージョン２１０ｂとして格納する。

なお、読取る旧バージョンは、検証処理の目的に応じて、直前のバージョンではなく、さらに過去に作成されたバージョンであってもよい。どのソースコードを旧バージョンとして採用する場合でも、対応する機能のテストケースを使用することで、テストケースにより特定される機能の検証が可能である。

ソースコード比較部２２０は、ｄｉｆｆコマンド、ｃｏｍｐコマンド、システムレベル・コマンドではなく、ファイル比較アプリケーションなど、ソースコードを比較することができるプログラムを含んで構成することができる。ソースコード比較部２２０は、バッファリングされた各バージョン２１０ａ、２１０ｂを読出して、新旧バージョンのソースコードにそれぞれコード行番号などのコード行識別値を割当てる。

その後、ソースコードの比較を実行し、新バージョンと、旧バージョンとの間で相違するコードを抽出する。その後、ソースコード比較部２２０の結果は、差分コード登録部２３０に送られ、差分コード登録部２３０は、ソースコード比較部２２０が出力した相違するコードを受領して差分コードとして登録する。差分コードの登録形式は、これまで知られたいかなる登録形式でも使用することができる。なお、差分コードの登録形式は、テーブルまたはリストとし、差分コード集合とすることが、以後の集合演算など好適に利用することができ、またデータベース・プログラムを使用して、検索および集合演算が可能となるので、好ましい実施形態である。

さらに、検証サーバ１１０は、テストケース取得部２５０と、ソースコード実行部２４０と、特定差分コード抽出部２７０とを含んでいる。テストケース取得部２５０は、説明する実施形態では、テストケースＤＢ１５０に対してテストケース１７０の照会要求を発行する。照会要求には、テストケースのタイムスタンプ、機能名、作成者名などを検索インデックスとして使用することができる。その後、検証サーバ１１０は、テストケース・サーバ１２０から、照会要求に適合したテストケースを取得し、ソースコード実行部２４０に渡す。ソースコード実行部２４０は、テストケースを受領して実行形式のオブジェクトまたはバイトコードなどの命令を作成し、ソースコードの行単位で、テストケースにより呼出されるコードを実行する。本実施形態で、命令とは、アセンブラ、機械語、またはＪＡＶＡ（登録商標）の場合には、バイトコードなどを意味する。

ソースコード実行部２４０は、当該命令の実行結果をコード実行検査部２６０に渡して、命令の実行とコードとの対応付けおよびコード内容の取得、実行結果の取得などを可能としている。また、コードの特定は、種々の方法を使用して行うことができるが、ソースコード比較部２２０が生成した行番号などのコード行識別値を使用して行うことができる。コード実行検査部２６０は、コード行と、命令とを対応付けた対応テーブルおよび実行済コード集合を管理している。この目的で、ソースコード実行部２４０およびコード実行検査部２６０は、デバッガを使用して実装することができ、採用するデバッガとしては、これまで知られたいかなるデバッガでも採用することができる。

コード実行検査部２６０は、新バージョンの命令が実行されると、対応テーブルを参照して対応するコードを取得し、実行済コードとして当該コードを実行済コード集合に登録する。なお、実行済コード集合のコードを実行順にソーティングしたファイルは、実行トレースとして利用することができる。

特定差分コード抽出部２７０は、差分コード登録部２３０が登録した差分コード集合と実行済コード集合とを読出し、各集合についての積集合を計算し、特定機能ユニットに関連するコードを抽出する。その後、特定差分コード抽出部２７０は、抽出されたコードを要素ノードとする特定差分コード集合２８０を登録する。

なお、特定差分コード集合２８０を生成する処理の他の実施形態で、コード実行検査部２６０は、ソースコード実行部２４０から、実行された命令に対応するコードのコード識別値に加えて、当該コードのコード内容、実行結果がＦＡＩＬであるか、またはＰＡＳＳであるかの判定を含むデータを使用して実行済コード集合を生成することができる。この実施形態の場合、特定差分コード抽出部２７０は、差分コード集合に登録された行番号などの対応する実行済コード集合の登録要素を抽出し、特定差分コード集合２８０を作成することができる。説明する当該実施形態は、特定差分コード集合２８０は、ソースコードの特定機能ユニットに関連するコードのデバッグ結果を提供することができる。

図３は、本実施形態の検証サーバ１１０による特定差分コード集合２８０の生成処理３００を、行番号などのコード識別値で指定されるコードを各集合の要素ノードとして示した図である。図３に示す生成処理３００においては、新バージョンが含む全コードの集合が集合３１０として示されている。検証サーバ１１０は、集合３１０のノードを、変更されないまま残されているコードである継承コード３４０を、要素ノードとして含む継承コード集合３２０と、変更または追加などの変更を受けたコード３７０、３８０を要素ノードとして含む差分コード集合３３０とに分離する。なお当該分離は、差分コード登録部２３０が実行する。なお、集合３５０は、説明する実施形態では、テストケースにより実行されない特定機能に帰属されるコード３７０を含む集合である。また、集合３６０は、差分コード集合３３０のうち、テストケースにより実行された特定差分コード集合３６０である。

また、特定差分コード抽出部２７０は、コード実行検査部２６０の検査により、テストケースの実行に際して実行済みとなったコードである実行済ノード集合の要素ノードと、差分コード集合３３０の要素ノードとについて積集合を計算する。当該積集合の結果は、要素ノード３８０を要素とする特定差分コード集合３６０を与える。

特定差分コード抽出部２７０は、実行済コード集合が含む全ノードについて積集合を計算した後、特定差分コード集合３６０を確定させ、検証サーバ１１０の出力として適切な記憶装置に格納し、検証ログファイルなどとして登録させている。また、他の実施形態では、特定差分コード集合３６０をクライアント１１２〜１１８などに送信し、プログラマによるデバッグ処理などを支援するために利用させ、処理を終了する。

図４は、本実施形態の検証サーバ１１０が実行するプログラミング支援方法を構成するコード変更検出処理の概略的なフローチャートを示す。図４の処理は、ステップＳ４００から開始し、ステップＳ４０１で機能追加前の旧バージョンと、コードが変更された新バージョンとを読込む。ステップＳ４０２では、ｄｉｆｆコマンドを含むソースコード比較部２２０により比較を実行し、新バージョンが含む差分コードのコード識別子を取得し、差分コード集合３３０に登録する。ステップＳ４０３では、特定の機能のみを起動するテストケースを実行させて、実行された命令に対応するコードを実行済コード集合に登録していき、実行済コード集合を作成する。本実施形態で、実行トレースを作成する場合、実行済コード集合の要素ノードを、実行順にソーティングし、適切なリストまたはテーブルとして登録することにより生成される。なお、好ましい実施形態では、実行済コード集合は、実行トレースと同一のデータとして構成することができる。

ステップＳ４０４では、実行済コード集合に登録されたコードが差分コード集合３３０の要素ノードとして含まれているか否かを判断して積集合を計算し、実行済コード集合に登録されたコードが差分コード集合３３０に登録されている場合、特定差分コード集合３６０の要素ノードとして登録し、ステップＳ４０５で処理を終了させる。

図５は、本実施形態で、コード実行検査部２６０が実行する、実行済コード集合を生成する処理のフローチャートを示す。図５の処理は、ステップＳ５００から開始し、ステップＳ５０１で、実行済コード集合を初期化し、さらに実行命令と新バージョンのソースコードとの対応テーブルを作成する。ステップＳ５０２では、ソースコード実行部２４０により命令を実行させ、ステップＳ５０３で、実行された命令に対応するコードのコード識別値を、対応テーブルを参照して取得する。

さらにステップＳ５０４で、コード実行検査部２６０は、取得したコードが実行済コード集合の要素ノードとしてすでに登録されているか否かを判断し、登録されていない場合（ｎｏ）、ステップＳ５０８で取得したコードのコード識別値を実行済コード集合に登録する。また、コード実行検査部２６０は、他の実施形態においてコード識別値に加え、コード内容および実行結果をソースコード実行部２４０から取得して、実行済コード集合の要素ノードを作成することができる。

一方、ステップＳ５０４で、実行済コード集合に取得した行番号がすでに登録されている場合（ｙｅｓ）には、コード実行検査部２６０は、処理をステップＳ５０５に進め、新バージョンのソースコードの全命令を実行完了したか否かを判断する。ステップＳ５０５の判断の結果、全命令の実行が完了していない場合（ｎｏ）処理をステップＳ５０２に分岐させて処理を反復させる。また、ステップＳ５０５で全命令の実行が完了したと判断された場合（ｙｅｓ）、処理をステップＳ５０６に分岐させて実行済コード集合を確定させ、この実施形態では、さらに実行済コード集合の要素ノードをコードの実行順にソーティングして実行トレースを作成して、処理をステップＳ５０７で終了させる。その後、コード実行検査部２６０は、特定差分コード抽出部２７０に通知を行い、特定差分コードの抽出を依頼する。

図６は、本実施形態が適用されるソースコードのバージョンと、当該バージョンに対応するテストケースの抽出処理６００の実施形態を示す。ソースコードは、複数のプログラマにより独立して、コード領域または関数などのユニット単位で作成される。そして、特定ソリューションを解決するためのプログラムが完成するまで、プログラムに対する機能の変更が、繰返し行われ、ソースコードがバージョンアップされている。例えば、ソースコード６１０では、機能αに対応するユニット６１２が追加されていて、バージョン名として、バージョンｖ_ｘ．ｘが与えられている。バージョンの登録履歴は、テストケース・サーバ１２０と検証サーバ１１０との間で、ソースコード・バージョンと、テストケースとを対応付けるように同期化処理が行われており、適切なテストケースを、検証するべきソースコード・バージョンに対応付けられている。

また、プログラマは、ユニット６１２を追加した場合、ユニット６１２の全コードを実行させることができるテストケース６１４を作成し、テストケース・サーバ１２０に登録する。

その後、プログラマによりソースコードに対して機能βに対応するユニット６２２が追加されたソースコード６２０が、バージョン名＝バージョンｖ_{ｘ．ｘ＋１}として登録される。このとき、テストケース・サーバ１２０には、プログラマから、テストケース６２４が送付され、登録される。さらにその後、プログラマにより、機能Ａおよび機能γに対応するユニット６３２、６３４が追加されていて、追加されたソースコードに対してバージョン名＝バージョンｖ_{ｘ．ｘ＋２}が付されている。本実施形態では、バージョンｖ_{ｘ．ｘ＋２}が新バージョンであり、バージョンｖ_{ｘ．ｘ＋１}が旧バージョンである。ソースコード６３０では、追加機能Ａおよび追加機能γに対応して、機能Ａの全コードおよび機能γの全コードを実行するためのテストケース６３６、６３８がテストケース・サーバ１２０に登録される。

本実施形態の検証サーバ１１０は、ソースコードに追加または修正された特定機能ユニットを分離してテストケースを読込み、ソースコードを実行することにより、特定の機能に関連する差分コードを識別することを可能とする。この目的のため、テストケース取得部２５０は、例えば新バージョン＝バージョンｖ_{ｘ．ｘ＋２}が登録された時点までに登録されたテストケースのうち、テストの目的に応じたテストケースを抽出する処理を実行する。テストケース取得部２５０がテストケースを抽出するための判断基準としては、種々の実施形態を採用することができる。

例えば、テストケースを取得する場合の、第１の実施形態では、新バージョンであるソースコード６３０と、旧バージョンのソースコード６２０とについて割り当てられる同期情報を参照し、旧バージョンが登録された後、新バージョンが登録されるまでにテストケース・サーバ１２０に登録されたテストケースを順次抽出する実施形態である。なお、同期情報は、ソースコードおよびテストケースの対応付けを行うことができる限り、タイムスタンプでも良いし、シリアル番号でも良いし、その他時系列的な動機付けを可能とする限り、いかなる値、フォーマットとすることができる。この実施形態について図６を使用して説明すると、例えば、新バージョンのソースコード６３０が登録された時刻では、テストケース６１４、テストケース６２４の他、新バージョンの登録までにテストケース６３６、６３８の２テストケースが登録されている。各テストケース６１４、６２４、６３６、６３８には、それぞれテストケース・サーバ１２０に登録された時刻を示すタイムスタンプが付されている。

第１の実施形態では、例えば、テストケース６３６が先に登録され、テストケース６３８が時間的に後に登録され、その後に新バージョンｖ_{ｘ．ｘ＋２}が登録されたものとして説明する。検証サーバ１１０は、旧バージョンの同期情報を参照し、当該同期情報より以後に登録されたテストケース６３６、６３８を読込んで、順に例えば実行キューに登録する。その後、テストケース６３６を実行させて、テストケース６３６に対応する特定差分コード集合を生成する。その後、テストケース６３８を実行させてテストケース６３８に対応する第２特定差分コード集合を生成することにより、特定の機能ごとに関連する差分コードを識別して抽出することが可能となる。

特定差分コード集合は、テストケースごとに独立したデータセットとして作成することもできるし、テストケースごとに生成される特定差分コード集合を統合して、テストケースごとに識別されたリストとして作成することもできる。特定差分コード集合を、プログラマに対してデバッグ結果として提示する実施形態の場合には、テストケースごとに異なる特定差分コード集合を生成する実施形態が、以後のデバッグ結果を報告する上では好ましい。

生成された特定差分コード集合は、検証サーバ１１０の検証ログファイルとして格納することもできる。さらに、特定差分コード集合は、特定差分コード集合の要素ノードの実行結果とともに検証サーバ１１０から、デバッグ結果報告としてテストケースを作成したプログラマが管理するクライアントまたは管理者の端末コンピュータに返却され、以後の処理に利用することができる。

テストケースを抽出する際の第２の実施形態は、追加・修正されたユニットにテストケースを指定するケース指示コードを埋込んでおく実施形態である。ケース指示コードは、ユニット名、機能名、（作成者＋バージョン名）の識別値セットなどを使用することができ、ファイル名、コメント行などとして埋め込むことができる。第２の実施形態の場合、テストケース取得部２５０は、ファイル名、ユニット名などの指示コードを新バージョンから取得する。

その後、テストケースＤＢ１５０に対してテストケースの照会要求を発行し、対応するテストケースを取得し、ソースコード実行部２４０に実行させることができる。この実施形態の場合、複数のテストケースが抽出された場合、登録時刻などの順に実行キューにテストケースを登録し、実行させる点では第１の実施形態と同様である。また、抽出された特定差分コード集合を適宜統合して検証ログまたはデバッグ結果を作成してもよい。

図７は、本実施形態が適用されるソースコード７００の実施形態を示す。図７に示すソースコード７００は、特定機能を提供するユニットに対応する旧バージョンであり、プログラマは、ソースコード７００に対して機能追加、機能変更などを目的としてクライアント１１２〜１１８においてコーディングを行う。コーディングが終了した後、変更コードを、新バージョンの作成のために検証サーバ１１０に送付する。

図８は、プログラマによるコーディングの結果、変更された新バージョンのソースコード８００を示す。新バージョンでは、function1()で指定される機能とは異なる、function2()および関連する機能が追加され、複数の機能に対応するコードを含んだ構成に変更されている。なお、特定のコード行については削除されているがより詳細には後述する。

図７および図８を参照して理解されるように、旧バージョンと新バージョンとの間で、どのコードが変更されたかを直感的に認識することは困難である。そして、この状況下で、これらのコードを一括して検証・デバッグ処理しても、ＸＰなどのプログラミング開発環境にあるプログラマは、却ってソースコードの理解および解釈に余分な時間を費やすことになる。このため、特定機能ユニットに関連付けてコード・セットを抽出することが必要である。

図９は、ソースコード比較部２２０による比較結果の実施形態を示す。ソースコード比較部２２０は、ｄｉｆｆコマンドを含んで構成されており、新バージョンおよび旧バージョンにそれぞれ行番号を付し、コード内容が不一致のコード行を識別して行マーキング、コード・リストなどの形式で差分コードを抽出する。例えば図９を使用して説明すると、図９では、コード領域９１０は、新バージョンにおいて削除されたコード領域であり、コード領域９２０、９４０は、新バージョンで変更された機能Ａに対応するコード領域である。

また、コード領域９３０は、新バージョンで追加された機能Ｂに対応するコード領域である。差分コード登録部２３０は、図９に示した差分コードであって、新バージョンに存在するコードの行番号を抽出し、差分コード集合として登録する。図９に示した実施形態では、行番号１２、１３、行番号２０−３０、行番号４２−４６が、差分コード集合の要素ノードとして登録される。

図１０は、図８に示した新バージョンのためのテストケース１０００の実施形態を示す。なお、図１０に示したテストケース１０００は、図９のソースコードのコード領域特定機能Ａに関連するコードを特定するためのテストケースである。テストケース１０００は、新バージョンのソースコード８００が含む特定機能に関連する関数およびメソッドを網羅的に呼び出すようにしてコーディングされ、例示的な実施形態では、例えばtestcase_componentAなどとしてファイル名が付され、テストケース・サーバに登録された時刻が、同期情報として付されて登録されている。

テストケース取得部２５０は、ケース指示コードや、タイムスタンプなどの同期情報を参照してテストケースを特定し、複数のテストケースが取得された場合、実行キューに格納し、複数のテストケースについて順次的にソースコードを実行させ、その実行トレースを使用して特定差分コード集合を生成させている。

図１１は、テストケース１０００を実行したときに生成される実行トレースの実施形態を、実行されたコード領域に対応付けて示した図である。実行トレース１１００は、テストケース１０００によって呼出されたソースコード８００のコード行が実行された順にコード識別値をソーティングして登録されている。実行トレースの要素ノードは、例えば、コードの行番号、コード内容、実行結果などを含ませて、実行済コード集合の要素ノードと同様の構成として生成することができる。図１１に示した実施形態では、実行トレース１１００では、各コード行の実行結果も併せて表示されていて、実行トレース１１００は、デバッグ結果も提供している。

図１１には、実行トレース１１００にリストされたコード行の内容を、説明の便宜上、ソースコード８００に実行トレースの実行順を重畳して示した実行コード・リスト１１５０を示す。実行コード・リスト１１５０は、実行トレースのコード内容として実行トレース自体に含ませることができる。実行コード・リスト１１５０を参照すると、まず実行番号（１）で関数super()が呼出され、実行番号（２）で、SampleCommon()が宣言された後、実行番号（３）で値sum、numが計算され、その計算のために実行番号（４）、（５）で関数commonMethod1()、commonMethod2()が呼出されている。実行番号（５）では、実行番号（６）で関数privateMethod1()が呼出され、privateMethod1()では、戻り値＝sum／numが計算されていて、０で除算するエラーが発生している。

なお、図１０を参照すると、テストケース１０００は、sum／numの値が返された時点で処理を終了する。コード領域９３０に対応するコードは、呼出されずに終了している。このため、テストケース１０００は、特定機能ユニットのみを呼出し、実行させていることが分かる。
また、実行番号（６）で発生したエラーは、実行結果としてＦＡＩＬが付され、実行トレース１１００に追加されている。

図１１に示した実行トレース１１００は、テーブル、リストの形式として検証サーバ１１０が管理する。また、情報処理システム１００の特定の実装形式および目的に応じて管理者にレポートすることもできる。また、さらに他の実施形態では、ソースコードおよびテストケースを作成したプログラマに、特定差分コード集合３６０または実行トレース１１００をデバッグ処理結果として送付することもできる。

実行トレース１１００を直接管理者またはプログラマにレポートするのではなく、特定差分コード集合３６０を作成してする場合に、特定差分コード集合３６０に、コード識別値に対応付けてコード内容および実行結果を含ませてもよい。この実施形態の場合、特定差分コード集合３６０のみを対象とするデバッグ結果が生成され、プログラマに対し送付することができる。またデバッグ結果は、検証サーバ１１０が検証結果ログとして登録することもでき、本実施形態のプログラミング支援の目的に応じていかなるようにデータ化されてもよい。

図１２は、図１１に示した実行トレースを与えるソースコード８００を使用して、特定差分コード集合３６０が生成される処理の概略図である。なお、図１２には、特定差分コード集合３６０の実施形態も示されている。ソースコード８００は、図１１に示すように、行番号１〜４８までを含んでおり、これらのうち、行番号１２、１３、行番号２０〜３０、行番号４２〜４６が差分コードとして識別される。そして、行番号１〜１１、行番号１４〜１９、行番号３１〜４１は、変更のない旧バージョンから継承したコードである。検証サーバ１１０は、差分コード登録部２３０を起動して、図１２に示すようにソースコード８００のコードを継承コード集合１２２０と、差分コード集合＝｛集合１２３０∪集合１２５０｝とに分類する。

そして、ソースコード実行部２４０による実行命令をコード実行検査部２６０が検査し、実行済コード集合および実行トレースを生成し、差分コード集合｛集合１２３０∪集合１２５０｝に含まれる要素ノードであって、実行トレースにも存在するコード１２４０を特定差分コード集合１２５０の要素として分離して登録する。図１２では、実行済コード集合１２７０を参考のために破線で示す。この結果、ソースコード８００が含むコードが、継承コード集合１２２０、特定差分コード集合１２５０、および差分コード集合１２３０に分類される。これらの集合のうち、コード１２４０からなる特定差分コード集合１２５０を検証結果として生成することで、特定機能ユニットごとに検証を行うことが可能となる。

図１２に示した特定差分コード集合１２５０は、ソースコード８００のうち、図１１に示した機能Ａに関連する差分コードのみを含み、その要素ノードは、行番号１２、１３、行番号４２〜４６のコード識別値、また他の実施形態ではコード内容および実行結果を含むものとされる。なお、図９のコード領域９３０に対応する行番号２０〜３０のコードは、差分コード集合１２３０に登録されたままとされている。

以上説明したように、本実施形態では、ソースコードが複数の変更を受けている可能性がある場合に、特定の機能を指定して変更を受けたコードのみを抽出することができるので、より効率的なデバッグ処理を可能とし、効率的なプログラミング支援技術を提供することができる。

さらに本実施形態によれば、複数のプログラマが並列的にソリューションを進化させて行く、アジャイルな環境下でのプログラム開発における、ＦＶＴ(Function Verification Test)またはＳＶＴ(System Verification Test)の効率を向上させることができる。

本実施形態の上記機能は、Ｃ、Ｃ＋＋、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｂｅａｎｓ、Ｊａｖａ（登録商標）Ａｐｐｌｅｔ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、Ｐｅｒｌ、Ｒｕｂｙなど、レガシープログラミング言語またはオブジェクト指向プログラミング言語などで記述された装置実行可能なプログラムにより実現でき、当該プログラムは、ハードディスク装置、ＣＤ−ＲＯＭ、ＭＯ、フレキシブルディスク、ＥＥＰＲＯＭ、ＥＰＲＯＭなどの装置可読な記録媒体に格納して頒布することができ、また他装置が可能な形式でネットワークを介して伝送することができる。

これまで本実施形態につき説明してきたが、本発明は、上述した実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。

本実施形態の情報処理システム１００の機能ブロック図。 本実施形態の検証サーバ１１０のソフトウェア・ブロック図。 本実施形態の検証サーバ１１０による特定差分コード集合２８０の生成処理３００を、コード識別値で指定されるコードを各集合のノードとして示した図。 本実施形態の検証サーバ１１０が実行するコード変更検出処理の概略的なフローチャート。 本実施形態で、コード実行検査部２６０が実行する処理のフローチャート。 本実施形態が適用されるソースコードのバージョンと、当該バージョンに対応するテストケースの抽出処理６００の実施形態を示した図。 本実施形態が適用されるソースコード７００の実施形態を示した図。 プログラマによるコーディングの結果、変更された新バージョンのソースコード８００を示した図。 ソースコード比較部２２０による比較結果の実施形態を示した図。 図８に示した新バージョンのためのテストケース１０００の実施形態を示した図。 テストケース１０００を実行したときに生成される実行トレースの実施形態を、実行されたコード領域に対応付けて示した図。 図１１に示した実行トレースを与えるソースコード８００を使用して、特定差分コード集合３６０が生成される処理の概略図。 従来のｄｉｆｆコマンドを使用するソースコードの概略的な変更検査手順１３００を示した図。 ２つソースコードのバージョンを比較して比較結果情報を生成し、現行バージョンを実行形式に変換してテストケースにより試験する従来処理のフローチャート。

符号の説明

１００…情報処理システム、１１０…検証サーバ、１１２〜１１８…ネットワーク・クライアント、１２０…テストケース・サーバ、１３０…ネットワーク、１４０…ソースコード・データベース、１５０…テストケース・データベース、１６０…ソースコード、１７０…テストケース、２００…ソフトウェア・ブロック（検証サーバ）、２１０…ソースコード読取部、２２０…ソースコード比較部、２３０…差分コード登録部、２４０…ソースコード実行部、２５０…テストケース取得部、２６０…コード実行検査部、２７０…特定差分コード抽出部、２８０…特定差分コード集合

Claims (21)

1. ソースコードの変更を検出する情報処理装置であって、前記情報処理装置は、
   前記ソースコードの新バージョンと旧バージョンとを取得するソースコード読取部と、
   前記新バージョンと前記旧バージョンとの間でコードの相違を比較するソースコード比較部と、
   相違した前記コードを抽出して差分コード集合を生成する差分コード登録部と、
   変更された前記ソースコードの特定機能ユニットに関連する全コードを実行させるため、変更に対応して前記旧バージョン以降に追加されたテストケースを取得して前記テストケースを実行させるソースコード実行部と、
   前記テストケースの実行により実行されたコードを検出し、実行済コード集合に登録するコード実行検査部と、
   前記差分コード集合と前記実行済コード集合の積集合を計算して前記特定機能ユニットに関連して変更されたコードを要素ノードとする特定差分コード集合を生成する特定差分コード抽出部と
   を含む、情報処理装置。
2. 前記情報処理装置は、テストケース取得部を含み、前記テストケース取得部は、前記新バージョンが登録される以前に追加され、前記特定機能ユニットの前記変更に関連するコードを実行させるテストケースを検索して取得する、請求項１に記載の情報処理装置。
3. 前記コード実行検査部は、前記実行済コード集合の前記要素ノードを実行順に登録する実行トレースを生成する、請求項２に記載の情報処理装置。
4. 前記実行済コード集合の前記要素ノードは、実行されたコードのコード識別値および実行結果を含み、前記特定差分コード集合は、前記特定機能ユニットの変更に対応するデバッグ結果を提供する、請求項３に記載の情報処理装置。
5. 前記ソースコードの変更は、エクストリーム・プログラミング環境で実行され、前記情報処理装置は、前記特定機能ユニットの変更に対する機能検証試験またはサイト検証試験を実行する、請求項４に記載の情報処理装置。
6. 前記特定差分コード集合は、前記ソースコードの変更に対応付けられた前記テストケースごとに作成される、請求項５に記載の情報処理装置。
7. ソースコードの変更を検出する検証サーバを含む情報処理システムであって、前記情報処理システムは、
   ネットワークを介して接続され、前記ソースコードの特定機能ユニットを変更するネットワーク・クライアントと、
   前記ネットワーク・クライアントによる特定機能ユニットに関連するコード・セットを受領してソースコードの旧バージョンから新バージョンを生成して前記旧バージョンおよび前記新バージョンを登録する検証サーバとを含み、前記検証サーバは、
   前記ソースコードの新バージョンと旧バージョンとを取得するソースコード読取部と、
   前記新バージョンと前記旧バージョンとの間でコードの相違を比較するソースコード比較部と、
   相違した前記コードを抽出して差分コード集合を生成する差分コード登録部と、
   変更された前記ソースコードの前記特定機能ユニットに関連する全コードを実行させるため変更に対応して前記旧バージョン以降に追加されたテストケースを取得して前記テストケースを実行させるソースコード実行部と、
   前記テストケースの実行により実行されたコードを検出し、実行済コード集合に登録するコード実行検査部と、
   前記差分コード集合と前記実行済コード集合の積集合を計算して前記特定機能ユニットに関連して変更されたコードを要素ノードとする特定差分コード集合を生成する特定差分コード抽出部と
   を含む、情報処理システム。
8. 前記検証サーバは、テストケース取得部を含み、前記テストケース取得部は、前記新バージョンが登録される以前に追加され、前記特定機能ユニットの前記変更に関連するコードを実行させるテストケースを検索して取得する、請求項７に記載の情報処理システム。
9. 前記コード実行検査部は、前記実行済コード集合の前記要素ノードを実行順に登録する実行トレースを生成する、請求項８に記載の情報処理システム。
10. 前記実行済コード集合の前記要素ノードは、実行されたコードのコード識別値および実行結果を含み、前記特定差分コード集合は、前記特定機能ユニットの変更に対応するデバッグ結果を提供する、請求項９に記載の情報処理システム。
11. 前記ソースコードの変更は、エクストリーム・プログラミング環境で実行され、前記検証サーバは、前記特定機能ユニットの変更に対する機能検証試験またはサイト検証試験を実行する、請求項１０に記載の情報処理システム。
12. 情報処理装置がソースコードの変更を特定機能ユニットに関連付けて検出するプログラミング支援方法であって、前記プログラミング支援方法は、前記情報処理装置が、
    前記ソースコードの新バージョンと旧バージョンとを取得するステップと、
    前記新バージョンと前記旧バージョンとの間でコードの相違を比較するステップと、
    相違した前記コードを抽出して差分コード集合を生成するステップと、
    変更された前記ソースコードの特定機能ユニットに関連する全コードを実行させるため変更に対応して前記旧バージョン以降に追加されたテストケースを取得して前記テストケースを実行させるステップと、
    前記テストケースの実行により実行されたコードを検出し、実行済コード集合に登録するステップと、
    前記差分コード集合と前記実行済コード集合の積集合を計算して前記特定機能ユニットに関連して変更されたコードを要素ノードとする特定差分コード集合を生成するステップと
    を実行する、プログラミング支援方法。
13. 前記プログラミング支援方法は、さらに前記テストケースを取得するステップを含み、前記テストケースを取得するステップは、前記新バージョンが登録される以前に追加され、前記特定機能ユニットの前記変更に関連するコードを実行させるテストケースを検索して取得するステップを含む、請求項１２に記載の方法。
14. 前記テストケースを実行させるステップは、前記実行済コード集合の前記要素ノードを実行順に登録する実行トレースを生成するステップを含み、さらに、前記プログラミング支援方法は、
    前記実行済コード集合の前記要素ノードに、実行されたコードのコード識別値および実行結果を追加するステップと、
    前記特定差分コード集合により、前記特定機能ユニットの変更に対応するデバッグ結果を提供するステップとを含む、請求項１３に記載の方法。
15. 前記ソースコードの変更は、エクストリーム・プログラミング環境で実行され、前記プログラミング支援方法は、前記特定機能ユニットの変更に対する機能検証試験またはサイト検証試験を実行するステップを含み、さらに前記特定差分コード集合を、前記ソースコードの変更に対応付けられた前記テストケースごとに作成するステップを含む、請求項１４に記載の方法。
16. 情報処理装置がソースコードの変更を特定機能ユニットに関連付けて検出するプログラミング支援方法を実行するための情報処理実行可能なプログラムであって前記プログラムは、前記情報処理装置が、
    前記ソースコードの新バージョンと旧バージョンとを取得するステップと、
    前記新バージョンと前記旧バージョンとの間でコードの相違を比較するステップと、
    相違した前記コードを抽出して差分コード集合を生成するステップと、
    変更された前記ソースコードの特定機能ユニットに関連する全コードを実行させるため変更に対応して前記旧バージョン以降に追加されたテストケースを取得して前記テストケースを実行させるステップと、
    前記テストケースの実行により実行されたコードを検出し、実行済コード集合に登録するステップと、
    前記差分コード集合と前記実行済コード集合の積集合を計算して前記特定機能ユニットに関連して変更されたコードを要素ノードとする特定差分コード集合を生成するステップと
    を実行する、情報処理実行可能なプログラム。
17. 前記プログラムは、さらに前記テストケースを取得するステップを含み、前記テストケースを取得するステップは、前記新バージョンが登録される以前に追加され、前記特定機能ユニットの前記変更に関連するコードを実行させるテストケースを検索して取得するステップを含む、請求項１６に記載のプログラム。
18. 前記テストケースを実行させるステップは、前記実行済コード集合の前記要素ノードを実行順に登録する実行トレースを生成するステップを含み、さらに、前記プログラムは、
    前記実行済コード集合の前記要素ノードに、実行されたコードのコード識別値および実行結果を追加するステップと、
    前記特定差分コード集合により、前記特定機能ユニットの変更に対応するデバッグ結果を提供するステップと
    を含む、請求項１７に記載のプログラム。
19. 前記ソースコードの変更は、エクストリーム・プログラミング環境で実行され、前記プログラミング支援方法は、前記特定機能ユニットの変更に対する機能検証試験またはサイト検証試験を実行するステップを含み、さらに前記特定差分コード集合を、前記ソースコードの変更に対応付けられた前記テストケースごとに作成するステップを含む、請求項１８に記載のプログラム。
20. 情報処理装置がソースコードの変更を特定機能ユニットに関連付けて検出するプログラミング支援方法であって、前記プログラミング支援方法は、前記情報処理装置が、
    前記ソースコードの新バージョンと旧バージョンとを取得するステップと、
    前記新バージョンと前記旧バージョンとの間でコードの相違を比較するステップと、
    相違した前記コードを抽出して差分コード集合を生成するステップと、
    変更された前記ソースコードの特定機能ユニットに関連する全コードを実行させるため変更に対応して前記旧バージョン以降に追加されたテストケースを、前記新バージョンが登録される以前に追加され、前記特定機能ユニットの前記変更に関連するコードを実行させるテストケースを検索して取得し、前記テストケースを実行させるステップと、
    前記テストケースの実行により実行されたコードを検出し、実行済コード集合に登録するステップと、
    前記差分コード集合と前記実行済コード集合の積集合を計算して前記特定機能ユニットに関連して変更されたコードを要素ノードとする特定差分コード集合を生成するステップと
    前記実行済コード集合の前記要素ノードに、実行されたコードのコード識別値および実行結果を追加するステップと、
    前記特定差分コード集合により、前記特定機能ユニットの変更に対応するデバッグ結果を提供するステップとを含み、前記デバッグ結果を提供するステップは、
    前記実行済コード集合の前記要素ノードを実行順に登録する実行トレースを生成するステップと、
    前記実行済コード集合の前記要素ノードに、実行されたコードのコード識別値および実行結果を追加するステップと、
    前記特定差分コード集合により、前記特定機能ユニットの変更に対応するデバッグ結果を提供するステップとを含み、
    前記ソースコードの変更は、エクストリーム・プログラミング環境で実行され、前記プログラミング支援方法は、前記特定機能ユニットの変更に対する機能検証試験またはサイト検証試験を実行し、さらに前記特定差分コード集合を、前記ソースコードの変更に対応付けられた前記テストケースごとに作成する、プログラミング支援方法。
21. ソースコードの変更を検出する情報処理装置であって、前記情報処理装置は、
    前記ソースコードの新バージョンと旧バージョンとを取得するソースコード読取部と、
    前記新バージョンと前記旧バージョンとの間でコードの相違を比較するソースコード比較部と、
    相違した前記コードを抽出して差分コード集合を生成する差分コード登録部と、
    変更された前記ソースコードの特定機能ユニットに関連する全コードを実行させるため、変更に対応して前記旧バージョン以降に追加されたテストケースを取得して前記テストケースを実行させるソースコード実行部と、
    前記テストケースの実行により実行されたコードを検出し、実行済コード集合に登録するコード実行検査部と、
    前記差分コード集合と前記実行済コード集合の積集合を計算して前記特定機能ユニットに関連して変更されたコードを要素ノードとし、前記ソースコードの変更に対応付けられた前記テストケースごとに作成される特定差分コード集合を生成する特定差分コード抽出部と
    前記新バージョンが登録される以前に追加され、前記特定機能ユニットの前記変更に関連するコードを実行させるテストケースを検索して取得するテストケース取得部とを含み、
    前記コード実行検査部は、前記実行済コード集合の前記要素ノードを実行順に登録する実行トレースを生成し、
    前記実行済コード集合の前記要素ノードは、実行されたコードのコード識別値および実行結果を含み、前記特定差分コード集合は、前記特定機能ユニットの変更に対応するデバッグ結果を提供しており、
    前記ソースコードは、エクストリーム・プログラミング環境で変更され、前記情報処理装置は、前記特定機能ユニットの変更に対する機能検証試験またはサイト検証試験を実行する、情報処理装置。

Images