JP2021082113A - 変更影響解析プログラム、変更影響解析方法および変更影響解析装置 - Google Patents

Abstract

【課題】呼出先プログラムの仕様変更による呼出元プログラムへの影響を適切に判定する変更影響解析プログラム、変更影響解析方法及び変更影響解析装置を提供する。【解決手段】変更影響解析装置１０において、処理部１２は、呼出元プログラムから呼び出される呼出先プログラムで用いられるデータの仕様が変更された場合に、呼出元プログラムと呼出先プログラムとに基づいて、呼出先プログラムから呼出元プログラムへのデータの送信の有無の確度と、呼出元プログラムにおけるデータの受信の必要度とを決定し、決定した確度と必要度との組合せに基づいて、データの仕様の変更による呼出元プログラムに対する影響を判定し、判定した影響を示す情報を出力する。【選択図】図１

Description

本発明は変更影響解析プログラム、変更影響解析方法および変更影響解析装置に関する。

情報処理システムでは複数のプログラムが実行される。情報処理システムでは、複数のプログラムにより実現される複数の機能が互いに連携することがある。例えば、情報処理システムは、あるプログラムから他のプログラムを呼び出し、呼出先の他のプログラムの出力データに基づいて、呼出元のプログラムによる処理を行うことがある。プログラムで用いられるデータの仕様は、プログラムの設計に応じて定められる。あるプログラムが他のプログラムと連携する場合、両プログラムの間で送受信されるデータは、両プログラムで扱われるデータの仕様に適合していることが求められる。

例えば、データテーブルにおける不整合なデータを整合化するためのデータクレンジング装置が提案されている。提案のデータクレンジング装置は、条件付関数従属性ルールリストに基づいて、複数タプルによる違反（Multi-tuple violation）と呼ばれるルール違反があるデータタプルを検出し、ユーザに提示する。

なお、テーブルの変更の内容を含む変更用データセットをトランザクションＩＤ（IDentifier）に関連付けてデータストアに蓄積することで、テーブルの書き換えを行わずに、データベースの内容を変更するデータベースシステムの提案もある。

国際公開第２０１３／０３５６８０号 国際公開第２０１８／２０３３７６号

機能の追加や修正のため、プログラムで用いられるデータの仕様が変更されることがある。データの仕様の変更により、当該プログラムの出力内容も変化し得る。このため、更新されるプログラムが別のプログラムから呼び出されて実行される場合、呼出元のプログラムへの影響の有無が問題となる。

例えば、呼出先のプログラムの変更により、呼出元のプログラムへ応答されていたデータに含まれるデータ項目の識別名が変更されたり、一部のデータ項目が応答されなくなったりすることがある。あるいは、呼出先のプログラムの変更により、呼出元のプログラムから呼出先のプログラムへの提供が任意であったデータ項目の提供が必須になることもある。この場合、情報処理システムでは、呼出元のプログラムと呼出先のプログラムとが適切に連携できなくなる可能性がある。

これに対し、例えば、呼出先のプログラムで呼出元のプログラムに影響を及ぼすと想定される仕様変更が行われる場合には、プログラムの変更を管理する装置により、呼出元のプログラムに対して一律に影響ありと判断してユーザに通知することが考えられる。しかし、例えば呼出元のプログラムでは、識別名が変更されたり応答から削除されたりしたデータ項目がない場合も予め考慮してコーディングされていることもある。また、例えば呼出元のプログラムから呼出先のプログラムへの提供が必須に変更されたデータ項目を通常ケースでは常に提供するように呼出元のプログラムがコーディングされていることもある。こうした場合には、呼出先のプログラムでのデータの仕様変更による呼出元のプログラムへの影響がないと考えられる。このように、呼出先のプログラムでのデータの仕様変更のみに基づき呼出元のプログラムに対して一律に影響ありとすると、本来は影響がないにも関わらず、影響があると誤判断することがある。

１つの側面では、本発明は、呼出先プログラムの仕様変更による呼出元プログラムへの影響を適切に判定できる変更影響解析プログラム、変更影響解析方法および変更影響解析装置を提供することを目的とする。

１つの態様では、変更影響解析プログラムが提供される。この変更影響解析プログラムは、コンピュータに、呼出元プログラムから呼び出される呼出先プログラムで用いられるデータの仕様が変更された場合に、呼出元プログラムと呼出先プログラムとに基づいて、呼出先プログラムから呼出元プログラムへのデータの送信の有無の確度と、呼出元プログラムにおけるデータの受信の必要度とを決定し、確度と必要度との組合せに基づいて、データの仕様の変更による呼出元プログラムに対する影響を判定し、判定した影響を示す情報を出力する、処理を実行させる。

また、１つの態様では、変更影響解析プログラムが提供される。この変更影響解析プログラムは、コンピュータに、呼出元プログラムから呼び出される呼出先プログラムで用いられるデータの仕様が変更された場合に、呼出元プログラムと呼出先プログラムとに基づいて、呼出元プログラムから呼出先プログラムへのデータの送信の有無の確度と、呼出先プログラムにおけるデータの受信の必要度とを決定し、確度と必要度との組合せに基づいて、データの仕様の変更による呼出元プログラムに対する影響を判定し、判定した影響を示す情報を出力する、処理を実行させる。

また、１つの態様では、変更影響解析方法が提供される。
また、１つの態様では、変更影響解析装置が提供される。

１つの側面では、呼出先プログラムの仕様変更による呼出元プログラムへの影響を適切に判定できる。

第１の実施の形態の変更影響解析装置の処理例を示す図である。 第２の実施の形態の変更影響解析装置の処理例を示す図である。 第３の実施の形態の情報処理システムの例を示す図である。 変更影響解析装置のハードウェア例を示す図である。 変更影響解析装置の機能例を示すブロック図である。 データの必須度の定義の例を示す図である。 呼出元側のソースコードの例を示す図である。 呼出先側のソースコードの例を示す図である。 データ授受仕様テーブルの例を示す図である。 辞書データ型仕様テーブルの例を示す図である。 辞書データ型仕様テーブルの例（続き）を示す図である。 生成仕様テーブルの例を示す図である。 受入仕様テーブルの例を示す図である。 データ授受成功度テーブルの例を示す図である。 不要コード可能性テーブルの例を示す図である。 変更影響解析装置の処理例を示すフローチャートである。 機能仕様抽出例を示すフローチャートである。 機能仕様抽出例（続き）を示すフローチャートである。 機能仕様抽出例（続き）を示すフローチャートである。 機能仕様抽出例（続き）を示すフローチャートである。 データ受入仕様の抽出例を示すフローチャートである。 データ生成仕様の抽出例を示すフローチャートである。 削除差分の抽出例を示すフローチャートである。 仕様変換例を示すフローチャートである。 データ授受成功度の演算例を示すフローチャートである。 多値論理値の演算例を示すフローチャートである。 ３値関係の演算の例を示す図である。 呼出元側のソースコードの例を示す図である。 呼出先側のソースコードの例を示す図である。 データ授受成功度テーブルの例を示す図である。 呼出元側のソースコードの例を示す図である。 不要コード可能性テーブルの例を示す図である。 出力画面の例を示す図である。 出力画面の他の例を示す図である。 変更影響の解析結果の例を示す図である。 変更影響の解析結果の比較例を示す図である。

以下、本実施の形態について図面を参照して説明する。
［第１の実施の形態］
第１の実施の形態を説明する。

図１は、第１の実施の形態の変更影響解析装置の処理例を示す図である。
変更影響解析装置１０は、情報処理システム（図示を省略している）で用いられるプログラムの開発を支援する。変更影響解析装置１０はコンピュータにより実現され得る。情報処理システムでは、複数のプログラムが連携する。あるプログラムを開発するユーザと、他のプログラムを開発するユーザとは、同じであることもあるし、異なることもある。複数のプログラムそれぞれは、プログラムを開発するユーザによって改版され得る。

２つのデータを互いに送受信することで連携し得る。このため、あるプログラムの改版に伴うデータの仕様の変更が、当該プログラムの呼出元のプログラムに影響を及ぼすことがある。そこで、変更影響解析装置１０は、当該変更による呼出元のプログラムへの影響を解析する。ここで、呼出元のプログラムから呼び出されるプログラムを呼出先プログラムと称する。呼出元のプログラムを呼出元プログラムと称する。

変更影響解析装置１０は、記憶部１１および処理部１２を有する。記憶部１１は、ＲＡＭ（Random Access Memory）などの揮発性記憶装置でもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性記憶装置でもよい。処理部１２は、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）などを含み得る。処理部１２はプログラムを実行するプロセッサであってもよい。ここでいう「プロセッサ」には、複数のプロセッサの集合（マルチプロセッサ）も含まれ得る。

記憶部１１は、呼出元プログラムと呼出先プログラムとを記憶する。プログラムは、例えば、高水準言語で記述されたソースプログラムである。ソースプログラムは、ソースコードと呼ばれてもよい。

処理部１２は、呼出先プログラムで用いられるデータの仕様が変更された場合に、呼出元プログラムと呼出先プログラムとに基づいて、呼出先プログラムから呼出元プログラムへのデータの送信の有無の確度と、呼出元プログラムにおけるデータの受信の必要度とを決定する。

呼出先プログラムから呼出元プログラムへのデータの送信は、例えば、呼出元プログラムからの要求に対する、呼出先プログラムから呼出元プログラムへの応答に相当する。データの仕様の変更には、例えば、当該データの送信対象からの除去や、当該データを識別するデータ項目名の変更などが挙げられる。ここで、呼出先プログラムおよび呼出元プログラムは、関数やメソッドなどと呼ばれる、ある１つの機能を実現するモジュールでもよい。例えば、ソースコードが記録された１つのソースファイルが、１または複数のモジュールの記述を含み得る。呼出元プログラムと呼出先プログラムとは異なるソースファイルに記録され得る。

例えば、処理部１２は、呼出元プログラムおよび呼出先プログラムそれぞれに対する静的解析を行う。そして、処理部１２は、各プログラムに対する静的解析により、呼出先プログラムから呼出元プログラムへのデータの送信の有無の確度と、呼出元プログラムにおけるデータの受信の必要度とを決定する。

より具体的には、処理部１２は、呼出元プログラムに応答されるデータ項目名へ値を設定するコードが、呼出先プログラムにおける条件分岐文の中に記述されているか否かを判定する。当該コードが、呼出先プログラムにおける条件分岐文の外に記述されている場合、処理部１２は、当該データ項目名に対応するデータを、呼出先プログラムが「必ず送信する」と判定する。データを「必ず送信する」ことを表す送信の確度を、「必ず送信」と表記することがある。あるいは、当該コードが、呼出先プログラムにおける条件分岐文の中に記述されている場合、処理部１２は、当該データ項目名に対応するデータを、呼出先プログラムが「送信することもあるし、送信しないこともある」と判定する。データを「送信することもあるし、送信しないこともある」ことを表す送信の確度を、「両方の場合あり」と表記することがある。

更に、処理部１２は、呼出先プログラムにおいて応答の生成に用いられていないデータ項目名に対応するデータを、呼出先プログラムが「決して送信しない」と判定する。データを「決して送信しない」ことを表す送信の確度を、「不送信」と表記することがある。なお、処理部１２は、改版前の呼出先プログラムで応答の生成に用いられるデータ項目名と改版後の呼出先プログラムで応答の生成に用いられるデータ項目名とを比較して、改版前には送信されていたが改版後には送信されなくなったデータ項目名を特定してもよい。この場合、処理部１２は、改版後に送信されなくなった当該データ項目名に対応するデータを「不送信」とする。

また、例えば、処理部１２は、呼出元プログラムに基づいて、呼出先プログラムから受け付けるデータ項目名に対して値設定の確認なしで値の参照が行われているか否かを判定する。値設定の確認としては、例えば、該当のデータ項目名に設定された値が「ｎｕｌｌ」であるか否かの確認が挙げられる。値設定の確認なしで値の参照が行われている場合、処理部１２は、呼出元プログラムにおいて当該データ項目名に対応するデータの受信の必要度を「必須」であると判定する。あるいは、値設定の確認を行ってから値の参照が行われている場合、処理部１２は、呼出元プログラムにおいて当該データ項目名に対応するデータの受信の必要度を「受信すれば使用」であると判定する。なお、該当のデータ項目名に対して値設定の確認を行ってから値の参照が行われている場合、呼出元プログラムにおいて、当該データ項目名に対する例外処理が既に実行済みであると考えられる。

更に、処理部１２は、例えば、呼出元プログラム内で使用されていないデータ項目名に対応するデータの受信の必要度を「受信しても不使用」であると判定する。
処理部１２は、決定した確度と必要度との組合せに基づいて、呼出先プログラムにおけるデータの仕様の変更による呼出元プログラムに対する影響を判定する。処理部１２は、判定した影響を示す情報を出力する。例えば、処理部１２は、該当のデータに対して、決定した確度と必要度との組合せに応じて、影響の度合いを示す影響度を判定し、当該影響度を出力する。影響度としては、「影響あり」を表す指標値および「影響なし」を表す指標値の他に、「影響ありの可能性あり」というように、「影響あり」と「影響なし」との中間の度合いを表す指標値が含まれる。

影響判定結果１３は、処理部１２による影響度の判定結果の一例を示す。影響判定結果１３は、呼出先プログラムによるデータの送信の確度、および、呼出元プログラムによる当該データの受信の必要度の各組合せに対して、次の判定結果を示す。

例えば、処理部１２は、呼出先プログラムによるデータの送信の確度が「必ず送信」、かつ、呼出元プログラムによる当該データの受信の必要度が「必須」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。

処理部１２は、呼出先プログラムによるデータの送信の確度が「必ず送信」、かつ、呼出元プログラムによる当該データの受信の必要度が「受信すれば使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。

処理部１２は、呼出先プログラムによるデータの送信の確度が「必ず送信」、かつ、呼出元プログラムによる当該データの受信の必要度が「受信しても不使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。

処理部１２は、呼出先プログラムによるデータの送信の確度が「両方の場合あり」、かつ、呼出元プログラムによる当該データの受信の必要度が「必須」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響ありの可能性あり」と判定する。

処理部１２は、呼出先プログラムによるデータの送信の確度が「両方の場合あり」、かつ、呼出元プログラムによる当該データの受信の必要度が「受信すれば使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。

処理部１２は、呼出先プログラムによるデータの送信の確度が「両方の場合あり」、かつ、呼出元プログラムによる当該データの受信の必要度が「受信しても不使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。

処理部１２は、呼出先プログラムによるデータの送信の確度が「不送信」、かつ、呼出元プログラムによる当該データの受信の必要度が「必須」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響あり」と判定する。

処理部１２は、呼出先プログラムによるデータの送信の確度が「不送信」、かつ、呼出元プログラムによる当該データの受信の必要度が「受信すれば使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。

処理部１２は、呼出先プログラムによるデータの送信の確度が「不送信」、かつ、呼出元プログラムによる当該データの受信の必要度が「受信しても不使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。

変更影響解析装置１０によれば、呼出元プログラムから呼び出される呼出先プログラムで用いられるデータの仕様が変更された場合に、呼出元プログラムと呼出先プログラムとに基づいて、呼出先プログラムから呼出元プログラムへのデータの送信の有無の確度と、呼出元プログラムにおけるデータの受信の必要度とが決定される。確度と必要度との組合せに基づいて、データの仕様の変更による呼出元プログラムに対する影響が判定される。判定した影響を示す情報が出力される。

これにより、呼出先プログラムの仕様変更による呼出元プログラムへの影響を適切に判定できる。
ここで、例えば、改版により呼出先プログラムによる応答の一部が削除される場合に、呼出元プログラムに対して一律に影響があると判断し、ユーザに通知することも考えられる。しかし、削除されたデータが呼出元プログラムの処理に必須でなければ、呼出元プログラムへの影響はない。このため、一律に影響があるとしてしまうと、本来は影響がないにも関わらず、影響があると誤判断するという偽陽性の判断を下してしまう可能性がある。偽陽性がユーザに通知されると、ユーザによる余計な確認作業が発生してしまい、プログラム開発の遅延要因になる。

そこで、変更影響解析装置１０では、呼出先プログラムによるデータの送信の確度と呼出元プログラムによるデータの受信の必要度との組合せに基づいて、呼出元プログラムに対する影響を判定することで、当該影響を詳細に判定可能になる。影響判定結果１３の例によれば、データの送信の確度「不送信」に対して、データの受信の必要度「必須」の場合に影響度が「影響あり」、必要度「受信すれば使用」、「受信しても不使用」の場合に影響度が「影響なし」となる。このため、例えば、呼出先プログラムによるデータの送信の確度「不送信」に対して、一律に「影響あり」をユーザに通知するよりも、呼出元プログラムへの影響を適切にユーザに通知できる。

また、処理部１２は、呼出先プログラムに関し、データの送信の確度として、「両方の場合あり」を特定する。更に、処理部１２は、呼出元プログラムへの影響度として、「影響あり」、「影響なし」に加え、これらの中間状態である「影響ありの可能性あり」を判定する。例えば、影響判定結果１３で示されるように、処理部１２は、データの送信の確度「両方の場合あり」に対して、データの受信の必要度「必須」の場合に、「影響ありの可能性あり」と判定する。このように、変更影響解析装置１０は、「影響あり」、「影響なし」の２種類だけでなく、「影響ありの可能性あり」も加えた３種類の影響度を判定することで、呼出元プログラムへの影響を適切にユーザに通知できる。

