JP2021082113A - 変更影響解析プログラム、変更影響解析方法および変更影響解析装置 - Google Patents
変更影響解析プログラム、変更影響解析方法および変更影響解析装置 Download PDFInfo
- Publication number
- JP2021082113A JP2021082113A JP2019210356A JP2019210356A JP2021082113A JP 2021082113 A JP2021082113 A JP 2021082113A JP 2019210356 A JP2019210356 A JP 2019210356A JP 2019210356 A JP2019210356 A JP 2019210356A JP 2021082113 A JP2021082113 A JP 2021082113A
- Authority
- JP
- Japan
- Prior art keywords
- program
- data
- necessity
- callee
- caller
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Stored Programmes (AREA)
Abstract
【課題】呼出先プログラムの仕様変更による呼出元プログラムへの影響を適切に判定する変更影響解析プログラム、変更影響解析方法及び変更影響解析装置を提供する。【解決手段】変更影響解析装置10において、処理部12は、呼出元プログラムから呼び出される呼出先プログラムで用いられるデータの仕様が変更された場合に、呼出元プログラムと呼出先プログラムとに基づいて、呼出先プログラムから呼出元プログラムへのデータの送信の有無の確度と、呼出元プログラムにおけるデータの受信の必要度とを決定し、決定した確度と必要度との組合せに基づいて、データの仕様の変更による呼出元プログラムに対する影響を判定し、判定した影響を示す情報を出力する。【選択図】図1
Description
本発明は変更影響解析プログラム、変更影響解析方法および変更影響解析装置に関する。
情報処理システムでは複数のプログラムが実行される。情報処理システムでは、複数のプログラムにより実現される複数の機能が互いに連携することがある。例えば、情報処理システムは、あるプログラムから他のプログラムを呼び出し、呼出先の他のプログラムの出力データに基づいて、呼出元のプログラムによる処理を行うことがある。プログラムで用いられるデータの仕様は、プログラムの設計に応じて定められる。あるプログラムが他のプログラムと連携する場合、両プログラムの間で送受信されるデータは、両プログラムで扱われるデータの仕様に適合していることが求められる。
例えば、データテーブルにおける不整合なデータを整合化するためのデータクレンジング装置が提案されている。提案のデータクレンジング装置は、条件付関数従属性ルールリストに基づいて、複数タプルによる違反(Multi-tuple violation)と呼ばれるルール違反があるデータタプルを検出し、ユーザに提示する。
なお、テーブルの変更の内容を含む変更用データセットをトランザクションID(IDentifier)に関連付けてデータストアに蓄積することで、テーブルの書き換えを行わずに、データベースの内容を変更するデータベースシステムの提案もある。
機能の追加や修正のため、プログラムで用いられるデータの仕様が変更されることがある。データの仕様の変更により、当該プログラムの出力内容も変化し得る。このため、更新されるプログラムが別のプログラムから呼び出されて実行される場合、呼出元のプログラムへの影響の有無が問題となる。
例えば、呼出先のプログラムの変更により、呼出元のプログラムへ応答されていたデータに含まれるデータ項目の識別名が変更されたり、一部のデータ項目が応答されなくなったりすることがある。あるいは、呼出先のプログラムの変更により、呼出元のプログラムから呼出先のプログラムへの提供が任意であったデータ項目の提供が必須になることもある。この場合、情報処理システムでは、呼出元のプログラムと呼出先のプログラムとが適切に連携できなくなる可能性がある。
これに対し、例えば、呼出先のプログラムで呼出元のプログラムに影響を及ぼすと想定される仕様変更が行われる場合には、プログラムの変更を管理する装置により、呼出元のプログラムに対して一律に影響ありと判断してユーザに通知することが考えられる。しかし、例えば呼出元のプログラムでは、識別名が変更されたり応答から削除されたりしたデータ項目がない場合も予め考慮してコーディングされていることもある。また、例えば呼出元のプログラムから呼出先のプログラムへの提供が必須に変更されたデータ項目を通常ケースでは常に提供するように呼出元のプログラムがコーディングされていることもある。こうした場合には、呼出先のプログラムでのデータの仕様変更による呼出元のプログラムへの影響がないと考えられる。このように、呼出先のプログラムでのデータの仕様変更のみに基づき呼出元のプログラムに対して一律に影響ありとすると、本来は影響がないにも関わらず、影響があると誤判断することがある。
1つの側面では、本発明は、呼出先プログラムの仕様変更による呼出元プログラムへの影響を適切に判定できる変更影響解析プログラム、変更影響解析方法および変更影響解析装置を提供することを目的とする。
1つの態様では、変更影響解析プログラムが提供される。この変更影響解析プログラムは、コンピュータに、呼出元プログラムから呼び出される呼出先プログラムで用いられるデータの仕様が変更された場合に、呼出元プログラムと呼出先プログラムとに基づいて、呼出先プログラムから呼出元プログラムへのデータの送信の有無の確度と、呼出元プログラムにおけるデータの受信の必要度とを決定し、確度と必要度との組合せに基づいて、データの仕様の変更による呼出元プログラムに対する影響を判定し、判定した影響を示す情報を出力する、処理を実行させる。
また、1つの態様では、変更影響解析プログラムが提供される。この変更影響解析プログラムは、コンピュータに、呼出元プログラムから呼び出される呼出先プログラムで用いられるデータの仕様が変更された場合に、呼出元プログラムと呼出先プログラムとに基づいて、呼出元プログラムから呼出先プログラムへのデータの送信の有無の確度と、呼出先プログラムにおけるデータの受信の必要度とを決定し、確度と必要度との組合せに基づいて、データの仕様の変更による呼出元プログラムに対する影響を判定し、判定した影響を示す情報を出力する、処理を実行させる。
また、1つの態様では、変更影響解析方法が提供される。
また、1つの態様では、変更影響解析装置が提供される。
また、1つの態様では、変更影響解析装置が提供される。
1つの側面では、呼出先プログラムの仕様変更による呼出元プログラムへの影響を適切に判定できる。
以下、本実施の形態について図面を参照して説明する。
[第1の実施の形態]
第1の実施の形態を説明する。
[第1の実施の形態]
第1の実施の形態を説明する。
図1は、第1の実施の形態の変更影響解析装置の処理例を示す図である。
変更影響解析装置10は、情報処理システム(図示を省略している)で用いられるプログラムの開発を支援する。変更影響解析装置10はコンピュータにより実現され得る。情報処理システムでは、複数のプログラムが連携する。あるプログラムを開発するユーザと、他のプログラムを開発するユーザとは、同じであることもあるし、異なることもある。複数のプログラムそれぞれは、プログラムを開発するユーザによって改版され得る。
変更影響解析装置10は、情報処理システム(図示を省略している)で用いられるプログラムの開発を支援する。変更影響解析装置10はコンピュータにより実現され得る。情報処理システムでは、複数のプログラムが連携する。あるプログラムを開発するユーザと、他のプログラムを開発するユーザとは、同じであることもあるし、異なることもある。複数のプログラムそれぞれは、プログラムを開発するユーザによって改版され得る。
2つのデータを互いに送受信することで連携し得る。このため、あるプログラムの改版に伴うデータの仕様の変更が、当該プログラムの呼出元のプログラムに影響を及ぼすことがある。そこで、変更影響解析装置10は、当該変更による呼出元のプログラムへの影響を解析する。ここで、呼出元のプログラムから呼び出されるプログラムを呼出先プログラムと称する。呼出元のプログラムを呼出元プログラムと称する。
変更影響解析装置10は、記憶部11および処理部12を有する。記憶部11は、RAM(Random Access Memory)などの揮発性記憶装置でもよいし、HDD(Hard Disk Drive)やフラッシュメモリなどの不揮発性記憶装置でもよい。処理部12は、CPU(Central Processing Unit)、DSP(Digital Signal Processor)、ASIC(Application Specific Integrated Circuit)、FPGA(Field Programmable Gate Array)などを含み得る。処理部12はプログラムを実行するプロセッサであってもよい。ここでいう「プロセッサ」には、複数のプロセッサの集合(マルチプロセッサ)も含まれ得る。
記憶部11は、呼出元プログラムと呼出先プログラムとを記憶する。プログラムは、例えば、高水準言語で記述されたソースプログラムである。ソースプログラムは、ソースコードと呼ばれてもよい。
処理部12は、呼出先プログラムで用いられるデータの仕様が変更された場合に、呼出元プログラムと呼出先プログラムとに基づいて、呼出先プログラムから呼出元プログラムへのデータの送信の有無の確度と、呼出元プログラムにおけるデータの受信の必要度とを決定する。
呼出先プログラムから呼出元プログラムへのデータの送信は、例えば、呼出元プログラムからの要求に対する、呼出先プログラムから呼出元プログラムへの応答に相当する。データの仕様の変更には、例えば、当該データの送信対象からの除去や、当該データを識別するデータ項目名の変更などが挙げられる。ここで、呼出先プログラムおよび呼出元プログラムは、関数やメソッドなどと呼ばれる、ある1つの機能を実現するモジュールでもよい。例えば、ソースコードが記録された1つのソースファイルが、1または複数のモジュールの記述を含み得る。呼出元プログラムと呼出先プログラムとは異なるソースファイルに記録され得る。
例えば、処理部12は、呼出元プログラムおよび呼出先プログラムそれぞれに対する静的解析を行う。そして、処理部12は、各プログラムに対する静的解析により、呼出先プログラムから呼出元プログラムへのデータの送信の有無の確度と、呼出元プログラムにおけるデータの受信の必要度とを決定する。
より具体的には、処理部12は、呼出元プログラムに応答されるデータ項目名へ値を設定するコードが、呼出先プログラムにおける条件分岐文の中に記述されているか否かを判定する。当該コードが、呼出先プログラムにおける条件分岐文の外に記述されている場合、処理部12は、当該データ項目名に対応するデータを、呼出先プログラムが「必ず送信する」と判定する。データを「必ず送信する」ことを表す送信の確度を、「必ず送信」と表記することがある。あるいは、当該コードが、呼出先プログラムにおける条件分岐文の中に記述されている場合、処理部12は、当該データ項目名に対応するデータを、呼出先プログラムが「送信することもあるし、送信しないこともある」と判定する。データを「送信することもあるし、送信しないこともある」ことを表す送信の確度を、「両方の場合あり」と表記することがある。
更に、処理部12は、呼出先プログラムにおいて応答の生成に用いられていないデータ項目名に対応するデータを、呼出先プログラムが「決して送信しない」と判定する。データを「決して送信しない」ことを表す送信の確度を、「不送信」と表記することがある。なお、処理部12は、改版前の呼出先プログラムで応答の生成に用いられるデータ項目名と改版後の呼出先プログラムで応答の生成に用いられるデータ項目名とを比較して、改版前には送信されていたが改版後には送信されなくなったデータ項目名を特定してもよい。この場合、処理部12は、改版後に送信されなくなった当該データ項目名に対応するデータを「不送信」とする。
また、例えば、処理部12は、呼出元プログラムに基づいて、呼出先プログラムから受け付けるデータ項目名に対して値設定の確認なしで値の参照が行われているか否かを判定する。値設定の確認としては、例えば、該当のデータ項目名に設定された値が「null」であるか否かの確認が挙げられる。値設定の確認なしで値の参照が行われている場合、処理部12は、呼出元プログラムにおいて当該データ項目名に対応するデータの受信の必要度を「必須」であると判定する。あるいは、値設定の確認を行ってから値の参照が行われている場合、処理部12は、呼出元プログラムにおいて当該データ項目名に対応するデータの受信の必要度を「受信すれば使用」であると判定する。なお、該当のデータ項目名に対して値設定の確認を行ってから値の参照が行われている場合、呼出元プログラムにおいて、当該データ項目名に対する例外処理が既に実行済みであると考えられる。
更に、処理部12は、例えば、呼出元プログラム内で使用されていないデータ項目名に対応するデータの受信の必要度を「受信しても不使用」であると判定する。
処理部12は、決定した確度と必要度との組合せに基づいて、呼出先プログラムにおけるデータの仕様の変更による呼出元プログラムに対する影響を判定する。処理部12は、判定した影響を示す情報を出力する。例えば、処理部12は、該当のデータに対して、決定した確度と必要度との組合せに応じて、影響の度合いを示す影響度を判定し、当該影響度を出力する。影響度としては、「影響あり」を表す指標値および「影響なし」を表す指標値の他に、「影響ありの可能性あり」というように、「影響あり」と「影響なし」との中間の度合いを表す指標値が含まれる。
処理部12は、決定した確度と必要度との組合せに基づいて、呼出先プログラムにおけるデータの仕様の変更による呼出元プログラムに対する影響を判定する。処理部12は、判定した影響を示す情報を出力する。例えば、処理部12は、該当のデータに対して、決定した確度と必要度との組合せに応じて、影響の度合いを示す影響度を判定し、当該影響度を出力する。影響度としては、「影響あり」を表す指標値および「影響なし」を表す指標値の他に、「影響ありの可能性あり」というように、「影響あり」と「影響なし」との中間の度合いを表す指標値が含まれる。
影響判定結果13は、処理部12による影響度の判定結果の一例を示す。影響判定結果13は、呼出先プログラムによるデータの送信の確度、および、呼出元プログラムによる当該データの受信の必要度の各組合せに対して、次の判定結果を示す。
例えば、処理部12は、呼出先プログラムによるデータの送信の確度が「必ず送信」、かつ、呼出元プログラムによる当該データの受信の必要度が「必須」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。
処理部12は、呼出先プログラムによるデータの送信の確度が「必ず送信」、かつ、呼出元プログラムによる当該データの受信の必要度が「受信すれば使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。
処理部12は、呼出先プログラムによるデータの送信の確度が「必ず送信」、かつ、呼出元プログラムによる当該データの受信の必要度が「受信しても不使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。
処理部12は、呼出先プログラムによるデータの送信の確度が「両方の場合あり」、かつ、呼出元プログラムによる当該データの受信の必要度が「必須」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響ありの可能性あり」と判定する。
処理部12は、呼出先プログラムによるデータの送信の確度が「両方の場合あり」、かつ、呼出元プログラムによる当該データの受信の必要度が「受信すれば使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。
処理部12は、呼出先プログラムによるデータの送信の確度が「両方の場合あり」、かつ、呼出元プログラムによる当該データの受信の必要度が「受信しても不使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。
処理部12は、呼出先プログラムによるデータの送信の確度が「不送信」、かつ、呼出元プログラムによる当該データの受信の必要度が「必須」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響あり」と判定する。
処理部12は、呼出先プログラムによるデータの送信の確度が「不送信」、かつ、呼出元プログラムによる当該データの受信の必要度が「受信すれば使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。
処理部12は、呼出先プログラムによるデータの送信の確度が「不送信」、かつ、呼出元プログラムによる当該データの受信の必要度が「受信しても不使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。
変更影響解析装置10によれば、呼出元プログラムから呼び出される呼出先プログラムで用いられるデータの仕様が変更された場合に、呼出元プログラムと呼出先プログラムとに基づいて、呼出先プログラムから呼出元プログラムへのデータの送信の有無の確度と、呼出元プログラムにおけるデータの受信の必要度とが決定される。確度と必要度との組合せに基づいて、データの仕様の変更による呼出元プログラムに対する影響が判定される。判定した影響を示す情報が出力される。
これにより、呼出先プログラムの仕様変更による呼出元プログラムへの影響を適切に判定できる。
ここで、例えば、改版により呼出先プログラムによる応答の一部が削除される場合に、呼出元プログラムに対して一律に影響があると判断し、ユーザに通知することも考えられる。しかし、削除されたデータが呼出元プログラムの処理に必須でなければ、呼出元プログラムへの影響はない。このため、一律に影響があるとしてしまうと、本来は影響がないにも関わらず、影響があると誤判断するという偽陽性の判断を下してしまう可能性がある。偽陽性がユーザに通知されると、ユーザによる余計な確認作業が発生してしまい、プログラム開発の遅延要因になる。
ここで、例えば、改版により呼出先プログラムによる応答の一部が削除される場合に、呼出元プログラムに対して一律に影響があると判断し、ユーザに通知することも考えられる。しかし、削除されたデータが呼出元プログラムの処理に必須でなければ、呼出元プログラムへの影響はない。このため、一律に影響があるとしてしまうと、本来は影響がないにも関わらず、影響があると誤判断するという偽陽性の判断を下してしまう可能性がある。偽陽性がユーザに通知されると、ユーザによる余計な確認作業が発生してしまい、プログラム開発の遅延要因になる。
そこで、変更影響解析装置10では、呼出先プログラムによるデータの送信の確度と呼出元プログラムによるデータの受信の必要度との組合せに基づいて、呼出元プログラムに対する影響を判定することで、当該影響を詳細に判定可能になる。影響判定結果13の例によれば、データの送信の確度「不送信」に対して、データの受信の必要度「必須」の場合に影響度が「影響あり」、必要度「受信すれば使用」、「受信しても不使用」の場合に影響度が「影響なし」となる。このため、例えば、呼出先プログラムによるデータの送信の確度「不送信」に対して、一律に「影響あり」をユーザに通知するよりも、呼出元プログラムへの影響を適切にユーザに通知できる。
また、処理部12は、呼出先プログラムに関し、データの送信の確度として、「両方の場合あり」を特定する。更に、処理部12は、呼出元プログラムへの影響度として、「影響あり」、「影響なし」に加え、これらの中間状態である「影響ありの可能性あり」を判定する。例えば、影響判定結果13で示されるように、処理部12は、データの送信の確度「両方の場合あり」に対して、データの受信の必要度「必須」の場合に、「影響ありの可能性あり」と判定する。このように、変更影響解析装置10は、「影響あり」、「影響なし」の2種類だけでなく、「影響ありの可能性あり」も加えた3種類の影響度を判定することで、呼出元プログラムへの影響を適切にユーザに通知できる。
その結果、ユーザは、呼出先プログラムのデータの仕様変更に対する対応作業を行うべき呼出元プログラムを適切に選択可能になる。また、ユーザは、対応作業の優先順位を判断できるようになる。例えば、ユーザは、変更影響解析装置10による判定結果を確認することで、影響度「影響あり」および「影響ありの可能性あり」の呼出元プログラムを適切に特定し、対応作業を開始することができる。更に、ユーザは、変更影響解析装置10による判定結果を確認して、影響度「影響あり」の呼出元プログラムを、「影響ありの可能性あり」のものよりも優先して、作業開始することができる。
[第2の実施の形態]
次に、第2の実施の形態を説明する。
図2は、第2の実施の形態の変更影響解析装置の処理例を示す図である。
次に、第2の実施の形態を説明する。
図2は、第2の実施の形態の変更影響解析装置の処理例を示す図である。
変更影響解析装置20は、情報処理システム(図示を省略している)で用いられるプログラムの開発を支援する。変更影響解析装置20はコンピュータにより実現され得る。情報処理システムでは、複数のプログラムが連携する。あるプログラムを開発するユーザと、他のプログラムを開発するユーザとは、同じであることもあるし、異なることもある。複数のプログラムそれぞれは、当該プログラムを開発するユーザによって改版され得る。
異なるプログラムがデータを互いに送受信することで連携し得る。このため、あるプログラムの改版に伴うデータの仕様の変更が、当該プログラムを呼び出す呼出元プログラムに影響を及ぼすことがある。そこで、変更影響解析装置20は、当該変更による呼出元プログラムへの影響を解析する。
変更影響解析装置20は、記憶部21および処理部22を有する。記憶部21は、RAMなどの揮発性記憶装置でもよいし、HDDやフラッシュメモリなどの不揮発性記憶装置でもよい。処理部22は、CPU、DSP、ASIC、FPGAなどを含み得る。処理部22はプログラムを実行するプロセッサであってもよい。ここでいう「プロセッサ」には、複数のプロセッサの集合(マルチプロセッサ)も含まれ得る。
記憶部21は、呼出元プログラムと呼出先プログラムとを記憶する。プログラムは、所定のプログラミング言語で記述されたソースプログラムである。ソースプログラムは、ソースコードと呼ばれてもよい。
処理部22は、呼出先プログラムで用いられるデータの仕様が変更された場合に、呼出元プログラムと呼出先プログラムとに基づいて、呼出元プログラムから呼出先プログラムへのデータの送信の有無の確度と、呼出先プログラムにおけるデータの受信の必要度とを決定する。
呼出元プログラムから呼出先プログラムへのデータの送信は、例えば、呼出元プログラムから呼出先プログラムへの要求に相当する。データの仕様の変更には、例えば、呼出元プログラムからの当該データの提供が任意であったものを、当該データの提供を必須とする変更などが挙げられる。ここで、呼出先プログラムおよび呼出元プログラムは、関数やメソッドなどと呼ばれる、ある1つの機能を実現するモジュールでもよい。例えば、ソースコードが記録された1つのソースファイルが、複数のモジュールの記述を含み得る。呼出元プログラムと呼出先プログラムとは異なるソースファイルに記録され得る。
例えば、処理部22は、呼出元プログラムおよび呼出先プログラムそれぞれに対する静的解析を行う。そして、処理部22は、各プログラムに対する静的解析により、呼出元プログラムから呼出先プログラムへのデータの送信の有無の確度と、呼出先プログラムにおけるデータの受信の必要度とを決定する。
より具体的には、処理部22は、呼出先プログラムに送信される、仕様変更対象のデータに対応するデータ項目名へ値を設定するコードが、呼出元プログラムにおける条件分岐文の中に記述されているか否かを判定する。当該コードが、呼出元プログラムにおける条件分岐文の外に記述されている場合、処理部22は、当該データ項目名に対応するデータを、呼出元プログラムが「必ず送信する」と判定する。あるいは、当該コードが、呼出元プログラムにおける条件分岐文の中に記述されている場合、処理部22は、当該データ項目名に対応するデータを、呼出元プログラムが「送信することもあるし、送信しないこともある」と判定する。
更に、処理部22は、例えば、仕様変更対象のデータに対応するデータ項目名が呼出元プログラムにおいて要求の生成に用いられていない場合、当該データを呼出元プログラムが「決して送信しない」と判定する。
また、例えば、処理部22は、呼出先プログラムに基づいて、呼出元プログラムから受け付けるデータ項目名に対して値設定の確認なしで値の参照が行われているか否かを判定する。値設定の確認としては、例えば、該当のデータ項目名に設定された値が「null」であるか否かの確認が挙げられる。値設定の確認なしで値の参照が行われている場合、処理部22は、呼出先プログラムにおいて当該データ項目名に対応するデータの受信の必要度を「必須」であると判定する。あるいは、値設定の確認を行ってから値の参照が行われている場合、処理部22は、呼出先プログラムにおいて当該データ項目名に対応するデータの受信の必要度を「受信すれば使用」であると判定する。
また、処理部22は、例えば、呼出先プログラム内で使用されていないデータ項目名に対応するデータの受信の必要度を「受信しても不使用」であると判定する。
処理部22は、決定した確度と必要度との組合せに基づいて、呼出先プログラムにおけるデータの仕様の変更による呼出元プログラムに対する影響を判定する。処理部22は、判定した影響を示す情報を出力する。例えば、処理部22は、該当のデータに対して、決定した確度と必要度との組合せに応じて、影響の度合いを示す影響度を判定し、当該影響度を出力する。影響度としては、「影響あり」を表す指標値および「影響なし」を表す指標値の他に、「影響ありの可能性あり」というように、「影響あり」と「影響なし」との中間の度合いを表す指標値が含まれる。
処理部22は、決定した確度と必要度との組合せに基づいて、呼出先プログラムにおけるデータの仕様の変更による呼出元プログラムに対する影響を判定する。処理部22は、判定した影響を示す情報を出力する。例えば、処理部22は、該当のデータに対して、決定した確度と必要度との組合せに応じて、影響の度合いを示す影響度を判定し、当該影響度を出力する。影響度としては、「影響あり」を表す指標値および「影響なし」を表す指標値の他に、「影響ありの可能性あり」というように、「影響あり」と「影響なし」との中間の度合いを表す指標値が含まれる。
影響判定結果23は、処理部22による影響度の判定結果の一例を示す。影響判定結果23は、呼出元プログラムによるデータの送信の確度、および、呼出先プログラムによる当該データの受信の必要度の各組合せに対して、次の判定結果を示す。
例えば、処理部22は、呼出元プログラムによるデータの送信の確度が「必ず送信」、かつ、呼出先プログラムによる当該データの受信の必要度が「必須」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。
処理部22は、呼出元プログラムによるデータの送信の確度が「必ず送信」、かつ、呼出先プログラムによる当該データの受信の必要度が「受信すれば使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。
処理部22は、呼出元プログラムによるデータの送信の確度が「必ず送信」、かつ、呼出先プログラムによる当該データの受信の必要度が「受信しても不使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。
処理部22は、呼出元プログラムによるデータの送信の確度が「両方の場合あり」、かつ、呼出先プログラムによる当該データの受信の必要度が「必須」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響ありの可能性あり」と判定する。
処理部22は、呼出元プログラムによるデータの送信の確度が「両方の場合あり」、かつ、呼出先プログラムによる当該データの受信の必要度が「受信すれば使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。
処理部22は、呼出元プログラムによるデータの送信の確度が「両方の場合あり」、かつ、呼出先プログラムによる当該データの受信の必要度が「受信しても不使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。
処理部22は、呼出元プログラムによるデータの送信の確度が「不送信」、かつ、呼出先プログラムによる当該データの受信の必要度が「必須」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響あり」と判定する。
処理部22は、呼出元プログラムによるデータの送信の確度が「不送信」、かつ、呼出先プログラムによる当該データの受信の必要度が「受信すれば使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。
処理部22は、呼出元プログラムによるデータの送信の確度が「不送信」、かつ、呼出先プログラムによる当該データの受信の必要度が「受信しても不使用」の場合、当該データの仕様変更による送信元プログラムへの影響度を、「影響なし」と判定する。
変更影響解析装置20によれば、呼出元プログラムから呼び出される呼出先プログラムで用いられるデータの仕様が変更された場合に、呼出元プログラムと呼出先プログラムとに基づいて、呼出元プログラムから呼出先プログラムへのデータの送信の有無の確度と、呼出先プログラムにおけるデータの受信の必要度とが決定される。確度と必要度との組合せに基づいて、データの仕様の変更による呼出元プログラムに対する影響が判定される。判定した影響を示す情報が出力される。
これにより、呼出先プログラムの仕様変更による呼出元プログラムへの影響を適切に判定できる。具体的には、呼出元プログラムによるデータの送信の確度と呼出先プログラムによるデータの受信の必要度との組合せに基づいて、呼出元プログラムに対する影響を判定することで、当該影響を詳細に判定可能になる。
ここで、例えば、呼出先プログラムにおいて、呼出元プログラムから呼出先プログラムへのあるデータ項目の提供が任意から必須に変更された場合に、呼出元プログラムに対して一律に「影響あり」と判断することも考えられる。しかし、呼出元プログラムにおいて、通常ケースでは該当のデータ項目を常に提供するようにコーディングされていることもある。この場合には、当該呼出元プログラムへの影響がないか、あるいは影響が比較的小さい可能性もある。
そこで、処理部22は、影響判定結果23の例のように、呼出元プログラムに関し、該当のデータの送信の確度として、「必ず送信」および「不送信」に加えて、「両方の場合あり」を特定する。また、処理部22は、呼出元からのデータの送信の確度と、呼出先での当該データの受信の必要度との組合せに対し、呼出元プログラムへの影響度として、「影響あり」、「影響なし」に加え、これらの中間状態である「影響ありの可能性あり」を判定する。例えば、処理部22は、影響判定結果23の例のように、データの送信の確度「必ず送信」と、データの受信の必要度「必須」に対して、影響度を「影響なし」と判定する。また、例えば、処理部22は、データの送信の確度「両方の場合あり」と、データの受信の必要度「必須」に対して、影響度を「影響ありの可能性あり」と判定する。このため、例えば、呼出先プログラムによるデータの受信の必要度「必須」に対して、一律に「影響あり」をユーザに通知するよりも、呼出元プログラムへの影響を適切にユーザに通知可能になる。
その結果、ユーザは、呼出先プログラムのデータの仕様変更に対して対応作業を行うべき呼出元プログラムを適切に選択し、また、対応作業の優先順位を判断できるようになる。例えば、ユーザは、変更影響解析装置20による判定結果を確認することで、影響度「影響あり」および「影響ありの可能性あり」の呼出元プログラムを適切に特定し、対応作業を開始することができる。更に、ユーザは、変更影響解析装置20による判定結果を確認して、影響度「影響あり」の呼出元プログラムを、「影響ありの可能性あり」のものよりも優先して、作業開始することができる。
以下では、より具体的な情報処理システムを例示して、変更影響解析装置10,20に関する機能を更に詳細に説明する。
[第3の実施の形態]
次に、第3の実施の形態を説明する。
[第3の実施の形態]
次に、第3の実施の形態を説明する。
図3は、第3の実施の形態の情報処理システムの例を示す図である。
第3の実施の形態の情報処理システムは、変更影響解析装置100およびリポジトリサーバ200を有する。変更影響解析装置100およびリポジトリサーバ200は、ネットワーク30に接続されている。ネットワーク30は、例えばLAN(Local Area Network)である。ネットワーク30は、WAN(Wide Area Network)やインターネットでもよい。
第3の実施の形態の情報処理システムは、変更影響解析装置100およびリポジトリサーバ200を有する。変更影響解析装置100およびリポジトリサーバ200は、ネットワーク30に接続されている。ネットワーク30は、例えばLAN(Local Area Network)である。ネットワーク30は、WAN(Wide Area Network)やインターネットでもよい。
変更影響解析装置100は、ユーザによるソフトウェア開発を支援するサーバコンピュータである。変更影響解析装置100は、あるソースコードの変更による他のソースコードに対する影響を解析し、他のソースコードにおける当該影響を受ける箇所をユーザに通知する。
リポジトリサーバ200は、ソースコードを記憶する。例えば、リポジトリサーバ200は、ソースコードDB(DataBase)の機能を有する。ソースコードDBは、ソースコードとソースコードの版数とを対応付けて保持する。
リポジトリサーバ200に記憶されたソースコードは、実行可能な形式に変換されて、図示を省略しているサーバコンピュータにより実行される。あるソースコードに記述された関数やメソッドなどのモジュールにより実現される機能が他の機能と連携して、1または複数のサービスを実現する。複数のソースコードにおける複数の機能が、複数のサーバコンピュータにより分散して実現されることもある。例えば、Webサービスやマイクロサービスなどのように、分散環境で稼働する比較的小規模な複数の機能を結合させたり、連携させたりすることで実現されるサービスもある。
例えば、Webサービスを提供するシステムにおいて、ある機能を呼び出すための規約の一種にREST API(REpresentational State Transfer Application Programming Interface)がある。REST APIは、RESTful APIと呼ばれることもある。REST APIでは、リソースをURI(Uniform Resource Identifier)により識別する。APIへのアクセスにはURIが用いられる。APIにアクセスするためのURIはエンドポイントと呼ばれる。リソースに対する操作は、アクションと呼ばれ、HTTP(Hyper Text Transfer Protocol)メソッドにより指定される。HTTPメソッドには、読み出しを行うGETメソッドや書き込みを行うPOSTメソッドなどがある。
システムを構成する比較的小規模な複数の機能それぞれは、互いに異なるユーザにより開発され得る。このため、当該複数の機能それぞれの開発においてシステム全体としての統制を図ることは容易ではない。これに対し、変更影響解析装置100は、ある小規模機能が仕様変更されたときに、複数の小規模機能が連携して実現される大規模機能の動作を維持できるように支援する。
機能の仕様変更では、当該機能を呼び出すときの外部仕様が変更され得る。外部仕様とは、呼出元の機能が呼出先の機能に対して呼出時に引き渡すリクエストのデータ構造の仕様や、呼出元の機能が呼出先の機能から応答時に受け取るレスポンスのデータ構造の仕様である。外部仕様の仕様変更は、破壊的変更および非破壊的変更に分類される。
破壊的変更とは、呼出元からの呼出が失敗するようになると一般的に考えられる仕様変更である。破壊的変更には、例えば、APIの削除、リクエストからのデータ項目の削除や改名、レスポンスからのデータ項目の削除・改名、リクエストに対するデータ項目への制約追加などが挙げられる。リクエストに対するデータ項目への制約追加には、例えば、当該データ項目の提供を「任意」から「必須」に指定することが挙げられる。
非破壊的変更は、呼出元からの呼出が引き続き成功すると一般的に考えられる仕様変更である。非破壊的変更には、例えば、APIの追加、リクエストに対するデータ項目の追加、レスポンスに対するデータ項目の追加、APIの利用説明文書の更新などが挙げられる。
例えば、破壊的変更が行われる場合に、一律に呼出元の機能への「影響あり」をユーザに通知する方法が考えられる。しかし、この方法では、機能の呼出元の事情に合わせた変更影響の有無をユーザに提示できず、誤判定が起こり得る。
例えば、レスポンスからデータ項目が削除される破壊的変更であっても、呼出元の機能で当該データ項目を参照していなければ、呼出元の機能に対する当該破壊的変更の影響はない。更に、呼出元の機能において元々必須ではない、あるいは、元々必ず送信されるとは限らない場合、レスポンスのデータ項目が削除されたとしても影響がない場合が多い。当該データ項目がレスポンスに含まれない場合を想定したコードが、呼出元の機能に予め存在しているためである。
そこで、変更影響解析装置100は、仕様変更された機能の呼出元の機能の事情に合わせて、変更影響を適切に判定可能にする機能を提供する。
図4は、変更影響解析装置のハードウェア例を示す図である。
図4は、変更影響解析装置のハードウェア例を示す図である。
変更影響解析装置100は、CPU101、RAM102、HDD103、画像信号処理部104、入力信号処理部105、媒体リーダ106およびNIC(Network Interface Card)107を有する。なお、CPU101は、第1の実施の形態の処理部12および第2の実施の形態の処理部22に対応する。RAM102またはHDD103は、第1の実施の形態の記憶部11および第2の実施の形態の記憶部21に対応する。
CPU101は、プログラムの命令を実行するプロセッサである。CPU101は、HDD103に記憶されたプログラムやデータの少なくとも一部をRAM102にロードし、プログラムを実行する。なお、CPU101は複数のプロセッサコアを含んでもよい。また、変更影響解析装置100は複数のプロセッサを有してもよい。以下で説明する処理は複数のプロセッサまたはプロセッサコアを用いて並列に実行されてもよい。また、複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うことがある。
RAM102は、CPU101が実行するプログラムやCPU101が演算に用いるデータを一時的に記憶する揮発性の半導体メモリである。なお、変更影響解析装置100は、RAM以外の種類のメモリを備えてもよく、複数個のメモリを備えてもよい。
HDD103は、OS(Operating System)やミドルウェアやアプリケーションソフトウェアなどのソフトウェアのプログラム、および、データを記憶する不揮発性の記憶装置である。なお、変更影響解析装置100は、フラッシュメモリやSSD(Solid State Drive)などの他の種類の記憶装置を備えてもよく、複数の不揮発性の記憶装置を備えてもよい。
画像信号処理部104は、CPU101からの命令に従って、変更影響解析装置100に接続されたディスプレイ111に画像を出力する。ディスプレイ111としては、CRT(Cathode Ray Tube)ディスプレイ、液晶ディスプレイ(LCD:Liquid Crystal Display)、プラズマディスプレイ、有機EL(OEL:Organic Electro-Luminescence)ディスプレイなど、任意の種類のディスプレイを用いることができる。
入力信号処理部105は、変更影響解析装置100に接続された入力デバイス112から入力信号を取得し、CPU101に出力する。入力デバイス112としては、マウス・タッチパネル・タッチパッド・トラックボールなどのポインティングデバイス、キーボード、リモートコントローラ、ボタンスイッチなどを用いることができる。また、変更影響解析装置100に、複数の種類の入力デバイスが接続されていてもよい。
媒体リーダ106は、記録媒体113に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体113として、例えば、磁気ディスク、光ディスク、光磁気ディスク(MO:Magneto-Optical disk)、半導体メモリなどを使用できる。磁気ディスクには、フレキシブルディスク(FD:Flexible Disk)やHDDが含まれる。光ディスクには、CD(Compact Disc)やDVD(Digital Versatile Disc)が含まれる。
媒体リーダ106は、例えば、記録媒体113から読み取ったプログラムやデータを、RAM102やHDD103などの他の記録媒体にコピーする。読み取られたプログラムは、例えば、CPU101によって実行される。なお、記録媒体113は可搬型記録媒体であってもよく、プログラムやデータの配布に用いられることがある。また、記録媒体113やHDD103を、コンピュータ読み取り可能な記録媒体と言うことがある。
NIC107は、ネットワーク30に接続され、ネットワーク30を介して他のコンピュータと通信を行うインタフェースである。NIC107は、例えば、スイッチやルータなどの通信装置とケーブルで接続される。
なお、リポジトリサーバ200も変更影響解析装置100と同様のハードウェアにより実現される。
図5は、変更影響解析装置の機能例を示すブロック図である。
図5は、変更影響解析装置の機能例を示すブロック図である。
変更影響解析装置100は、記憶部120、制御部130および通信部140を有する。記憶部120には、RAM102またはHDD103の記憶領域が用いられる。制御部130および通信部140は、CPU101がRAM102に記憶されたプログラムを実行することで実現される。
記憶部120は、制御部130の処理に用いられる各種のデータを記憶する。記憶部120は、データ授受仕様記憶部121、変更影響抽出対象記憶部122、仕様タプル記憶部123および解析結果記憶部124を有する。
データ授受仕様記憶部121は、データ授受仕様テーブルおよび辞書データ型テーブルを記憶する。データ授受仕様テーブルは、データ授受仕様を表す辞書を、ソースコードに記述された機能ごとに管理するためのテーブルである。ここで、「辞書」は、「キー」および「値」の組をもつデータである。「キー」は、文字列や数値である。「値」は、「キー」で名前付けられた値であり、数値や文字列のようなプリミティブ型の値か、辞書構造の値をもつ。キーで名前付けられた値は、「キー名付き値」と呼ばれることがある。データ授受仕様は、該当の機能におけるデータ構造の受入および生成に関する仕様を示す。辞書データ型テーブルは、上記の辞書に相当し、各機能で扱われるデータ構造の仕様を保持する。
変更影響抽出対象記憶部122は、変更影響の抽出対象を示す情報を記憶する。変更影響の抽出対象は、改版された機能の識別子と、改版前の版数と、改版後の版数とによって指定される。変更影響の抽出対象を示す情報は、ユーザにより変更影響解析装置100に入力される。
仕様タプル記憶部123は、生成仕様テーブルおよび受入仕様テーブルを記憶する。生成仕様テーブルは、データの生成に関する機能ごとの仕様を論理値の組合せで表したテーブルである。受入仕様テーブルは、データの受入に関する機能ごとの仕様を論理値の組合せで表したテーブルである。
解析結果記憶部124は、データ授受成功度テーブルおよび不要コード可能性テーブルを記憶する。データ授受成功度テーブルは、連携する機能間のデータ授受の成功度を3値の多値論理値により示すテーブルである。成功度は、「常に成功する」、「成功する場合と失敗する場合がある」、「常に失敗する」の3値である。不要コード可能性テーブルは、他の機能を呼び出す機能が実装されたソースコードのうち、今後使用されない箇所が存在するソースコードを示すテーブルである。
制御部130は、変更影響解析の処理の全体を制御する。制御部130は、機能仕様抽出部131、変更影響抽出指示部132、削除差分抽出部133、仕様変換部134、データ授受成功度演算部135、不要コード可能性演算部136および出力部137を有する。
機能仕様抽出部131は、リポジトリサーバ200に記憶された各ソースコードを静的解析することで、データ授受仕様テーブルおよび辞書データ型テーブルを生成し、データ授受仕様記憶部121に格納する。ここで、ソースコードに記述された各機能に対して、次の仕様が存在し得る。
第1には、リクエストとして受け入れられるデータ構造の仕様である。リクエストとして受け入れられるデータ構造の仕様は、受入仕様の一種であり、「リクエスト受入仕様」と呼ばれる。
第2には、レスポンスとして生成するデータ構造の仕様である。レスポンスとして生成するデータ構造の仕様は、生成仕様の一種であり、「レスポンス生成仕様」と呼ばれる。
第3には、呼出元の機能が呼出先の機能に対して生成するリクエストのデータ構造の仕様である。呼出元の機能が呼出先の機能に対して生成するリクエストのデータ構造の仕様は、生成仕様の一種であり、「リクエスト生成仕様」と呼ばれる。
第3には、呼出元の機能が呼出先の機能に対して生成するリクエストのデータ構造の仕様である。呼出元の機能が呼出先の機能に対して生成するリクエストのデータ構造の仕様は、生成仕様の一種であり、「リクエスト生成仕様」と呼ばれる。
第4には、呼出元の機能が呼出先の機能から受け入れるレスポンスのデータ構造の仕様である。呼出元の機能が呼出先の機能から受け入れるレスポンスのデータ構造の仕様は、受入仕様の一種であり、「レスポンス受入仕様」と呼ばれる。
変更影響抽出指示部132は、ユーザにより入力された変更影響の抽出対象を示す情報を削除差分抽出部133に指示する。
削除差分抽出部133は、変更影響抽出指示部132から変更影響の抽出対象を示す情報を受け付け、変更影響抽出対象記憶部122に格納する。削除差分抽出部133は、変更影響の抽出対象である改版前の機能および改版後の機能の削除差分を抽出する。削除差分とは、改版前の機能による応答には存在するが、改版後の機能による応答には存在しないデータや、改版前の機能による要求には存在するが、改版後の機能による要求には存在しないデータである。削除差分抽出部133は、抽出した削除差分に関して、データ授受仕様テーブルおよび辞書データ型テーブルそれぞれにレコードを追加する。
削除差分抽出部133は、変更影響抽出指示部132から変更影響の抽出対象を示す情報を受け付け、変更影響抽出対象記憶部122に格納する。削除差分抽出部133は、変更影響の抽出対象である改版前の機能および改版後の機能の削除差分を抽出する。削除差分とは、改版前の機能による応答には存在するが、改版後の機能による応答には存在しないデータや、改版前の機能による要求には存在するが、改版後の機能による要求には存在しないデータである。削除差分抽出部133は、抽出した削除差分に関して、データ授受仕様テーブルおよび辞書データ型テーブルそれぞれにレコードを追加する。
仕様変換部134は、データ授受仕様記憶部121に記憶されたデータ授受仕様テーブルおよび辞書データ型テーブルに基づいて、生成仕様テーブルおよび受入仕様テーブルを生成し、仕様タプル記憶部123に格納する。仕様変換部134は、データ授受仕様テーブルおよび辞書データ型テーブルで表されるデータ構造の仕様を、論理値の組合せに変換することで、生成仕様テーブルおよび受入仕様テーブルを生成する。
データ授受成功度演算部135は、仕様タプル記憶部123に記憶された生成仕様テーブルおよび受入仕様テーブルに基づいて、データ授受成功度テーブルを生成し、解析結果記憶部124に格納する。データ授受成功度演算部135は、生成仕様に対応する論理値の組合せと、受入仕様に対応する論理値の組合せとを用いた論理演算によって、機能間のデータ授受成功度を求める。
不要コード可能性演算部136は、仕様タプル記憶部123に記憶された生成仕様テーブルおよび受入仕様テーブルに基づいて、不要コード可能性テーブルを生成し、解析結果記憶部124に格納する。不要コード可能性演算部136は、生成仕様に対応する所定の論理値と受入仕様に対応する所定の論理値とを用いた論理演算により、機能ごとの不要なコード箇所の有無を示す論理値を求める。
出力部137は、解析結果記憶部124に記憶されたデータ授受成功度テーブルおよび不要コード可能性テーブルに基づいて、変更影響の解析結果を出力する。解析結果は、ソースコードにおいて影響を受ける機能の識別子や不要なコード箇所を含む機能の識別子を含む。出力部137は、ディスプレイ111に解析結果を表示させてもよいし、通信部140に解析結果を出力し、ネットワーク30などに接続された他のサーバコンピュータに解析結果を送信させてもよい。
通信部140は、ネットワーク30を介して、リポジトリサーバ200などの他のサーバコンピュータと通信する。通信部140は、機能仕様の抽出対象のソースコードとソースコードの版数とをリポジトリサーバ200から取得し、機能仕様抽出部131に提供する。また、通信部140は、変更影響の抽出対象を示す情報の入力を受け付け、変更影響抽出指示部132に提供する。更に、通信部140は、出力部137から変更影響の解析結果を取得し、ネットワーク30を介して他のサーバコンピュータに送信する。
次に、変更影響解析装置100におけるデータ構造を説明する。まず、データ構造で用いられる必須度の定義について説明する。
図6は、データの必須度の定義の例を示す図である。
図6は、データの必須度の定義の例を示す図である。
図6(A)は、表41を示す。表41は、ある機能が他の機能へデータを送信するときの、当該データの送り方に対する必須度を表す。データの送信に関する必須度は、データの送信の確度に相当する。表41は、値およびデータの送り方に関する意味の項目を含む。値は、必須度の値である。データの送り方に関する意味は、必須度の値の意味である。
例えば、表41によれば、必須度の値「mandatory」は、ある機能から他の機能へ該当のデータを「必ず送出する」ことを示す。また、必須度の値「possible」は、ある機能から他の機能へ該当のデータを「送出する場合と送出しない場合がある」ことを示す。更に、必須度の値「impossible」は、「該当のデータは仕様にない」か、あるいは、ある機能から他の機能へ該当のデータを「決して送出しない」ことを示す。
図6(B)は、表42を示す。表42は、ある機能が他の機能からデータを受信するときの、当該データの受け方に対する必須度を表す。データの受信に関する必須度は、データの受信の必要度に相当する。表42は、値およびデータの受け方に関する意味の項目を含む。値は、必須度の値である。データの受け方に関する意味は、必須度の値の意味である。
例えば、表42によれば、必須度の値「mandatory」は、該当の機能において、該当のデータの「到達が動作に必須である」ことを示す。また、必須度の値「possible」は、該当の機能において、該当のデータが「到達すれば使う」ことを示す。また、必須度の値「unattended」は、該当の機能において、該当のデータが「到達しても使わない」ことを示す。更に、必須度の値「impossible」は、該当の機能において、該当のデータが「到達すると動作できない」ことを示す。
次に、具体的なソースコードの例を示す。以下では、高水準言語、すなわち、抽象度の高いプログラミング言語として、JAVA(登録商標)を例示する。また、開発に用いられるJAVAフレームワークの一例として、スプリング(登録商標)フレームワークを示す。ただし、スプリングフレームワーク以外のJAVAフレームワークを用いることもできる。また、プログラミング言語として、JAVA以外のプログラミング言語を用いることもできる。
図7は、呼出元側のソースコードの例を示す図である。
ソースコード201は、リポジトリサーバ200に格納される。ソースコード201は、呼出元側のソースコードの一例である。ソースコード201の版数は「1.0」である。ソースコード201は、OrderControllerクラスの定義を含む。
ソースコード201は、リポジトリサーバ200に格納される。ソースコード201は、呼出元側のソースコードの一例である。ソースコード201の版数は「1.0」である。ソースコード201は、OrderControllerクラスの定義を含む。
例えば、ソースコード201の3行目における「@GetMapping(“/order”)」は、GETリクエスト用のアノテーションであり、後続のメソッドがエンドポイント「/order」の情報を取得するメソッドであることを示す。当該メソッドの名称は「getOrder」である。メソッド「getOrder」は、エンドポイント「/order」の情報の取得結果を応答する。
ソースコード201では、14行目の記述で、getStatusメソッドを用いている。getStatusメソッドは、ソースコード201の19行目〜25行目に記述されている。getStatusメソッドは、20行目〜23行目の記述「ResponseEntity<Progress> p=…」により、図8のソースコードで示される機能を呼び出す。getStatusメソッドは、入力「orderId」に対して呼出先の機能から取得した「statusString」を返す。
図8は、呼出先側のソースコードの例を示す図である。
図8(A)は、リポジトリサーバ200に格納されるソースコード211を示す。ソースコード211は、改版前(旧版)の呼出先側のソースコードの一例である。ソースコード211の版数は、「1.0」である。ソースコード211は、ProgressControllerクラスの定義を含む。
図8(A)は、リポジトリサーバ200に格納されるソースコード211を示す。ソースコード211は、改版前(旧版)の呼出先側のソースコードの一例である。ソースコード211の版数は、「1.0」である。ソースコード211は、ProgressControllerクラスの定義を含む。
例えば、ソースコード211の3行目における「@GetMapping(“/progress/{orderId}”)」は、GETリクエスト用のアノテーションである。当該アノテーションは、後続のメソッドがエンドポイント「/progress/{orderId}」の情報を取得するメソッドであることを示す。当該メソッドの名称は「getProgress」である。メソッド「getProgress」は、エンドポイント「/progress/{orderId}」の情報の取得結果を応答する。
ここで、ソースコード211の4行目のアノテーション「@PathVariable String orderID」は、エンドポイントの記述に含まれる「{orderId}」をリクエストから取得することを示す。
図8(B)は、リポジトリサーバ200に格納されるソースコード212を示す。ソースコード212は、改版後(新版)の呼出先側のソースコードの一例である。ソースコード212の版数は、「2.0」である。ソースコード212では、ソースコード211の7行目のキー名「itemLocation」に関する記述が削除されている。
機能仕様抽出部131は、ソースコード201,211,212の静的解析によりデータ授受仕様テーブルを生成する。また、削除差分抽出部133は、データ授受仕様テーブルに対して削除差分のレコードを追加する。
図9は、データ授受仕様テーブルの例を示す図である。
データ授受仕様テーブル151は、データ授受仕様記憶部121に格納される。ここで、図9(A)では、機能仕様抽出部131により生成されるレコードを示している。図9(B)では、削除差分抽出部133により生成されるレコードを示している。
データ授受仕様テーブル151は、データ授受仕様記憶部121に格納される。ここで、図9(A)では、機能仕様抽出部131により生成されるレコードを示している。図9(B)では、削除差分抽出部133により生成されるレコードを示している。
データ授受仕様テーブル151は、仕様種別、機能の識別子、旧版番号、版番号、呼出先の機能識別子および辞書データ型IDの項目を含む。仕様種別、機能の識別子、旧版番号、版番号および呼出先の機能識別子の組は、データ授受仕様テーブル151の主キー(pk:primary key)である。ただし、辞書データ型IDも主キーの候補であるため、当該組は候補キーとも呼ばれる。
仕様種別の項目には、仕様種別が登録される。仕様種別は、前述のように4種類ある。具体的には、リクエスト受入仕様、レスポンス生成仕様、リクエスト生成仕様およびレスポンス受入仕様である。ここで、リクエスト受入仕様を「QA」(reQust Acceptance)と表記する。レスポンス生成仕様を「PC」(resPonse Creation)と表記する。リクエスト生成仕様を「QC」(reQuest Creation)と表記する。レスポンス受入仕様を「PA」(resPonse Acceptance)と表記する。
機能の識別子の項目には、機能の識別子が登録される。例えば、機能の識別子は、所定のアノテーションによって示される「GET」や「PUT」などのアクションと、エンドポイントとの組合せによって表される。
旧版番号の項目には、該当の機能に対する旧版の番号が登録される。版番号の項目には、該当の機能の現版の番号が登録される。旧版番号の値は「null」に設定されることがある。なお、機能の版番号は、当該機能の記述を含むソースコードの版番号であるとも言える。呼出先の機能識別子の項目には、該当の機能から呼び出される呼出先の機能の識別子が登録される。仕様種別によっては、呼出先の機能識別子が「null」になることがある。辞書データ型IDの項目には、該当の仕様種別、機能の識別子、旧版番号、版番号および呼出先の機能識別子に対する辞書データ型IDが登録される。
例えば、データ授受仕様テーブル151には、仕様種別が「QA」、機能の識別子が「GET /order」、旧版番号が「null」、版番号が「1.0」、呼出先の機能識別子が「null」、辞書データ型IDが「1」というレコードが登録される。このレコードは、仕様種別「QA」、機能の識別子「GET /order」、版番号「1.0」に対する辞書データ型IDが「1」であることを示す。
ここで、データ授受仕様テーブル151において、辞書データ型ID「1」〜「4」は、ソースコード201に対応するレコードである。辞書データ型ID「5」、「6」は、旧版のソースコード211に対応するレコードである。辞書データ型ID「7」、「8」は、新版のソースコード212に対応するレコードである。辞書データ型ID「9」は、ソースコード212においてソースコード211から削除された差分に対応するレコードである。
次に、機能仕様抽出部131および削除差分抽出部133により生成される辞書データ仕様テーブルを説明する。まず、辞書データ仕様テーブルのうち、機能仕様抽出部131により生成されるレコード群を説明する。
図10は、辞書データ型仕様テーブルの例を示す図である。
辞書データ型仕様テーブル152は、データ授受仕様記憶部121に格納される。辞書データ型仕様テーブル152は、辞書データ型ID、キー名および必須度の項目を含む。辞書データ型IDおよびキー名の組は、辞書データ型仕様テーブル152の主キー(pk)である。
辞書データ型仕様テーブル152は、データ授受仕様記憶部121に格納される。辞書データ型仕様テーブル152は、辞書データ型ID、キー名および必須度の項目を含む。辞書データ型IDおよびキー名の組は、辞書データ型仕様テーブル152の主キー(pk)である。
辞書データ型IDの項目には、辞書データ型IDが登録される。キー名の項目には、キー名が登録される。キー名は、データ項目名に相当する。必須度の項目には、当該キー名で表されるデータの必須度が登録される。
機能仕様抽出部131は、ソースコード201,211,212の静的解析により、図10に示す辞書データ型仕様テーブル152の各レコードを生成する。
例えば、辞書データ型仕様テーブル152には、辞書データ型IDが「1」、キー名が「orderId」、必須度が「mandatory」というレコードが登録される。このレコードは、辞書データ型ID「1」に対して、キー名「orderId」の必須度が「mandatory」であることを示す。
例えば、辞書データ型仕様テーブル152には、辞書データ型IDが「1」、キー名が「orderId」、必須度が「mandatory」というレコードが登録される。このレコードは、辞書データ型ID「1」に対して、キー名「orderId」の必須度が「mandatory」であることを示す。
なお、辞書データ型仕様テーブル152におけるキー名「暗黙」のレコードは、該当の機能の該当の仕様種別において存在していないキー名に対する必須度(暗黙必須度と言うことがある)を表すレコードである。
次に、辞書データ型仕様テーブル152のうち、削除差分抽出部133により生成されるレコード群を説明する。
図11は、辞書データ型仕様テーブルの例(続き)を示す図である。
図11は、辞書データ型仕様テーブルの例(続き)を示す図である。
削除差分抽出部133は、データ授受仕様テーブル151および図10に示される辞書データ型仕様テーブル152のレコード群に基づいて、ソースコード211,212の差分に対して下記のレコードを生成し、辞書データ型仕様テーブル152に追加する。前述のように、ソースコード212では、ソースコード211の7行目の記述が削除されている。このため、削除差分抽出部133は、当該7行目の記述に含まれるキー名「itemLocation」に関するレコードを生成する。
例えば、辞書データ型仕様テーブル152には、辞書データ型IDが「9」、キー名が「itemLocation」、必須度が「impossible」というレコードが登録される。このレコードは、辞書データ型ID「9」に対して、キー名「itemLocation」の必須度が「impossible」であることを示す。
仕様変換部134は、データ授受仕様テーブル151および辞書データ型仕様テーブル152に基づいて、生成仕様テーブルおよび受入仕様テーブルを生成する。次に、生成仕様テーブルおよび受入仕様テーブルについて説明する。
図12は、生成仕様テーブルの例を示す図である。
生成仕様テーブル161は、仕様タプル記憶部123に格納される。生成仕様テーブル161には、仕様種別「QC」および「PC」の生成仕様を論理値で表したレコード(生成仕様タプルと言うことがある)が登録される。
生成仕様テーブル161は、仕様タプル記憶部123に格納される。生成仕様テーブル161には、仕様種別「QC」および「PC」の生成仕様を論理値で表したレコード(生成仕様タプルと言うことがある)が登録される。
生成仕様テーブル161は、辞書データ型ID、キー名、EaおよびEnの項目を含む。辞書データ型IDおよびキー名の組は、生成仕様テーブル161の主キー(pk)である。
辞書データ型IDの項目には、辞書データ型IDが登録される。キー名の項目には、キー名が登録される。Eaの項目には、論理変数Eaの値が登録される。Enの項目には、論理変数Enの値が登録される。
論理変数Eaは、該当のキー名のデータを必ず送出するか否かを表す。必ず送出する場合にEa=True(真)、送出しないこともある場合にEa=False(偽)である。
論理変数Enは、該当のキー名のデータを決して送出しないか否かを表す。決して送出しない場合にEn=True、送出することもある場合にEn=Falseである。
なお、論理値「True」を「T」、論理値「False」を「F」と略記することがある。
なお、論理値「True」を「T」、論理値「False」を「F」と略記することがある。
例えば、生成仕様テーブル161には、辞書データ型IDが「2」、キー名が「orderId」、Eaが「T」、Enが「F」というレコードが登録される。このレコードは、辞書データ型ID「2」のキー名「orderId」の生成仕様がEa=TかつEn=Fで表されることを示す。
図13は、受入仕様テーブルの例を示す図である。
受入仕様テーブル162は、仕様タプル記憶部123に格納される。受入仕様テーブル162には、仕様種別「QA」および「PA」の受入仕様を論理値で表したレコード(受入仕様タプルと言うことがある)が登録される。
受入仕様テーブル162は、仕様タプル記憶部123に格納される。受入仕様テーブル162には、仕様種別「QA」および「PA」の受入仕様を論理値で表したレコード(受入仕様タプルと言うことがある)が登録される。
受入仕様テーブル162は、辞書データ型ID、キー名、Sr、SuおよびAの項目を含む。辞書データ型IDおよびキー名の組は、受入仕様テーブル162の主キー(pk)である。
辞書データ型IDの項目には、辞書データ型IDが登録される。キー名の項目には、キー名が登録される。Srの項目には、論理変数Srの値が登録される。Suの項目には、論理変数Suの値が登録される。Aの項目には、論理変数Aの値が登録される。
論理変数Srは、該当のキー名のデータが到達した場合に動作可能であるか否かを表す。到達した場合に動作可能である場合にSr=Tであり、到達した場合に動作可能でない場合にSr=Fである。
論理変数Suは、該当のキー名のデータが到達しなかった場合に動作可能であるか否かを表す。到達しなかった場合に動作可能である場合にSu=Tであり、到達しなかった場合に動作可能でない場合にSu=Fである。
論理変数Aは、受け付けた該当のキー名のデータを利用するか否かを表す。利用する場合にA=Tであり、利用しない場合にA=Fである。
例えば、受入仕様テーブル162には、辞書データ型IDが「1」、キー名が「orderId」、Srが「T」、Suが「F」、Aが「T」というレコードが登録される。このレコードは、辞書データ型ID「1」のキー名「orderId」の受入仕様がSr=T、Su=FかつA=Tで表されることを示す。
例えば、受入仕様テーブル162には、辞書データ型IDが「1」、キー名が「orderId」、Srが「T」、Suが「F」、Aが「T」というレコードが登録される。このレコードは、辞書データ型ID「1」のキー名「orderId」の受入仕様がSr=T、Su=FかつA=Tで表されることを示す。
データ授受成功度演算部135は、生成仕様テーブル161および受入仕様テーブル162に基づいて、データ授受成功度テーブルを生成する。
図14は、データ授受成功度テーブルの例を示す図である。
図14は、データ授受成功度テーブルの例を示す図である。
データ授受成功度テーブル171は、解析結果記憶部124に格納される。データ授受成功度テーブル171は、機能の識別子、版番号、呼出先の機能識別子、呼出先の旧版番号、呼出先の版番号、キー名、種別およびデータ授受成功度の項目を含む。機能の識別子、版番号、呼出先の機能識別子、呼出先の旧版番号、呼出先の版番号、キー名および種別の組は、データ授受成功度テーブル171の主キー(pk)である。
機能の識別子の項目には、呼出元側のソースコードにおける機能の識別子が登録される。版番号の項目には、呼出元側のソースコードの版番号が登録される。呼出先の機能識別子の項目には、呼出先側のソースコードにおける機能の識別子が登録される。呼出先の旧版番号の項目には、呼出先側のソースコードの改版前の版番号が登録される。呼出先の版番号の項目には、呼出先側のソースコードの改版後の版番号が登録される。キー名の項目には、キー名が登録される。種別の項目には、「リクエスト」であるか「レスポンス」であるかの種別が登録される。データ授受成功度の項目には、データ授受成功度を表す論理値が登録される。データ授受成功度は、3値の多値論理値で表される。データ授受成功度は、必ず成功することを「T」、成功することもあるし失敗することもあることを「H」、必ず失敗することを「F」で表す。データ授受成功度「H」は、データ授受成功度「T」および「F」の中間の状態を示す。
例えば、データ授受成功度テーブル171には、機能の識別子が「GET /order」、版番号が「1.0」、呼出先の機能識別子が「GET /progress」、呼出先の旧版番号が「1.0」、呼出先の版番号が「2.0」、キー名が「orderId」、種別が「リクエスト」、データ授受成功度が「T」というレコードが登録される。このレコードは、呼出元の機能識別子「GET /order」、版番号「1.0」、呼出先の機能識別子「GET /progress」、呼出先の旧版番号「1.0」、呼出先の版番号「2.0」、キー名「orderId」、種別「リクエスト」に対して、データ授受成功度が「T」、すなわち、必ず成功であることを示す。
ここで、データ授受成功度は、呼出先のソースコードの改版による呼出元のソースコード、あるいは、呼出元のソースコードに対応する機能への影響の度合い、すなわち、影響度を表すと言える。
例えば、データ授受成功度が「F」のとき、呼出先のソースコードの改版によって呼出元の機能が必ず影響を受けることを意味する。また、種別「レスポンス」に対してデータ授受成功度が「H」のとき、呼出先のソースコードの改版によって呼出元の機能が影響を受ける可能性があることを意味する。更に、種別「レスポンス」に対してデータ授受成功度が「T」のとき、呼出先のソースコードの改版によって呼出元の機能が影響を受けないことを意味する。
不要コード可能性演算部136は、生成仕様テーブル161および受入仕様テーブル162に基づいて、不要コード可能性テーブルを生成する。
図15は、不要コード可能性テーブルの例を示す図である。
図15は、不要コード可能性テーブルの例を示す図である。
不要コード可能性テーブル172は、解析結果記憶部124に格納される。不要コード可能性テーブル172は、機能の識別子、版番号、呼出先の機能識別子、呼出先の旧版番号、呼出先の版番号、キー名、対象コードおよび不要コード可能性の項目を含む。機能の識別子、版番号、呼出先の機能識別子、呼出先の旧版番号、呼出先の版番号、キー名および対象コードの組は、不要コード可能性テーブル172の主キー(pk)である。
機能の識別子の項目には、呼出元側のソースコードにおける機能の識別子が登録される。版番号の項目には、呼出元型のソースコードの版番号が登録される。呼出先の機能識別子の項目には、呼出先側のソースコードにおける機能の識別子が登録される。呼出先の旧版番号の項目には、呼出先側のソースコードの改版前の版番号が登録される。呼出先の版番号の項目には、呼出先側のソースコードの改版後の版番号が登録される。キー名の項目には、キー名が登録される。対象コードの項目には、不要コードが存在する可能性のあるソースコードが呼出先側であるか呼出元側であるかの区分が登録される。不要コード可能性の項目には、不要コードが存在する可能性の有無を表す論理値が登録される。不要コードが存在する可能性がある場合、不要コード可能性は「T」である。不要コードが存在する可能性がない場合、不要コード可能性は「F」である。
例えば、不要コード可能性テーブル172には、機能の識別子が「GET /order」、版番号が「1.0」、呼出先の機能識別子が「GET /progress」、呼出先の旧版番号「1.0」、呼出先の版番号が「2.0」、キー名が「orderId」、対象コードが「呼出先」、不要コード可能性が「F」というレコードが登録される。このレコードは、呼出元の機能識別子「GET /order」、版番号「1.0」、呼出先の機能識別子「GET /progress」、呼出先の旧版番号「1.0」、呼出先の版番号「2.0」、キー名「orderId」、対象コード「呼出先」に対して、不要コード可能性が「F」、すなわち、呼出先側のソースコードに不要コードが存在する可能性がないことを示す。
また、不要コード可能性テーブル172には、機能の識別子「GET /order」のキー名「statusString」について、呼出元側のソースコードに不要コードが存在する可能性がないことを示すレコードも登録されている。更に、不要コード可能性テーブル172には、機能の識別子「GET /order」のキー名「itemLocation」について、呼出元側のソースコードに不要コードが存在する可能性がないことを示すレコードも登録されている。
次に、変更影響解析装置100の処理手順を説明する。
図16は、変更影響解析装置の処理例を示すフローチャートである。
(S10)制御部130は、対象のソースコードに関して、各REST APIに対してステップS11〜S13を繰り返し実行する。ここで、REST API、すなわち、当該ソースコードに実装される機能は、アクションaおよびエンドポイントeの組により識別される。処理対象とするREST APIの識別情報は、ユーザにより入力されてもよいし、リポジトリサーバ200に記憶された各ソースコードから、制御部130により抽出されてもよい。
図16は、変更影響解析装置の処理例を示すフローチャートである。
(S10)制御部130は、対象のソースコードに関して、各REST APIに対してステップS11〜S13を繰り返し実行する。ここで、REST API、すなわち、当該ソースコードに実装される機能は、アクションaおよびエンドポイントeの組により識別される。処理対象とするREST APIの識別情報は、ユーザにより入力されてもよいし、リポジトリサーバ200に記憶された各ソースコードから、制御部130により抽出されてもよい。
(S11)制御部130は、リポジトリサーバ200上の各ソースコードのうち、対象REST APIを実装する各版番号vのメソッドmに対して、ステップS12を繰り返し実行する。
(S12)制御部130は、機能仕様抽出を実行する。機能仕様抽出の詳細は後述される。なお、機能仕様抽出のための引数は、REST APIのアクションa、REST APIのエンドポイントe、REST APIを実装するメソッドmおよびリポジトリサーバ200におけるソースコードの版番号vである。
(S13)制御部130は、全ての(v,m)の組に対して、ステップS12を実行すると、繰り返しを終了し、ステップS14に処理を進める。
(S14)制御部130は、全ての(a,e)の組に対して、ステップS11〜S13を実行すると、繰り返しを終了し、ステップS15に処理を進める。
(S14)制御部130は、全ての(a,e)の組に対して、ステップS11〜S13を実行すると、繰り返しを終了し、ステップS15に処理を進める。
(S15)制御部130は、変更影響抽出の指示を受け付けたか否かを判定する。変更影響抽出の指示を受け付けた場合、制御部130は、ステップS16に処理を進める。変更影響抽出の指示を受け付けていない場合、制御部130は、ステップS15に処理を進め、変更影響抽出の指示を待ち受ける。例えば、変更影響抽出の指示は、ユーザにより、変更影響解析装置100に入力される。変更影響抽出の指示は、変更影響の抽出対象とする機能の識別子、改版対象のソースコードの改版前の版数、および、改版対象のソースコードの改版後の版数の指定を含む。
(S16)制御部130は、削除差分抽出を実行する。削除差分抽出の詳細は後述される。
(S17)制御部130は、仕様変換を実行する。仕様変換の詳細は後述される。
(S17)制御部130は、仕様変換を実行する。仕様変換の詳細は後述される。
(S18)制御部130は、データ授受成功度の演算を実行する。データ授受成功度の演算の詳細は後述される。
(S19)制御部130は、データ処理コードの不要可能性の演算を実行する。データ処理コードの不要可能性の演算の詳細は後述される。
(S19)制御部130は、データ処理コードの不要可能性の演算を実行する。データ処理コードの不要可能性の演算の詳細は後述される。
制御部130は、ステップS18,S19の実行結果に基づいて、解析結果を出力する。例えば、出力部137は、ディスプレイ111に解析結果を表示させることもできるし、通信部140を介して、ネットワーク30に接続された他のコンピュータに解析結果を送信させてもよい。
なお、ステップS10〜S14における機能仕様抽出は、任意のタイミングで実行され得る。例えば、リポジトリサーバ200に新たなソースコードが格納された場合に、制御部130は、リポジトリサーバ200から新たなソースコードが格納された旨の通知を受け付けてもよい。そして、制御部130は、当該通知を契機にして、新たなソースコードをリポジトリサーバ200から取得し、当該ソースコードに対して、ステップS10〜S14を実行してもよい。
図17は、機能仕様抽出例を示すフローチャートである。
機能仕様抽出はステップS12に相当する。
(S20)機能仕様抽出部131は、新たな辞書データ型IDを生成する。新たな辞書データ型IDをidとする。
機能仕様抽出はステップS12に相当する。
(S20)機能仕様抽出部131は、新たな辞書データ型IDを生成する。新たな辞書データ型IDをidとする。
(S21)機能仕様抽出部131は、データ授受仕様のうちのリクエスト受入仕様のレコードを作成し、データ授受仕様テーブル151に登録する。当該レコードは、仕様種別「QA」、機能の識別子「a+e」、版番号「v」、辞書データ型ID「id」である。それ以外の項目は「null」である。ここで、「a+e」は、アクションの文字列とエンドポイントの文字列とを結合した文字列を意味する。
(S22)機能仕様抽出部131は、暗黙必須度の辞書データ型仕様のレコードを作成し、辞書データ型仕様テーブル152に登録する。当該レコードは、辞書データ型ID「id」、キー名「(暗黙)」、必須度「unattended」である。
(S23)機能仕様抽出部131は、該当のREST APIに入力される各パラメタに対してステップS24,S25を繰り返し実行する。処理対象のパラメタをpとする。
(S24)機能仕様抽出部131は、パラメタpに対する辞書データ型仕様のレコードs1を作成し、辞書データ型仕様テーブル152に登録する。レコードs1は、辞書データ型ID「id」、キー名「(パラメタpの名前)」である。この段階では、レコードs1の必須度は未登録である。
(S24)機能仕様抽出部131は、パラメタpに対する辞書データ型仕様のレコードs1を作成し、辞書データ型仕様テーブル152に登録する。レコードs1は、辞書データ型ID「id」、キー名「(パラメタpの名前)」である。この段階では、レコードs1の必須度は未登録である。
(S25)機能仕様抽出部131は、データ受入仕様の抽出を行う。データ受入仕様の抽出の詳細は後述される。データ受入仕様の抽出のための引数は、メソッドm上のパラメタpに対応する引数、メソッドmおよび辞書データ型仕様のレコードs1である。
(S26)機能仕様抽出部131は、該当のREST APIに入力される全てのパラメタpに対してステップS24,S25を実行すると、繰り返しを終了し、ステップS27に処理を進める。
図18は、機能仕様抽出例(続き)を示すフローチャートである。
(S27)機能仕様抽出部131は、新たな辞書データ型IDを生成する。新たな辞書データ型IDをid2とする。
(S27)機能仕様抽出部131は、新たな辞書データ型IDを生成する。新たな辞書データ型IDをid2とする。
(S28)機能仕様抽出部131は、データ授受仕様のうちのレスポンス生成仕様のレコードを作成し、データ授受仕様テーブル151に登録する。当該レコードは、仕様種別「PC」、機能の識別子「a+e」、版番号「v」、辞書データ型ID「id2」である。それ以外の項目は「null」である。
(S29)機能仕様抽出部131は、暗黙必須度の辞書データ型仕様のレコードを作成し、辞書データ型仕様テーブル152に登録する。当該レコードは、辞書データ型ID「id2」、キー名「(暗黙)」、必須度「impossible」である。
(S30)機能仕様抽出部131は、該当のREST APIのレスポンスデータの各キー付き値に対してステップS31,S32を繰り返し実行する。処理対象のキー名付き値をkv2とする。図7のソースコード201の例では、10行目の「o.orderId」の「orderId」、11行目の「o.itemName」の「itemName」および14行目の「o.status」の「status」のそれぞれが、kv2の一例である。
(S31)機能仕様抽出部131は、キー名付き値kv2に対する辞書データ型仕様のレコードs2を作成し、辞書データ型仕様テーブル152に登録する。レコードs2は、辞書データ型ID「id2」、キー名「(kv2のキー名)」である。この段階では、レコードs2の必須度は未登録である。
(S32)機能仕様抽出部131は、データ生成仕様の抽出を行う。データ生成仕様の抽出の詳細は後述される。データ生成仕様の抽出のための引数は、対象のキー名付き値kv3、メソッドmおよび辞書データ型仕様のレコードs2である。
(S33)機能仕様抽出部131は、該当のREST APIのレスポンスデータの全てのキー名付き値kv2に対してステップS31,S32を実行すると、繰り返しを終了し、ステップS34に処理を進める。
図19は、機能仕様抽出例(続き)を示すフローチャートである。
(S34)機能仕様抽出部131は、メソッドm中で呼び出す各REST APIに対して、ステップS35〜S48を繰り返し実行する。当該REST APIは、メソッドmから呼び出される呼出先の機能である。呼出先のREST APIは、アクションa2およびエンドポイントe2の組により識別される。
(S34)機能仕様抽出部131は、メソッドm中で呼び出す各REST APIに対して、ステップS35〜S48を繰り返し実行する。当該REST APIは、メソッドmから呼び出される呼出先の機能である。呼出先のREST APIは、アクションa2およびエンドポイントe2の組により識別される。
(S35)機能仕様抽出部131は、新たな辞書データ型IDを生成する。新たな辞書データ型IDをid3とする。
(S36)機能仕様抽出部131は、データ授受仕様のうちのリクエスト生成仕様のレコードを作成し、データ授受仕様テーブル151に登録する。当該レコードは、仕様種別「QC」、機能の識別子「a+e」、版番号「v」、呼出先の機能識別子「a2+e2」、辞書データ型ID「id3」である。それ以外の項目は「null」である。
(S36)機能仕様抽出部131は、データ授受仕様のうちのリクエスト生成仕様のレコードを作成し、データ授受仕様テーブル151に登録する。当該レコードは、仕様種別「QC」、機能の識別子「a+e」、版番号「v」、呼出先の機能識別子「a2+e2」、辞書データ型ID「id3」である。それ以外の項目は「null」である。
(S37)機能仕様抽出部131は、暗黙必須度の辞書データ型仕様のレコードを作成し、辞書データ型仕様テーブル152に登録する。当該レコードは、辞書データ型ID「id3」、キー名「(暗黙)」、必須度「impossible」である。
(S38)機能仕様抽出部131は、該当の呼出元のREST APIのリクエストデータの各キー付き値に対してステップS39,S40を繰り返し実行する。処理対象のキー名付き値をkv3とする。
(S39)機能仕様抽出部131は、キー名付き値kv3に対する辞書データ型仕様のレコードs3を作成し、辞書データ型仕様テーブル152に登録する。レコードs3は、辞書データ型ID「id3」、キー名「(kv3のキー名)」である。この段階では、レコードs3の必須度は未登録である。
(S40)機能仕様抽出部131は、データ生成仕様の抽出を行う。データ生成仕様の抽出の詳細は後述される。データ生成仕様の抽出のための引数は、対象のキー名付き値kv3、メソッドmおよび辞書データ型仕様のレコードs3である。
(S41)機能仕様抽出部131は、該当の呼出元のREST APIのリクエストデータの全てのキー名付き値kv3に対してステップS39,S40を実行すると、繰り返しを終了し、ステップS42に処理を進める。
図20は、機能仕様抽出例(続き)を示すフローチャートである。
(S42)機能仕様抽出部131は、新たな辞書データ型IDを生成する。新たな辞書データ型IDをid4とする。
(S42)機能仕様抽出部131は、新たな辞書データ型IDを生成する。新たな辞書データ型IDをid4とする。
(S43)機能仕様抽出部131は、データ授受仕様のうちのレスポンス受入仕様のレコードを作成し、データ授受仕様テーブル151に登録する。当該レコードは、仕様種別「PA」、機能の識別子「a+e」、版番号「v」、呼出先の機能識別子「a2+e2」、辞書データ型ID「id4」である。それ以外の項目は「null」である。
(S44)機能仕様抽出部131は、暗黙必須度の辞書データ型仕様のレコードを作成し、辞書データ型仕様テーブル152に登録する。当該レコードは、辞書データ型ID「id4」、キー名「(暗黙)」、必須度「unattended」である。
(S45)機能仕様抽出部131は、呼出元のREST APIにおいて、レスポンスデータを格納する変数をrとする。図7のソースコード201の例では、20行目の変数「p」がrの一例である。
(S46)機能仕様抽出部131は、変数rの各キー名付き値に対してステップS47,S48を繰り返し実行する。処理対象のキー名付き値をkv4とする。図7のソースコード201の例では24行目の「statusString」がkv4の一例である。
(S47)機能仕様抽出部131は、キー名付き値kv4に対する辞書データ型仕様のレコードs4を作成し、辞書データ型仕様テーブル152に登録する。レコードs4は、辞書データ型ID「id4」、キー名「(kv4のキー名)」である。この段階では、レコードs4の必須度は未登録である。
(S48)機能仕様抽出部131は、データ受入仕様の抽出を行う。データ受入仕様の抽出の詳細は後述される。データ受入仕様の抽出のための引数は、対象のキー名付き値kv4、メソッドmおよび辞書データ型仕様のレコードs4である。
(S49)機能仕様抽出部131は、変数rの全てのキー名付き値kv4に対してステップS47,S48を実行すると、繰り返しを終了し、ステップS50に処理を進める。
(S50)機能仕様抽出部131は、メソッドm中で呼び出す呼出先の各REST APIに対してステップS35〜S48を実行すると、繰り返しを終了し、機能仕様抽出を終了する。
(S50)機能仕様抽出部131は、メソッドm中で呼び出す呼出先の各REST APIに対してステップS35〜S48を実行すると、繰り返しを終了し、機能仕様抽出を終了する。
図21は、データ受入仕様の抽出例を示すフローチャートである。
データ受入仕様の抽出はステップS25,S48に相当する。
(S60)機能仕様抽出部131は、メソッドm中での対象変数の参照前に、値設定確認があるか否かを判定する。対象変数の参照前に値設定確認がない場合、機能仕様抽出部131は、ステップS61に処理を進める。対象変数の参照前に値設定確認がある場合、機能仕様抽出部131は、ステップS62に処理を進める。例えば、値設定確認とは、対象変数に対する「null」か否かの確認などを意味する。例えば、メソッドmにおいて、当該値設定確認に応じて、対象変数の参照が行われるか否かが決定される場合に、値設定確認があることになる。値設定確認後に対象変数の参照が行われている例として、図7のソースコード201の12行目〜13行目の変数「withStatus」の記述が挙げられる。
データ受入仕様の抽出はステップS25,S48に相当する。
(S60)機能仕様抽出部131は、メソッドm中での対象変数の参照前に、値設定確認があるか否かを判定する。対象変数の参照前に値設定確認がない場合、機能仕様抽出部131は、ステップS61に処理を進める。対象変数の参照前に値設定確認がある場合、機能仕様抽出部131は、ステップS62に処理を進める。例えば、値設定確認とは、対象変数に対する「null」か否かの確認などを意味する。例えば、メソッドmにおいて、当該値設定確認に応じて、対象変数の参照が行われるか否かが決定される場合に、値設定確認があることになる。値設定確認後に対象変数の参照が行われている例として、図7のソースコード201の12行目〜13行目の変数「withStatus」の記述が挙げられる。
(S61)機能仕様抽出部131は、辞書データ型仕様のレコードsの必須度に「mandatory」を設定する。ここで、ステップS25ではs=s1であり、ステップS48ではs=s4である。そして、機能仕様抽出部131は、データ受入仕様の抽出を終了する。
(S62)機能仕様抽出部131は、辞書データ型仕様のレコードsの必須度に「possible」を設定する。ここで、ステップS25ではレコードs=s1であり、ステップS48ではレコードs=s4である。そして、機能仕様抽出部131は、データ受入仕様の抽出を終了する。
図22は、データ生成仕様の抽出例を示すフローチャートである。
データ生成仕様の抽出はステップS32,S40に相当する。
(S70)機能仕様抽出部131は、メソッドm内の条件分岐中でキー名kvの値を設定しているか否かを判定する。ここで、条件分岐中とは、例えば、if文におけるthen節の内部やelse節の内部である。条件分岐中でkvの値を設定していない場合、機能仕様抽出部131は、ステップS71に処理を進める。条件分岐中でkvの値を設定している場合、機能仕様抽出部131は、ステップS72に処理を進める。ここで、ステップS32ではキー名kv=kv2であり、ステップS40ではキー名kv=kv3である。条件分岐中でkvの値を設定している例としては、図7のソースコード201の13行目〜14行目の「status」に関する記述が挙げられる。
データ生成仕様の抽出はステップS32,S40に相当する。
(S70)機能仕様抽出部131は、メソッドm内の条件分岐中でキー名kvの値を設定しているか否かを判定する。ここで、条件分岐中とは、例えば、if文におけるthen節の内部やelse節の内部である。条件分岐中でkvの値を設定していない場合、機能仕様抽出部131は、ステップS71に処理を進める。条件分岐中でkvの値を設定している場合、機能仕様抽出部131は、ステップS72に処理を進める。ここで、ステップS32ではキー名kv=kv2であり、ステップS40ではキー名kv=kv3である。条件分岐中でkvの値を設定している例としては、図7のソースコード201の13行目〜14行目の「status」に関する記述が挙げられる。
(S71)機能仕様抽出部131は、辞書データ型仕様のレコードsの必須度に「mandatory」を設定する。ここで、ステップS32ではレコードs=s2であり、ステップS40ではレコードs=s3である。そして、機能仕様抽出部131は、データ生成仕様の抽出を終了する。
(S72)機能仕様抽出部131は、辞書データ型仕様のレコードsの必須度に「possible」を設定する。ここで、ステップS32ではレコードs=s2であり、ステップS40ではレコードs=s3である。そして、機能仕様抽出部131は、データ生成仕様の抽出を終了する。
図23は、削除差分の抽出例を示すフローチャートである。
削除差分の抽出はステップS16に相当する。削除差分抽出部133には、引数として機能の識別子ae、新版番号nおよび旧版番号oが渡される。
削除差分の抽出はステップS16に相当する。削除差分抽出部133には、引数として機能の識別子ae、新版番号nおよび旧版番号oが渡される。
(S80)削除差分抽出部133は、データ授受仕様テーブル151の各仕様種別に対して下記の処理を繰り返し実行する。仕様種別の候補は、QA、PC、QC、PAである。処理対象の仕様種別をkとする。
(S81)削除差分抽出部133は、データ授受仕様テーブル151に基づいて、仕様種別k、機能の識別子ae、版番号oに対応するデータ授受仕様のレコードsがあるか否かを判定する。当該データ授受仕様のレコードsがある場合、削除差分抽出部133は、ステップS82に処理を進める。当該データ授受仕様のレコードsがない場合、削除差分抽出部133は、ステップS86に処理を進める。
ここで、「データ授受仕様のレコードs」を、図中、「データ授受仕様s」のように略記することがある。
(S82)削除差分抽出部133は、レコードsの辞書データ型IDをidoとする。
(S82)削除差分抽出部133は、レコードsの辞書データ型IDをidoとする。
(S83)削除差分抽出部133は、機能の識別子ae、版番号nに対応するデータ授受仕様のレコードsnがあるか否かを判定する。当該データ授受仕様のレコードsnがある場合、削除差分抽出部133は、ステップS87に処理を進める。当該データ授受仕様のレコードsnがない場合、削除差分抽出部133は、ステップS84に処理を進める。
(S84)削除差分抽出部133は、データ授受仕様のレコードsn2を作成し、データ授受仕様テーブル151に登録する。当該レコードsn2は、仕様種別「k」、旧版番号「o」、版番号「n」、辞書データ型ID「idn2」である。削除差分抽出部133は、辞書データ型ID「idn2」を新規に付与する。レコードsn2のその他の各pkの項目は「(レコードsの同名の項目の値)」である。レコードsn2のそれ以外の項目は「null」となる。
(S85)削除差分抽出部133は、暗黙必須度の辞書データ型仕様のレコードを作成し、辞書データ型仕様テーブル152に登録する。当該レコードは、辞書データ型ID「idn2」、キー名「(暗黙)」、必須度「impossible」である。
(S86)削除差分抽出部133は、全ての仕様種別kに対してステップS81〜S85、あるいは、場合によってはS81〜S83,S87〜S94を実行すると、繰り返しを終了し、削除差分の抽出を終了する。
(S87)削除差分抽出部133は、データ授受仕様のレコードsnの辞書データ型IDをidnとする。
(S88)削除差分抽出部133は、辞書データ型IDがidoである辞書データ型仕様の各キー名に対してステップS89〜S93を繰り返し実行する。処理対象のキー名をkvoとする。
(S88)削除差分抽出部133は、辞書データ型IDがidoである辞書データ型仕様の各キー名に対してステップS89〜S93を繰り返し実行する。処理対象のキー名をkvoとする。
(S89)削除差分抽出部133は、辞書データ型仕様テーブル152に基づいて、キー名kvoとキー名が同一で辞書データ型IDがidnである辞書データ型仕様のレコードがあるか否かを判定する。当該辞書データ型仕様のレコードがない場合、削除差分抽出部133は、ステップS90に処理を進める。当該辞書データ型仕様のレコードがある場合、削除差分抽出部133は、ステップS94に処理を進める。
(S90)削除差分抽出部133は、データ授受仕様テーブル151において、データ授受仕様のレコードsn2を作成済みであるか否かを判定する。データ授受仕様のレコードsn2を作成済みでない場合、削除差分抽出部133は、ステップS91に処理を進める。データ授受仕様のレコードsn2を作成済みの場合、削除差分抽出部133は、ステップS93に処理を進める。
(S91)削除差分抽出部133は、データ授受仕様のレコードsn2を作成し、データ授受仕様テーブル151に登録する。当該レコードsn2は、仕様種別「k」、旧版番号「o」、版番号「n」、辞書データ型ID「idn2」である。削除差分抽出部133は、辞書データ型ID「idn2」を新規に付与する。レコードsn2のその他の各pkの項目は「(レコードsの同名の項目の値)」である。レコードsn2のそれ以外の項目は「null」となる。
(S92)削除差分抽出部133は、暗黙必須度の辞書データ型仕様のレコードを作成し、辞書データ型仕様テーブル152に登録する。当該レコードは、辞書データ型ID「idn2」、キー名「(暗黙)」、必須度「(データ授受仕様のレコードsの辞書データ型IDに対応するキー名「暗黙」の必須度)」である。
(S93)削除差分抽出部133は、辞書データ型仕様のレコードを作成し、辞書データ型仕様テーブル152に登録する。当該レコードは、辞書データ型ID「idn2」、キー名「(kvoのキー名)」、必須度「impossible」である。
(S94)削除差分抽出部133は、全てのkvoに対してステップS89〜S93を実行すると、繰り返しを終了し、ステップS86に処理を進める。
図24は、仕様変換例を示すフローチャートである。
図24は、仕様変換例を示すフローチャートである。
仕様変換はステップS17に相当する。
(S100)仕様変換部134は、データ授受仕様の各仕様に対して、ステップS101〜S118を繰り返し実行する。データ授受仕様の各仕様は、データ授受仕様テーブル151の各レコードを意味する。処理対象のレコードをs0とする。レコードs0において、仕様種別はk、機能の識別子はa+e、旧版番号はo、版番号はv、呼出先の機能識別子はdであるとする。
(S100)仕様変換部134は、データ授受仕様の各仕様に対して、ステップS101〜S118を繰り返し実行する。データ授受仕様の各仕様は、データ授受仕様テーブル151の各レコードを意味する。処理対象のレコードをs0とする。レコードs0において、仕様種別はk、機能の識別子はa+e、旧版番号はo、版番号はv、呼出先の機能識別子はdであるとする。
(S101)仕様変換部134は、対象仕様のレコードs0における辞書データ型IDをidとする。
(S102)仕様変換部134は、辞書データ型IDがidである、辞書データ型仕様の各仕様に対して下記の処理を繰り返し実行する。辞書データ型仕様の各仕様は、辞書データ型仕様テーブル152の各レコードを意味する。辞書データ型仕様テーブル152の処理対象のレコードをsとする。
(S102)仕様変換部134は、辞書データ型IDがidである、辞書データ型仕様の各仕様に対して下記の処理を繰り返し実行する。辞書データ型仕様の各仕様は、辞書データ型仕様テーブル152の各レコードを意味する。辞書データ型仕様テーブル152の処理対象のレコードをsとする。
(S103)仕様変換部134は、レコードs0の仕様種別kが「QC」または「PC」、すなわち、生成仕様であるか否かを判定する。レコードs0の仕様種別kが「QC」または「PC」である場合、仕様変換部134は、ステップS104に処理を進める。レコードs0の仕様種別kが「QC」および「PC」の何れでもない場合、仕様変換部134は、ステップS110に処理を進める。
(S104)仕様変換部134は、Ea=F、En=Fに設定する。なお、Ea=Fなどに設定することを、図中では「Ea:=F」のように表記する。
(S105)仕様変換部134は、レコードsの必須度がmandatoryであるか否かを判定する。レコードsの必須度がmandatoryである場合、仕様変換部134は、ステップS106に処理を進める。レコードsの必須度がmandatoryでない場合、仕様変換部134は、ステップS107に処理を進める。
(S105)仕様変換部134は、レコードsの必須度がmandatoryであるか否かを判定する。レコードsの必須度がmandatoryである場合、仕様変換部134は、ステップS106に処理を進める。レコードsの必須度がmandatoryでない場合、仕様変換部134は、ステップS107に処理を進める。
(S106)仕様変換部134は、Ea=Tに設定する。そして、仕様変換部134は、ステップS109に処理を進める。
(S107)仕様変換部134は、レコードsの必須度がimpossibleであるか否かを判定する。レコードsの必須度がimpossibleである場合、仕様変換部134は、ステップS108に処理を進める。レコードsの必須度がimpossibleでない場合、仕様変換部134は、ステップS109に処理を進める。
(S107)仕様変換部134は、レコードsの必須度がimpossibleであるか否かを判定する。レコードsの必須度がimpossibleである場合、仕様変換部134は、ステップS108に処理を進める。レコードsの必須度がimpossibleでない場合、仕様変換部134は、ステップS109に処理を進める。
(S108)仕様変換部134は、En=Tに設定する。
(S109)仕様変換部134は、辞書データ型ID「id」およびレコードsのキー名に対する生成仕様タプルを生成し、生成仕様テーブル161に登録する。生成仕様タプルのEa,Enの値は、ステップS104〜S108で設定された値となる。そして、仕様変換部134は、ステップS118に処理を進める。
(S109)仕様変換部134は、辞書データ型ID「id」およびレコードsのキー名に対する生成仕様タプルを生成し、生成仕様テーブル161に登録する。生成仕様タプルのEa,Enの値は、ステップS104〜S108で設定された値となる。そして、仕様変換部134は、ステップS118に処理を進める。
(S110)仕様変換部134は、Sr=T、Su=T、A=Tに設定する。
(S111)仕様変換部134は、レコードsの必須度がmandatoryであるか否かを判定する。レコードsの必須度がmandatoryである場合、仕様変換部134は、ステップS112に処理を進める。レコードsの必須度がmandatoryでない場合、仕様変換部134は、ステップS113に処理を進める。
(S111)仕様変換部134は、レコードsの必須度がmandatoryであるか否かを判定する。レコードsの必須度がmandatoryである場合、仕様変換部134は、ステップS112に処理を進める。レコードsの必須度がmandatoryでない場合、仕様変換部134は、ステップS113に処理を進める。
(S112)仕様変換部134は、Su=Fに設定する。そして、仕様変換部134は、ステップS117に処理を進める。
(S113)仕様変換部134は、レコードsの必須度がimpossibleであるか否かを判定する。レコードsの必須度がimpossibleである場合、仕様変換部134は、ステップS114に処理を進める。レコードsの必須度がimpossibleでない場合、仕様変換部134は、ステップS115に処理を進める。
(S113)仕様変換部134は、レコードsの必須度がimpossibleであるか否かを判定する。レコードsの必須度がimpossibleである場合、仕様変換部134は、ステップS114に処理を進める。レコードsの必須度がimpossibleでない場合、仕様変換部134は、ステップS115に処理を進める。
(S114)仕様変換部134は、Sr=F、A=Fに設定する。そして、仕様変換部134は、ステップS117に処理を進める。
(S115)仕様変換部134は、レコードsの必須度がunattendedであるか否かを判定する。レコードsの必須度がunattendedである場合、仕様変換部134は、ステップS116に処理を進める。レコードsの必須度がunattendedでない場合、仕様変換部134は、ステップS117に処理を進める。
(S115)仕様変換部134は、レコードsの必須度がunattendedであるか否かを判定する。レコードsの必須度がunattendedである場合、仕様変換部134は、ステップS116に処理を進める。レコードsの必須度がunattendedでない場合、仕様変換部134は、ステップS117に処理を進める。
(S116)仕様変換部134は、A=Fに設定する。
(S117)仕様変換部134は、辞書データ型ID「id」およびレコードsのキー名に対する受入仕様タプルを生成し、受入仕様テーブル162に登録する。受入仕様タプルのSr,Su,Aの値は、ステップS110〜S116で設定された値となる。
(S117)仕様変換部134は、辞書データ型ID「id」およびレコードsのキー名に対する受入仕様タプルを生成し、受入仕様テーブル162に登録する。受入仕様タプルのSr,Su,Aの値は、ステップS110〜S116で設定された値となる。
(S118)仕様変換部134は、辞書データ型仕様テーブル152における辞書データ型ID「id」の全てのレコードsに対してステップS103以降の処理を実行すると、繰り返しを終了して、ステップS119に処理を進める。
(S119)仕様変換部134は、データ授受仕様テーブル151における全てのレコードs0に対してステップS101以降の処理を実行すると、繰り返しを終了して、仕様変換を終了する。
図25は、データ授受成功度の演算例を示すフローチャートである。
データ授受成功度の演算はステップS18に相当する。データ授受成功度演算部135には、引数として、呼出元の機能識別子c、呼出元の版番号v、呼出先の機能識別子e、呼出先の新版番号nおよび旧版番号oが渡される。
データ授受成功度の演算はステップS18に相当する。データ授受成功度演算部135には、引数として、呼出元の機能識別子c、呼出元の版番号v、呼出先の機能識別子e、呼出先の新版番号nおよび旧版番号oが渡される。
(S120)データ授受成功度演算部135は、リクエスト送信側の辞書データ型IDをsとし、sdを「null」に設定する。具体的には、データ授受成功度演算部135は、データ授受仕様テーブル151において、仕様種別QC、機能の識別子c、版番号v、呼出先の機能識別子eに対応する辞書データ型IDをsとする。
(S121)データ授受成功度演算部135は、リクエスト受信側の辞書データ型IDをrとし、rdを設定する。具体的には、データ授受成功度演算部135は、データ授受仕様テーブル151において、仕様種別QA、機能の識別子e、版番号nのレコードのうち、旧版番号「null」に対する辞書データ型IDをrとし、旧版番号oに対する辞書データ型IDをrdとする。
(S122)データ授受成功度演算部135は、多値論理値の演算を行う。多値論理値の演算の詳細は後述される。ステップS122の多値論理値の演算のための引数は、演算対象、ステップS120,S121のs,sd,r,rd、呼出元の機能識別子cと版番号v、呼出先の機能識別子eと新版番号nと旧版番号o、および、種別「リクエスト」である。演算対象としては、「データ授受成功度」または「データ処理コードの不要可能性」が指定される。ステップS18では、演算対象として、「データ授受成功度」が指定される。
(S123)データ授受成功度演算部135は、レスポンス送信側の辞書データ型IDをsとし、sdを設定する。具体的には、データ授受成功度演算部135は、データ授受仕様テーブル151において、仕様種別PC、機能の識別子e、版番号nのレコードのうち、旧版番号「null」に対する辞書データ型IDをsとし、旧版番号oに対する辞書データ型IDをsdとする。
(S124)データ授受成功度演算部135は、レスポンス受信側の辞書データ型IDをrとし、rdを「null」に設定する。具体的には、データ授受成功度演算部135は、データ授受仕様テーブル151において、仕様種別PA、機能の識別子c、版番号v、呼出先の機能識別子eのレコードの辞書データ型IDをrとする。
(S125)データ授受成功度演算部135は、多値論理値の演算を行う。多値論理値の演算の詳細は後述される。ステップS125の多値論理値の演算のための引数は、演算対象を示す情報、ステップS123,S124のs,sd,r,rd、呼出元の機能識別子cと版番号v、呼出先の機能識別子eと新版番号nと旧版番号o、および、種別「リクエスト」である。演算対象を示す情報としては、「データ授受成功度」または「データ処理コードの不要可能性」が指定される。ステップS18では、演算対象として、「データ授受成功度」が指定される。そして、データ授受成功度演算部135は、データ授受成功度の演算を終了する。
なお、ステップS19の「データ処理コードの不要可能性の演算」も図25で例示した「データ授受成功度の演算」と同様の手順により実行される。ただし、ステップS19は、不要コード可能性演算部136により実行される。このため、「データ処理コードの不要可能性の演算」の場合は、ステップS120〜S125の「データ授受成功度演算部135」を、「不要コード可能性演算部136」と読み替えればよい。更に、ステップS19の場合、ステップS122,S125の演算対象を示す引数に「データ処理コードの不要可能性」が指定される。
図26は、多値論理値の演算例を示すフローチャートである。
多値論理値の演算はステップS122,S125に相当する。多値論理値の演算の引数は、演算対象、送受信されるデータの辞書データ型(s,sd,r,rd)、呼出元の機能識別子cと版番号v、呼出先の機能識別子eと新版番号nと旧版番号o、および、種別tである。なお、多値論理値の演算では、演算対象の引数として「データ授受成功度」または「データ処理コードの不要可能性」が指定される。以下では、演算対象が「データ授受成功度」の場合(ステップS18)のデータ授受成功度演算部135の処理を例示するが、演算対象が「データ処理コードの不要可能性」の場合(ステップS19)の不要コード可能性演算部136の処理も同様の手順となる。ただし、図26の各ステップのうち、ステップS140についてはデータ授受成功度演算部135のみが行う手順であり、ステップS141〜S144については不要コード可能性演算部136のみが行う手順である。
多値論理値の演算はステップS122,S125に相当する。多値論理値の演算の引数は、演算対象、送受信されるデータの辞書データ型(s,sd,r,rd)、呼出元の機能識別子cと版番号v、呼出先の機能識別子eと新版番号nと旧版番号o、および、種別tである。なお、多値論理値の演算では、演算対象の引数として「データ授受成功度」または「データ処理コードの不要可能性」が指定される。以下では、演算対象が「データ授受成功度」の場合(ステップS18)のデータ授受成功度演算部135の処理を例示するが、演算対象が「データ処理コードの不要可能性」の場合(ステップS19)の不要コード可能性演算部136の処理も同様の手順となる。ただし、図26の各ステップのうち、ステップS140についてはデータ授受成功度演算部135のみが行う手順であり、ステップS141〜S144については不要コード可能性演算部136のみが行う手順である。
(S130)データ授受成功度演算部135は、送信側キー名の集合ksを設定する。集合ksは、生成仕様テーブル161のうち、辞書データ型IDがsまたはsdであって、キー名が「(暗黙)」ではない生成仕様タプルのキー名の集合である。
(S131)データ授受成功度演算部135は、受信側キー名の集合krを設定する。集合krは、受入仕様テーブル162のうち、辞書データ型IDがrまたはrdであって、キー名が「(暗黙)」ではない受入仕様タプルのキー名の集合である。
(S132)データ授受成功度演算部135は、和集合ks∪krの各要素kに対して下記の処理を繰り返し実行する。
(S133)データ授受成功度演算部135は、生成仕様テーブル161に基づいて、辞書データ型ID=s、キー名kの生成仕様タプルtcがあるか否かを判定する。当該生成仕様タプルtcがない場合、データ授受成功度演算部135は、ステップS134に処理を進める。当該生成仕様タプルtcがある場合、データ授受成功度演算部135は、ステップS136に処理を進める。
(S133)データ授受成功度演算部135は、生成仕様テーブル161に基づいて、辞書データ型ID=s、キー名kの生成仕様タプルtcがあるか否かを判定する。当該生成仕様タプルtcがない場合、データ授受成功度演算部135は、ステップS134に処理を進める。当該生成仕様タプルtcがある場合、データ授受成功度演算部135は、ステップS136に処理を進める。
(S134)データ授受成功度演算部135は、生成仕様テーブル161に基づいて、辞書データ型ID=sd、キー名kの生成仕様タプルtcがあるか否かを判定する。当該生成仕様タプルtcがない場合、データ授受成功度演算部135は、ステップS135に処理を進める。当該生成仕様タプルtcがある場合、データ授受成功度演算部135は、ステップS136に処理を進める。
(S135)データ授受成功度演算部135は、生成仕様テーブル161のうち、辞書データ型ID=sd、キー名「(暗黙)」の生成仕様タプルをtcとする。
(S136)データ授受成功度演算部135は、受入仕様テーブル162に基づいて、辞書データ型ID=r、キー名kの受入仕様タプルtaがあるか否かを判定する。当該受入仕様タプルtaがない場合、データ授受成功度演算部135は、ステップS137に処理を進める。当該受入仕様タプルtaがある場合、データ授受成功度演算部135は、ステップS139に処理を進める。
(S136)データ授受成功度演算部135は、受入仕様テーブル162に基づいて、辞書データ型ID=r、キー名kの受入仕様タプルtaがあるか否かを判定する。当該受入仕様タプルtaがない場合、データ授受成功度演算部135は、ステップS137に処理を進める。当該受入仕様タプルtaがある場合、データ授受成功度演算部135は、ステップS139に処理を進める。
(S137)データ授受成功度演算部135は、受入仕様テーブル162に基づいて、辞書データ型ID=rd、キー名kの受入仕様タプルtaがあるか否かを判定する。当該受入仕様タプルtaがある場合、データ授受成功度演算部135は、ステップS139に処理を進める。当該受入仕様タプルtaがない場合、データ授受成功度演算部135は、ステップS138に処理を進める。
(S138)データ授受成功度演算部135は、受入仕様テーブル162のうち、辞書データ型ID=rd、キー名「(暗黙)」の受入仕様タプルをtaとする。
(S139)データ授受成功度演算部135は、演算対象がデータ授受成功度であるか否かを判定する。演算対象がデータ授受成功度である場合、ステップS140に処理が進む。演算対象がデータ授受成功度ではない場合、ステップS141に処理が進む。演算対象がデータ授受成功度ではない場合、演算対象は、データ処理コードの不要可能性である。
(S139)データ授受成功度演算部135は、演算対象がデータ授受成功度であるか否かを判定する。演算対象がデータ授受成功度である場合、ステップS140に処理が進む。演算対象がデータ授受成功度ではない場合、ステップS141に処理が進む。演算対象がデータ授受成功度ではない場合、演算対象は、データ処理コードの不要可能性である。
(S140)データ授受成功度演算部135は、呼出先が機能e、新旧版n,oのときの機能c、版v、種別tのデータ授受成功度Sを計算し、データ授受成功度テーブル171に格納する。データ授受成功度Sは、生成仕様タプルtcのEa,En、および、受入仕様タプルtaのSr,Su,Aに対して、次の式(1)により計算される。
S=((Su∧¬En)∨(Sr∧¬Ea))∧(H∨((Su∨Ea)∧(Sr∨En))) ・・・(1)
そして、データ授受成功度演算部135は、ステップS145に処理を進める。
そして、データ授受成功度演算部135は、ステップS145に処理を進める。
(S141)不要コード可能性演算部136は、種別t=リクエストであるか否かを判定する。種別t=リクエストである場合、不要コード可能性演算部136は、ステップS142に処理を進める。種別t=リクエストでない場合、不要コード可能性演算部136は、ステップS143に処理を進める。
(S142)不要コード可能性演算部136は、対象コードg=呼出先に設定する。そして、ステップS144に処理を進める。
(S143)不要コード可能性演算部136は、対象コードg=呼出元に設定する。
(S143)不要コード可能性演算部136は、対象コードg=呼出元に設定する。
(S144)不要コード可能性演算部136は、呼出先が機能e、新旧版n,oのときの機能c、版vでの対象コードgの不要コード可能性Uを計算し、不要コード可能性テーブル172に格納する。不要コード可能性Uは、生成仕様タプルtcのEn、および、受入仕様タプルtaのAに対して、次の式(2)により計算される。
U=A∧En ・・・(2)
そして、不要コード可能性演算部136は、ステップS145に処理を進める。
(S145)データ授受成功度演算部135は、和集合ks∪krの全ての要素kに対してデータ授受成功度Sまたは不要コード可能性Uを計算すると、繰り返しを終了し、多値論理値の演算を終了する。
そして、不要コード可能性演算部136は、ステップS145に処理を進める。
(S145)データ授受成功度演算部135は、和集合ks∪krの全ての要素kに対してデータ授受成功度Sまたは不要コード可能性Uを計算すると、繰り返しを終了し、多値論理値の演算を終了する。
図27は、3値関係の演算の例を示す図である。
表51は、論理変数A,Bに対する3値関係(Kleeneの3値論理)の演算の例を示す。論理変数A,Bは、それぞれF,T,Hの3つ値の何れかを取り得る。Fは、失敗(Failure)を表す。Tは、成功(Success)を表す。Hは、失敗の場合も成功の場合もあること(Both occur)を表す。
表51は、論理変数A,Bに対する3値関係(Kleeneの3値論理)の演算の例を示す。論理変数A,Bは、それぞれF,T,Hの3つ値の何れかを取り得る。Fは、失敗(Failure)を表す。Tは、成功(Success)を表す。Hは、失敗の場合も成功の場合もあること(Both occur)を表す。
ここで、Tを数値[T]=1とする。Hを数値[H]=1/2とする。Fを数値[F]=0とする。すると、論理変数A,Bに対する論理演算を次のように数式化できる。
[¬A]=1−[A]
[A∧B]=min([A],[B])
[A∨B]=max([A],[B])
[A→B]=[¬A∨B]
[A=B]=[A←→B]=[(A→B)∧(B→A)]
表51は、論理変数Aの値および論理変数Bの値の組に対する論理演算A→B、A∧B、A∨B、¬Aの結果を示す。
[¬A]=1−[A]
[A∧B]=min([A],[B])
[A∨B]=max([A],[B])
[A→B]=[¬A∨B]
[A=B]=[A←→B]=[(A→B)∧(B→A)]
表51は、論理変数Aの値および論理変数Bの値の組に対する論理演算A→B、A∧B、A∨B、¬Aの結果を示す。
第2の実施の形態の例によれば、変更影響解析装置100により、リポジトリサーバ200に格納されているソースコード201,211,212に対して、機能仕様抽出が行われる。機能仕様抽出の結果、データ授受仕様テーブル151および辞書データ型仕様テーブル152が生成される。
ユーザは、機能「GET /progress」を旧版番号「1.0」から版番号「2.0」へ変更したときの影響を確認するため、機能の識別子「GET /progress」、旧版番号「1.0」、版番号「2.0」を変更影響解析装置100に入力する。すると、変更影響解析装置100は、当該入力に応じて、データ授受成功度テーブル171および不要コード可能性テーブル172を生成し、機能「GET /progress」に関するデータ授受成功度および不要コード可能性をユーザに通知する。
ソースコード211,212の例では、新版の「GET /progress」において、レスポンスからキー名「itemLocation」のデータが削除されている。
ここで、呼出先の機能による応答の一部が削除される場合に、呼出元の機能に対して一律に影響があると判断し、ユーザに通知することも考えられる。しかし、削除されたデータが呼出元の処理に必須でなければ、呼出元の機能への影響はない。このため、一律に影響があるとしてしまうと、本来は影響がないにも関わらず、影響があると誤判断するという偽陽性の判断を下してしまう可能性がある。偽陽性がユーザに通知されると、ユーザによる余計な確認作業が発生してしまい、プログラム開発の遅延要因になる。
ここで、呼出先の機能による応答の一部が削除される場合に、呼出元の機能に対して一律に影響があると判断し、ユーザに通知することも考えられる。しかし、削除されたデータが呼出元の処理に必須でなければ、呼出元の機能への影響はない。このため、一律に影響があるとしてしまうと、本来は影響がないにも関わらず、影響があると誤判断するという偽陽性の判断を下してしまう可能性がある。偽陽性がユーザに通知されると、ユーザによる余計な確認作業が発生してしまい、プログラム開発の遅延要因になる。
そこで、変更影響解析装置100では、呼出先の機能によるデータの送信の確度と呼出元の機能によるデータの受信の必要度との組合せに基づいて、呼出元の機能に対する影響を判定することで、当該影響を詳細に判定可能になる。データ授受成功度テーブル171の例によれば、呼出先の機能「GET /progress」から呼出元の機能「GET /order」にキー名「itemLocation」のデータが応答されなくなるが、データ授受成功度は「T」(必ず成功)である。これは、呼出元の機能「GET /order」において、キー名「itemLocation」のデータが必須ではないためである。このように、キー名「itemLocation」のデータが応答から削除されても、呼出元の機能「GET /order」は影響を受けないことが適切に判断される。
これにより、呼出先の機能による応答の一部が削除される場合に、呼出元の機能に対して一律に「影響あり」をユーザに通知するよりも、呼出元の機能への影響を適切にユーザに通知できる。また、偽陽性がユーザに通知されることを抑制することで、ユーザによる余計な確認作業を削減でき、プログラム開発の期間の短縮に寄与する。
次に、他のソースコードを例示して、変更影響解析装置100による解析結果の他の例を説明する。まず、データ授受成功度が「H」と評価される例を示す。
図28は、呼出元側のソースコードの例を示す図である。
図28は、呼出元側のソースコードの例を示す図である。
ソースコード202は、リポジトリサーバ200に格納される。ソースコード202は、呼出元側のソースコードの一例である。ソースコード202の版数は「1.0」である。ソースコード202は、OrderControllerクラスの定義を含む。
例えば、ソースコード202の11行目〜12行目によれば、機能呼出時に呼出元から呼出先に送られるパラメタ「inStock」の設定がif文内に記述されている。すなわち、パラメタ「inStock」は、呼出元において条件付きで設定される。すなわち、「inStock」は、呼出元の機能から呼出先の機能へ送信される場合もあるし、送信されない場合もある。
図29は、呼出先側のソースコードの例を示す図である。
図29(A)は、リポジトリサーバ200に格納されるソースコード221を示す。ソースコード221は、改版前(旧版)の呼出先側のソースコードの一例である。ソースコード221の版数は、「1.0」である。ソースコード221は、ItemControllerクラスの定義を含む。
図29(A)は、リポジトリサーバ200に格納されるソースコード221を示す。ソースコード221は、改版前(旧版)の呼出先側のソースコードの一例である。ソースコード221の版数は、「1.0」である。ソースコード221は、ItemControllerクラスの定義を含む。
例えば、ソースコード221の6行目では、リクエストによるパラメタ「inStock」の受け付けは任意(「required=false」)であり、必須ではない。
図29(B)は、リポジトリサーバ200に格納されるソースコード222を示す。ソースコード222は、改版後(新版)の呼出先側のソースコードの一例である。ソースコード222の版数は、「2.0」である。ソースコード222の6行目によれば、パラメタ「inStock」の受け付けは、任意から必須(「required=true」)に変更されている。
図29(B)は、リポジトリサーバ200に格納されるソースコード222を示す。ソースコード222は、改版後(新版)の呼出先側のソースコードの一例である。ソースコード222の版数は、「2.0」である。ソースコード222の6行目によれば、パラメタ「inStock」の受け付けは、任意から必須(「required=true」)に変更されている。
次に、ソースコード202,221,222に対するデータ授受成功度テーブルを例示する。
図30は、データ授受成功度テーブルの例を示す図である。
図30は、データ授受成功度テーブルの例を示す図である。
変更影響解析装置100は、ソースコード202,221,222に対して、データ授受成功度テーブル173を生成し、解析結果記憶部124に格納する。
ソースコード222の改版による変更影響を確認するために、ユーザが機能「GET /item」、旧版番号「1.0」、新版番号「2.0」を変更影響解析装置100に入力すると、データ授受成功度テーブル173が生成される。機能「GET /item」の呼出元は、ソースコード201における機能「PUT /order」である。データ授受成功度テーブル173によれば、ソースコード222におけるパラメタ「inStock」の必須パラメタへの変更に対して、「PUT /order」からのリクエストのデータ授受成功度が「H」と判断されている。データ授受成功度「H」は、「成功する場合も失敗する場合も両方ある」ことを示し、また、呼出元の機能に「影響がある可能性がある」ことを示す。
ソースコード222の改版による変更影響を確認するために、ユーザが機能「GET /item」、旧版番号「1.0」、新版番号「2.0」を変更影響解析装置100に入力すると、データ授受成功度テーブル173が生成される。機能「GET /item」の呼出元は、ソースコード201における機能「PUT /order」である。データ授受成功度テーブル173によれば、ソースコード222におけるパラメタ「inStock」の必須パラメタへの変更に対して、「PUT /order」からのリクエストのデータ授受成功度が「H」と判断されている。データ授受成功度「H」は、「成功する場合も失敗する場合も両方ある」ことを示し、また、呼出元の機能に「影響がある可能性がある」ことを示す。
ここで、呼出時のパラメタ「inStock」が必須パラメタに変更されることは、破壊的変更として呼出元に「影響あり」と判断することも考えられる。一方、パラメタ「inStock」は呼出元により条件付きで設定しており、通常ケースでは呼出元において常に設定される可能性がある。呼出元でパラメタ「inStock」が常に設定される場合、呼出先で「inStock」が必須パラメタに変更されても影響はない。すなわち、呼出元の機能「PUT /order」の設計や実装の状況によっては、変更影響への対応作業の優先度を落とせる可能性がある。そこで、変更影響解析装置100は、呼出元の機能「PUT /order」に対するデータ授受成功度を「H」と評価することで、この可能性をユーザに通知することができる。
例えば、ユーザは、影響の「可能性がある」箇所か、影響が「必ずある」箇所かの違いにより、作業の優先度を決めることができる。このため、呼出側の機能の仕様変更に対する早期暫定対応が行えるという利点もある。
次に、不要コード可能性が「T」と評価される例を示す。
図31は、呼出元側のソースコードの例を示す図である。
ソースコード203は、リポジトリサーバ200に格納される。ソースコード203は、呼出元側のソースコードの一例である。ソースコード203の版数は「1.0」である。ソースコード203は、OrderControllerクラスの定義を含む。
図31は、呼出元側のソースコードの例を示す図である。
ソースコード203は、リポジトリサーバ200に格納される。ソースコード203は、呼出元側のソースコードの一例である。ソースコード203の版数は「1.0」である。ソースコード203は、OrderControllerクラスの定義を含む。
ソースコード203に対する呼出先側のソースコードは、ソースコード211,212であるとする。
ソースコード203は、機能「DELETE /order」の記述を含む。機能「DELETE /order」は、ソースコード211,212における機能「GET /progress」を呼び出す。ソースコード203の10行目〜12行目には、呼出先からのレスポンスにおける「itemLocation」に基づく処理が記述されている。
ソースコード203は、機能「DELETE /order」の記述を含む。機能「DELETE /order」は、ソースコード211,212における機能「GET /progress」を呼び出す。ソースコード203の10行目〜12行目には、呼出先からのレスポンスにおける「itemLocation」に基づく処理が記述されている。
一方、ソースコード212では、前述のように、ソースコード211と比べて、「GET /progress」のレスポンスから「itemLocation」が削除されている。
図32は、不要コード可能性テーブルの例を示す図である。
変更影響解析装置100は、ソースコード203,211,212に対して、不要コード可能性テーブル174を生成し、解析結果記憶部124に格納する。
変更影響解析装置100は、ソースコード203,211,212に対して、不要コード可能性テーブル174を生成し、解析結果記憶部124に格納する。
ソースコード212の改版による変更影響を確認するために、ユーザが機能「GET /progress」、旧版番号「1.0」、新版番号「2.0」を変更影響解析装置100に入力すると、不要コード可能性テーブル174が生成される。機能「GET /progress」の呼出元は、ソースコード203における機能「DELETE /order」である。不要コード可能性テーブル174によれば、ソースコード212におけるレスポンスからの「itemLocation」の削除に対して、「DELETE /order」の不要コード可能性が「T」と判断されている。不要コード可能性「T」は、不要な処理コードが含まれている可能性があることを示す。
ソースコード203の例では、ソースコード211からソースコード212への改版により、11行目および12行目(「TECHNICAL DEBT」とコメントされている行)は呼び出されることがなくなる。呼び出されることがないコードを維持することは、テストや今後の改変での考慮点が無駄に増えてしまい、技術的負債となる。例えば、必須ではないレスポンスのキー名付き値の削除に対してコード修正が行われず、呼出元側のソースコードに今後使用されない無駄なコードが残り続ける。すると、回帰テストに余計な時間がかかる、障害対応時などに余計なコードの見直しコストがかかる、などソースコードのメンテナンス性が低下する。
これに対して、変更影響解析装置100は、不要コード可能性を「T」と評価することで、このような不要コードが存在する可能性をユーザに適切に通知でき、無駄なコードがソースコードに残り続けることを防げる。
次に、変更影響解析装置100による出力画面の例を説明する。
図33は、出力画面の例を示す図である。
出力画面180は、出力部137がディスプレイ111に表示させる画面である。出力画面180は、変更影響の解析結果をユーザに通知するための画面である。出力画面180は、ネットワーク30を介して接続された他のコンピュータのディスプレイなどに表示されてもよい。出力画面180は、ソースコード202,221,222がリポジトリサーバ200に格納された状態で、「GET /item」の版番号を「1.0」から「2.0」に変えたときの影響を表す。
図33は、出力画面の例を示す図である。
出力画面180は、出力部137がディスプレイ111に表示させる画面である。出力画面180は、変更影響の解析結果をユーザに通知するための画面である。出力画面180は、ネットワーク30を介して接続された他のコンピュータのディスプレイなどに表示されてもよい。出力画面180は、ソースコード202,221,222がリポジトリサーバ200に格納された状態で、「GET /item」の版番号を「1.0」から「2.0」に変えたときの影響を表す。
出力画面180は、機能選択フォーム181、旧版番号入力フォーム182、新版番号入力フォーム183、ボタン184および変更影響表示領域185を有する。
機能選択フォーム181は、変更影響の抽出対象とする機能の識別子を選択するためのフォームである。
機能選択フォーム181は、変更影響の抽出対象とする機能の識別子を選択するためのフォームである。
旧版番号入力フォーム182は、機能選択フォーム181で選択された機能に対応する旧版番号を入力するためのフォームである。
新版番号入力フォーム183は、機能選択フォーム181で選択された機能に対応する新版番号を入力するためのフォームである。
新版番号入力フォーム183は、機能選択フォーム181で選択された機能に対応する新版番号を入力するためのフォームである。
ボタン184は、機能選択フォーム181の選択内容、旧版番号入力フォーム182の入力内容および新版番号入力フォーム183の入力内容を確定し、変更影響解析装置100に変更影響抽出の指示を入力するためのボタンである。
変更影響表示領域185は、変更影響解析装置100による変更影響の解析結果を表示するための領域である。
例えば、機能選択フォーム181に「GET /item」、旧版番号入力フォーム182に「ver.1.0」、新版番号入力フォーム183に「ver.2.0」が入力された状態でユーザによりボタン184が押下操作される。すると、機能選択フォーム181、旧版番号入力フォーム182および新版番号入力フォーム183に入力されたこれらの情報を含む変更影響抽出の指示が変更影響解析装置100に入力される。変更影響解析装置100は、変更影響抽出の指示を受け付けると、データ授受成功度テーブル173を生成する。変更影響解析装置100は、不要コード可能性テーブルも生成するが、不要コード可能性については該当コードがないため説明を省略する。
例えば、機能選択フォーム181に「GET /item」、旧版番号入力フォーム182に「ver.1.0」、新版番号入力フォーム183に「ver.2.0」が入力された状態でユーザによりボタン184が押下操作される。すると、機能選択フォーム181、旧版番号入力フォーム182および新版番号入力フォーム183に入力されたこれらの情報を含む変更影響抽出の指示が変更影響解析装置100に入力される。変更影響解析装置100は、変更影響抽出の指示を受け付けると、データ授受成功度テーブル173を生成する。変更影響解析装置100は、不要コード可能性テーブルも生成するが、不要コード可能性については該当コードがないため説明を省略する。
出力部137は、データ授受成功度テーブル173に基づいて、データ授受成功度の問題箇所を表す画像を変更影響表示領域185に表示させる。データ授受成功度の問題箇所は、データ授受成功度テーブル173において、データ授受成功度が「F」(影響あり)または「H」(影響する可能性あり)であるレコードに対応する。データ授受成功度テーブル173の例では、「GET /order」の旧版「1.0」から新版「2.0」への変更が、機能「PUT /order」の版「1.0」のリクエストに影響する可能性があることが、変更影響表示領域185に表示される。
ユーザは、出力画面180を確認することで、「PUT /order」が影響を受ける可能性があることを適切に把握することができる。
図34は、出力画面の他の例を示す図である。
図34は、出力画面の他の例を示す図である。
出力画面190は、出力部137がディスプレイ111に表示させる画面である。出力画面190は、変更影響の解析結果をユーザに通知するための画面である。出力画面190は、ネットワーク30を介して接続された他のコンピュータのディスプレイなどに表示されてもよい。出力画面190は、ソースコード203,211,212がリポジトリサーバ200に格納された状態で、「GET /progress」の版番号を「1.0」から「2.0」に変えたときの影響を表す。
出力画面190は、機能選択フォーム191、旧版番号入力フォーム192、新版番号入力フォーム193、ボタン194および変更影響表示領域195を有する。機能選択フォーム191、旧版番号入力フォーム192、新版番号入力フォーム193、ボタン194および変更影響表示領域195それぞれは、図33で示した出力画面180の同名の構成に対応する。
例えば、機能選択フォーム191に「GET /progress」、旧版番号入力フォーム192に「ver.1.0」、新版番号入力フォーム193に「ver.2.0」が入力された状態でユーザによりボタン194が押下操作される。すると、機能選択フォーム191、旧版番号入力フォーム192および新版番号入力フォーム193に入力されたこれらの情報を含む変更影響抽出の指示が変更影響解析装置100に入力される。変更影響解析装置100は、変更影響抽出の指示を受け付けると、不要コード可能性テーブル174を生成する。変更影響解析装置100は、データ授受成功度テーブルも生成するが、データ授受成功度については問題箇所がないため説明を省略する。
出力部137は、不要コード可能性テーブル174に基づいて、不要コードが含まれる可能性がある箇所を表す画像を変更影響表示領域195に表示させる。不要コードが含まれる可能性がある箇所は、不要コード可能性テーブル174において、不要コード可能性が「T」のレコードに対応する。例えば、「GET /progress」の旧版「1.0」から新版「2.0」への変更により、呼出元の機能「DELETE /order」の版「1.0」のリクエスト生成に、不要コードが含まれる可能性があることが変更影響表示領域195に表示される。
ユーザは、出力画面190を確認することで、「DELETE /order」に不要コードが存在する可能性があることを適切に把握することができる。
次に、変更影響解析装置100による変更影響の解析結果をまとめる。
次に、変更影響解析装置100による変更影響の解析結果をまとめる。
図35は、変更影響の解析結果の例を示す図である。
図35(A)は、送信側によるデータの送信の確度と、受信側による当該データの受信の必要度との組に応じた、変更影響解析装置100によるデータ授受成功度Sの解析結果61を示す。送信の確度は、データの生成仕様における必須度である。受信の必要度は、データの受入仕様における必須度である。(送信側、受信側)の組合せは、呼出先から呼出元へのレスポンスの場合に(呼出先の機能、呼出元の機能)であり、呼出元から呼出先へのリクエストの場合に(呼出元の機能、呼出先の機能)である。
図35(A)は、送信側によるデータの送信の確度と、受信側による当該データの受信の必要度との組に応じた、変更影響解析装置100によるデータ授受成功度Sの解析結果61を示す。送信の確度は、データの生成仕様における必須度である。受信の必要度は、データの受入仕様における必須度である。(送信側、受信側)の組合せは、呼出先から呼出元へのレスポンスの場合に(呼出先の機能、呼出元の機能)であり、呼出元から呼出先へのリクエストの場合に(呼出元の機能、呼出先の機能)である。
送信の確度「mandatory」は、Ea=TかつEn=Fに相当する。
送信の確度「possible」は、Ea=FかつEn=Fに相当する。
送信の確度「impossible」は、Ea=FかつEn=Tに相当する。
送信の確度「possible」は、Ea=FかつEn=Fに相当する。
送信の確度「impossible」は、Ea=FかつEn=Tに相当する。
受信の必要度「mandatory」は、Sr=T、Su=FかつA=Tに相当する。
受信の必要度「possible」は、Sr=T、Su=TかつA=Tに相当する。
受信の必要度「unattended」は、Sr=T、Su=TかつA=Fに相当する。
受信の必要度「possible」は、Sr=T、Su=TかつA=Tに相当する。
受信の必要度「unattended」は、Sr=T、Su=TかつA=Fに相当する。
受信の必要度「impossible」は、Sr=F、Su=TかつA=Fに相当する。
データ授受成功度S=Tは「影響なし」を示す。データ授受成功度S=Hは「影響ありの可能性あり」を示す。データ授受成功度S=Fは「影響あり」を示す。
データ授受成功度S=Tは「影響なし」を示す。データ授受成功度S=Hは「影響ありの可能性あり」を示す。データ授受成功度S=Fは「影響あり」を示す。
なお、図中、破壊的変更に対して一律に影響ありとする方法に対する偽陽性の修正箇所を「CFP」(Corrected False Positive)と表記する。また、本来は不要コードが存在する可能性があるにも関わらず、それを見過ごすことを、便宜的に「偽陰性」と称し、偽陰性の修正箇所を「CFN」(Corrected False Negative)と表記する。
解析結果61の例では、送信の確度「impossible」と受信の必要度「possible」との組に対してS=Tであり、偽陽性が修正される。同様に、送信の確度「impossible」と受信の必要度「unattended」との組に対してS=Tであり、偽陽性が修正される。更に、送信の確度「impossible」と受信の必要度「impossible」の組に対してS=Tであり、偽陽性が修正される。
また、送信の確度「possible」と受信の必要度「mandatory」との組に対してS=Hであり、影響の可能性があることをユーザに通知できる。また、送信の確度「possible」と受信の必要度「impossible」との組に対してS=Hであり、影響の可能性があることをユーザに通知できる。
更に、送信の確度「mandatory」と受信の必要度「impossible」との組に対してS=Fであり、偽陰性が修正される。
なお、解析結果61の例では、送信の確度「impossible」と受信の必要度「mandatory」との組に対してS=Fであり、それ以外の組に対してS=Tである。
なお、解析結果61の例では、送信の確度「impossible」と受信の必要度「mandatory」との組に対してS=Fであり、それ以外の組に対してS=Tである。
図35(B)は、送信側によるデータの送信の確度と、受信側による当該データの受信の必要度との組に応じた、変更影響解析装置100による不要コード可能性Uの解析結果62を示す。不要コード可能性U=Tは「不要コードが存在する可能性あり」を示す。不要コード可能性U=Fは「不要コードが存在する可能性なし」を示す。
解析結果62の例では、送信の確度「impossible」と受信の必要度「possible」との組に対してU=Tであり、偽陰性が修正される。解析結果62の例では、送信の確度と受信の必要度とのその他の組に対してU=Fである。
このように、変更影響解析装置100は、呼出元の機能において、データの受信が必須であることを示す第1の必要度と、データを受信すれば使用することを示す第2の必要度と、データを受信しても使用しないことを示す第3の必要度とを含む複数の必要度のうちの何れに当該データが該当するかを決定する。これにより、呼出元側の機能の状況を詳細に分析可能になる。
また、変更影響解析装置100は、改版前の呼出先の機能により送信されるが改版後の呼出先の機能により送信されないデータの、呼出元における必要度が上記第2の必要度および上記第3の必要度の場合、呼出元の機能への影響がないと判定する。これにより、偽陽性が削減される。
また、変更影響解析装置100は、送信の確度の決定では、改版後の呼出先の機能によりデータが送信される場合および送信されない場合の両方の場合があることを示す確度を決定する。そして、変更影響解析装置100は、変更影響の判定では、上記第1の必要度と当該両方の場合があることを示す確度との組合せに対して、呼出元の機能への影響がある可能性があると判定する。これにより、コード確認作業の適切な優先順位付けが可能になる。
また、変更影響解析装置100は、改版後の呼出先の機能により送信されないデータの、呼出元における受信の必要度が上記第2の必要度の場合、呼出元の機能のソースコードに不要なコードが含まれる可能性があると判定し、当該可能性をユーザに通知する。これにより、ソースコードに無駄なコードが残されることを抑えられる。
更に、変更影響解析装置100は、呼出元の機能から改版後の呼出先の機能へのデータの送信の有無の他の確度と、改版後の呼出先の機能における当該データの受信の他の必要度とを決定する。そして、変更影響解析装置100は、決定した他の確度と他の必要度との組合せに基づいて、データの仕様の変更による呼出元の機能に対する影響を判定する。これにより、呼出元から呼出先に送信されるリクエストデータに関しても、呼出元の機能への影響を適切に判定できる。
図36は、変更影響の解析結果の比較例を示す図である。
図36(A)は、受信側でのデータの受信の必要度を考慮しない場合のデータ授受成功度Sの解析結果71を示す。解析結果71の例では、送信の確度「possible」は考慮されていない。例えば、解析結果71では、該当のデータの送信が必ずしも行われない場合でも、必ず送信する場合と同じように扱われて、データ授受成功度Sが評価されている。解析結果71によれば、送信の確度「mandatory」、受信の任意の必要度に対して、S=Tである。また、送信の確度「impossible」、受信の任意の必要度に対して、S=Fである。すなわち、送信の確度「impossible」に対し、受信側での受信の必要度によっては影響がないにも関わらず、S=Fと誤判定されてしまう。
図36(A)は、受信側でのデータの受信の必要度を考慮しない場合のデータ授受成功度Sの解析結果71を示す。解析結果71の例では、送信の確度「possible」は考慮されていない。例えば、解析結果71では、該当のデータの送信が必ずしも行われない場合でも、必ず送信する場合と同じように扱われて、データ授受成功度Sが評価されている。解析結果71によれば、送信の確度「mandatory」、受信の任意の必要度に対して、S=Tである。また、送信の確度「impossible」、受信の任意の必要度に対して、S=Fである。すなわち、送信の確度「impossible」に対し、受信側での受信の必要度によっては影響がないにも関わらず、S=Fと誤判定されてしまう。
図36(B)は、受信側でのデータの受信の必要度を考慮しない場合の不要コード可能性Uの解析結果72を示す。解析結果72の例では、受信側のソースコードを参照しないため、送信の確度が何れの場合でも、不要コード可能性U=Fである。すなわち、不要コード可能性Uを評価することはできない。
図36の比較例のように、受信側のデータの必要度に関わらず同じ結果を出力すると、偽陽性や偽陰性が発生してしまう。変更影響解析装置100によれば、送信側のデータの送信の確度と受信側の当該データの受信の必要度との組に応じて、データ授受成功度や不要コード可能性を評価することで、図35で示したように、偽陽性や偽陰性の発生を抑えられる。
変更影響解析装置100によれば、効率的なシステム開発を支援することができる。例えば、分散環境などで稼働する小規模の機能群を結合・連携させることで大規模なシステムを実現することがある。変更影響解析装置100は、このような大規模なシステムにおいて、小規模機能が仕様変更されたときに、変更の影響がある箇所を列挙する。
比較例の方法では、破壊的変更があった小規模機能の連携先を、全て影響ありとして列挙するため、列挙結果に偽陽性が含まれることがあり、ユーザは、作業対象とすべき小規模機能を適切に絞り込むことが難しい。
そこで、変更影響解析装置100は、まずはソースコードを静的解析して、小規模機能が生成するデータの仕様と、小規模機能が受け入れるデータの仕様とを抽出する。これらの仕様群を複数種類の3値論理値に分解・変換し、授受がある機能間のデータ授受成功度を3値論理演算することで、変更影響の有無箇所を詳細に解析可能になるとともに、影響ありとする箇所の列挙結果から偽陽性を削減できる。
また、前述の3値論理値を用いて、データを受け取る側の機能の実装コードに、今後仕様されない部位があるかを論理値演算により判定することで、修正すべきコードの見過ごし、すなわち、偽陰性を削減できる。
このようにして、変更影響解析装置100は、呼出先の機能の仕様変更による呼出元の機能への影響を適切に判定できる。ユーザは、変更影響解析装置100による判定結果を確認することで、作業対象とすべき機能を適切に絞り込める。その結果、ユーザによる余計な作業が削減され、システム開発の期間の短縮に寄与する。
なお、第1の実施の形態の情報処理は、処理部12にプログラムを実行させることで実現できる。また、第2の実施の形態の情報処理は、処理部22にプログラムを実行させることで実現できる。更に、第3の実施の形態の情報処理は、CPU101にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体113に記録できる。
例えば、プログラムを記録した記録媒体113を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体113に記録されたプログラムまたは他のコンピュータから受信したプログラムを、RAM102やHDD103などの記憶装置に格納し(インストールし)、当該記憶装置からプログラムを読み込んで実行してもよい。
10 変更影響解析装置
11 記憶部
12 処理部
13 影響判定結果
11 記憶部
12 処理部
13 影響判定結果
Claims (11)
- コンピュータに、
呼出元プログラムから呼び出される呼出先プログラムで用いられるデータの仕様が変更された場合に、前記呼出元プログラムと前記呼出先プログラムとに基づいて、前記呼出先プログラムから前記呼出元プログラムへの前記データの送信の有無の確度と、前記呼出元プログラムにおける前記データの受信の必要度とを決定し、
前記確度と前記必要度との組合せに基づいて、前記データの仕様の変更による前記呼出元プログラムに対する影響を判定し、判定した前記影響を示す情報を出力する、
処理を実行させる変更影響解析プログラム。 - 前記必要度の決定では、前記呼出元プログラムにおいて、前記データの受信が必須であることを示す第1の必要度と、前記データを受信すれば使用することを示す第2の必要度と、前記データを受信しても使用しないことを示す第3の必要度とを含む複数の前記必要度のうちの何れに前記データが該当するかを決定する、
請求項1記載の変更影響解析プログラム。 - 前記影響の判定では、改版前の前記呼出先プログラムにより送信されるが改版後の前記呼出先プログラムにより送信されない前記データの前記必要度が前記第2の必要度および前記第3の必要度の場合、前記呼出元プログラムへの前記影響がないと判定する、
請求項2記載の変更影響解析プログラム。 - 前記確度の決定では、前記呼出先プログラムにより前記データが送信される場合および送信されない場合の両方の場合があることを示す前記確度を決定し、
前記影響の判定では、前記第1の必要度と前記両方の場合があることを示す前記確度との組合せに対して、前記呼出元プログラムへの前記影響がある可能性があると判定する、
請求項2または3記載の変更影響解析プログラム。 - 前記影響の判定では、前記呼出先プログラムにより送信されない前記データの前記必要度が前記第2の必要度の場合、前記呼出元プログラムに不要なコードが含まれる可能性があると判定する、
請求項2乃至4の何れか一項に記載の変更影響解析プログラム。 - 前記確度および前記必要度の決定では、前記呼出元プログラムから前記呼出先プログラムへの前記データの送信の有無の他の確度と、前記呼出先プログラムにおける前記データの受信の他の必要度とを決定し、
前記影響の判定では、前記他の確度と前記他の必要度との組合せに基づいて、前記データの仕様の変更による前記呼出元プログラムに対する前記影響を判定する、
請求項1乃至5の何れか一項に記載の変更影響解析プログラム。 - コンピュータが、
呼出元プログラムから呼び出される呼出先プログラムで用いられるデータの仕様が変更された場合に、前記呼出元プログラムと前記呼出先プログラムとに基づいて、前記呼出先プログラムから前記呼出元プログラムへの前記データの送信の有無の確度と、前記呼出元プログラムにおける前記データの受信の必要度とを決定し、
前記確度と前記必要度との組合せに基づいて、前記データの仕様の変更による前記呼出元プログラムに対する影響を判定し、判定した前記影響を示す情報を出力する、
変更影響解析方法。 - 呼出元プログラムと前記呼出元プログラムから呼び出される呼出先プログラムとを記憶する記憶部と、
前記呼出先プログラムで用いられるデータの仕様が変更された場合に、前記呼出元プログラムと前記呼出先プログラムとに基づいて、前記呼出先プログラムから前記呼出元プログラムへの前記データの送信の有無の確度と、前記呼出元プログラムにおける前記データの受信の必要度とを決定し、前記確度と前記必要度との組合せに基づいて、前記データの仕様の変更による前記呼出元プログラムに対する影響を判定し、判定した前記影響を示す情報を出力する処理部と、
を有する変更影響解析装置。 - コンピュータに、
呼出元プログラムから呼び出される呼出先プログラムで用いられるデータの仕様が変更された場合に、前記呼出元プログラムと前記呼出先プログラムとに基づいて、前記呼出元プログラムから前記呼出先プログラムへの前記データの送信の有無の確度と、前記呼出先プログラムにおける前記データの受信の必要度とを決定し、
前記確度と前記必要度との組合せに基づいて、前記データの仕様の変更による前記呼出元プログラムに対する影響を判定し、判定した前記影響を示す情報を出力する、
処理を実行させる変更影響解析プログラム。 - コンピュータが、
呼出元プログラムから呼び出される呼出先プログラムで用いられるデータの仕様が変更された場合に、前記呼出元プログラムと前記呼出先プログラムとに基づいて、前記呼出元プログラムから前記呼出先プログラムへの前記データの送信の有無の確度と、前記呼出先プログラムにおける前記データの受信の必要度とを決定し、
前記確度と前記必要度との組合せに基づいて、前記データの仕様の変更による前記呼出元プログラムに対する影響を判定し、判定した前記影響を示す情報を出力する、
変更影響解析方法。 - 呼出元プログラムと前記呼出元プログラムから呼び出される呼出先プログラムとを記憶する記憶部と、
前記呼出先プログラムで用いられるデータの仕様が変更された場合に、前記呼出元プログラムと前記呼出先プログラムとに基づいて、前記呼出元プログラムから前記呼出先プログラムへの前記データの送信の有無の確度と、前記呼出先プログラムにおける前記データの受信の必要度とを決定し、前記確度と前記必要度との組合せに基づいて、前記データの仕様の変更による前記呼出元プログラムに対する影響を判定し、判定した前記影響を示す情報を出力する処理部と、
を有する変更影響解析装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2019210356A JP2021082113A (ja) | 2019-11-21 | 2019-11-21 | 変更影響解析プログラム、変更影響解析方法および変更影響解析装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2019210356A JP2021082113A (ja) | 2019-11-21 | 2019-11-21 | 変更影響解析プログラム、変更影響解析方法および変更影響解析装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2021082113A true JP2021082113A (ja) | 2021-05-27 |
Family
ID=75965320
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2019210356A Pending JP2021082113A (ja) | 2019-11-21 | 2019-11-21 | 変更影響解析プログラム、変更影響解析方法および変更影響解析装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2021082113A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2021112677A (ja) * | 2019-07-31 | 2021-08-05 | 株式会社三洋物産 | 遊技機 |
-
2019
- 2019-11-21 JP JP2019210356A patent/JP2021082113A/ja active Pending
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2021112677A (ja) * | 2019-07-31 | 2021-08-05 | 株式会社三洋物産 | 遊技機 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10095499B2 (en) | Optimization for multi-project package manager | |
US11062022B1 (en) | Container packaging device | |
US7921190B2 (en) | Method and system for interactively configuring a network device | |
US9092230B2 (en) | Configuration of componentized software applications | |
US8087013B2 (en) | Assisted migration in a data processing environment | |
US8589884B2 (en) | Method and system for identifying regression test cases for a software | |
EP2270655B1 (en) | Compatibility evaluation apparatus, compatibility evaluation method, and recording medium | |
CN108845940B (zh) | 一种企业级信息系统自动化功能测试方法和系统 | |
US7284155B2 (en) | Remote software support agent system with electronic documents for troubleshooting | |
CN107704256B (zh) | 一种Ubuntu上实现Python依赖系统库自动化安装的方法 | |
Liu et al. | Morest: Model-based RESTful API testing with execution feedback | |
US20160378434A1 (en) | Integration of revision control systems and process tools | |
Felício et al. | Rapitest: Continuous black-box testing of restful web apis | |
US20120290560A1 (en) | Mechanism for efficiently querying application binary interface/application programming interface-related information | |
JP6163707B2 (ja) | 組み込み機器、プログラム作成装置、プログラム | |
US20120317255A1 (en) | Utilization of uncertainty dependency relationships between items in a data stream | |
US20150254309A1 (en) | Operation search method and operation search apparatus | |
JP2021082113A (ja) | 変更影響解析プログラム、変更影響解析方法および変更影響解析装置 | |
CN112134918B (zh) | 云服务中函数与触发器匹配状态的检测及处理方法 | |
US20090193411A1 (en) | Method and system for assessing deployment and un-deployment of software installations | |
JP2006294019A (ja) | 汎用ソフトウェア要件アナライザ | |
CN113918525A (zh) | 数据交换调度方法、系统、电子设备、介质及程序产品 | |
CN114281688A (zh) | 一种无码或低码的自动化用例管理方法和装置 | |
Milhem et al. | Extraction of architectural patterns from frameworks and modeling their contributions to qualities | |
US20230409956A1 (en) | Machine learning prediction of additional steps of a computerized workflow |