その結果、ユーザは、呼出先プログラムのデータの仕様変更に対する対応作業を行うべき呼出元プログラムを適切に選択可能になる。また、ユーザは、対応作業の優先順位を判断できるようになる。例えば、ユーザは、変更影響解析装置１０による判定結果を確認することで、影響度「影響あり」および「影響ありの可能性あり」の呼出元プログラムを適切に特定し、対応作業を開始することができる。更に、ユーザは、変更影響解析装置１０による判定結果を確認して、影響度「影響あり」の呼出元プログラムを、「影響ありの可能性あり」のものよりも優先して、作業開始することができる。

［第２の実施の形態］
次に、第２の実施の形態を説明する。
図２は、第２の実施の形態の変更影響解析装置の処理例を示す図である。

変更影響解析装置２０は、情報処理システム（図示を省略している）で用いられるプログラムの開発を支援する。変更影響解析装置２０はコンピュータにより実現され得る。情報処理システムでは、複数のプログラムが連携する。あるプログラムを開発するユーザと、他のプログラムを開発するユーザとは、同じであることもあるし、異なることもある。複数のプログラムそれぞれは、当該プログラムを開発するユーザによって改版され得る。

異なるプログラムがデータを互いに送受信することで連携し得る。このため、あるプログラムの改版に伴うデータの仕様の変更が、当該プログラムを呼び出す呼出元プログラムに影響を及ぼすことがある。そこで、変更影響解析装置２０は、当該変更による呼出元プログラムへの影響を解析する。

変更影響解析装置２０は、記憶部２１および処理部２２を有する。記憶部２１は、ＲＡＭなどの揮発性記憶装置でもよいし、ＨＤＤやフラッシュメモリなどの不揮発性記憶装置でもよい。処理部２２は、ＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどを含み得る。処理部２２はプログラムを実行するプロセッサであってもよい。ここでいう「プロセッサ」には、複数のプロセッサの集合（マルチプロセッサ）も含まれ得る。

記憶部２１は、呼出元プログラムと呼出先プログラムとを記憶する。プログラムは、所定のプログラミング言語で記述されたソースプログラムである。ソースプログラムは、ソースコードと呼ばれてもよい。

処理部２２は、呼出先プログラムで用いられるデータの仕様が変更された場合に、呼出元プログラムと呼出先プログラムとに基づいて、呼出元プログラムから呼出先プログラムへのデータの送信の有無の確度と、呼出先プログラムにおけるデータの受信の必要度とを決定する。

呼出元プログラムから呼出先プログラムへのデータの送信は、例えば、呼出元プログラムから呼出先プログラムへの要求に相当する。データの仕様の変更には、例えば、呼出元プログラムからの当該データの提供が任意であったものを、当該データの提供を必須とする変更などが挙げられる。ここで、呼出先プログラムおよび呼出元プログラムは、関数やメソッドなどと呼ばれる、ある１つの機能を実現するモジュールでもよい。例えば、ソースコードが記録された１つのソースファイルが、複数のモジュールの記述を含み得る。呼出元プログラムと呼出先プログラムとは異なるソースファイルに記録され得る。

例えば、処理部２２は、呼出元プログラムおよび呼出先プログラムそれぞれに対する静的解析を行う。そして、処理部２２は、各プログラムに対する静的解析により、呼出元プログラムから呼出先プログラムへのデータの送信の有無の確度と、呼出先プログラムにおけるデータの受信の必要度とを決定する。

より具体的には、処理部２２は、呼出先プログラムに送信される、仕様変更対象のデータに対応するデータ項目名へ値を設定するコードが、呼出元プログラムにおける条件分岐文の中に記述されているか否かを判定する。当該コードが、呼出元プログラムにおける条件分岐文の外に記述されている場合、処理部２２は、当該データ項目名に対応するデータを、呼出元プログラムが「必ず送信する」と判定する。あるいは、当該コードが、呼出元プログラムにおける条件分岐文の中に記述されている場合、処理部２２は、当該データ項目名に対応するデータを、呼出元プログラムが「送信することもあるし、送信しないこともある」と判定する。

更に、処理部２２は、例えば、仕様変更対象のデータに対応するデータ項目名が呼出元プログラムにおいて要求の生成に用いられていない場合、当該データを呼出元プログラムが「決して送信しない」と判定する。

また、例えば、処理部２２は、呼出先プログラムに基づいて、呼出元プログラムから受け付けるデータ項目名に対して値設定の確認なしで値の参照が行われているか否かを判定する。値設定の確認としては、例えば、該当のデータ項目名に設定された値が「ｎｕｌｌ」であるか否かの確認が挙げられる。値設定の確認なしで値の参照が行われている場合、処理部２２は、呼出先プログラムにおいて当該データ項目名に対応するデータの受信の必要度を「必須」であると判定する。あるいは、値設定の確認を行ってから値の参照が行われている場合、処理部２２は、呼出先プログラムにおいて当該データ項目名に対応するデータの受信の必要度を「受信すれば使用」であると判定する。

また、処理部２２は、例えば、呼出先プログラム内で使用されていないデータ項目名に対応するデータの受信の必要度を「受信しても不使用」であると判定する。
処理部２２は、決定した確度と必要度との組合せに基づいて、呼出先プログラムにおけるデータの仕様の変更による呼出元プログラムに対する影響を判定する。処理部２２は、判定した影響を示す情報を出力する。例えば、処理部２２は、該当のデータに対して、決定した確度と必要度との組合せに応じて、影響の度合いを示す影響度を判定し、当該影響度を出力する。影響度としては、「影響あり」を表す指標値および「影響なし」を表す指標値の他に、「影響ありの可能性あり」というように、「影響あり」と「影響なし」との中間の度合いを表す指標値が含まれる。

影響判定結果２３は、処理部２２による影響度の判定結果の一例を示す。影響判定結果２３は、呼出元プログラムによるデータの送信の確度、および、呼出先プログラムによる当該データの受信の必要度の各組合せに対して、次の判定結果を示す。

例えば、処理部２２は、呼出元プログラムによるデータの送信の確度が「必ず送信」、かつ、呼出先プログラムによる当該データの受信の必要度が「必須」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。

処理部２２は、呼出元プログラムによるデータの送信の確度が「必ず送信」、かつ、呼出先プログラムによる当該データの受信の必要度が「受信すれば使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。

処理部２２は、呼出元プログラムによるデータの送信の確度が「必ず送信」、かつ、呼出先プログラムによる当該データの受信の必要度が「受信しても不使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。

処理部２２は、呼出元プログラムによるデータの送信の確度が「両方の場合あり」、かつ、呼出先プログラムによる当該データの受信の必要度が「必須」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響ありの可能性あり」と判定する。

処理部２２は、呼出元プログラムによるデータの送信の確度が「両方の場合あり」、かつ、呼出先プログラムによる当該データの受信の必要度が「受信すれば使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。

処理部２２は、呼出元プログラムによるデータの送信の確度が「両方の場合あり」、かつ、呼出先プログラムによる当該データの受信の必要度が「受信しても不使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。

処理部２２は、呼出元プログラムによるデータの送信の確度が「不送信」、かつ、呼出先プログラムによる当該データの受信の必要度が「必須」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響あり」と判定する。

処理部２２は、呼出元プログラムによるデータの送信の確度が「不送信」、かつ、呼出先プログラムによる当該データの受信の必要度が「受信すれば使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。

処理部２２は、呼出元プログラムによるデータの送信の確度が「不送信」、かつ、呼出先プログラムによる当該データの受信の必要度が「受信しても不使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。

変更影響解析装置２０によれば、呼出元プログラムから呼び出される呼出先プログラムで用いられるデータの仕様が変更された場合に、呼出元プログラムと呼出先プログラムとに基づいて、呼出元プログラムから呼出先プログラムへのデータの送信の有無の確度と、呼出先プログラムにおけるデータの受信の必要度とが決定される。確度と必要度との組合せに基づいて、データの仕様の変更による呼出元プログラムに対する影響が判定される。判定した影響を示す情報が出力される。

これにより、呼出先プログラムの仕様変更による呼出元プログラムへの影響を適切に判定できる。具体的には、呼出元プログラムによるデータの送信の確度と呼出先プログラムによるデータの受信の必要度との組合せに基づいて、呼出元プログラムに対する影響を判定することで、当該影響を詳細に判定可能になる。

ここで、例えば、呼出先プログラムにおいて、呼出元プログラムから呼出先プログラムへのあるデータ項目の提供が任意から必須に変更された場合に、呼出元プログラムに対して一律に「影響あり」と判断することも考えられる。しかし、呼出元プログラムにおいて、通常ケースでは該当のデータ項目を常に提供するようにコーディングされていることもある。この場合には、当該呼出元プログラムへの影響がないか、あるいは影響が比較的小さい可能性もある。

そこで、処理部２２は、影響判定結果２３の例のように、呼出元プログラムに関し、該当のデータの送信の確度として、「必ず送信」および「不送信」に加えて、「両方の場合あり」を特定する。また、処理部２２は、呼出元からのデータの送信の確度と、呼出先での当該データの受信の必要度との組合せに対し、呼出元プログラムへの影響度として、「影響あり」、「影響なし」に加え、これらの中間状態である「影響ありの可能性あり」を判定する。例えば、処理部２２は、影響判定結果２３の例のように、データの送信の確度「必ず送信」と、データの受信の必要度「必須」に対して、影響度を「影響なし」と判定する。また、例えば、処理部２２は、データの送信の確度「両方の場合あり」と、データの受信の必要度「必須」に対して、影響度を「影響ありの可能性あり」と判定する。このため、例えば、呼出先プログラムによるデータの受信の必要度「必須」に対して、一律に「影響あり」をユーザに通知するよりも、呼出元プログラムへの影響を適切にユーザに通知可能になる。

その結果、ユーザは、呼出先プログラムのデータの仕様変更に対して対応作業を行うべき呼出元プログラムを適切に選択し、また、対応作業の優先順位を判断できるようになる。例えば、ユーザは、変更影響解析装置２０による判定結果を確認することで、影響度「影響あり」および「影響ありの可能性あり」の呼出元プログラムを適切に特定し、対応作業を開始することができる。更に、ユーザは、変更影響解析装置２０による判定結果を確認して、影響度「影響あり」の呼出元プログラムを、「影響ありの可能性あり」のものよりも優先して、作業開始することができる。

以下では、より具体的な情報処理システムを例示して、変更影響解析装置１０，２０に関する機能を更に詳細に説明する。
［第３の実施の形態］
次に、第３の実施の形態を説明する。

図３は、第３の実施の形態の情報処理システムの例を示す図である。
第３の実施の形態の情報処理システムは、変更影響解析装置１００およびリポジトリサーバ２００を有する。変更影響解析装置１００およびリポジトリサーバ２００は、ネットワーク３０に接続されている。ネットワーク３０は、例えばＬＡＮ（Local Area Network）である。ネットワーク３０は、ＷＡＮ（Wide Area Network）やインターネットでもよい。

変更影響解析装置１００は、ユーザによるソフトウェア開発を支援するサーバコンピュータである。変更影響解析装置１００は、あるソースコードの変更による他のソースコードに対する影響を解析し、他のソースコードにおける当該影響を受ける箇所をユーザに通知する。

リポジトリサーバ２００は、ソースコードを記憶する。例えば、リポジトリサーバ２００は、ソースコードＤＢ（DataBase）の機能を有する。ソースコードＤＢは、ソースコードとソースコードの版数とを対応付けて保持する。

リポジトリサーバ２００に記憶されたソースコードは、実行可能な形式に変換されて、図示を省略しているサーバコンピュータにより実行される。あるソースコードに記述された関数やメソッドなどのモジュールにより実現される機能が他の機能と連携して、１または複数のサービスを実現する。複数のソースコードにおける複数の機能が、複数のサーバコンピュータにより分散して実現されることもある。例えば、Ｗｅｂサービスやマイクロサービスなどのように、分散環境で稼働する比較的小規模な複数の機能を結合させたり、連携させたりすることで実現されるサービスもある。

例えば、Ｗｅｂサービスを提供するシステムにおいて、ある機能を呼び出すための規約の一種にＲＥＳＴ ＡＰＩ（REpresentational State Transfer Application Programming Interface）がある。ＲＥＳＴ ＡＰＩは、ＲＥＳＴｆｕｌ ＡＰＩと呼ばれることもある。ＲＥＳＴ ＡＰＩでは、リソースをＵＲＩ（Uniform Resource Identifier）により識別する。ＡＰＩへのアクセスにはＵＲＩが用いられる。ＡＰＩにアクセスするためのＵＲＩはエンドポイントと呼ばれる。リソースに対する操作は、アクションと呼ばれ、ＨＴＴＰ（Hyper Text Transfer Protocol）メソッドにより指定される。ＨＴＴＰメソッドには、読み出しを行うＧＥＴメソッドや書き込みを行うＰＯＳＴメソッドなどがある。

システムを構成する比較的小規模な複数の機能それぞれは、互いに異なるユーザにより開発され得る。このため、当該複数の機能それぞれの開発においてシステム全体としての統制を図ることは容易ではない。これに対し、変更影響解析装置１００は、ある小規模機能が仕様変更されたときに、複数の小規模機能が連携して実現される大規模機能の動作を維持できるように支援する。

機能の仕様変更では、当該機能を呼び出すときの外部仕様が変更され得る。外部仕様とは、呼出元の機能が呼出先の機能に対して呼出時に引き渡すリクエストのデータ構造の仕様や、呼出元の機能が呼出先の機能から応答時に受け取るレスポンスのデータ構造の仕様である。外部仕様の仕様変更は、破壊的変更および非破壊的変更に分類される。

破壊的変更とは、呼出元からの呼出が失敗するようになると一般的に考えられる仕様変更である。破壊的変更には、例えば、ＡＰＩの削除、リクエストからのデータ項目の削除や改名、レスポンスからのデータ項目の削除・改名、リクエストに対するデータ項目への制約追加などが挙げられる。リクエストに対するデータ項目への制約追加には、例えば、当該データ項目の提供を「任意」から「必須」に指定することが挙げられる。

非破壊的変更は、呼出元からの呼出が引き続き成功すると一般的に考えられる仕様変更である。非破壊的変更には、例えば、ＡＰＩの追加、リクエストに対するデータ項目の追加、レスポンスに対するデータ項目の追加、ＡＰＩの利用説明文書の更新などが挙げられる。

例えば、破壊的変更が行われる場合に、一律に呼出元の機能への「影響あり」をユーザに通知する方法が考えられる。しかし、この方法では、機能の呼出元の事情に合わせた変更影響の有無をユーザに提示できず、誤判定が起こり得る。

例えば、レスポンスからデータ項目が削除される破壊的変更であっても、呼出元の機能で当該データ項目を参照していなければ、呼出元の機能に対する当該破壊的変更の影響はない。更に、呼出元の機能において元々必須ではない、あるいは、元々必ず送信されるとは限らない場合、レスポンスのデータ項目が削除されたとしても影響がない場合が多い。当該データ項目がレスポンスに含まれない場合を想定したコードが、呼出元の機能に予め存在しているためである。

そこで、変更影響解析装置１００は、仕様変更された機能の呼出元の機能の事情に合わせて、変更影響を適切に判定可能にする機能を提供する。
図４は、変更影響解析装置のハードウェア例を示す図である。

変更影響解析装置１００は、ＣＰＵ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力信号処理部１０５、媒体リーダ１０６およびＮＩＣ（Network Interface Card）１０７を有する。なお、ＣＰＵ１０１は、第１の実施の形態の処理部１２および第２の実施の形態の処理部２２に対応する。ＲＡＭ１０２またはＨＤＤ１０３は、第１の実施の形態の記憶部１１および第２の実施の形態の記憶部２１に対応する。

ＣＰＵ１０１は、プログラムの命令を実行するプロセッサである。ＣＰＵ１０１は、ＨＤＤ１０３に記憶されたプログラムやデータの少なくとも一部をＲＡＭ１０２にロードし、プログラムを実行する。なお、ＣＰＵ１０１は複数のプロセッサコアを含んでもよい。また、変更影響解析装置１００は複数のプロセッサを有してもよい。以下で説明する処理は複数のプロセッサまたはプロセッサコアを用いて並列に実行されてもよい。また、複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うことがある。

ＲＡＭ１０２は、ＣＰＵ１０１が実行するプログラムやＣＰＵ１０１が演算に用いるデータを一時的に記憶する揮発性の半導体メモリである。なお、変更影響解析装置１００は、ＲＡＭ以外の種類のメモリを備えてもよく、複数個のメモリを備えてもよい。

ＨＤＤ１０３は、ＯＳ（Operating System）やミドルウェアやアプリケーションソフトウェアなどのソフトウェアのプログラム、および、データを記憶する不揮発性の記憶装置である。なお、変更影響解析装置１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の記憶装置を備えてもよく、複数の不揮発性の記憶装置を備えてもよい。

画像信号処理部１０４は、ＣＰＵ１０１からの命令に従って、変更影響解析装置１００に接続されたディスプレイ１１１に画像を出力する。ディスプレイ１１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイ、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）、プラズマディスプレイ、有機ＥＬ（ＯＥＬ：Organic Electro-Luminescence）ディスプレイなど、任意の種類のディスプレイを用いることができる。

入力信号処理部１０５は、変更影響解析装置１００に接続された入力デバイス１１２から入力信号を取得し、ＣＰＵ１０１に出力する。入力デバイス１１２としては、マウス・タッチパネル・タッチパッド・トラックボールなどのポインティングデバイス、キーボード、リモートコントローラ、ボタンスイッチなどを用いることができる。また、変更影響解析装置１００に、複数の種類の入力デバイスが接続されていてもよい。

媒体リーダ１０６は、記録媒体１１３に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体１１３として、例えば、磁気ディスク、光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）、半導体メモリなどを使用できる。磁気ディスクには、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤが含まれる。光ディスクには、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）が含まれる。

媒体リーダ１０６は、例えば、記録媒体１１３から読み取ったプログラムやデータを、ＲＡＭ１０２やＨＤＤ１０３などの他の記録媒体にコピーする。読み取られたプログラムは、例えば、ＣＰＵ１０１によって実行される。なお、記録媒体１１３は可搬型記録媒体であってもよく、プログラムやデータの配布に用いられることがある。また、記録媒体１１３やＨＤＤ１０３を、コンピュータ読み取り可能な記録媒体と言うことがある。

ＮＩＣ１０７は、ネットワーク３０に接続され、ネットワーク３０を介して他のコンピュータと通信を行うインタフェースである。ＮＩＣ１０７は、例えば、スイッチやルータなどの通信装置とケーブルで接続される。

なお、リポジトリサーバ２００も変更影響解析装置１００と同様のハードウェアにより実現される。
図５は、変更影響解析装置の機能例を示すブロック図である。

変更影響解析装置１００は、記憶部１２０、制御部１３０および通信部１４０を有する。記憶部１２０には、ＲＡＭ１０２またはＨＤＤ１０３の記憶領域が用いられる。制御部１３０および通信部１４０は、ＣＰＵ１０１がＲＡＭ１０２に記憶されたプログラムを実行することで実現される。

記憶部１２０は、制御部１３０の処理に用いられる各種のデータを記憶する。記憶部１２０は、データ授受仕様記憶部１２１、変更影響抽出対象記憶部１２２、仕様タプル記憶部１２３および解析結果記憶部１２４を有する。

データ授受仕様記憶部１２１は、データ授受仕様テーブルおよび辞書データ型テーブルを記憶する。データ授受仕様テーブルは、データ授受仕様を表す辞書を、ソースコードに記述された機能ごとに管理するためのテーブルである。ここで、「辞書」は、「キー」および「値」の組をもつデータである。「キー」は、文字列や数値である。「値」は、「キー」で名前付けられた値であり、数値や文字列のようなプリミティブ型の値か、辞書構造の値をもつ。キーで名前付けられた値は、「キー名付き値」と呼ばれることがある。データ授受仕様は、該当の機能におけるデータ構造の受入および生成に関する仕様を示す。辞書データ型テーブルは、上記の辞書に相当し、各機能で扱われるデータ構造の仕様を保持する。

変更影響抽出対象記憶部１２２は、変更影響の抽出対象を示す情報を記憶する。変更影響の抽出対象は、改版された機能の識別子と、改版前の版数と、改版後の版数とによって指定される。変更影響の抽出対象を示す情報は、ユーザにより変更影響解析装置１００に入力される。

仕様タプル記憶部１２３は、生成仕様テーブルおよび受入仕様テーブルを記憶する。生成仕様テーブルは、データの生成に関する機能ごとの仕様を論理値の組合せで表したテーブルである。受入仕様テーブルは、データの受入に関する機能ごとの仕様を論理値の組合せで表したテーブルである。

解析結果記憶部１２４は、データ授受成功度テーブルおよび不要コード可能性テーブルを記憶する。データ授受成功度テーブルは、連携する機能間のデータ授受の成功度を３値の多値論理値により示すテーブルである。成功度は、「常に成功する」、「成功する場合と失敗する場合がある」、「常に失敗する」の３値である。不要コード可能性テーブルは、他の機能を呼び出す機能が実装されたソースコードのうち、今後使用されない箇所が存在するソースコードを示すテーブルである。

制御部１３０は、変更影響解析の処理の全体を制御する。制御部１３０は、機能仕様抽出部１３１、変更影響抽出指示部１３２、削除差分抽出部１３３、仕様変換部１３４、データ授受成功度演算部１３５、不要コード可能性演算部１３６および出力部１３７を有する。

機能仕様抽出部１３１は、リポジトリサーバ２００に記憶された各ソースコードを静的解析することで、データ授受仕様テーブルおよび辞書データ型テーブルを生成し、データ授受仕様記憶部１２１に格納する。ここで、ソースコードに記述された各機能に対して、次の仕様が存在し得る。

第１には、リクエストとして受け入れられるデータ構造の仕様である。リクエストとして受け入れられるデータ構造の仕様は、受入仕様の一種であり、「リクエスト受入仕様」と呼ばれる。

第２には、レスポンスとして生成するデータ構造の仕様である。レスポンスとして生成するデータ構造の仕様は、生成仕様の一種であり、「レスポンス生成仕様」と呼ばれる。
第３には、呼出元の機能が呼出先の機能に対して生成するリクエストのデータ構造の仕様である。呼出元の機能が呼出先の機能に対して生成するリクエストのデータ構造の仕様は、生成仕様の一種であり、「リクエスト生成仕様」と呼ばれる。

第４には、呼出元の機能が呼出先の機能から受け入れるレスポンスのデータ構造の仕様である。呼出元の機能が呼出先の機能から受け入れるレスポンスのデータ構造の仕様は、受入仕様の一種であり、「レスポンス受入仕様」と呼ばれる。

変更影響抽出指示部１３２は、ユーザにより入力された変更影響の抽出対象を示す情報を削除差分抽出部１３３に指示する。
削除差分抽出部１３３は、変更影響抽出指示部１３２から変更影響の抽出対象を示す情報を受け付け、変更影響抽出対象記憶部１２２に格納する。削除差分抽出部１３３は、変更影響の抽出対象である改版前の機能および改版後の機能の削除差分を抽出する。削除差分とは、改版前の機能による応答には存在するが、改版後の機能による応答には存在しないデータや、改版前の機能による要求には存在するが、改版後の機能による要求には存在しないデータである。削除差分抽出部１３３は、抽出した削除差分に関して、データ授受仕様テーブルおよび辞書データ型テーブルそれぞれにレコードを追加する。

仕様変換部１３４は、データ授受仕様記憶部１２１に記憶されたデータ授受仕様テーブルおよび辞書データ型テーブルに基づいて、生成仕様テーブルおよび受入仕様テーブルを生成し、仕様タプル記憶部１２３に格納する。仕様変換部１３４は、データ授受仕様テーブルおよび辞書データ型テーブルで表されるデータ構造の仕様を、論理値の組合せに変換することで、生成仕様テーブルおよび受入仕様テーブルを生成する。

データ授受成功度演算部１３５は、仕様タプル記憶部１２３に記憶された生成仕様テーブルおよび受入仕様テーブルに基づいて、データ授受成功度テーブルを生成し、解析結果記憶部１２４に格納する。データ授受成功度演算部１３５は、生成仕様に対応する論理値の組合せと、受入仕様に対応する論理値の組合せとを用いた論理演算によって、機能間のデータ授受成功度を求める。

不要コード可能性演算部１３６は、仕様タプル記憶部１２３に記憶された生成仕様テーブルおよび受入仕様テーブルに基づいて、不要コード可能性テーブルを生成し、解析結果記憶部１２４に格納する。不要コード可能性演算部１３６は、生成仕様に対応する所定の論理値と受入仕様に対応する所定の論理値とを用いた論理演算により、機能ごとの不要なコード箇所の有無を示す論理値を求める。

出力部１３７は、解析結果記憶部１２４に記憶されたデータ授受成功度テーブルおよび不要コード可能性テーブルに基づいて、変更影響の解析結果を出力する。解析結果は、ソースコードにおいて影響を受ける機能の識別子や不要なコード箇所を含む機能の識別子を含む。出力部１３７は、ディスプレイ１１１に解析結果を表示させてもよいし、通信部１４０に解析結果を出力し、ネットワーク３０などに接続された他のサーバコンピュータに解析結果を送信させてもよい。

通信部１４０は、ネットワーク３０を介して、リポジトリサーバ２００などの他のサーバコンピュータと通信する。通信部１４０は、機能仕様の抽出対象のソースコードとソースコードの版数とをリポジトリサーバ２００から取得し、機能仕様抽出部１３１に提供する。また、通信部１４０は、変更影響の抽出対象を示す情報の入力を受け付け、変更影響抽出指示部１３２に提供する。更に、通信部１４０は、出力部１３７から変更影響の解析結果を取得し、ネットワーク３０を介して他のサーバコンピュータに送信する。

次に、変更影響解析装置１００におけるデータ構造を説明する。まず、データ構造で用いられる必須度の定義について説明する。
図６は、データの必須度の定義の例を示す図である。

図６（Ａ）は、表４１を示す。表４１は、ある機能が他の機能へデータを送信するときの、当該データの送り方に対する必須度を表す。データの送信に関する必須度は、データの送信の確度に相当する。表４１は、値およびデータの送り方に関する意味の項目を含む。値は、必須度の値である。データの送り方に関する意味は、必須度の値の意味である。

例えば、表４１によれば、必須度の値「ｍａｎｄａｔｏｒｙ」は、ある機能から他の機能へ該当のデータを「必ず送出する」ことを示す。また、必須度の値「ｐｏｓｓｉｂｌｅ」は、ある機能から他の機能へ該当のデータを「送出する場合と送出しない場合がある」ことを示す。更に、必須度の値「ｉｍｐｏｓｓｉｂｌｅ」は、「該当のデータは仕様にない」か、あるいは、ある機能から他の機能へ該当のデータを「決して送出しない」ことを示す。

図６（Ｂ）は、表４２を示す。表４２は、ある機能が他の機能からデータを受信するときの、当該データの受け方に対する必須度を表す。データの受信に関する必須度は、データの受信の必要度に相当する。表４２は、値およびデータの受け方に関する意味の項目を含む。値は、必須度の値である。データの受け方に関する意味は、必須度の値の意味である。

例えば、表４２によれば、必須度の値「ｍａｎｄａｔｏｒｙ」は、該当の機能において、該当のデータの「到達が動作に必須である」ことを示す。また、必須度の値「ｐｏｓｓｉｂｌｅ」は、該当の機能において、該当のデータが「到達すれば使う」ことを示す。また、必須度の値「ｕｎａｔｔｅｎｄｅｄ」は、該当の機能において、該当のデータが「到達しても使わない」ことを示す。更に、必須度の値「ｉｍｐｏｓｓｉｂｌｅ」は、該当の機能において、該当のデータが「到達すると動作できない」ことを示す。

次に、具体的なソースコードの例を示す。以下では、高水準言語、すなわち、抽象度の高いプログラミング言語として、ＪＡＶＡ（登録商標）を例示する。また、開発に用いられるＪＡＶＡフレームワークの一例として、スプリング（登録商標）フレームワークを示す。ただし、スプリングフレームワーク以外のＪＡＶＡフレームワークを用いることもできる。また、プログラミング言語として、ＪＡＶＡ以外のプログラミング言語を用いることもできる。

図７は、呼出元側のソースコードの例を示す図である。
ソースコード２０１は、リポジトリサーバ２００に格納される。ソースコード２０１は、呼出元側のソースコードの一例である。ソースコード２０１の版数は「１．０」である。ソースコード２０１は、ＯｒｄｅｒＣｏｎｔｒｏｌｌｅｒクラスの定義を含む。

例えば、ソースコード２０１の３行目における「＠ＧｅｔＭａｐｐｉｎｇ（“／ｏｒｄｅｒ”）」は、ＧＥＴリクエスト用のアノテーションであり、後続のメソッドがエンドポイント「／ｏｒｄｅｒ」の情報を取得するメソッドであることを示す。当該メソッドの名称は「ｇｅｔＯｒｄｅｒ」である。メソッド「ｇｅｔＯｒｄｅｒ」は、エンドポイント「／ｏｒｄｅｒ」の情報の取得結果を応答する。

ソースコード２０１では、１４行目の記述で、ｇｅｔＳｔａｔｕｓメソッドを用いている。ｇｅｔＳｔａｔｕｓメソッドは、ソースコード２０１の１９行目〜２５行目に記述されている。ｇｅｔＳｔａｔｕｓメソッドは、２０行目〜２３行目の記述「ＲｅｓｐｏｎｓｅＥｎｔｉｔｙ＜Ｐｒｏｇｒｅｓｓ＞ ｐ＝…」により、図８のソースコードで示される機能を呼び出す。ｇｅｔＳｔａｔｕｓメソッドは、入力「ｏｒｄｅｒＩｄ」に対して呼出先の機能から取得した「ｓｔａｔｕｓＳｔｒｉｎｇ」を返す。

図８は、呼出先側のソースコードの例を示す図である。
図８（Ａ）は、リポジトリサーバ２００に格納されるソースコード２１１を示す。ソースコード２１１は、改版前（旧版）の呼出先側のソースコードの一例である。ソースコード２１１の版数は、「１．０」である。ソースコード２１１は、ＰｒｏｇｒｅｓｓＣｏｎｔｒｏｌｌｅｒクラスの定義を含む。

例えば、ソースコード２１１の３行目における「＠ＧｅｔＭａｐｐｉｎｇ（“／ｐｒｏｇｒｅｓｓ／｛ｏｒｄｅｒＩｄ｝”）」は、ＧＥＴリクエスト用のアノテーションである。当該アノテーションは、後続のメソッドがエンドポイント「／ｐｒｏｇｒｅｓｓ／｛ｏｒｄｅｒＩｄ｝」の情報を取得するメソッドであることを示す。当該メソッドの名称は「ｇｅｔＰｒｏｇｒｅｓｓ」である。メソッド「ｇｅｔＰｒｏｇｒｅｓｓ」は、エンドポイント「／ｐｒｏｇｒｅｓｓ／｛ｏｒｄｅｒＩｄ｝」の情報の取得結果を応答する。

ここで、ソースコード２１１の４行目のアノテーション「＠ＰａｔｈＶａｒｉａｂｌｅ Ｓｔｒｉｎｇ ｏｒｄｅｒＩＤ」は、エンドポイントの記述に含まれる「｛ｏｒｄｅｒＩｄ｝」をリクエストから取得することを示す。

図８（Ｂ）は、リポジトリサーバ２００に格納されるソースコード２１２を示す。ソースコード２１２は、改版後（新版）の呼出先側のソースコードの一例である。ソースコード２１２の版数は、「２．０」である。ソースコード２１２では、ソースコード２１１の７行目のキー名「ｉｔｅｍＬｏｃａｔｉｏｎ」に関する記述が削除されている。

機能仕様抽出部１３１は、ソースコード２０１，２１１，２１２の静的解析によりデータ授受仕様テーブルを生成する。また、削除差分抽出部１３３は、データ授受仕様テーブルに対して削除差分のレコードを追加する。

図９は、データ授受仕様テーブルの例を示す図である。
データ授受仕様テーブル１５１は、データ授受仕様記憶部１２１に格納される。ここで、図９（Ａ）では、機能仕様抽出部１３１により生成されるレコードを示している。図９（Ｂ）では、削除差分抽出部１３３により生成されるレコードを示している。

データ授受仕様テーブル１５１は、仕様種別、機能の識別子、旧版番号、版番号、呼出先の機能識別子および辞書データ型ＩＤの項目を含む。仕様種別、機能の識別子、旧版番号、版番号および呼出先の機能識別子の組は、データ授受仕様テーブル１５１の主キー（ｐｋ：primary key）である。ただし、辞書データ型ＩＤも主キーの候補であるため、当該組は候補キーとも呼ばれる。

仕様種別の項目には、仕様種別が登録される。仕様種別は、前述のように４種類ある。具体的には、リクエスト受入仕様、レスポンス生成仕様、リクエスト生成仕様およびレスポンス受入仕様である。ここで、リクエスト受入仕様を「ＱＡ」（reQust Acceptance）と表記する。レスポンス生成仕様を「ＰＣ」（resPonse Creation）と表記する。リクエスト生成仕様を「ＱＣ」（reQuest Creation）と表記する。レスポンス受入仕様を「ＰＡ」（resPonse Acceptance）と表記する。

機能の識別子の項目には、機能の識別子が登録される。例えば、機能の識別子は、所定のアノテーションによって示される「ＧＥＴ」や「ＰＵＴ」などのアクションと、エンドポイントとの組合せによって表される。

旧版番号の項目には、該当の機能に対する旧版の番号が登録される。版番号の項目には、該当の機能の現版の番号が登録される。旧版番号の値は「ｎｕｌｌ」に設定されることがある。なお、機能の版番号は、当該機能の記述を含むソースコードの版番号であるとも言える。呼出先の機能識別子の項目には、該当の機能から呼び出される呼出先の機能の識別子が登録される。仕様種別によっては、呼出先の機能識別子が「ｎｕｌｌ」になることがある。辞書データ型ＩＤの項目には、該当の仕様種別、機能の識別子、旧版番号、版番号および呼出先の機能識別子に対する辞書データ型ＩＤが登録される。

例えば、データ授受仕様テーブル１５１には、仕様種別が「ＱＡ」、機能の識別子が「ＧＥＴ ／ｏｒｄｅｒ」、旧版番号が「ｎｕｌｌ」、版番号が「１．０」、呼出先の機能識別子が「ｎｕｌｌ」、辞書データ型ＩＤが「１」というレコードが登録される。このレコードは、仕様種別「ＱＡ」、機能の識別子「ＧＥＴ ／ｏｒｄｅｒ」、版番号「１．０」に対する辞書データ型ＩＤが「１」であることを示す。

ここで、データ授受仕様テーブル１５１において、辞書データ型ＩＤ「１」〜「４」は、ソースコード２０１に対応するレコードである。辞書データ型ＩＤ「５」、「６」は、旧版のソースコード２１１に対応するレコードである。辞書データ型ＩＤ「７」、「８」は、新版のソースコード２１２に対応するレコードである。辞書データ型ＩＤ「９」は、ソースコード２１２においてソースコード２１１から削除された差分に対応するレコードである。

次に、機能仕様抽出部１３１および削除差分抽出部１３３により生成される辞書データ仕様テーブルを説明する。まず、辞書データ仕様テーブルのうち、機能仕様抽出部１３１により生成されるレコード群を説明する。

図１０は、辞書データ型仕様テーブルの例を示す図である。
辞書データ型仕様テーブル１５２は、データ授受仕様記憶部１２１に格納される。辞書データ型仕様テーブル１５２は、辞書データ型ＩＤ、キー名および必須度の項目を含む。辞書データ型ＩＤおよびキー名の組は、辞書データ型仕様テーブル１５２の主キー（ｐｋ）である。

辞書データ型ＩＤの項目には、辞書データ型ＩＤが登録される。キー名の項目には、キー名が登録される。キー名は、データ項目名に相当する。必須度の項目には、当該キー名で表されるデータの必須度が登録される。

機能仕様抽出部１３１は、ソースコード２０１，２１１，２１２の静的解析により、図１０に示す辞書データ型仕様テーブル１５２の各レコードを生成する。
例えば、辞書データ型仕様テーブル１５２には、辞書データ型ＩＤが「１」、キー名が「ｏｒｄｅｒＩｄ」、必須度が「ｍａｎｄａｔｏｒｙ」というレコードが登録される。このレコードは、辞書データ型ＩＤ「１」に対して、キー名「ｏｒｄｅｒＩｄ」の必須度が「ｍａｎｄａｔｏｒｙ」であることを示す。

なお、辞書データ型仕様テーブル１５２におけるキー名「暗黙」のレコードは、該当の機能の該当の仕様種別において存在していないキー名に対する必須度（暗黙必須度と言うことがある）を表すレコードである。

次に、辞書データ型仕様テーブル１５２のうち、削除差分抽出部１３３により生成されるレコード群を説明する。
図１１は、辞書データ型仕様テーブルの例（続き）を示す図である。

削除差分抽出部１３３は、データ授受仕様テーブル１５１および図１０に示される辞書データ型仕様テーブル１５２のレコード群に基づいて、ソースコード２１１，２１２の差分に対して下記のレコードを生成し、辞書データ型仕様テーブル１５２に追加する。前述のように、ソースコード２１２では、ソースコード２１１の７行目の記述が削除されている。このため、削除差分抽出部１３３は、当該７行目の記述に含まれるキー名「ｉｔｅｍＬｏｃａｔｉｏｎ」に関するレコードを生成する。

例えば、辞書データ型仕様テーブル１５２には、辞書データ型ＩＤが「９」、キー名が「ｉｔｅｍＬｏｃａｔｉｏｎ」、必須度が「ｉｍｐｏｓｓｉｂｌｅ」というレコードが登録される。このレコードは、辞書データ型ＩＤ「９」に対して、キー名「ｉｔｅｍＬｏｃａｔｉｏｎ」の必須度が「ｉｍｐｏｓｓｉｂｌｅ」であることを示す。

仕様変換部１３４は、データ授受仕様テーブル１５１および辞書データ型仕様テーブル１５２に基づいて、生成仕様テーブルおよび受入仕様テーブルを生成する。次に、生成仕様テーブルおよび受入仕様テーブルについて説明する。

図１２は、生成仕様テーブルの例を示す図である。
生成仕様テーブル１６１は、仕様タプル記憶部１２３に格納される。生成仕様テーブル１６１には、仕様種別「ＱＣ」および「ＰＣ」の生成仕様を論理値で表したレコード（生成仕様タプルと言うことがある）が登録される。

生成仕様テーブル１６１は、辞書データ型ＩＤ、キー名、ＥａおよびＥｎの項目を含む。辞書データ型ＩＤおよびキー名の組は、生成仕様テーブル１６１の主キー（ｐｋ）である。

辞書データ型ＩＤの項目には、辞書データ型ＩＤが登録される。キー名の項目には、キー名が登録される。Ｅａの項目には、論理変数Ｅａの値が登録される。Ｅｎの項目には、論理変数Ｅｎの値が登録される。

論理変数Ｅａは、該当のキー名のデータを必ず送出するか否かを表す。必ず送出する場合にＥａ＝Ｔｒｕｅ（真）、送出しないこともある場合にＥａ＝Ｆａｌｓｅ（偽）である。

論理変数Ｅｎは、該当のキー名のデータを決して送出しないか否かを表す。決して送出しない場合にＥｎ＝Ｔｒｕｅ、送出することもある場合にＥｎ＝Ｆａｌｓｅである。
なお、論理値「Ｔｒｕｅ」を「Ｔ」、論理値「Ｆａｌｓｅ」を「Ｆ」と略記することがある。

例えば、生成仕様テーブル１６１には、辞書データ型ＩＤが「２」、キー名が「ｏｒｄｅｒＩｄ」、Ｅａが「Ｔ」、Ｅｎが「Ｆ」というレコードが登録される。このレコードは、辞書データ型ＩＤ「２」のキー名「ｏｒｄｅｒＩｄ」の生成仕様がＥａ＝ＴかつＥｎ＝Ｆで表されることを示す。

図１３は、受入仕様テーブルの例を示す図である。
受入仕様テーブル１６２は、仕様タプル記憶部１２３に格納される。受入仕様テーブル１６２には、仕様種別「ＱＡ」および「ＰＡ」の受入仕様を論理値で表したレコード（受入仕様タプルと言うことがある）が登録される。

受入仕様テーブル１６２は、辞書データ型ＩＤ、キー名、Ｓｒ、ＳｕおよびＡの項目を含む。辞書データ型ＩＤおよびキー名の組は、受入仕様テーブル１６２の主キー（ｐｋ）である。

辞書データ型ＩＤの項目には、辞書データ型ＩＤが登録される。キー名の項目には、キー名が登録される。Ｓｒの項目には、論理変数Ｓｒの値が登録される。Ｓｕの項目には、論理変数Ｓｕの値が登録される。Ａの項目には、論理変数Ａの値が登録される。

論理変数Ｓｒは、該当のキー名のデータが到達した場合に動作可能であるか否かを表す。到達した場合に動作可能である場合にＳｒ＝Ｔであり、到達した場合に動作可能でない場合にＳｒ＝Ｆである。

論理変数Ｓｕは、該当のキー名のデータが到達しなかった場合に動作可能であるか否かを表す。到達しなかった場合に動作可能である場合にＳｕ＝Ｔであり、到達しなかった場合に動作可能でない場合にＳｕ＝Ｆである。

論理変数Ａは、受け付けた該当のキー名のデータを利用するか否かを表す。利用する場合にＡ＝Ｔであり、利用しない場合にＡ＝Ｆである。
例えば、受入仕様テーブル１６２には、辞書データ型ＩＤが「１」、キー名が「ｏｒｄｅｒＩｄ」、Ｓｒが「Ｔ」、Ｓｕが「Ｆ」、Ａが「Ｔ」というレコードが登録される。このレコードは、辞書データ型ＩＤ「１」のキー名「ｏｒｄｅｒＩｄ」の受入仕様がＳｒ＝Ｔ、Ｓｕ＝ＦかつＡ＝Ｔで表されることを示す。

データ授受成功度演算部１３５は、生成仕様テーブル１６１および受入仕様テーブル１６２に基づいて、データ授受成功度テーブルを生成する。
図１４は、データ授受成功度テーブルの例を示す図である。

データ授受成功度テーブル１７１は、解析結果記憶部１２４に格納される。データ授受成功度テーブル１７１は、機能の識別子、版番号、呼出先の機能識別子、呼出先の旧版番号、呼出先の版番号、キー名、種別およびデータ授受成功度の項目を含む。機能の識別子、版番号、呼出先の機能識別子、呼出先の旧版番号、呼出先の版番号、キー名および種別の組は、データ授受成功度テーブル１７１の主キー（ｐｋ）である。

機能の識別子の項目には、呼出元側のソースコードにおける機能の識別子が登録される。版番号の項目には、呼出元側のソースコードの版番号が登録される。呼出先の機能識別子の項目には、呼出先側のソースコードにおける機能の識別子が登録される。呼出先の旧版番号の項目には、呼出先側のソースコードの改版前の版番号が登録される。呼出先の版番号の項目には、呼出先側のソースコードの改版後の版番号が登録される。キー名の項目には、キー名が登録される。種別の項目には、「リクエスト」であるか「レスポンス」であるかの種別が登録される。データ授受成功度の項目には、データ授受成功度を表す論理値が登録される。データ授受成功度は、３値の多値論理値で表される。データ授受成功度は、必ず成功することを「Ｔ」、成功することもあるし失敗することもあることを「Ｈ」、必ず失敗することを「Ｆ」で表す。データ授受成功度「Ｈ」は、データ授受成功度「Ｔ」および「Ｆ」の中間の状態を示す。

例えば、データ授受成功度テーブル１７１には、機能の識別子が「ＧＥＴ ／ｏｒｄｅｒ」、版番号が「１．０」、呼出先の機能識別子が「ＧＥＴ ／ｐｒｏｇｒｅｓｓ」、呼出先の旧版番号が「１．０」、呼出先の版番号が「２．０」、キー名が「ｏｒｄｅｒＩｄ」、種別が「リクエスト」、データ授受成功度が「Ｔ」というレコードが登録される。このレコードは、呼出元の機能識別子「ＧＥＴ ／ｏｒｄｅｒ」、版番号「１．０」、呼出先の機能識別子「ＧＥＴ ／ｐｒｏｇｒｅｓｓ」、呼出先の旧版番号「１．０」、呼出先の版番号「２．０」、キー名「ｏｒｄｅｒＩｄ」、種別「リクエスト」に対して、データ授受成功度が「Ｔ」、すなわち、必ず成功であることを示す。

ここで、データ授受成功度は、呼出先のソースコードの改版による呼出元のソースコード、あるいは、呼出元のソースコードに対応する機能への影響の度合い、すなわち、影響度を表すと言える。

例えば、データ授受成功度が「Ｆ」のとき、呼出先のソースコードの改版によって呼出元の機能が必ず影響を受けることを意味する。また、種別「レスポンス」に対してデータ授受成功度が「Ｈ」のとき、呼出先のソースコードの改版によって呼出元の機能が影響を受ける可能性があることを意味する。更に、種別「レスポンス」に対してデータ授受成功度が「Ｔ」のとき、呼出先のソースコードの改版によって呼出元の機能が影響を受けないことを意味する。

不要コード可能性演算部１３６は、生成仕様テーブル１６１および受入仕様テーブル１６２に基づいて、不要コード可能性テーブルを生成する。
図１５は、不要コード可能性テーブルの例を示す図である。

不要コード可能性テーブル１７２は、解析結果記憶部１２４に格納される。不要コード可能性テーブル１７２は、機能の識別子、版番号、呼出先の機能識別子、呼出先の旧版番号、呼出先の版番号、キー名、対象コードおよび不要コード可能性の項目を含む。機能の識別子、版番号、呼出先の機能識別子、呼出先の旧版番号、呼出先の版番号、キー名および対象コードの組は、不要コード可能性テーブル１７２の主キー（ｐｋ）である。

機能の識別子の項目には、呼出元側のソースコードにおける機能の識別子が登録される。版番号の項目には、呼出元型のソースコードの版番号が登録される。呼出先の機能識別子の項目には、呼出先側のソースコードにおける機能の識別子が登録される。呼出先の旧版番号の項目には、呼出先側のソースコードの改版前の版番号が登録される。呼出先の版番号の項目には、呼出先側のソースコードの改版後の版番号が登録される。キー名の項目には、キー名が登録される。対象コードの項目には、不要コードが存在する可能性のあるソースコードが呼出先側であるか呼出元側であるかの区分が登録される。不要コード可能性の項目には、不要コードが存在する可能性の有無を表す論理値が登録される。不要コードが存在する可能性がある場合、不要コード可能性は「Ｔ」である。不要コードが存在する可能性がない場合、不要コード可能性は「Ｆ」である。

例えば、不要コード可能性テーブル１７２には、機能の識別子が「ＧＥＴ ／ｏｒｄｅｒ」、版番号が「１．０」、呼出先の機能識別子が「ＧＥＴ ／ｐｒｏｇｒｅｓｓ」、呼出先の旧版番号「１．０」、呼出先の版番号が「２．０」、キー名が「ｏｒｄｅｒＩｄ」、対象コードが「呼出先」、不要コード可能性が「Ｆ」というレコードが登録される。このレコードは、呼出元の機能識別子「ＧＥＴ ／ｏｒｄｅｒ」、版番号「１．０」、呼出先の機能識別子「ＧＥＴ ／ｐｒｏｇｒｅｓｓ」、呼出先の旧版番号「１．０」、呼出先の版番号「２．０」、キー名「ｏｒｄｅｒＩｄ」、対象コード「呼出先」に対して、不要コード可能性が「Ｆ」、すなわち、呼出先側のソースコードに不要コードが存在する可能性がないことを示す。

また、不要コード可能性テーブル１７２には、機能の識別子「ＧＥＴ ／ｏｒｄｅｒ」のキー名「ｓｔａｔｕｓＳｔｒｉｎｇ」について、呼出元側のソースコードに不要コードが存在する可能性がないことを示すレコードも登録されている。更に、不要コード可能性テーブル１７２には、機能の識別子「ＧＥＴ ／ｏｒｄｅｒ」のキー名「ｉｔｅｍＬｏｃａｔｉｏｎ」について、呼出元側のソースコードに不要コードが存在する可能性がないことを示すレコードも登録されている。

次に、変更影響解析装置１００の処理手順を説明する。
図１６は、変更影響解析装置の処理例を示すフローチャートである。
（Ｓ１０）制御部１３０は、対象のソースコードに関して、各ＲＥＳＴ ＡＰＩに対してステップＳ１１〜Ｓ１３を繰り返し実行する。ここで、ＲＥＳＴ ＡＰＩ、すなわち、当該ソースコードに実装される機能は、アクションａおよびエンドポイントｅの組により識別される。処理対象とするＲＥＳＴ ＡＰＩの識別情報は、ユーザにより入力されてもよいし、リポジトリサーバ２００に記憶された各ソースコードから、制御部１３０により抽出されてもよい。

（Ｓ１１）制御部１３０は、リポジトリサーバ２００上の各ソースコードのうち、対象ＲＥＳＴ ＡＰＩを実装する各版番号ｖのメソッドｍに対して、ステップＳ１２を繰り返し実行する。

（Ｓ１２）制御部１３０は、機能仕様抽出を実行する。機能仕様抽出の詳細は後述される。なお、機能仕様抽出のための引数は、ＲＥＳＴ ＡＰＩのアクションａ、ＲＥＳＴ ＡＰＩのエンドポイントｅ、ＲＥＳＴ ＡＰＩを実装するメソッドｍおよびリポジトリサーバ２００におけるソースコードの版番号ｖである。

（Ｓ１３）制御部１３０は、全ての（ｖ，ｍ）の組に対して、ステップＳ１２を実行すると、繰り返しを終了し、ステップＳ１４に処理を進める。
（Ｓ１４）制御部１３０は、全ての（ａ，ｅ）の組に対して、ステップＳ１１〜Ｓ１３を実行すると、繰り返しを終了し、ステップＳ１５に処理を進める。

（Ｓ１５）制御部１３０は、変更影響抽出の指示を受け付けたか否かを判定する。変更影響抽出の指示を受け付けた場合、制御部１３０は、ステップＳ１６に処理を進める。変更影響抽出の指示を受け付けていない場合、制御部１３０は、ステップＳ１５に処理を進め、変更影響抽出の指示を待ち受ける。例えば、変更影響抽出の指示は、ユーザにより、変更影響解析装置１００に入力される。変更影響抽出の指示は、変更影響の抽出対象とする機能の識別子、改版対象のソースコードの改版前の版数、および、改版対象のソースコードの改版後の版数の指定を含む。

（Ｓ１６）制御部１３０は、削除差分抽出を実行する。削除差分抽出の詳細は後述される。
（Ｓ１７）制御部１３０は、仕様変換を実行する。仕様変換の詳細は後述される。

（Ｓ１８）制御部１３０は、データ授受成功度の演算を実行する。データ授受成功度の演算の詳細は後述される。
（Ｓ１９）制御部１３０は、データ処理コードの不要可能性の演算を実行する。データ処理コードの不要可能性の演算の詳細は後述される。

制御部１３０は、ステップＳ１８，Ｓ１９の実行結果に基づいて、解析結果を出力する。例えば、出力部１３７は、ディスプレイ１１１に解析結果を表示させることもできるし、通信部１４０を介して、ネットワーク３０に接続された他のコンピュータに解析結果を送信させてもよい。

なお、ステップＳ１０〜Ｓ１４における機能仕様抽出は、任意のタイミングで実行され得る。例えば、リポジトリサーバ２００に新たなソースコードが格納された場合に、制御部１３０は、リポジトリサーバ２００から新たなソースコードが格納された旨の通知を受け付けてもよい。そして、制御部１３０は、当該通知を契機にして、新たなソースコードをリポジトリサーバ２００から取得し、当該ソースコードに対して、ステップＳ１０〜Ｓ１４を実行してもよい。

図１７は、機能仕様抽出例を示すフローチャートである。
機能仕様抽出はステップＳ１２に相当する。
（Ｓ２０）機能仕様抽出部１３１は、新たな辞書データ型ＩＤを生成する。新たな辞書データ型ＩＤをｉｄとする。

（Ｓ２１）機能仕様抽出部１３１は、データ授受仕様のうちのリクエスト受入仕様のレコードを作成し、データ授受仕様テーブル１５１に登録する。当該レコードは、仕様種別「ＱＡ」、機能の識別子「ａ＋ｅ」、版番号「ｖ」、辞書データ型ＩＤ「ｉｄ」である。それ以外の項目は「ｎｕｌｌ」である。ここで、「ａ＋ｅ」は、アクションの文字列とエンドポイントの文字列とを結合した文字列を意味する。

（Ｓ２２）機能仕様抽出部１３１は、暗黙必須度の辞書データ型仕様のレコードを作成し、辞書データ型仕様テーブル１５２に登録する。当該レコードは、辞書データ型ＩＤ「ｉｄ」、キー名「（暗黙）」、必須度「ｕｎａｔｔｅｎｄｅｄ」である。

（Ｓ２３）機能仕様抽出部１３１は、該当のＲＥＳＴ ＡＰＩに入力される各パラメタに対してステップＳ２４，Ｓ２５を繰り返し実行する。処理対象のパラメタをｐとする。
（Ｓ２４）機能仕様抽出部１３１は、パラメタｐに対する辞書データ型仕様のレコードｓ１を作成し、辞書データ型仕様テーブル１５２に登録する。レコードｓ１は、辞書データ型ＩＤ「ｉｄ」、キー名「（パラメタｐの名前）」である。この段階では、レコードｓ１の必須度は未登録である。

（Ｓ２５）機能仕様抽出部１３１は、データ受入仕様の抽出を行う。データ受入仕様の抽出の詳細は後述される。データ受入仕様の抽出のための引数は、メソッドｍ上のパラメタｐに対応する引数、メソッドｍおよび辞書データ型仕様のレコードｓ１である。

（Ｓ２６）機能仕様抽出部１３１は、該当のＲＥＳＴ ＡＰＩに入力される全てのパラメタｐに対してステップＳ２４，Ｓ２５を実行すると、繰り返しを終了し、ステップＳ２７に処理を進める。

図１８は、機能仕様抽出例（続き）を示すフローチャートである。
（Ｓ２７）機能仕様抽出部１３１は、新たな辞書データ型ＩＤを生成する。新たな辞書データ型ＩＤをｉｄ２とする。

（Ｓ２８）機能仕様抽出部１３１は、データ授受仕様のうちのレスポンス生成仕様のレコードを作成し、データ授受仕様テーブル１５１に登録する。当該レコードは、仕様種別「ＰＣ」、機能の識別子「ａ＋ｅ」、版番号「ｖ」、辞書データ型ＩＤ「ｉｄ２」である。それ以外の項目は「ｎｕｌｌ」である。

（Ｓ２９）機能仕様抽出部１３１は、暗黙必須度の辞書データ型仕様のレコードを作成し、辞書データ型仕様テーブル１５２に登録する。当該レコードは、辞書データ型ＩＤ「ｉｄ２」、キー名「（暗黙）」、必須度「ｉｍｐｏｓｓｉｂｌｅ」である。

（Ｓ３０）機能仕様抽出部１３１は、該当のＲＥＳＴ ＡＰＩのレスポンスデータの各キー付き値に対してステップＳ３１，Ｓ３２を繰り返し実行する。処理対象のキー名付き値をｋｖ２とする。図７のソースコード２０１の例では、１０行目の「ｏ．ｏｒｄｅｒＩｄ」の「ｏｒｄｅｒＩｄ」、１１行目の「ｏ．ｉｔｅｍＮａｍｅ」の「ｉｔｅｍＮａｍｅ」および１４行目の「ｏ．ｓｔａｔｕｓ」の「ｓｔａｔｕｓ」のそれぞれが、ｋｖ２の一例である。

（Ｓ３１）機能仕様抽出部１３１は、キー名付き値ｋｖ２に対する辞書データ型仕様のレコードｓ２を作成し、辞書データ型仕様テーブル１５２に登録する。レコードｓ２は、辞書データ型ＩＤ「ｉｄ２」、キー名「（ｋｖ２のキー名）」である。この段階では、レコードｓ２の必須度は未登録である。

（Ｓ３２）機能仕様抽出部１３１は、データ生成仕様の抽出を行う。データ生成仕様の抽出の詳細は後述される。データ生成仕様の抽出のための引数は、対象のキー名付き値ｋｖ３、メソッドｍおよび辞書データ型仕様のレコードｓ２である。

（Ｓ３３）機能仕様抽出部１３１は、該当のＲＥＳＴ ＡＰＩのレスポンスデータの全てのキー名付き値ｋｖ２に対してステップＳ３１，Ｓ３２を実行すると、繰り返しを終了し、ステップＳ３４に処理を進める。

図１９は、機能仕様抽出例（続き）を示すフローチャートである。
（Ｓ３４）機能仕様抽出部１３１は、メソッドｍ中で呼び出す各ＲＥＳＴ ＡＰＩに対して、ステップＳ３５〜Ｓ４８を繰り返し実行する。当該ＲＥＳＴ ＡＰＩは、メソッドｍから呼び出される呼出先の機能である。呼出先のＲＥＳＴ ＡＰＩは、アクションａ２およびエンドポイントｅ２の組により識別される。

（Ｓ３５）機能仕様抽出部１３１は、新たな辞書データ型ＩＤを生成する。新たな辞書データ型ＩＤをｉｄ３とする。
（Ｓ３６）機能仕様抽出部１３１は、データ授受仕様のうちのリクエスト生成仕様のレコードを作成し、データ授受仕様テーブル１５１に登録する。当該レコードは、仕様種別「ＱＣ」、機能の識別子「ａ＋ｅ」、版番号「ｖ」、呼出先の機能識別子「ａ２＋ｅ２」、辞書データ型ＩＤ「ｉｄ３」である。それ以外の項目は「ｎｕｌｌ」である。

（Ｓ３７）機能仕様抽出部１３１は、暗黙必須度の辞書データ型仕様のレコードを作成し、辞書データ型仕様テーブル１５２に登録する。当該レコードは、辞書データ型ＩＤ「ｉｄ３」、キー名「（暗黙）」、必須度「ｉｍｐｏｓｓｉｂｌｅ」である。

（Ｓ３８）機能仕様抽出部１３１は、該当の呼出元のＲＥＳＴ ＡＰＩのリクエストデータの各キー付き値に対してステップＳ３９，Ｓ４０を繰り返し実行する。処理対象のキー名付き値をｋｖ３とする。

（Ｓ３９）機能仕様抽出部１３１は、キー名付き値ｋｖ３に対する辞書データ型仕様のレコードｓ３を作成し、辞書データ型仕様テーブル１５２に登録する。レコードｓ３は、辞書データ型ＩＤ「ｉｄ３」、キー名「（ｋｖ３のキー名）」である。この段階では、レコードｓ３の必須度は未登録である。

（Ｓ４０）機能仕様抽出部１３１は、データ生成仕様の抽出を行う。データ生成仕様の抽出の詳細は後述される。データ生成仕様の抽出のための引数は、対象のキー名付き値ｋｖ３、メソッドｍおよび辞書データ型仕様のレコードｓ３である。

（Ｓ４１）機能仕様抽出部１３１は、該当の呼出元のＲＥＳＴ ＡＰＩのリクエストデータの全てのキー名付き値ｋｖ３に対してステップＳ３９，Ｓ４０を実行すると、繰り返しを終了し、ステップＳ４２に処理を進める。

図２０は、機能仕様抽出例（続き）を示すフローチャートである。
（Ｓ４２）機能仕様抽出部１３１は、新たな辞書データ型ＩＤを生成する。新たな辞書データ型ＩＤをｉｄ４とする。

（Ｓ４３）機能仕様抽出部１３１は、データ授受仕様のうちのレスポンス受入仕様のレコードを作成し、データ授受仕様テーブル１５１に登録する。当該レコードは、仕様種別「ＰＡ」、機能の識別子「ａ＋ｅ」、版番号「ｖ」、呼出先の機能識別子「ａ２＋ｅ２」、辞書データ型ＩＤ「ｉｄ４」である。それ以外の項目は「ｎｕｌｌ」である。

（Ｓ４４）機能仕様抽出部１３１は、暗黙必須度の辞書データ型仕様のレコードを作成し、辞書データ型仕様テーブル１５２に登録する。当該レコードは、辞書データ型ＩＤ「ｉｄ４」、キー名「（暗黙）」、必須度「ｕｎａｔｔｅｎｄｅｄ」である。

（Ｓ４５）機能仕様抽出部１３１は、呼出元のＲＥＳＴ ＡＰＩにおいて、レスポンスデータを格納する変数をｒとする。図７のソースコード２０１の例では、２０行目の変数「ｐ」がｒの一例である。

（Ｓ４６）機能仕様抽出部１３１は、変数ｒの各キー名付き値に対してステップＳ４７，Ｓ４８を繰り返し実行する。処理対象のキー名付き値をｋｖ４とする。図７のソースコード２０１の例では２４行目の「ｓｔａｔｕｓＳｔｒｉｎｇ」がｋｖ４の一例である。

（Ｓ４７）機能仕様抽出部１３１は、キー名付き値ｋｖ４に対する辞書データ型仕様のレコードｓ４を作成し、辞書データ型仕様テーブル１５２に登録する。レコードｓ４は、辞書データ型ＩＤ「ｉｄ４」、キー名「（ｋｖ４のキー名）」である。この段階では、レコードｓ４の必須度は未登録である。

（Ｓ４８）機能仕様抽出部１３１は、データ受入仕様の抽出を行う。データ受入仕様の抽出の詳細は後述される。データ受入仕様の抽出のための引数は、対象のキー名付き値ｋｖ４、メソッドｍおよび辞書データ型仕様のレコードｓ４である。

（Ｓ４９）機能仕様抽出部１３１は、変数ｒの全てのキー名付き値ｋｖ４に対してステップＳ４７，Ｓ４８を実行すると、繰り返しを終了し、ステップＳ５０に処理を進める。
（Ｓ５０）機能仕様抽出部１３１は、メソッドｍ中で呼び出す呼出先の各ＲＥＳＴ ＡＰＩに対してステップＳ３５〜Ｓ４８を実行すると、繰り返しを終了し、機能仕様抽出を終了する。

図２１は、データ受入仕様の抽出例を示すフローチャートである。
データ受入仕様の抽出はステップＳ２５，Ｓ４８に相当する。
（Ｓ６０）機能仕様抽出部１３１は、メソッドｍ中での対象変数の参照前に、値設定確認があるか否かを判定する。対象変数の参照前に値設定確認がない場合、機能仕様抽出部１３１は、ステップＳ６１に処理を進める。対象変数の参照前に値設定確認がある場合、機能仕様抽出部１３１は、ステップＳ６２に処理を進める。例えば、値設定確認とは、対象変数に対する「ｎｕｌｌ」か否かの確認などを意味する。例えば、メソッドｍにおいて、当該値設定確認に応じて、対象変数の参照が行われるか否かが決定される場合に、値設定確認があることになる。値設定確認後に対象変数の参照が行われている例として、図７のソースコード２０１の１２行目〜１３行目の変数「ｗｉｔｈＳｔａｔｕｓ」の記述が挙げられる。

（Ｓ６１）機能仕様抽出部１３１は、辞書データ型仕様のレコードｓの必須度に「ｍａｎｄａｔｏｒｙ」を設定する。ここで、ステップＳ２５ではｓ＝ｓ１であり、ステップＳ４８ではｓ＝ｓ４である。そして、機能仕様抽出部１３１は、データ受入仕様の抽出を終了する。

（Ｓ６２）機能仕様抽出部１３１は、辞書データ型仕様のレコードｓの必須度に「ｐｏｓｓｉｂｌｅ」を設定する。ここで、ステップＳ２５ではレコードｓ＝ｓ１であり、ステップＳ４８ではレコードｓ＝ｓ４である。そして、機能仕様抽出部１３１は、データ受入仕様の抽出を終了する。

図２２は、データ生成仕様の抽出例を示すフローチャートである。
データ生成仕様の抽出はステップＳ３２，Ｓ４０に相当する。
（Ｓ７０）機能仕様抽出部１３１は、メソッドｍ内の条件分岐中でキー名ｋｖの値を設定しているか否かを判定する。ここで、条件分岐中とは、例えば、ｉｆ文におけるｔｈｅｎ節の内部やｅｌｓｅ節の内部である。条件分岐中でｋｖの値を設定していない場合、機能仕様抽出部１３１は、ステップＳ７１に処理を進める。条件分岐中でｋｖの値を設定している場合、機能仕様抽出部１３１は、ステップＳ７２に処理を進める。ここで、ステップＳ３２ではキー名ｋｖ＝ｋｖ２であり、ステップＳ４０ではキー名ｋｖ＝ｋｖ３である。条件分岐中でｋｖの値を設定している例としては、図７のソースコード２０１の１３行目〜１４行目の「ｓｔａｔｕｓ」に関する記述が挙げられる。

（Ｓ７１）機能仕様抽出部１３１は、辞書データ型仕様のレコードｓの必須度に「ｍａｎｄａｔｏｒｙ」を設定する。ここで、ステップＳ３２ではレコードｓ＝ｓ２であり、ステップＳ４０ではレコードｓ＝ｓ３である。そして、機能仕様抽出部１３１は、データ生成仕様の抽出を終了する。

（Ｓ７２）機能仕様抽出部１３１は、辞書データ型仕様のレコードｓの必須度に「ｐｏｓｓｉｂｌｅ」を設定する。ここで、ステップＳ３２ではレコードｓ＝ｓ２であり、ステップＳ４０ではレコードｓ＝ｓ３である。そして、機能仕様抽出部１３１は、データ生成仕様の抽出を終了する。

図２３は、削除差分の抽出例を示すフローチャートである。
削除差分の抽出はステップＳ１６に相当する。削除差分抽出部１３３には、引数として機能の識別子ａｅ、新版番号ｎおよび旧版番号ｏが渡される。

（Ｓ８０）削除差分抽出部１３３は、データ授受仕様テーブル１５１の各仕様種別に対して下記の処理を繰り返し実行する。仕様種別の候補は、ＱＡ、ＰＣ、ＱＣ、ＰＡである。処理対象の仕様種別をｋとする。

（Ｓ８１）削除差分抽出部１３３は、データ授受仕様テーブル１５１に基づいて、仕様種別ｋ、機能の識別子ａｅ、版番号ｏに対応するデータ授受仕様のレコードｓがあるか否かを判定する。当該データ授受仕様のレコードｓがある場合、削除差分抽出部１３３は、ステップＳ８２に処理を進める。当該データ授受仕様のレコードｓがない場合、削除差分抽出部１３３は、ステップＳ８６に処理を進める。

ここで、「データ授受仕様のレコードｓ」を、図中、「データ授受仕様ｓ」のように略記することがある。
（Ｓ８２）削除差分抽出部１３３は、レコードｓの辞書データ型ＩＤをｉｄｏとする。

（Ｓ８３）削除差分抽出部１３３は、機能の識別子ａｅ、版番号ｎに対応するデータ授受仕様のレコードｓｎがあるか否かを判定する。当該データ授受仕様のレコードｓｎがある場合、削除差分抽出部１３３は、ステップＳ８７に処理を進める。当該データ授受仕様のレコードｓｎがない場合、削除差分抽出部１３３は、ステップＳ８４に処理を進める。

（Ｓ８４）削除差分抽出部１３３は、データ授受仕様のレコードｓｎ２を作成し、データ授受仕様テーブル１５１に登録する。当該レコードｓｎ２は、仕様種別「ｋ」、旧版番号「ｏ」、版番号「ｎ」、辞書データ型ＩＤ「ｉｄｎ２」である。削除差分抽出部１３３は、辞書データ型ＩＤ「ｉｄｎ２」を新規に付与する。レコードｓｎ２のその他の各ｐｋの項目は「（レコードｓの同名の項目の値）」である。レコードｓｎ２のそれ以外の項目は「ｎｕｌｌ」となる。

（Ｓ８５）削除差分抽出部１３３は、暗黙必須度の辞書データ型仕様のレコードを作成し、辞書データ型仕様テーブル１５２に登録する。当該レコードは、辞書データ型ＩＤ「ｉｄｎ２」、キー名「（暗黙）」、必須度「ｉｍｐｏｓｓｉｂｌｅ」である。

（Ｓ８６）削除差分抽出部１３３は、全ての仕様種別ｋに対してステップＳ８１〜Ｓ８５、あるいは、場合によってはＳ８１〜Ｓ８３，Ｓ８７〜Ｓ９４を実行すると、繰り返しを終了し、削除差分の抽出を終了する。

（Ｓ８７）削除差分抽出部１３３は、データ授受仕様のレコードｓｎの辞書データ型ＩＤをｉｄｎとする。
（Ｓ８８）削除差分抽出部１３３は、辞書データ型ＩＤがｉｄｏである辞書データ型仕様の各キー名に対してステップＳ８９〜Ｓ９３を繰り返し実行する。処理対象のキー名をｋｖｏとする。

（Ｓ８９）削除差分抽出部１３３は、辞書データ型仕様テーブル１５２に基づいて、キー名ｋｖｏとキー名が同一で辞書データ型ＩＤがｉｄｎである辞書データ型仕様のレコードがあるか否かを判定する。当該辞書データ型仕様のレコードがない場合、削除差分抽出部１３３は、ステップＳ９０に処理を進める。当該辞書データ型仕様のレコードがある場合、削除差分抽出部１３３は、ステップＳ９４に処理を進める。

（Ｓ９０）削除差分抽出部１３３は、データ授受仕様テーブル１５１において、データ授受仕様のレコードｓｎ２を作成済みであるか否かを判定する。データ授受仕様のレコードｓｎ２を作成済みでない場合、削除差分抽出部１３３は、ステップＳ９１に処理を進める。データ授受仕様のレコードｓｎ２を作成済みの場合、削除差分抽出部１３３は、ステップＳ９３に処理を進める。

（Ｓ９１）削除差分抽出部１３３は、データ授受仕様のレコードｓｎ２を作成し、データ授受仕様テーブル１５１に登録する。当該レコードｓｎ２は、仕様種別「ｋ」、旧版番号「ｏ」、版番号「ｎ」、辞書データ型ＩＤ「ｉｄｎ２」である。削除差分抽出部１３３は、辞書データ型ＩＤ「ｉｄｎ２」を新規に付与する。レコードｓｎ２のその他の各ｐｋの項目は「（レコードｓの同名の項目の値）」である。レコードｓｎ２のそれ以外の項目は「ｎｕｌｌ」となる。

（Ｓ９２）削除差分抽出部１３３は、暗黙必須度の辞書データ型仕様のレコードを作成し、辞書データ型仕様テーブル１５２に登録する。当該レコードは、辞書データ型ＩＤ「ｉｄｎ２」、キー名「（暗黙）」、必須度「（データ授受仕様のレコードｓの辞書データ型ＩＤに対応するキー名「暗黙」の必須度）」である。

（Ｓ９３）削除差分抽出部１３３は、辞書データ型仕様のレコードを作成し、辞書データ型仕様テーブル１５２に登録する。当該レコードは、辞書データ型ＩＤ「ｉｄｎ２」、キー名「（ｋｖｏのキー名）」、必須度「ｉｍｐｏｓｓｉｂｌｅ」である。

（Ｓ９４）削除差分抽出部１３３は、全てのｋｖｏに対してステップＳ８９〜Ｓ９３を実行すると、繰り返しを終了し、ステップＳ８６に処理を進める。
図２４は、仕様変換例を示すフローチャートである。

仕様変換はステップＳ１７に相当する。
（Ｓ１００）仕様変換部１３４は、データ授受仕様の各仕様に対して、ステップＳ１０１〜Ｓ１１８を繰り返し実行する。データ授受仕様の各仕様は、データ授受仕様テーブル１５１の各レコードを意味する。処理対象のレコードをｓ０とする。レコードｓ０において、仕様種別はｋ、機能の識別子はａ＋ｅ、旧版番号はｏ、版番号はｖ、呼出先の機能識別子はｄであるとする。

（Ｓ１０１）仕様変換部１３４は、対象仕様のレコードｓ０における辞書データ型ＩＤをｉｄとする。
（Ｓ１０２）仕様変換部１３４は、辞書データ型ＩＤがｉｄである、辞書データ型仕様の各仕様に対して下記の処理を繰り返し実行する。辞書データ型仕様の各仕様は、辞書データ型仕様テーブル１５２の各レコードを意味する。辞書データ型仕様テーブル１５２の処理対象のレコードをｓとする。

（Ｓ１０３）仕様変換部１３４は、レコードｓ０の仕様種別ｋが「ＱＣ」または「ＰＣ」、すなわち、生成仕様であるか否かを判定する。レコードｓ０の仕様種別ｋが「ＱＣ」または「ＰＣ」である場合、仕様変換部１３４は、ステップＳ１０４に処理を進める。レコードｓ０の仕様種別ｋが「ＱＣ」および「ＰＣ」の何れでもない場合、仕様変換部１３４は、ステップＳ１１０に処理を進める。

（Ｓ１０４）仕様変換部１３４は、Ｅａ＝Ｆ、Ｅｎ＝Ｆに設定する。なお、Ｅａ＝Ｆなどに設定することを、図中では「Ｅａ：＝Ｆ」のように表記する。
（Ｓ１０５）仕様変換部１３４は、レコードｓの必須度がｍａｎｄａｔｏｒｙであるか否かを判定する。レコードｓの必須度がｍａｎｄａｔｏｒｙである場合、仕様変換部１３４は、ステップＳ１０６に処理を進める。レコードｓの必須度がｍａｎｄａｔｏｒｙでない場合、仕様変換部１３４は、ステップＳ１０７に処理を進める。

（Ｓ１０６）仕様変換部１３４は、Ｅａ＝Ｔに設定する。そして、仕様変換部１３４は、ステップＳ１０９に処理を進める。
（Ｓ１０７）仕様変換部１３４は、レコードｓの必須度がｉｍｐｏｓｓｉｂｌｅであるか否かを判定する。レコードｓの必須度がｉｍｐｏｓｓｉｂｌｅである場合、仕様変換部１３４は、ステップＳ１０８に処理を進める。レコードｓの必須度がｉｍｐｏｓｓｉｂｌｅでない場合、仕様変換部１３４は、ステップＳ１０９に処理を進める。

（Ｓ１０８）仕様変換部１３４は、Ｅｎ＝Ｔに設定する。
（Ｓ１０９）仕様変換部１３４は、辞書データ型ＩＤ「ｉｄ」およびレコードｓのキー名に対する生成仕様タプルを生成し、生成仕様テーブル１６１に登録する。生成仕様タプルのＥａ，Ｅｎの値は、ステップＳ１０４〜Ｓ１０８で設定された値となる。そして、仕様変換部１３４は、ステップＳ１１８に処理を進める。

（Ｓ１１０）仕様変換部１３４は、Ｓｒ＝Ｔ、Ｓｕ＝Ｔ、Ａ＝Ｔに設定する。
（Ｓ１１１）仕様変換部１３４は、レコードｓの必須度がｍａｎｄａｔｏｒｙであるか否かを判定する。レコードｓの必須度がｍａｎｄａｔｏｒｙである場合、仕様変換部１３４は、ステップＳ１１２に処理を進める。レコードｓの必須度がｍａｎｄａｔｏｒｙでない場合、仕様変換部１３４は、ステップＳ１１３に処理を進める。

（Ｓ１１２）仕様変換部１３４は、Ｓｕ＝Ｆに設定する。そして、仕様変換部１３４は、ステップＳ１１７に処理を進める。
（Ｓ１１３）仕様変換部１３４は、レコードｓの必須度がｉｍｐｏｓｓｉｂｌｅであるか否かを判定する。レコードｓの必須度がｉｍｐｏｓｓｉｂｌｅである場合、仕様変換部１３４は、ステップＳ１１４に処理を進める。レコードｓの必須度がｉｍｐｏｓｓｉｂｌｅでない場合、仕様変換部１３４は、ステップＳ１１５に処理を進める。

（Ｓ１１４）仕様変換部１３４は、Ｓｒ＝Ｆ、Ａ＝Ｆに設定する。そして、仕様変換部１３４は、ステップＳ１１７に処理を進める。
（Ｓ１１５）仕様変換部１３４は、レコードｓの必須度がｕｎａｔｔｅｎｄｅｄであるか否かを判定する。レコードｓの必須度がｕｎａｔｔｅｎｄｅｄである場合、仕様変換部１３４は、ステップＳ１１６に処理を進める。レコードｓの必須度がｕｎａｔｔｅｎｄｅｄでない場合、仕様変換部１３４は、ステップＳ１１７に処理を進める。

（Ｓ１１６）仕様変換部１３４は、Ａ＝Ｆに設定する。
（Ｓ１１７）仕様変換部１３４は、辞書データ型ＩＤ「ｉｄ」およびレコードｓのキー名に対する受入仕様タプルを生成し、受入仕様テーブル１６２に登録する。受入仕様タプルのＳｒ，Ｓｕ，Ａの値は、ステップＳ１１０〜Ｓ１１６で設定された値となる。

（Ｓ１１８）仕様変換部１３４は、辞書データ型仕様テーブル１５２における辞書データ型ＩＤ「ｉｄ」の全てのレコードｓに対してステップＳ１０３以降の処理を実行すると、繰り返しを終了して、ステップＳ１１９に処理を進める。

（Ｓ１１９）仕様変換部１３４は、データ授受仕様テーブル１５１における全てのレコードｓ０に対してステップＳ１０１以降の処理を実行すると、繰り返しを終了して、仕様変換を終了する。

図２５は、データ授受成功度の演算例を示すフローチャートである。
データ授受成功度の演算はステップＳ１８に相当する。データ授受成功度演算部１３５には、引数として、呼出元の機能識別子ｃ、呼出元の版番号ｖ、呼出先の機能識別子ｅ、呼出先の新版番号ｎおよび旧版番号ｏが渡される。

（Ｓ１２０）データ授受成功度演算部１３５は、リクエスト送信側の辞書データ型ＩＤをｓとし、ｓｄを「ｎｕｌｌ」に設定する。具体的には、データ授受成功度演算部１３５は、データ授受仕様テーブル１５１において、仕様種別ＱＣ、機能の識別子ｃ、版番号ｖ、呼出先の機能識別子ｅに対応する辞書データ型ＩＤをｓとする。

（Ｓ１２１）データ授受成功度演算部１３５は、リクエスト受信側の辞書データ型ＩＤをｒとし、ｒｄを設定する。具体的には、データ授受成功度演算部１３５は、データ授受仕様テーブル１５１において、仕様種別ＱＡ、機能の識別子ｅ、版番号ｎのレコードのうち、旧版番号「ｎｕｌｌ」に対する辞書データ型ＩＤをｒとし、旧版番号ｏに対する辞書データ型ＩＤをｒｄとする。

（Ｓ１２２）データ授受成功度演算部１３５は、多値論理値の演算を行う。多値論理値の演算の詳細は後述される。ステップＳ１２２の多値論理値の演算のための引数は、演算対象、ステップＳ１２０，Ｓ１２１のｓ，ｓｄ，ｒ，ｒｄ、呼出元の機能識別子ｃと版番号ｖ、呼出先の機能識別子ｅと新版番号ｎと旧版番号ｏ、および、種別「リクエスト」である。演算対象としては、「データ授受成功度」または「データ処理コードの不要可能性」が指定される。ステップＳ１８では、演算対象として、「データ授受成功度」が指定される。

（Ｓ１２３）データ授受成功度演算部１３５は、レスポンス送信側の辞書データ型ＩＤをｓとし、ｓｄを設定する。具体的には、データ授受成功度演算部１３５は、データ授受仕様テーブル１５１において、仕様種別ＰＣ、機能の識別子ｅ、版番号ｎのレコードのうち、旧版番号「ｎｕｌｌ」に対する辞書データ型ＩＤをｓとし、旧版番号ｏに対する辞書データ型ＩＤをｓｄとする。

（Ｓ１２４）データ授受成功度演算部１３５は、レスポンス受信側の辞書データ型ＩＤをｒとし、ｒｄを「ｎｕｌｌ」に設定する。具体的には、データ授受成功度演算部１３５は、データ授受仕様テーブル１５１において、仕様種別ＰＡ、機能の識別子ｃ、版番号ｖ、呼出先の機能識別子ｅのレコードの辞書データ型ＩＤをｒとする。

（Ｓ１２５）データ授受成功度演算部１３５は、多値論理値の演算を行う。多値論理値の演算の詳細は後述される。ステップＳ１２５の多値論理値の演算のための引数は、演算対象を示す情報、ステップＳ１２３，Ｓ１２４のｓ，ｓｄ，ｒ，ｒｄ、呼出元の機能識別子ｃと版番号ｖ、呼出先の機能識別子ｅと新版番号ｎと旧版番号ｏ、および、種別「リクエスト」である。演算対象を示す情報としては、「データ授受成功度」または「データ処理コードの不要可能性」が指定される。ステップＳ１８では、演算対象として、「データ授受成功度」が指定される。そして、データ授受成功度演算部１３５は、データ授受成功度の演算を終了する。

なお、ステップＳ１９の「データ処理コードの不要可能性の演算」も図２５で例示した「データ授受成功度の演算」と同様の手順により実行される。ただし、ステップＳ１９は、不要コード可能性演算部１３６により実行される。このため、「データ処理コードの不要可能性の演算」の場合は、ステップＳ１２０〜Ｓ１２５の「データ授受成功度演算部１３５」を、「不要コード可能性演算部１３６」と読み替えればよい。更に、ステップＳ１９の場合、ステップＳ１２２，Ｓ１２５の演算対象を示す引数に「データ処理コードの不要可能性」が指定される。

図２６は、多値論理値の演算例を示すフローチャートである。
多値論理値の演算はステップＳ１２２，Ｓ１２５に相当する。多値論理値の演算の引数は、演算対象、送受信されるデータの辞書データ型（ｓ，ｓｄ，ｒ，ｒｄ）、呼出元の機能識別子ｃと版番号ｖ、呼出先の機能識別子ｅと新版番号ｎと旧版番号ｏ、および、種別ｔである。なお、多値論理値の演算では、演算対象の引数として「データ授受成功度」または「データ処理コードの不要可能性」が指定される。以下では、演算対象が「データ授受成功度」の場合（ステップＳ１８）のデータ授受成功度演算部１３５の処理を例示するが、演算対象が「データ処理コードの不要可能性」の場合（ステップＳ１９）の不要コード可能性演算部１３６の処理も同様の手順となる。ただし、図２６の各ステップのうち、ステップＳ１４０についてはデータ授受成功度演算部１３５のみが行う手順であり、ステップＳ１４１〜Ｓ１４４については不要コード可能性演算部１３６のみが行う手順である。

（Ｓ１３０）データ授受成功度演算部１３５は、送信側キー名の集合ｋｓを設定する。集合ｋｓは、生成仕様テーブル１６１のうち、辞書データ型ＩＤがｓまたはｓｄであって、キー名が「（暗黙）」ではない生成仕様タプルのキー名の集合である。

（Ｓ１３１）データ授受成功度演算部１３５は、受信側キー名の集合ｋｒを設定する。集合ｋｒは、受入仕様テーブル１６２のうち、辞書データ型ＩＤがｒまたはｒｄであって、キー名が「（暗黙）」ではない受入仕様タプルのキー名の集合である。

（Ｓ１３２）データ授受成功度演算部１３５は、和集合ｋｓ∪ｋｒの各要素ｋに対して下記の処理を繰り返し実行する。
（Ｓ１３３）データ授受成功度演算部１３５は、生成仕様テーブル１６１に基づいて、辞書データ型ＩＤ＝ｓ、キー名ｋの生成仕様タプルｔｃがあるか否かを判定する。当該生成仕様タプルｔｃがない場合、データ授受成功度演算部１３５は、ステップＳ１３４に処理を進める。当該生成仕様タプルｔｃがある場合、データ授受成功度演算部１３５は、ステップＳ１３６に処理を進める。

（Ｓ１３４）データ授受成功度演算部１３５は、生成仕様テーブル１６１に基づいて、辞書データ型ＩＤ＝ｓｄ、キー名ｋの生成仕様タプルｔｃがあるか否かを判定する。当該生成仕様タプルｔｃがない場合、データ授受成功度演算部１３５は、ステップＳ１３５に処理を進める。当該生成仕様タプルｔｃがある場合、データ授受成功度演算部１３５は、ステップＳ１３６に処理を進める。

（Ｓ１３５）データ授受成功度演算部１３５は、生成仕様テーブル１６１のうち、辞書データ型ＩＤ＝ｓｄ、キー名「（暗黙）」の生成仕様タプルをｔｃとする。
（Ｓ１３６）データ授受成功度演算部１３５は、受入仕様テーブル１６２に基づいて、辞書データ型ＩＤ＝ｒ、キー名ｋの受入仕様タプルｔａがあるか否かを判定する。当該受入仕様タプルｔａがない場合、データ授受成功度演算部１３５は、ステップＳ１３７に処理を進める。当該受入仕様タプルｔａがある場合、データ授受成功度演算部１３５は、ステップＳ１３９に処理を進める。

（Ｓ１３７）データ授受成功度演算部１３５は、受入仕様テーブル１６２に基づいて、辞書データ型ＩＤ＝ｒｄ、キー名ｋの受入仕様タプルｔａがあるか否かを判定する。当該受入仕様タプルｔａがある場合、データ授受成功度演算部１３５は、ステップＳ１３９に処理を進める。当該受入仕様タプルｔａがない場合、データ授受成功度演算部１３５は、ステップＳ１３８に処理を進める。

（Ｓ１３８）データ授受成功度演算部１３５は、受入仕様テーブル１６２のうち、辞書データ型ＩＤ＝ｒｄ、キー名「（暗黙）」の受入仕様タプルをｔａとする。
（Ｓ１３９）データ授受成功度演算部１３５は、演算対象がデータ授受成功度であるか否かを判定する。演算対象がデータ授受成功度である場合、ステップＳ１４０に処理が進む。演算対象がデータ授受成功度ではない場合、ステップＳ１４１に処理が進む。演算対象がデータ授受成功度ではない場合、演算対象は、データ処理コードの不要可能性である。

（Ｓ１４０）データ授受成功度演算部１３５は、呼出先が機能ｅ、新旧版ｎ，ｏのときの機能ｃ、版ｖ、種別ｔのデータ授受成功度Ｓを計算し、データ授受成功度テーブル１７１に格納する。データ授受成功度Ｓは、生成仕様タプルｔｃのＥａ，Ｅｎ、および、受入仕様タプルｔａのＳｒ，Ｓｕ，Ａに対して、次の式（１）により計算される。

Ｓ＝（（Ｓｕ∧¬Ｅｎ）∨（Ｓｒ∧¬Ｅａ））∧（Ｈ∨（（Ｓｕ∨Ｅａ）∧（Ｓｒ∨Ｅｎ））） ・・・（１）
そして、データ授受成功度演算部１３５は、ステップＳ１４５に処理を進める。

（Ｓ１４１）不要コード可能性演算部１３６は、種別ｔ＝リクエストであるか否かを判定する。種別ｔ＝リクエストである場合、不要コード可能性演算部１３６は、ステップＳ１４２に処理を進める。種別ｔ＝リクエストでない場合、不要コード可能性演算部１３６は、ステップＳ１４３に処理を進める。

（Ｓ１４２）不要コード可能性演算部１３６は、対象コードｇ＝呼出先に設定する。そして、ステップＳ１４４に処理を進める。
（Ｓ１４３）不要コード可能性演算部１３６は、対象コードｇ＝呼出元に設定する。

（Ｓ１４４）不要コード可能性演算部１３６は、呼出先が機能ｅ、新旧版ｎ，ｏのときの機能ｃ、版ｖでの対象コードｇの不要コード可能性Ｕを計算し、不要コード可能性テーブル１７２に格納する。不要コード可能性Ｕは、生成仕様タプルｔｃのＥｎ、および、受入仕様タプルｔａのＡに対して、次の式（２）により計算される。

Ｕ＝Ａ∧Ｅｎ ・・・（２）
そして、不要コード可能性演算部１３６は、ステップＳ１４５に処理を進める。
（Ｓ１４５）データ授受成功度演算部１３５は、和集合ｋｓ∪ｋｒの全ての要素ｋに対してデータ授受成功度Ｓまたは不要コード可能性Ｕを計算すると、繰り返しを終了し、多値論理値の演算を終了する。

図２７は、３値関係の演算の例を示す図である。
表５１は、論理変数Ａ，Ｂに対する３値関係（Kleeneの３値論理）の演算の例を示す。論理変数Ａ，Ｂは、それぞれＦ，Ｔ，Ｈの３つ値の何れかを取り得る。Ｆは、失敗（Failure）を表す。Ｔは、成功（Success）を表す。Ｈは、失敗の場合も成功の場合もあること（Both occur）を表す。

ここで、Ｔを数値［Ｔ］＝１とする。Ｈを数値［Ｈ］＝１／２とする。Ｆを数値［Ｆ］＝０とする。すると、論理変数Ａ，Ｂに対する論理演算を次のように数式化できる。
［¬Ａ］＝１−［Ａ］
［Ａ∧Ｂ］＝ｍｉｎ（［Ａ］，［Ｂ］）
［Ａ∨Ｂ］＝ｍａｘ（［Ａ］，［Ｂ］）
［Ａ→Ｂ］＝［¬Ａ∨Ｂ］
［Ａ＝Ｂ］＝［Ａ←→Ｂ］＝［（Ａ→Ｂ）∧（Ｂ→Ａ）］
表５１は、論理変数Ａの値および論理変数Ｂの値の組に対する論理演算Ａ→Ｂ、Ａ∧Ｂ、Ａ∨Ｂ、¬Ａの結果を示す。

第２の実施の形態の例によれば、変更影響解析装置１００により、リポジトリサーバ２００に格納されているソースコード２０１，２１１，２１２に対して、機能仕様抽出が行われる。機能仕様抽出の結果、データ授受仕様テーブル１５１および辞書データ型仕様テーブル１５２が生成される。

ユーザは、機能「ＧＥＴ ／ｐｒｏｇｒｅｓｓ」を旧版番号「１．０」から版番号「２．０」へ変更したときの影響を確認するため、機能の識別子「ＧＥＴ ／ｐｒｏｇｒｅｓｓ」、旧版番号「１．０」、版番号「２．０」を変更影響解析装置１００に入力する。すると、変更影響解析装置１００は、当該入力に応じて、データ授受成功度テーブル１７１および不要コード可能性テーブル１７２を生成し、機能「ＧＥＴ ／ｐｒｏｇｒｅｓｓ」に関するデータ授受成功度および不要コード可能性をユーザに通知する。

ソースコード２１１，２１２の例では、新版の「ＧＥＴ ／ｐｒｏｇｒｅｓｓ」において、レスポンスからキー名「ｉｔｅｍＬｏｃａｔｉｏｎ」のデータが削除されている。
ここで、呼出先の機能による応答の一部が削除される場合に、呼出元の機能に対して一律に影響があると判断し、ユーザに通知することも考えられる。しかし、削除されたデータが呼出元の処理に必須でなければ、呼出元の機能への影響はない。このため、一律に影響があるとしてしまうと、本来は影響がないにも関わらず、影響があると誤判断するという偽陽性の判断を下してしまう可能性がある。偽陽性がユーザに通知されると、ユーザによる余計な確認作業が発生してしまい、プログラム開発の遅延要因になる。

そこで、変更影響解析装置１００では、呼出先の機能によるデータの送信の確度と呼出元の機能によるデータの受信の必要度との組合せに基づいて、呼出元の機能に対する影響を判定することで、当該影響を詳細に判定可能になる。データ授受成功度テーブル１７１の例によれば、呼出先の機能「ＧＥＴ ／ｐｒｏｇｒｅｓｓ」から呼出元の機能「ＧＥＴ ／ｏｒｄｅｒ」にキー名「ｉｔｅｍＬｏｃａｔｉｏｎ」のデータが応答されなくなるが、データ授受成功度は「Ｔ」（必ず成功）である。これは、呼出元の機能「ＧＥＴ ／ｏｒｄｅｒ」において、キー名「ｉｔｅｍＬｏｃａｔｉｏｎ」のデータが必須ではないためである。このように、キー名「ｉｔｅｍＬｏｃａｔｉｏｎ」のデータが応答から削除されても、呼出元の機能「ＧＥＴ ／ｏｒｄｅｒ」は影響を受けないことが適切に判断される。

これにより、呼出先の機能による応答の一部が削除される場合に、呼出元の機能に対して一律に「影響あり」をユーザに通知するよりも、呼出元の機能への影響を適切にユーザに通知できる。また、偽陽性がユーザに通知されることを抑制することで、ユーザによる余計な確認作業を削減でき、プログラム開発の期間の短縮に寄与する。

次に、他のソースコードを例示して、変更影響解析装置１００による解析結果の他の例を説明する。まず、データ授受成功度が「Ｈ」と評価される例を示す。
図２８は、呼出元側のソースコードの例を示す図である。

ソースコード２０２は、リポジトリサーバ２００に格納される。ソースコード２０２は、呼出元側のソースコードの一例である。ソースコード２０２の版数は「１．０」である。ソースコード２０２は、ＯｒｄｅｒＣｏｎｔｒｏｌｌｅｒクラスの定義を含む。

例えば、ソースコード２０２の１１行目〜１２行目によれば、機能呼出時に呼出元から呼出先に送られるパラメタ「ｉｎＳｔｏｃｋ」の設定がｉｆ文内に記述されている。すなわち、パラメタ「ｉｎＳｔｏｃｋ」は、呼出元において条件付きで設定される。すなわち、「ｉｎＳｔｏｃｋ」は、呼出元の機能から呼出先の機能へ送信される場合もあるし、送信されない場合もある。

図２９は、呼出先側のソースコードの例を示す図である。
図２９（Ａ）は、リポジトリサーバ２００に格納されるソースコード２２１を示す。ソースコード２２１は、改版前（旧版）の呼出先側のソースコードの一例である。ソースコード２２１の版数は、「１．０」である。ソースコード２２１は、ＩｔｅｍＣｏｎｔｒｏｌｌｅｒクラスの定義を含む。

例えば、ソースコード２２１の６行目では、リクエストによるパラメタ「ｉｎＳｔｏｃｋ」の受け付けは任意（「ｒｅｑｕｉｒｅｄ＝ｆａｌｓｅ」）であり、必須ではない。
図２９（Ｂ）は、リポジトリサーバ２００に格納されるソースコード２２２を示す。ソースコード２２２は、改版後（新版）の呼出先側のソースコードの一例である。ソースコード２２２の版数は、「２．０」である。ソースコード２２２の６行目によれば、パラメタ「ｉｎＳｔｏｃｋ」の受け付けは、任意から必須（「ｒｅｑｕｉｒｅｄ＝ｔｒｕｅ」）に変更されている。

次に、ソースコード２０２，２２１，２２２に対するデータ授受成功度テーブルを例示する。
図３０は、データ授受成功度テーブルの例を示す図である。

変更影響解析装置１００は、ソースコード２０２，２２１，２２２に対して、データ授受成功度テーブル１７３を生成し、解析結果記憶部１２４に格納する。
ソースコード２２２の改版による変更影響を確認するために、ユーザが機能「ＧＥＴ ／ｉｔｅｍ」、旧版番号「１．０」、新版番号「２．０」を変更影響解析装置１００に入力すると、データ授受成功度テーブル１７３が生成される。機能「ＧＥＴ ／ｉｔｅｍ」の呼出元は、ソースコード２０１における機能「ＰＵＴ ／ｏｒｄｅｒ」である。データ授受成功度テーブル１７３によれば、ソースコード２２２におけるパラメタ「ｉｎＳｔｏｃｋ」の必須パラメタへの変更に対して、「ＰＵＴ ／ｏｒｄｅｒ」からのリクエストのデータ授受成功度が「Ｈ」と判断されている。データ授受成功度「Ｈ」は、「成功する場合も失敗する場合も両方ある」ことを示し、また、呼出元の機能に「影響がある可能性がある」ことを示す。

ここで、呼出時のパラメタ「ｉｎＳｔｏｃｋ」が必須パラメタに変更されることは、破壊的変更として呼出元に「影響あり」と判断することも考えられる。一方、パラメタ「ｉｎＳｔｏｃｋ」は呼出元により条件付きで設定しており、通常ケースでは呼出元において常に設定される可能性がある。呼出元でパラメタ「ｉｎＳｔｏｃｋ」が常に設定される場合、呼出先で「ｉｎＳｔｏｃｋ」が必須パラメタに変更されても影響はない。すなわち、呼出元の機能「ＰＵＴ ／ｏｒｄｅｒ」の設計や実装の状況によっては、変更影響への対応作業の優先度を落とせる可能性がある。そこで、変更影響解析装置１００は、呼出元の機能「ＰＵＴ ／ｏｒｄｅｒ」に対するデータ授受成功度を「Ｈ」と評価することで、この可能性をユーザに通知することができる。

例えば、ユーザは、影響の「可能性がある」箇所か、影響が「必ずある」箇所かの違いにより、作業の優先度を決めることができる。このため、呼出側の機能の仕様変更に対する早期暫定対応が行えるという利点もある。

次に、不要コード可能性が「Ｔ」と評価される例を示す。
図３１は、呼出元側のソースコードの例を示す図である。
ソースコード２０３は、リポジトリサーバ２００に格納される。ソースコード２０３は、呼出元側のソースコードの一例である。ソースコード２０３の版数は「１．０」である。ソースコード２０３は、ＯｒｄｅｒＣｏｎｔｒｏｌｌｅｒクラスの定義を含む。

ソースコード２０３に対する呼出先側のソースコードは、ソースコード２１１，２１２であるとする。
ソースコード２０３は、機能「ＤＥＬＥＴＥ ／ｏｒｄｅｒ」の記述を含む。機能「ＤＥＬＥＴＥ ／ｏｒｄｅｒ」は、ソースコード２１１，２１２における機能「ＧＥＴ ／ｐｒｏｇｒｅｓｓ」を呼び出す。ソースコード２０３の１０行目〜１２行目には、呼出先からのレスポンスにおける「ｉｔｅｍＬｏｃａｔｉｏｎ」に基づく処理が記述されている。

一方、ソースコード２１２では、前述のように、ソースコード２１１と比べて、「ＧＥＴ ／ｐｒｏｇｒｅｓｓ」のレスポンスから「ｉｔｅｍＬｏｃａｔｉｏｎ」が削除されている。

図３２は、不要コード可能性テーブルの例を示す図である。
変更影響解析装置１００は、ソースコード２０３，２１１，２１２に対して、不要コード可能性テーブル１７４を生成し、解析結果記憶部１２４に格納する。

ソースコード２１２の改版による変更影響を確認するために、ユーザが機能「ＧＥＴ ／ｐｒｏｇｒｅｓｓ」、旧版番号「１．０」、新版番号「２．０」を変更影響解析装置１００に入力すると、不要コード可能性テーブル１７４が生成される。機能「ＧＥＴ ／ｐｒｏｇｒｅｓｓ」の呼出元は、ソースコード２０３における機能「ＤＥＬＥＴＥ ／ｏｒｄｅｒ」である。不要コード可能性テーブル１７４によれば、ソースコード２１２におけるレスポンスからの「ｉｔｅｍＬｏｃａｔｉｏｎ」の削除に対して、「ＤＥＬＥＴＥ ／ｏｒｄｅｒ」の不要コード可能性が「Ｔ」と判断されている。不要コード可能性「Ｔ」は、不要な処理コードが含まれている可能性があることを示す。

ソースコード２０３の例では、ソースコード２１１からソースコード２１２への改版により、１１行目および１２行目（「ＴＥＣＨＮＩＣＡＬ ＤＥＢＴ」とコメントされている行）は呼び出されることがなくなる。呼び出されることがないコードを維持することは、テストや今後の改変での考慮点が無駄に増えてしまい、技術的負債となる。例えば、必須ではないレスポンスのキー名付き値の削除に対してコード修正が行われず、呼出元側のソースコードに今後使用されない無駄なコードが残り続ける。すると、回帰テストに余計な時間がかかる、障害対応時などに余計なコードの見直しコストがかかる、などソースコードのメンテナンス性が低下する。

これに対して、変更影響解析装置１００は、不要コード可能性を「Ｔ」と評価することで、このような不要コードが存在する可能性をユーザに適切に通知でき、無駄なコードがソースコードに残り続けることを防げる。

次に、変更影響解析装置１００による出力画面の例を説明する。
図３３は、出力画面の例を示す図である。
出力画面１８０は、出力部１３７がディスプレイ１１１に表示させる画面である。出力画面１８０は、変更影響の解析結果をユーザに通知するための画面である。出力画面１８０は、ネットワーク３０を介して接続された他のコンピュータのディスプレイなどに表示されてもよい。出力画面１８０は、ソースコード２０２，２２１，２２２がリポジトリサーバ２００に格納された状態で、「ＧＥＴ ／ｉｔｅｍ」の版番号を「１．０」から「２．０」に変えたときの影響を表す。

出力画面１８０は、機能選択フォーム１８１、旧版番号入力フォーム１８２、新版番号入力フォーム１８３、ボタン１８４および変更影響表示領域１８５を有する。
機能選択フォーム１８１は、変更影響の抽出対象とする機能の識別子を選択するためのフォームである。

旧版番号入力フォーム１８２は、機能選択フォーム１８１で選択された機能に対応する旧版番号を入力するためのフォームである。
新版番号入力フォーム１８３は、機能選択フォーム１８１で選択された機能に対応する新版番号を入力するためのフォームである。

ボタン１８４は、機能選択フォーム１８１の選択内容、旧版番号入力フォーム１８２の入力内容および新版番号入力フォーム１８３の入力内容を確定し、変更影響解析装置１００に変更影響抽出の指示を入力するためのボタンである。

変更影響表示領域１８５は、変更影響解析装置１００による変更影響の解析結果を表示するための領域である。
例えば、機能選択フォーム１８１に「ＧＥＴ ／ｉｔｅｍ」、旧版番号入力フォーム１８２に「ｖｅｒ．１．０」、新版番号入力フォーム１８３に「ｖｅｒ．２．０」が入力された状態でユーザによりボタン１８４が押下操作される。すると、機能選択フォーム１８１、旧版番号入力フォーム１８２および新版番号入力フォーム１８３に入力されたこれらの情報を含む変更影響抽出の指示が変更影響解析装置１００に入力される。変更影響解析装置１００は、変更影響抽出の指示を受け付けると、データ授受成功度テーブル１７３を生成する。変更影響解析装置１００は、不要コード可能性テーブルも生成するが、不要コード可能性については該当コードがないため説明を省略する。

出力部１３７は、データ授受成功度テーブル１７３に基づいて、データ授受成功度の問題箇所を表す画像を変更影響表示領域１８５に表示させる。データ授受成功度の問題箇所は、データ授受成功度テーブル１７３において、データ授受成功度が「Ｆ」（影響あり）または「Ｈ」（影響する可能性あり）であるレコードに対応する。データ授受成功度テーブル１７３の例では、「ＧＥＴ ／ｏｒｄｅｒ」の旧版「１．０」から新版「２．０」への変更が、機能「ＰＵＴ ／ｏｒｄｅｒ」の版「１．０」のリクエストに影響する可能性があることが、変更影響表示領域１８５に表示される。

ユーザは、出力画面１８０を確認することで、「ＰＵＴ ／ｏｒｄｅｒ」が影響を受ける可能性があることを適切に把握することができる。
図３４は、出力画面の他の例を示す図である。

出力画面１９０は、出力部１３７がディスプレイ１１１に表示させる画面である。出力画面１９０は、変更影響の解析結果をユーザに通知するための画面である。出力画面１９０は、ネットワーク３０を介して接続された他のコンピュータのディスプレイなどに表示されてもよい。出力画面１９０は、ソースコード２０３，２１１，２１２がリポジトリサーバ２００に格納された状態で、「ＧＥＴ ／ｐｒｏｇｒｅｓｓ」の版番号を「１．０」から「２．０」に変えたときの影響を表す。

出力画面１９０は、機能選択フォーム１９１、旧版番号入力フォーム１９２、新版番号入力フォーム１９３、ボタン１９４および変更影響表示領域１９５を有する。機能選択フォーム１９１、旧版番号入力フォーム１９２、新版番号入力フォーム１９３、ボタン１９４および変更影響表示領域１９５それぞれは、図３３で示した出力画面１８０の同名の構成に対応する。

例えば、機能選択フォーム１９１に「ＧＥＴ ／ｐｒｏｇｒｅｓｓ」、旧版番号入力フォーム１９２に「ｖｅｒ．１．０」、新版番号入力フォーム１９３に「ｖｅｒ．２．０」が入力された状態でユーザによりボタン１９４が押下操作される。すると、機能選択フォーム１９１、旧版番号入力フォーム１９２および新版番号入力フォーム１９３に入力されたこれらの情報を含む変更影響抽出の指示が変更影響解析装置１００に入力される。変更影響解析装置１００は、変更影響抽出の指示を受け付けると、不要コード可能性テーブル１７４を生成する。変更影響解析装置１００は、データ授受成功度テーブルも生成するが、データ授受成功度については問題箇所がないため説明を省略する。

出力部１３７は、不要コード可能性テーブル１７４に基づいて、不要コードが含まれる可能性がある箇所を表す画像を変更影響表示領域１９５に表示させる。不要コードが含まれる可能性がある箇所は、不要コード可能性テーブル１７４において、不要コード可能性が「Ｔ」のレコードに対応する。例えば、「ＧＥＴ ／ｐｒｏｇｒｅｓｓ」の旧版「１．０」から新版「２．０」への変更により、呼出元の機能「ＤＥＬＥＴＥ ／ｏｒｄｅｒ」の版「１．０」のリクエスト生成に、不要コードが含まれる可能性があることが変更影響表示領域１９５に表示される。

ユーザは、出力画面１９０を確認することで、「ＤＥＬＥＴＥ ／ｏｒｄｅｒ」に不要コードが存在する可能性があることを適切に把握することができる。
次に、変更影響解析装置１００による変更影響の解析結果をまとめる。

図３５は、変更影響の解析結果の例を示す図である。
図３５（Ａ）は、送信側によるデータの送信の確度と、受信側による当該データの受信の必要度との組に応じた、変更影響解析装置１００によるデータ授受成功度Ｓの解析結果６１を示す。送信の確度は、データの生成仕様における必須度である。受信の必要度は、データの受入仕様における必須度である。（送信側、受信側）の組合せは、呼出先から呼出元へのレスポンスの場合に（呼出先の機能、呼出元の機能）であり、呼出元から呼出先へのリクエストの場合に（呼出元の機能、呼出先の機能）である。

送信の確度「ｍａｎｄａｔｏｒｙ」は、Ｅａ＝ＴかつＥｎ＝Ｆに相当する。
送信の確度「ｐｏｓｓｉｂｌｅ」は、Ｅａ＝ＦかつＥｎ＝Ｆに相当する。
送信の確度「ｉｍｐｏｓｓｉｂｌｅ」は、Ｅａ＝ＦかつＥｎ＝Ｔに相当する。

受信の必要度「ｍａｎｄａｔｏｒｙ」は、Ｓｒ＝Ｔ、Ｓｕ＝ＦかつＡ＝Ｔに相当する。
受信の必要度「ｐｏｓｓｉｂｌｅ」は、Ｓｒ＝Ｔ、Ｓｕ＝ＴかつＡ＝Ｔに相当する。
受信の必要度「ｕｎａｔｔｅｎｄｅｄ」は、Ｓｒ＝Ｔ、Ｓｕ＝ＴかつＡ＝Ｆに相当する。

受信の必要度「ｉｍｐｏｓｓｉｂｌｅ」は、Ｓｒ＝Ｆ、Ｓｕ＝ＴかつＡ＝Ｆに相当する。
データ授受成功度Ｓ＝Ｔは「影響なし」を示す。データ授受成功度Ｓ＝Ｈは「影響ありの可能性あり」を示す。データ授受成功度Ｓ＝Ｆは「影響あり」を示す。

なお、図中、破壊的変更に対して一律に影響ありとする方法に対する偽陽性の修正箇所を「ＣＦＰ」（Corrected False Positive）と表記する。また、本来は不要コードが存在する可能性があるにも関わらず、それを見過ごすことを、便宜的に「偽陰性」と称し、偽陰性の修正箇所を「ＣＦＮ」（Corrected False Negative）と表記する。

解析結果６１の例では、送信の確度「ｉｍｐｏｓｓｉｂｌｅ」と受信の必要度「ｐｏｓｓｉｂｌｅ」との組に対してＳ＝Ｔであり、偽陽性が修正される。同様に、送信の確度「ｉｍｐｏｓｓｉｂｌｅ」と受信の必要度「ｕｎａｔｔｅｎｄｅｄ」との組に対してＳ＝Ｔであり、偽陽性が修正される。更に、送信の確度「ｉｍｐｏｓｓｉｂｌｅ」と受信の必要度「ｉｍｐｏｓｓｉｂｌｅ」の組に対してＳ＝Ｔであり、偽陽性が修正される。

また、送信の確度「ｐｏｓｓｉｂｌｅ」と受信の必要度「ｍａｎｄａｔｏｒｙ」との組に対してＳ＝Ｈであり、影響の可能性があることをユーザに通知できる。また、送信の確度「ｐｏｓｓｉｂｌｅ」と受信の必要度「ｉｍｐｏｓｓｉｂｌｅ」との組に対してＳ＝Ｈであり、影響の可能性があることをユーザに通知できる。

更に、送信の確度「ｍａｎｄａｔｏｒｙ」と受信の必要度「ｉｍｐｏｓｓｉｂｌｅ」との組に対してＳ＝Ｆであり、偽陰性が修正される。
なお、解析結果６１の例では、送信の確度「ｉｍｐｏｓｓｉｂｌｅ」と受信の必要度「ｍａｎｄａｔｏｒｙ」との組に対してＳ＝Ｆであり、それ以外の組に対してＳ＝Ｔである。

図３５（Ｂ）は、送信側によるデータの送信の確度と、受信側による当該データの受信の必要度との組に応じた、変更影響解析装置１００による不要コード可能性Ｕの解析結果６２を示す。不要コード可能性Ｕ＝Ｔは「不要コードが存在する可能性あり」を示す。不要コード可能性Ｕ＝Ｆは「不要コードが存在する可能性なし」を示す。

解析結果６２の例では、送信の確度「ｉｍｐｏｓｓｉｂｌｅ」と受信の必要度「ｐｏｓｓｉｂｌｅ」との組に対してＵ＝Ｔであり、偽陰性が修正される。解析結果６２の例では、送信の確度と受信の必要度とのその他の組に対してＵ＝Ｆである。

このように、変更影響解析装置１００は、呼出元の機能において、データの受信が必須であることを示す第１の必要度と、データを受信すれば使用することを示す第２の必要度と、データを受信しても使用しないことを示す第３の必要度とを含む複数の必要度のうちの何れに当該データが該当するかを決定する。これにより、呼出元側の機能の状況を詳細に分析可能になる。

また、変更影響解析装置１００は、改版前の呼出先の機能により送信されるが改版後の呼出先の機能により送信されないデータの、呼出元における必要度が上記第２の必要度および上記第３の必要度の場合、呼出元の機能への影響がないと判定する。これにより、偽陽性が削減される。

また、変更影響解析装置１００は、送信の確度の決定では、改版後の呼出先の機能によりデータが送信される場合および送信されない場合の両方の場合があることを示す確度を決定する。そして、変更影響解析装置１００は、変更影響の判定では、上記第１の必要度と当該両方の場合があることを示す確度との組合せに対して、呼出元の機能への影響がある可能性があると判定する。これにより、コード確認作業の適切な優先順位付けが可能になる。

また、変更影響解析装置１００は、改版後の呼出先の機能により送信されないデータの、呼出元における受信の必要度が上記第２の必要度の場合、呼出元の機能のソースコードに不要なコードが含まれる可能性があると判定し、当該可能性をユーザに通知する。これにより、ソースコードに無駄なコードが残されることを抑えられる。

更に、変更影響解析装置１００は、呼出元の機能から改版後の呼出先の機能へのデータの送信の有無の他の確度と、改版後の呼出先の機能における当該データの受信の他の必要度とを決定する。そして、変更影響解析装置１００は、決定した他の確度と他の必要度との組合せに基づいて、データの仕様の変更による呼出元の機能に対する影響を判定する。これにより、呼出元から呼出先に送信されるリクエストデータに関しても、呼出元の機能への影響を適切に判定できる。

図３６は、変更影響の解析結果の比較例を示す図である。
図３６（Ａ）は、受信側でのデータの受信の必要度を考慮しない場合のデータ授受成功度Ｓの解析結果７１を示す。解析結果７１の例では、送信の確度「ｐｏｓｓｉｂｌｅ」は考慮されていない。例えば、解析結果７１では、該当のデータの送信が必ずしも行われない場合でも、必ず送信する場合と同じように扱われて、データ授受成功度Ｓが評価されている。解析結果７１によれば、送信の確度「ｍａｎｄａｔｏｒｙ」、受信の任意の必要度に対して、Ｓ＝Ｔである。また、送信の確度「ｉｍｐｏｓｓｉｂｌｅ」、受信の任意の必要度に対して、Ｓ＝Ｆである。すなわち、送信の確度「ｉｍｐｏｓｓｉｂｌｅ」に対し、受信側での受信の必要度によっては影響がないにも関わらず、Ｓ＝Ｆと誤判定されてしまう。

図３６（Ｂ）は、受信側でのデータの受信の必要度を考慮しない場合の不要コード可能性Ｕの解析結果７２を示す。解析結果７２の例では、受信側のソースコードを参照しないため、送信の確度が何れの場合でも、不要コード可能性Ｕ＝Ｆである。すなわち、不要コード可能性Ｕを評価することはできない。

図３６の比較例のように、受信側のデータの必要度に関わらず同じ結果を出力すると、偽陽性や偽陰性が発生してしまう。変更影響解析装置１００によれば、送信側のデータの送信の確度と受信側の当該データの受信の必要度との組に応じて、データ授受成功度や不要コード可能性を評価することで、図３５で示したように、偽陽性や偽陰性の発生を抑えられる。

変更影響解析装置１００によれば、効率的なシステム開発を支援することができる。例えば、分散環境などで稼働する小規模の機能群を結合・連携させることで大規模なシステムを実現することがある。変更影響解析装置１００は、このような大規模なシステムにおいて、小規模機能が仕様変更されたときに、変更の影響がある箇所を列挙する。

比較例の方法では、破壊的変更があった小規模機能の連携先を、全て影響ありとして列挙するため、列挙結果に偽陽性が含まれることがあり、ユーザは、作業対象とすべき小規模機能を適切に絞り込むことが難しい。

そこで、変更影響解析装置１００は、まずはソースコードを静的解析して、小規模機能が生成するデータの仕様と、小規模機能が受け入れるデータの仕様とを抽出する。これらの仕様群を複数種類の３値論理値に分解・変換し、授受がある機能間のデータ授受成功度を３値論理演算することで、変更影響の有無箇所を詳細に解析可能になるとともに、影響ありとする箇所の列挙結果から偽陽性を削減できる。

また、前述の３値論理値を用いて、データを受け取る側の機能の実装コードに、今後仕様されない部位があるかを論理値演算により判定することで、修正すべきコードの見過ごし、すなわち、偽陰性を削減できる。

このようにして、変更影響解析装置１００は、呼出先の機能の仕様変更による呼出元の機能への影響を適切に判定できる。ユーザは、変更影響解析装置１００による判定結果を確認することで、作業対象とすべき機能を適切に絞り込める。その結果、ユーザによる余計な作業が削減され、システム開発の期間の短縮に寄与する。

なお、第１の実施の形態の情報処理は、処理部１２にプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、処理部２２にプログラムを実行させることで実現できる。更に、第３の実施の形態の情報処理は、ＣＰＵ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体１１３に記録できる。

例えば、プログラムを記録した記録媒体１１３を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体１１３に記録されたプログラムまたは他のコンピュータから受信したプログラムを、ＲＡＭ１０２やＨＤＤ１０３などの記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。

１０ 変更影響解析装置
１１ 記憶部
１２ 処理部
１３ 影響判定結果

Claims (11)

1. コンピュータに、
   呼出元プログラムから呼び出される呼出先プログラムで用いられるデータの仕様が変更された場合に、前記呼出元プログラムと前記呼出先プログラムとに基づいて、前記呼出先プログラムから前記呼出元プログラムへの前記データの送信の有無の確度と、前記呼出元プログラムにおける前記データの受信の必要度とを決定し、
   前記確度と前記必要度との組合せに基づいて、前記データの仕様の変更による前記呼出元プログラムに対する影響を判定し、判定した前記影響を示す情報を出力する、
   処理を実行させる変更影響解析プログラム。
2. 前記必要度の決定では、前記呼出元プログラムにおいて、前記データの受信が必須であることを示す第１の必要度と、前記データを受信すれば使用することを示す第２の必要度と、前記データを受信しても使用しないことを示す第３の必要度とを含む複数の前記必要度のうちの何れに前記データが該当するかを決定する、
   請求項１記載の変更影響解析プログラム。
3. 前記影響の判定では、改版前の前記呼出先プログラムにより送信されるが改版後の前記呼出先プログラムにより送信されない前記データの前記必要度が前記第２の必要度および前記第３の必要度の場合、前記呼出元プログラムへの前記影響がないと判定する、
   請求項２記載の変更影響解析プログラム。
4. 前記確度の決定では、前記呼出先プログラムにより前記データが送信される場合および送信されない場合の両方の場合があることを示す前記確度を決定し、
   前記影響の判定では、前記第１の必要度と前記両方の場合があることを示す前記確度との組合せに対して、前記呼出元プログラムへの前記影響がある可能性があると判定する、
   請求項２または３記載の変更影響解析プログラム。
5. 前記影響の判定では、前記呼出先プログラムにより送信されない前記データの前記必要度が前記第２の必要度の場合、前記呼出元プログラムに不要なコードが含まれる可能性があると判定する、
   請求項２乃至４の何れか一項に記載の変更影響解析プログラム。
6. 前記確度および前記必要度の決定では、前記呼出元プログラムから前記呼出先プログラムへの前記データの送信の有無の他の確度と、前記呼出先プログラムにおける前記データの受信の他の必要度とを決定し、
   前記影響の判定では、前記他の確度と前記他の必要度との組合せに基づいて、前記データの仕様の変更による前記呼出元プログラムに対する前記影響を判定する、
   請求項１乃至５の何れか一項に記載の変更影響解析プログラム。
7. コンピュータが、
   呼出元プログラムから呼び出される呼出先プログラムで用いられるデータの仕様が変更された場合に、前記呼出元プログラムと前記呼出先プログラムとに基づいて、前記呼出先プログラムから前記呼出元プログラムへの前記データの送信の有無の確度と、前記呼出元プログラムにおける前記データの受信の必要度とを決定し、
   前記確度と前記必要度との組合せに基づいて、前記データの仕様の変更による前記呼出元プログラムに対する影響を判定し、判定した前記影響を示す情報を出力する、
   変更影響解析方法。
8. 呼出元プログラムと前記呼出元プログラムから呼び出される呼出先プログラムとを記憶する記憶部と、
   前記呼出先プログラムで用いられるデータの仕様が変更された場合に、前記呼出元プログラムと前記呼出先プログラムとに基づいて、前記呼出先プログラムから前記呼出元プログラムへの前記データの送信の有無の確度と、前記呼出元プログラムにおける前記データの受信の必要度とを決定し、前記確度と前記必要度との組合せに基づいて、前記データの仕様の変更による前記呼出元プログラムに対する影響を判定し、判定した前記影響を示す情報を出力する処理部と、
   を有する変更影響解析装置。
9. コンピュータに、
   呼出元プログラムから呼び出される呼出先プログラムで用いられるデータの仕様が変更された場合に、前記呼出元プログラムと前記呼出先プログラムとに基づいて、前記呼出元プログラムから前記呼出先プログラムへの前記データの送信の有無の確度と、前記呼出先プログラムにおける前記データの受信の必要度とを決定し、
   前記確度と前記必要度との組合せに基づいて、前記データの仕様の変更による前記呼出元プログラムに対する影響を判定し、判定した前記影響を示す情報を出力する、
   処理を実行させる変更影響解析プログラム。
10. コンピュータが、
    呼出元プログラムから呼び出される呼出先プログラムで用いられるデータの仕様が変更された場合に、前記呼出元プログラムと前記呼出先プログラムとに基づいて、前記呼出元プログラムから前記呼出先プログラムへの前記データの送信の有無の確度と、前記呼出先プログラムにおける前記データの受信の必要度とを決定し、
    前記確度と前記必要度との組合せに基づいて、前記データの仕様の変更による前記呼出元プログラムに対する影響を判定し、判定した前記影響を示す情報を出力する、
    変更影響解析方法。
11. 呼出元プログラムと前記呼出元プログラムから呼び出される呼出先プログラムとを記憶する記憶部と、
    前記呼出先プログラムで用いられるデータの仕様が変更された場合に、前記呼出元プログラムと前記呼出先プログラムとに基づいて、前記呼出元プログラムから前記呼出先プログラムへの前記データの送信の有無の確度と、前記呼出先プログラムにおける前記データの受信の必要度とを決定し、前記確度と前記必要度との組合せに基づいて、前記データの仕様の変更による前記呼出元プログラムに対する影響を判定し、判定した前記影響を示す情報を出力する処理部と、
    を有する変更影響解析装置。

Images