JP7046217B2 - ソフトウェア解析装置、ソフトウェア解析方法およびソフトウェア解析プログラム - Google Patents

Description

本発明は、ソフトウェア解析装置、ソフトウェア解析方法およびソフトウェア解析プログラムに関し、特に、ソフトウェアのオブジェクト間の依存関係を解析するためのソフトウェア解析装置、ソフトウェア解析方法およびソフトウェア解析プログラムに関する。

近年、製品の多機能化に伴い、ソフトウェア開発の規模および複雑度が増加している。また、多種多様な要望に迅速に対応するため、新規にソフトウェアを開発するより、既存のソフトウェアを流用して開発を行うことが主流となっている。ソフトウェア、特に既存のソフトウェアを変更した場合に影響が及ぶ範囲を把握するために、ソフトウェアのオブジェクト等の構成要素間の依存関係を解析する必要がある。

特許文献１は、コンピュータにソースコードの構文解析を実行させるための構文解析部と、コンピュータに構文解析部による構文解析結果から、ソースコード中の記述位置毎に区別された複数の変数について、変数間の依存関係を導出させるための変数依存関係解析部と、を備えるソフトウェアの構造可視化プログラムを開示する。これにより、設計者や検証者がソフトウェアの構造や処理概要を、変数依存関係の観点から理解することができる。

特許文献２は、ソースコードをログ取得可能なプログラムに加工するソースコード加工手段と、ソースコード加工手段により加工されたプログラムについてユーザが着目する機能に関するテストケースで実行し、ログを取得するテスト実行手段と、テスト実行手段により取得されたログを解析し、オブジェクトの一覧と該オブジェクト間の関係を収集するログ解析手段と、ログ解析手段により収集されたオブジェクト間の関係をもとに、重要度の高いオブジェクトの組み合わせをつなぎあわせてオブジェクト構造を抽出するオブジェクト構造抽出手段と、を備えるオブジェクト図表示装置を開示する。これにより、オブジェクト指向言語で記述されたソースコードの視覚化に際して、包含関係や関連を含むクラス間の関係情報でユーザに必要な情報を表示するとともに、実際にプログラムを実行した場合のクラス間関係を明確化することで、ユーザのソフトウェア開発を効果的に支援することができる。

特開２０１３－１５６７８６号公報 国際公開第２０１８／９６６３２号

しかしながら、特許文献１に開示された発明は、ソースコードの静的な構文解析結果を用いているため、アドレスを介するポインタ変数等によって依存関係を有することになるソフトウェア構成要素間の依存関係を解析することができない。

特許文献２に開示された発明は、ソースコードの静的解析のみならず、プログラムをテストケースで実行し、ログを取得する動的解析を用いるものであるが、ソフトウェア構成要素間の依存関係は静的解析で全て解析されており、動的解析の結果は、依存関係の重要度を示すことに使用されているに過ぎない。したがって、アドレスを介するポインタ変数等によって依存関係を有することになるソフトウェア構成要素間の依存関係を解析することができない。

本発明は、上記のような課題を解決するためになされたものであり、静的解析によって得られたソフトウェアの構成要素間の依存関係と、動的解析によって得られたソフトウェアの構成要素間の依存関係と、に基づいて、従来技術より網羅的かつ高精度にソフトウェアの構成要素間の依存関係を解析することを目的する。

本発明の一態様は、ソフトウェアのソースコードの構造を静的に解析し、ソフトウェアのオブジェクト間の依存関係を解析する第１解析部と、ソースコードが示すプログラムを実行してオブジェクトの動作に関する第１情報を取得し、第１情報に基づいてオブジェクト間の依存関係を解析する第２解析部と、を備え、第１解析部の解析結果と、第２解析部の解析結果と、に基づいて、オブジェクト間の依存関係を解析するソフトウェア解析装置を提供する。

本発明の他の態様は、ソフトウェアのソースコードの構造を静的に解析し、ソフトウェアのオブジェクト間の依存関係を解析する第１解析ステップと、ソースコードが示すプログラムを実行してオブジェクトの動作に関する第１情報を取得し、第１情報に基づいてオブジェクト間の依存関係を解析する第２解析ステップと、第１解析ステップの解析結果と、第２解析ステップの解析結果と、に基づいて、オブジェクト間の依存関係を解析するステップと、を含むソフトウェア解析方法を提供する。

本発明の更に他の態様は、上記のソフトウェア解析方法をコンピュータに実行させるためのソフトウェア解析プログラムを提供する。

本発明により、従来技術より網羅的かつ高精度にソフトウェアの構成要素間の依存関係を解析することができるソフトウェア解析装置、ソフトウェア解析方法およびソフトウェア解析プログラムを得る。

本発明の実施の形態１に係る解析装置の構成を示すブロック図である。 本発明の実施の形態１に係る解析装置の動作の流れを示すフローチャートである。 図２に示した静的解析ステップの詳細な流れを示すフローチャートである。 ソースコードの一例を示す図である。 静的解析結果データベースの一例を示す図である。 静的依存関係データベースの一例を示す図である。 図２に示した動的解析ステップの詳細な流れを示すフローチャートである。 修正コードの一例を示す図である。 ログを生成するステップの詳細な流れを示すフローチャートである。 動作ログの一例を示す図である。 動的依存関係を解析するステップの詳細な流れを示すフローチャートである。 動的依存関係解析スタックの一例を示す図である。 動的依存関係データベースの一例を示す図である。 図２に示した総合的な依存関係を解析するステップの詳細な流れを示すフローチャートである。 解析結果の一例を示す図である。 本発明の実施の形態２に係る解析装置の構成を示すブロック図である。 実施の形態２における動的解析の流れを示すフローチャートである。 図１５のログを生成するステップの詳細な流れを示すフローチャートである。 メッセージログの一例を示す図である。 動的依存関係を解析するステップの詳細な流れを示すフローチャートである。 動的依存関係データベースの一例を示す図である。 本発明の実施の形態３に係る解析装置の構成を示すブロック図である。 実施の形態３における動的解析の流れを示すフローチャートである。 ソースコードの一例を示す図である。 共有メモリのアドレス一覧を示す図である。 関数実行ログの一例を示す図である。 共有メモリアクセスログの一例を示す図である。 動的依存関係を解析するステップの詳細な流れを示すフローチャートである。 共有メモリアクセス記録の一例を示す図である。 動的依存関係データベースの一例を示す図である。 本発明の実施の形態４に係る解析装置の構成を示すブロック図である。 実施の形態４における動的解析の流れを示すフローチャートである。 プログラムの実行の途中から取得された動作ログの一例を示す図である。 動的依存関係を解析するステップの詳細な流れを示すフローチャートである。 動的依存関係解析スタックの一例を示す図である。 呼出し元不明関数スタックの一例を示す図である。 動的依存関係データベースの一例を示す図である。 本発明の実施の形態５に係る解析装置の構成を示すブロック図である。 動作ログの一例を示す図である。 実施の形態５における動的依存関係を解析するステップの詳細な流れを示すフローチャートである。 本発明の実施の形態６に係る解析装置の構成を示すブロック図である。 動作ログの一例を示す図である。 動的依存関係解析スタックの一例を示す図である。 実施の形態６における動的依存関係を解析するステップの詳細な流れを示すフローチャートである。 動的依存関係データベースの一例を示す図である。 ソースコードの一例を示す図である。 静的依存関係データベースの一例を示す図である。 総合的な依存関係を解析するステップの詳細な流れを示すフローチャートである。 総合的な依存関係を解析するステップを終えた後の解析結果の一例を示す図である。 本発明の実施の形態７に係る解析装置の構成を示すブロック図である。 動的依存関係データベースの一例を示す図である。 総合的な依存関係を解析するステップの詳細な流れを示すフローチャートである。 解析結果の一例を示す図である。 本発明の実施の形態８に係る解析装置の構成を示すブロック図である。 本発明の実施の形態８に係る解析装置の動作の流れを示すフローチャートである。 ソースコードの一例を示す図である。 静的解析結果データベースの一例を示す図である。 動的依存関係データベースの一例を示す図である。 図５２に示した関数テーブル内の関数の依存関係を解析するステップの詳細な流れを示すフローチャートである。 関数テーブル依存関係データベースの一例を示す図である。 関数テーブル依存関係データベースの他の例を示す図である。 解析結果の一例を示す図である。 本発明の実施の形態９に係る解析装置の構成を示すブロック図である。 特定の環境で特定の入力データを与えて実行プログラムを実行して得られた動作ログの一例を示す図である。 他の環境でまたは他の入力データを与えて実行プログラムを実行することにより得られた動作ログの一例を示す図である。 図６０ａの動作ログに基づいて得られる動的依存関係を示す図である。 図６０ｂの動作ログに基づいて得られる動的依存関係を示す図である。 図６１ａの動的依存関係と図６１ｂの動的依存関係とを組み合わせることによって得られる動的依存関係を示す図である。

以下、本発明の実施の形態に係る解析装置について、図面を参照して説明する。各実施の形態において、同一の構成には同一の符号を付して、重複説明を省略する。

実施の形態１．
［１．構成］
図１は、本発明の実施の形態１に係る解析装置１００の構成を示すブロック図である。解析装置１００は、入力部１、静的解析部２、静的解析結果データベース（ＤＢ）３、静的依存関係解析部４および静的依存関係データベース（ＤＢ）５を備える。

入力部１は、プログラムとして実行可能なソースコード２０を読み込み、解析装置１００に入力する。入力されるソースコード２０は、例えばユーザのファイル指定によって選択される。ソースコードは、例えばオブジェクト指向言語で記載される。

静的解析部２は、ソースコード２０の静的構造解析を行い、解析結果を出力する。ここで、静的構造解析とは、プログラムを実行することなく、ソースコードの構文および構造等を解析する技術を指す。静的解析部２から出力された静的解析結果には、クラス参照、関数呼出し、オブジェクト呼出し、ヘッダーファイル参照等のソフトウェア構成要素（オブジェクト）間の依存関係（呼出し関係または被呼出し関係とも呼ばれる）に関する情報が含まれる。ここで、オブジェクトとは、関数およびデータ（例えば変数および定数）の集合である。

静的解析結果データベース３には、静的解析部２から出力された静的解析結果が格納される。

静的依存関係解析部４は、静的解析結果データベース３に格納された静的解析結果を解析して、ソフトウェア構成要素間の依存関係を整理して静的依存関係データベース５に格納する。

解析装置１００は、コード加工部６、コンパイル部７、実行部８、動的解析部９および動的解析結果データベース（ＤＢ）１０を更に備える。

入力部１に入力されたソースコード２０は、静的解析部２にだけでなく、動的解析を行うために、コード加工部６にも送信される。コード加工部６は、ソースコード２０を加工して、ログ取得可能な修正コードを作成する。

コンパイル部７は、修正コードをコンパイルする。すなわち、コンパイル部７は、修正コードを機械語等の実行可能な形式の実行プログラムに変換する。

実行部８は、実行プログラムを実行する。この際、動的解析部９は、実行プログラムの処理を監視して実行ログ、アクセスログ等のログを生成し、動的解析結果データベース１０に格納する。

解析装置１００は、動的依存関係解析部１１および動的依存関係データベース（ＤＢ）１２を更に備える。動的依存関係解析部１１は、動的解析結果データベース１０に格納された情報から、ソフトウェア構成要素間の依存関係を解析して動的依存関係データベース１２に格納する。

解析装置１００は、総合的依存関係解析部１３および出力部１５を更に備える。総合的依存関係解析部１３は、静的依存関係データベース５に格納された静的依存関係と、動的依存関係データベース１２に格納された動的依存関係を組み合わせて、ソフトウェア構成要素間の総合的な依存関係を示す解析結果１４を出力する。出力部１５は、解析結果１４を解析装置１００の外部へ出力する。

静的解析結果データベース３、静的依存関係データベース５、動的解析結果データベース１０および動的依存関係データベース１２は、種々の情報を記録する媒体である。これらのデータベースは、それぞれ、例えば、ＲＯＭ、フラッシュメモリ、ＳＳＤ等の半導体メモリ装置、ハードディスク等のディスク装置、その他の記憶デバイス単独でまたはそれらを適宜組み合わせて実現される。

解析装置１００は、ソフトウェアによって実現される。例えば、解析装置１００の静的解析部２、静的依存関係解析部４、コード加工部６、コンパイル部７、実行部８、動的解析部９、動的依存関係解析部１１、総合的依存関係解析部１３および出力部１５は、プログラムによって実現される。このようなプログラムは、上記の記憶デバイス内に格納され、ＣＰＵまたはＭＰＵのような汎用プロセッサによって呼び出されて実行される。

［２．動作］
図２は、解析装置１００の動作の流れを示すフローチャートである。まず、解析装置１００は、入力部１を介して、ソースコード２０を読み込む（Ｓ１０１）。次に、解析装置１００は、ソースコード２０に静的解析を実行し、静的依存関係を解析する（Ｓ１０２）。次に、解析装置１００は、ソースコード２０に動的解析を実行し、動的依存関係を解析する（Ｓ１０３）。解析装置１００は、ステップＳ１０２で得られた静的依存関係と、ステップＳ１０３で得られた動的依存関係を組み合わせて、総合的な依存関係を解析する（Ｓ１０４）。最後に、解析装置１００は、ステップＳ１０４で得られた解析結果１４を出力部１５から出力する（Ｓ１０５）。なお、ステップＳ１０２とステップＳ１０３の実行順は逆であってもよく、ステップＳ１０２の前にステップＳ１０３が実行されてもよい。

［２－１．静的解析］
図３は、図２に示した静的解析ステップＳ１０２の詳細な流れを示すフローチャートである。まず、静的解析部２は、ソースコード２０の静的構造解析を行う（Ｓ１１０）。次に、静的解析結果データベース３に、静的解析部２から出力された静的解析結果が格納される（Ｓ１１１）。

図４ａは、ソースコード２０の一例を示す図である。図４ｂは、静的解析結果データベース３の一例を示す図である。ステップＳ１１０の静的構造解析では、ソースコード２０を実行せずに（静的に）、ソースコード２０の構文、構造等が解析され、図４ｂのような静的解析結果を得る。図４ｂは、ソースコード２０に記載された関数を列挙する関数一覧であり、列挙された関数が呼び出している呼出し先関数についての情報を含む。図４ｂの「関数」列には、ソースコード２０に含まれる関数が列挙されている。図４ｂの「呼出し先関数」列には、「関数」列に示された関数が呼び出している関数が示されている。

例えば、図４ｂのＮｏ．１の行は、ソースコード２０において、ｍａｉｎ関数内でｔｅｓｔ１関数、ｔｅｓｔ２関数およびｔｅｓｔ３関数が呼び出されることを示している。次にＮｏ．５の行を見ると、ｔｅｓｔ３関数からｆｕｎｃ関数が呼び出されていることがわかる。

しかしながら、静的解析によるソフトウェア構成要素間の依存関係解析には限界がある。例えば、図４ａに示したソースコードでは、ｔｅｓｔ１関数においてｆｕｎｃ関数のアドレスが関数ポインタｐｆに代入され、ｔｅｓｔ２関数において関数ポインタｐｆが呼び出されている。しかし、図４ｂの静的解析結果データベース３に示されているように、静的解析ではｔｅｓｔ２関数から関数ポインタｐｆのアドレス先であるｆｕｎｃ関数が呼び出されたことは解析できていない。関数ポインタｐｆのアドレス先であるｆｕｎｃ関数がｔｅｓｔ２関数から呼び出されたことは、後述の動的解析によって解析される。

図３に戻り、ステップＳ１１１の後、静的依存関係解析部４は、静的解析結果データベース３に格納された静的解析結果を解析して（Ｓ１１２）、ソフトウェア構成要素間の依存関係を整理して静的依存関係データベース５に格納する（Ｓ１１３）。図４ｃは、静的依存関係データベース５の一例を示す図である。例えば図４ｃのＮｏ．１の行は、ｍａｉｎ関数がｔｅｓｔ１関数に依存していることを示している。したがって、図４ｃのＮｏ．１の行を見ると、ｔｅｓｔ１関数に変更が生じた場合、その変更の影響がｍａｉｎ関数にも及ぶことがわかる。

［２－２．動的解析］
図５は、図２に示した動的解析ステップＳ１０３の詳細な流れを示すフローチャートである。まず、コード加工部６は、ソースコード２０をログ取得可能に加工して、図６に示すような修正コード２１を作成する（Ｓ１２０）。修正コード２１は、例えばソースコード２０に記載されている関数の先頭に［関数名］＿ＩＮ（例えば、ｆｕｎｃ＿ＩＮ）という関数を挿入し、関数の末尾に［関数名］＿ＯＵＴ（例えば、ｆｕｎｃ＿ＯＵＴ）という関数を挿入したものである。

次に、コンパイル部７は、修正コード２１をコンパイルし、実行可能な形式の実行プログラムに変換する（Ｓ１２１）。実行部８は、実行プログラムを実行する。実行の際、例えば、実行プログラムにテストケースが与えられる。ここで、テストケースとは、プログラムの特定の機能を実現するための入力データである。テストケースは、ユーザや開発者によって外部から入力されてもよい。あるいは、テストケースは、解析装置１００に備えられたフラッシュメモリ、ＨＤＤ、ＳＳＤ等の記憶装置（図示せず）の中に予め格納されていてもよい。実行プログラムの実行の際、動的解析部９は、実行プログラムの処理を監視して実行ログ、アクセスログ等のログを生成する（Ｓ１２２）。

図７は、ログを生成するステップＳ１２２の詳細な流れを示すフローチャートである。ログを生成するステップＳ１２２では、まず、動的解析部９が、実行プログラムの実行が終了したか否かを判定する（Ｓ１３０）。実行プログラムの実行が終了していないと判定した場合、動的解析部９は、修正コード２１（実際は、修正コード２１をコンパイルした後の実行プログラム）の［関数名］＿ＩＮ関数または［関数名］＿ＯＵＴ関数が実行されたか否かを監視する（Ｓ１３１）。いずれも実行されていない場合は、ステップＳ１３０に戻る。

ステップＳ１３１において［関数名］＿ＩＮ関数が実行された場合は、図８に示すような動作ログ２２の「関数名」欄に［関数名］を、「状態」欄にＩＮを記録する（Ｓ１３２）。例えば、図８に示す例では、最初（実行順１）にｍａｉｎ＿ＩＮ関数が実行されたため、動作ログ２２の「関数名」欄にｍａｉｎと記録され、「状態」欄にＩＮと記録されている。記録した後、ステップＳ１３０に戻る。

ステップＳ１３１において［関数名］＿ＯＵＴ関数が実行された場合は、動作ログ２２の「関数名」欄に［関数名］を、「状態」欄にＯＵＴを記録する（Ｓ１３３）。記録した後、ステップＳ１３０に戻る。

以上のステップＳ１３０～Ｓ１３３を繰り返すことにより、図８に示すような動作ログ２２が生成される。ステップＳ１３０において実行プログラムの終了を検知した場合は、ログを生成するステップＳ１２２を終え、図５に示したステップＳ１２３に進む。

図５に戻り、ステップＳ１２２で生成された動作ログ２２は、動的解析結果データベース１０に格納される（Ｓ１２３）。動的依存関係解析部１１は、動的解析結果データベース１０に格納された動作ログ２２等の情報から、ソフトウェア構成要素間の動的依存関係を解析する（Ｓ１２４）。

図９は、動的依存関係を解析するステップＳ１２４の詳細な流れを示すフローチャートである。まず、動的依存関係解析部１１は、動作ログ２２（図８参照）の実行順１の「状態」欄の内容を確認する（Ｓ１４０、Ｓ１４１）。動作ログ２２の「状態」欄にＩＮが記録されていると判定した場合、動的依存関係解析部１１は、動的依存関係解析スタック２３（以下、「第１スタック」という。）に関数が格納されているか否かを判定する（Ｓ１４２）。図８に示した例では、実行順１の「状態」欄にはＩＮが記録されているため、第１スタック２３に関数が格納されているか否かを判定することになる。

第１スタック等のスタックは、例えば種々の情報を一時的に記憶するＳＲＡＭ、ＤＲＡＭ等の揮発性メモリを用いて実現される。

図１０は、第１スタック２３の一例を示す図である。実行順１についてのステップＳ１４２の時点では、第１スタック２３には関数が格納されていない（図１０の実行順１の行の上の行を参照）。ステップＳ１４２において、第１スタック２３に関数が格納されていない場合、動作ログ２２の現在の実行順の関数を第１スタック２３に登録（プッシュ、ｐｕｓｈ）する（Ｓ１４４）。図示の例では、実行順１で実行される関数はｍａｉｎ関数である（図８参照）。したがって、図１０に示す第１スタック２３の実行順１に、ｍａｉｎ関数をプッシュする。このようにして、第１スタック２３は、図１０の実行順１の行に示した状態となる。

図９のフローチャートの説明に戻ると、ステップＳ１４２において、第１スタック２３に関数が格納されている場合、動的依存関係解析部１１は、第１スタック２３に格納された関数を依存元とし、動作ログ２２の現在の実行順の関数を依存先として、動的依存関係に登録する（Ｓ１４３）。図９に示すように、ステップＳ１４３の次にも、ステップＳ１４４が実行される。

ステップＳ１４４の次に、動的依存関係解析部１１は、動作ログ２２の実行順が最後であるか否かを判定する（Ｓ１４７）。最後である場合は、動的依存関係を解析するステップＳ１２４を終えて、図５に示すステップＳ１２５に進む。最後でない場合は、実行順をインクリメントし（Ｓ１４８）、ステップＳ１４１に戻る。

以上では、動作ログ２２の「状態」欄にＩＮが記録されている場合、すなわち、ステップＳ１４１の判定結果がＹｅｓである場合について説明した。次に、動作ログ２２の「状態」欄にＩＮが記録されていない場合、すなわち、ステップＳ１４１の判定結果がＮｏである場合について説明する。この場合、動作ログ２２の「状態」欄にＯＵＴが記録されていることになる。この場合、ステップＳ１４２と同様に、第１スタック２３に関数が格納されているか否かを判定する（Ｓ１４５）。

ステップＳ１４５において、第１スタック２３に関数が格納されている場合、動的依存関係解析部１１は、第１スタック２３から関数を除外（ポップ、ｐｏｐ）する（Ｓ１４６）。ステップＳ１４５において、第１スタック２３に関数が格納されていない場合、ステップＳ１４７に進む。ステップＳ１４６が実行された後も、ステップＳ１４７に進む。

このようにして、最後の実行順まで実行順がインクリメントされ、ステップＳ１４７においてＹｅｓと判定された後は、第１スタック２３からは全ての関数がポップされ（図１０の実行順１２の行を参照）、図１１に示したような動的依存関係が得られている。そして図５に示すステップＳ１２５に進み、図１１に示したような動的依存関係が、動的依存関係データベース１２に格納される。

［２－３．総合的依存関係解析］
図１２は、図２に示した総合的な依存関係を解析するステップＳ１０４の詳細な流れを示すフローチャートである。ステップＳ１０４では、静的依存関係データベース５に格納された情報と、動的依存関係データベース１２に格納された情報と、を統合した依存関係が得られる。まず、総合的依存関係解析部１３は、図４ｃに示すような静的依存関係データベース５に格納されている全ての依存関係を解析結果１４に格納する（Ｓ１５０）。

次に、総合的依存関係解析部１３は、図１１に示すような動的依存関係データベース１２のＮｏ．１の行に格納された依存関係を取得する（Ｓ１５１）。図１１に示す例では、動的依存関係データベース１２のＮｏ．１の行には、ｍａｉｎ関数を依存元とし、ｔｅｓｔ１関数を依存先とする依存関係が格納されている。

次に、総合的依存関係解析部１３は、取得した依存関係が解析結果１４の中に存在するか否かを判定する（Ｓ１５２）。存在しないと判定した場合、総合的依存関係解析部１３は、取得した依存関係を解析結果１４に格納し（Ｓ１５３）、次のステップＳ１５４に進む。ステップＳ１５２において、取得した依存関係が解析結果１４の中に存在すると判定した場合も、ステップＳ１５４に進む。

ステップＳ１５４では、総合的依存関係解析部１３は、動的依存関係データベース１２の全ての行の依存関係を確認したか否かを判定する。全ての行の依存関係を確認し終えていない場合、総合的依存関係解析部１３は、動的依存関係データベース１２の次の行に格納された依存関係を取得する（Ｓ１５５）。その後、ステップＳ１５２に戻る。

ステップＳ１５４において、動的依存関係データベース１２の全ての行の依存関係を確認したと判定した場合には、総合的な依存関係を解析するステップＳ１０４を終え、図２に示したステップＳ１０５に進む。

図１３は、総合的な依存関係を解析するステップＳ１０４を終えた後の解析結果１４の一例を示す図である。図４ｃに示した静的依存関係データベース５と比較すると、図１３の解析結果１４には、Ｎｏ．４の行の依存関係が追加されている。静的解析ではｔｅｓｔ２関数から関数ポインタｐｆのアドレス先であるｆｕｎｃ関数が呼び出されたことは解析できないが、動的解析によって解析できるため、解析結果１４には静的依存関係データベース５にはない依存関係が追加されている。

［３．効果等］
以上のように、解析装置１００は、ソフトウェアのソースコード２０の構造を静的に解析する静的解析部２と、静的解析結果に基づいてソフトウェアのオブジェクト間の依存関係を解析する静的依存関係解析部４と、ソースコード２０が示すプログラムを実行して動作ログ２２を取得し、動作ログ２２に基づいてオブジェクト間の依存関係を解析する動的依存関係解析部１１と、を備える。解析装置１００は、静的依存関係解析部４の解析結果と、動的依存関係解析部１１の解析結果と、に基づいて、オブジェクト間の依存関係を解析する。

解析装置１００は、動的依存関係解析部１１による解析結果を用いることにより、静的解析では解析できなかったポインタ参照を介した関数間の依存関係を解析することができる。このように、解析装置１００は、動的解析と静的解析とを組み合わせることにより、従来技術より網羅的にソフトウェアの構成要素間の依存関係を解析することができる。

実施の形態２．
図１４は、本発明の実施の形態２に係る解析装置２００の構成を示すブロック図である。実施の形態１の解析装置１００と比較すると、解析装置２００にはコード加工部６が備えられていない。また、解析装置２００の動的解析部２０９、動的解析結果データベース２１０および動的依存関係解析部２１１のそれぞれの機能または動作が、実施の形態１の場合と異なる。

実施の形態２では、ソースコード２０の動的解析は、タスク間で送受信されるメッセージパッシングを解析することによって行われる。メッセージパッシングは、オブジェクト間の通信方式の１つであり、複数のタスクが並列に実行されるソフトウェアプログラムにおいて、タスク間で情報を共有するための手段の１つである。

解析装置２００の動作の流れは、実施の形態１の図２のフローチャートが示す流れと同様であるが、動的解析ステップ（図２のＳ１０３）の中身のみが異なる。図１５は、実施の形態２における動的解析の流れを示すフローチャートである。実施の形態１の図５のフローチャートと比較すると、図１５には、修正コードを作成するステップと、動的依存関係を動的依存関係データベースに格納するステップがない。動的依存関係を動的依存関係データベースに格納する動作は、実施の形態２では、後述のステップＳ２２４に含まれている。

図１６は、図１５のログを生成するステップＳ２２２の詳細な流れを示すフローチャートである。まず、動的解析部２０９が、実行プログラムの実行が終了したか否かを判定する（Ｓ２３０）。実行プログラムの実行が終了していないと判定した場合、動的解析部２０９は、タスクがメッセージを受信または送信したか否かを監視する（Ｓ２３１）。受信も送信もしていない場合は、ステップＳ２３０に戻る。

ステップＳ２３１においてタスクがメッセージを送信したことを認めた場合、動的解析部２０９は、図１７に示すようなメッセージログ２２２に、送信されたメッセージのコンテキストＩＤと、メッセージ内容と、メッセージを送信したタスクと、を記録する（Ｓ２３２）。例えば、タスクＡがコンテキストＩＤ＝０ｘ０００１で識別されるメッセージを送信した場合、図１７のメッセージログ２２２の最上行に示すように、「コンテキストＩＤ」欄と、「メッセージ内容」欄と、「送信タスク」欄に図示のような値が記録される。記録した後、ステップＳ２３０に戻る。

ステップＳ２３１においてタスクがメッセージを受信したと判定した場合、動的解析部２０９は、メッセージログ２２２に、メッセージを受信したタスクを記録する（Ｓ２３３）。例えば、タスクＡがコンテキストＩＤ＝０ｘ０００１で識別されるメッセージを送信した先の例において、タスクＸがこのメッセージを受信した場合、動的解析部２０９は、図１７のメッセージログ２２２の最上行に示すように、「受信タスク」欄にタスクＸと記録する。記録した後、ステップＳ２３０に戻る。

以上のステップＳ２３０～Ｓ２３３を繰り返すことにより、図１７に示すようなメッセージログ２２２が生成される。ステップＳ２３０において実行プログラムの終了を検知した場合は、ログを生成するステップＳ２２２を終え、図１５に示したステップＳ２２３に進む。

ステップＳ２２２で生成されたメッセージログ２２２は、動的解析結果データベース２１０に格納される（Ｓ２２３）。動的依存関係解析部２１１は、動的解析結果データベース２１０に格納されたメッセージログ２２２等の情報から、ソフトウェア構成要素間の動的依存関係を解析する（Ｓ２２４）。

図１８は、動的依存関係を解析するステップＳ２２４の詳細な流れを示すフローチャートである。まず、動的依存関係解析部２１１は、動的解析結果データベース２１０に格納されたメッセージログ２２２の全てのメッセージについて解析を終えたか否かを判定する（Ｓ２４０）。終えていない場合、動的依存関係解析部２１１は、未解析のメッセージを１つ選択し、そのコンテキストＩＤで識別される「受信タスク」欄の記録と「送信タスク」欄の記録を取得する（Ｓ２４１）。

次に、動的依存関係解析部２１１は、取得した受信タスクを依存元とし、かつ、送信タスクを依存先とする依存関係が動的依存関係データベース２１２に格納されているか否かを確認する（Ｓ２４２）。格納されている場合は、ステップＳ２４０に戻る。格納されていない場合は、取得した受信タスクを依存元とし、かつ、送信タスクを依存先とする依存関係を、動的依存関係データベース２１２に格納する（Ｓ２４３）。

Ｓ２４０において、全てのメッセージについて解析を終えたと判定した場合、動的依存関係を解析するステップＳ２２４を終える。このようにして、図１９に示したような動的依存関係データベース２１２が得られる。

以上のように、解析装置２００において、動的依存関係解析部２１１は、メッセージを送信したタスクと、前記メッセージを受信したタスクと、の間に依存関係があることを示す解析結果を生成する。動的依存関係解析部２１１は、この解析結果に基づいて動的解析を行い、解析装置２００は、静的依存関係解析部４の解析結果と、動的依存関係解析部２１１の解析結果と、に基づいて、タスク間の依存関係を解析する。

あるタスクから発信されたメッセージパッシングが、どのタスクで受信されて処理されるかは、プログラムを実行して動作させなければ把握できず、ソースコードの構造を静的に解析しただけではわからない。解析装置２００は、動的依存関係解析部２１１による解析結果を用いることにより、静的解析では解析できなかったメッセージパッシングを介した関数間の依存関係を解析することができる。このように、解析装置２００は、動的解析と静的解析とを組み合わせることにより、従来技術より網羅的にソフトウェアの構成要素間の依存関係を解析することができる。

実施の形態３．
図２０は、本発明の実施の形態３に係る解析装置３００の構成を示すブロック図である。実施の形態１の解析装置１００と比較すると、解析装置３００の動的解析部３０９、動的解析結果データベース３１０および動的依存関係解析部３１１のそれぞれの機能または動作が、実施の形態１の動的解析部９、動的解析結果データベース１０および動的依存関係解析部１１と異なる。

実施の形態３では、解析装置３００は、共有メモリを介してデータの受け渡しを行うオブジェクト間の動作を解析する。共有メモリは、例えば種々の情報を一時的に記憶するＳＲＡＭ、ＤＲＡＭ等の揮発性メモリで構成される。

解析装置３００の動作の流れは、実施の形態１の図２のフローチャートが示す流れと同様であるが、動的解析ステップ（図２のＳ１０３）の中身のみが異なる。図２１は、実施の形態３における動的解析の流れを示すフローチャートである。図２０および図２１を参照して、動的解析の流れを説明する。

まず、コンパイル部７は、ソースコード３２０をコンパイルし、実行可能な形式の実行プログラムに変換する（Ｓ３２１）。図２２は、ソースコード３２０の一例を示す図である。ソースコード３２０内では、共有メモリが利用されている。ソースコード３２０では、構造体Ｐｏｉｎｔがグローバルに宣言され、ｍａｉｎ関数内で実体が宣言されている。ｍａｉｎ関数内からＰｒｉｎｔＰｏｉｎｔ関数が実行される際に、ＰｒｉｎｔＰｏｉｎｔ関数の引数としてアドレスが渡されている。ＰｒｉｎｔＰｏｉｎｔ関数では、渡されたアドレス先の値を読み込む処理が行われている。図２３は、ソースコード３２０内で利用されている共有メモリのアドレス一覧３２１を示す図である。

次に、実行部８は、実行プログラムを実行する。この際、動的解析部３０９は、実行プログラムの処理を監視して、図２４に示すような関数実行ログ３２２と、図２５に示すような共有メモリアクセスログ３２３と、を生成する（Ｓ３２２）。

関数実行ログ３２２には、関数処理の開始時刻と終了時刻が記録される。図２４に示す例では、ｍａｉｎ関数が時刻００：００から時刻００：０５まで実行され、ＰｒｉｎｔＰｏｉｎｔ関数が時刻００：０５から時刻００：２０まで実行されたことがわかる。

共有メモリアクセスログ３２３には、アクセス先アドレスとアクセス時刻が記録される。動的解析部３０９は、共有メモリが宣言された際に確保されるアドレスを解析してアクセス先アドレスとアクセス時刻とを取得する。動的解析部３０９は、共有メモリにアクセスがあった際のアクセス先アドレスおよびアクセス時刻を共有メモリアクセスログ３２３に記録する。図２５に示す例では、アドレス０ｘ００００にアクセスがあった時刻は、００：０１および００：０６であったことがわかる。

図２１に戻り、生成された関数実行ログ３２２および共有メモリアクセスログ３２３は、動的解析結果データベース３１０に格納される（Ｓ３２３）。動的依存関係解析部３１１は、動的解析結果データベース３１０に格納された関数実行ログ３２２および共有メモリアクセスログ３２３から、ソフトウェア構成要素間の動的依存関係を解析する（Ｓ３２４）。

図２６は、動的依存関係を解析するステップＳ３２４の詳細な流れを示すフローチャートである。まず、動的依存関係解析部３１１は、共有メモリアクセスログ３２３からアクセス時刻を取得する（Ｓ３４０）。例えば、図２５に示した例において、アクセス時刻００：０１を取得する。他のアクセス時刻は、後のループの後に取得されるが、その際、取得済みの時刻（例えば００：０１）は取得しない。

図２６に戻り、動的依存関係解析部３１１は、ステップＳ３４０で取得したアクセス時刻に実行されていた関数を、関数実行ログ３２２から取得する（Ｓ３４１）。先の例では、取得したアクセス時刻は００：０１であった。図２４を参照すると、アクセス時刻００：０１において実行されていた関数は、ｍａｉｎ関数である。したがって、動的依存関係解析部３１１は、関数実行ログ３２２からｍａｉｎ関数を取得する。

次に、動的依存関係解析部３１１は、ステップＳ３４１で取得した関数を、アクセス時刻に共有メモリアドレスにアクセスしていた関数として、図２７に示すような共有メモリアクセス記録３２４に記録する（Ｓ３４２）。

次に、動的依存関係解析部３１１は、共有メモリアクセスログ３２３の全てのアクセス時刻を取得したか否かを判定する（Ｓ３４３）。取得していないと判定した場合は、ステップＳ３４０に戻る。取得したと判定した場合は、ステップＳ３４４に進む。共有メモリアクセスログ３２３の全てのアクセス時刻を取得した場合、図２７に示すような共有メモリアクセス記録３２４が完成したことになる。

次に、動的依存関係解析部３１１は、共有メモリアクセス記録３２４に記録された共有メモリアドレスのうち、未確認の１つを選択する（Ｓ３４４）。動的依存関係解析部３１１は、共有メモリアクセス記録３２４を確認し、選択された共有メモリアドレスに複数の関数からアクセスがあったか否かを判定する（Ｓ３４５）。

例えば、図２７に示した例において、ステップＳ３４４で共有メモリアドレス０ｘ００００を選択した場合、選択した共有メモリアドレス０ｘ００００にはｍａｉｎ関数およびＰｒｉｎｔＰｏｉｎｔ関数の複数の関数からアクセスがあったと判定できる。

ステップＳ３４５において複数の関数からアクセスがあったと判定した場合、アクセスした全ての関数を互いに依存元および依存先として組み合わせて、動的依存関係データベース３１２に格納する（Ｓ３４６）。先述の例では、共有メモリアドレス０ｘ００００にアクセスした関数は、ｍａｉｎ関数およびＰｒｉｎｔＰｏｉｎｔ関数であった。したがって、動的依存関係データベース３１２には、ＰｒｉｎｔＰｏｉｎｔ関数を依存元とし、ｍａｉｎ関数を依存先とする依存関係Ｎｏ．１と、ｍａｉｎ関数を依存元とし、ＰｒｉｎｔＰｏｉｎｔ関数を依存先とする依存関係Ｎｏ．２とが格納される。このようにして、図２８に示したような動的依存関係データベース３１２が得られる。

以上のように、解析装置３００は、共有メモリを利用する。動的依存関係解析部３１１は、ソースコード３２０が示すプログラムがアクセスした共有メモリのアドレスと、アクセスした時刻と、に基づいて、関数間の依存関係を解析する。

従来、関数呼出しによってアドレス渡しをした先の関数で共有メモリの値が書き換えられた場合、静的解析ではアドレスを介した依存関係を解析できなかった。解析装置３００は、静的解析では解析できなかった共有メモリを介した関数間の依存関係を解析することができる。このように、解析装置３００は、動的解析と静的解析とを組み合わせることにより、従来技術より網羅的にソフトウェアの構成要素間の依存関係を解析することができる。

実施の形態４．
図２９は、本発明の実施の形態４に係る解析装置４００の構成を示すブロック図である。解析装置４００は、実施の形態１の解析装置１００の構成に加えて、依存元補完部４１１を更に備える。依存元補完部４１１は、動作ログ（図８参照）がプログラム実行の途中から取得された場合であっても、呼出し先関数から呼出し元関数に遷移する際に依存関係を解析することができる。

解析装置４００の動作の流れは、実施の形態１の図２のフローチャートが示す流れと同様であるが、動的解析ステップ（図２のＳ１０３）の中身のみが異なる。図３０は、実施の形態４における動的解析の流れを示すフローチャートである。図３０のフローチャートも、動的依存関係を解析するステップＳ４２４以外は実施の形態１の図５のフローチャートと同様である。

しかしながら、ログを生成するステップＳ１２２がプログラムの途中から実行されているため、動作ログがプログラム実行の途中から取得されている。図３１は、プログラムの実行の途中から取得された動作ログ４２２の一例を示す図である。動作ログ４２２には、実行順４以降の関数名と状態が記録されている。実行順１～３の関数名と状態は記録されていない。

図３２は、動的依存関係を解析するステップＳ４２４の詳細な流れを示すフローチャートである。依存元補完部４１１は、動作ログ４２２の実行順１の「状態」欄にＩＮが記録されているか否かを判定する（Ｓ１４０、Ｓ１４１）。ＩＮが記録されていると判定した場合、ステップＳ１４２へ進むが、ステップＳ１４２以降の流れは図９に示した実施の形態１の流れと同様であるため、説明を省略する。

ステップＳ１４１においてＩＮが記録されていないと判定した場合、依存元補完部４１１は、図３３に示す動的依存関係解析スタック（第１スタック）４２３に関数が格納されているか否かを判定する（Ｓ１４５）。第１スタック４２３に関数が格納されている場合、第１スタック４２３から関数をポップする（Ｓ１４６）。

ポップした後、依存元補完部４１１は、第１スタック４２３が空になったか否かを判定する（Ｓ４４０）。空になったと判定した場合、依存元補完部４１１は、ステップＳ１４６でポップされた関数を、呼出し元不明関数スタック４２４（以下、「第２スタック」という。）にプッシュする（Ｓ４４１）。図３４は、第２スタックの一例を示す図である。ステップＳ４４１の後、実施の形態１で述べたステップＳ１４７（図９参照）に進む。

ステップＳ１４５において第１スタック４２３に関数が格納されていないと判定した場合、依存元補完部４１１は、第２スタックに関数が格納されているか否かを判定する（Ｓ４４２）。第２スタックに関数が格納されていると判定した場合、依存元補完部４１１は、動作ログ４２２の現在の実行順の関数を依存元とし、第２スタックに登録されている関数を依存先として、動的依存関係に登録する（Ｓ４４３）。登録後、ステップＳ１４７に進む。

このような実施の形態４の特徴を図示の例を用いて説明する。図示の例では、プログラムの途中から動作ログ４２２（図３１参照）を取得したため、ｔｅｓｔ２関数の開始処理より前のプログラム動作が不明となっている。そのため、実行順７でｔｅｓｔ２関数の状態がＯＵＴとなった際に（図３１参照）、第１スタック４２３（図３３）からｔｅｓｔ２関数がポップされ、第１スタック４２３内の関数がなくなってしまう。すなわち、ｔｅｓｔ２関数の呼出し元が不明である。そこで、ｔｅｓｔ２関数を呼出し元不明関数スタック（第２スタック）４２４に登録する（Ｓ４４１）。ｔｅｓｔ２関数の呼出し関数がｍａｉｎ関数であったことがわかるのは、実行順１２でｍａｉｎ関数の状態がＯＵＴとなった（図３１参照）時である。そこで、依存元関数をｍａｉｎ関数、依存先関数をｔｅｓｔ２関数として動的依存関係に登録する（Ｓ４４３）。ｔｅｓｔ３関数についても同様である。

以上のようにして、図３５に示すような動的依存関係データベース４１２が得られる。

上記のように、解析装置４００において、依存元補完部４１１は、関数の実行順を示す動作ログ４２２をプログラムの実行途中から取得した場合、呼出し先の関数から呼出し元の関数への遷移を示す動作ログ４２２の情報に基づいて、関数間の依存関係を補完する。

これにより、解析装置４００は、動的解析においてプログラムが途中から実行された場合においても、呼出し元の関数を解析することができ、従来技術より網羅的にソフトウェアの構成要素間の依存関係を解析することができる。

実施の形態５．
図３６は、本発明の実施の形態５に係る解析装置５００の構成を示すブロック図である。解析装置５００は、実施の形態１の解析装置１００の構成に加えて、タスク指定部５１１を更に備える。

解析装置５００の動作の流れは、実施の形態１の図２のフローチャートが示す流れと同様であるが、動的解析ステップ（図２のＳ１０３）の中の動的依存関係を解析するステップ（図５のＳ１２４）のみが異なる。

図３７は、動作ログ５２２を示す図である。動作ログ５２２は、動的解析部５０９によって作成され、動的解析結果データベース５１０に格納される。図８に示した実施の形態１の動作ログ２２と比較すると、動作ログ５２２には、「タスク」欄が更に設けられている。「タスク」欄には、「関数名」欄に記載された関数を実行するタスクが記録される。動作ログ５２２の実行順５および６に記載されたｉｎｔｅｒｒｕｐｔ関数は、割り込みタスクＩｎｔｅｒｒｕｐｔによって実行された割り込み処理の一例である。

図３８は、実施の形態５における動的依存関係を解析するステップの詳細な流れを示すフローチャートである。実施の形態５では、ユーザが、除外タスク５３０（図３６参照）を指定する。指定されたタスクは、解析対象から除外される。ユーザは、マウス、キーボード、タッチパネル、ボタン、音声入力のためのマイク等の入力装置（図示せず）を用いて、解析装置５００に除外タスク５３０を入力する。除外タスク５３０は、動作ログ５２２の中から選択されてもよいし、予め設定されていてもよい。

タスク指定部５１１は、まず、入力された除外タスク５３０を読み込む（Ｓ５３９）。次に、動作ログ５２２（図３７参照）の実行順１の「状態」欄と「タスク」欄とを確認する（Ｓ５４０）。「タスク」欄に記録されたタスクが除外タスク５３０に該当しない場合、ステップＳ１４１に進む（Ｓ５４１）。ステップＳ１４１～Ｓ１４８は、図９に示した実施の形態１のステップと同様であるため、説明を省略する。

ステップＳ５４１において「タスク」欄に記録されたタスクが除外タスク５３０に該当すると判定した場合、動的依存関係の解析を省略してステップＳ１４７に進む。

例えば、ユーザが割り込み処理についての依存関係解析を除外したいと考えた場合、ユーザは、除外タスク５３０としてＩｎｔｅｒｒｕｐｔタスクを指定する。これにより、図３７に示した動作ログ５２２の実行順５および６は解析対象から除外される。したがって、ｔｅｓｔ２関数とｉｎｔｅｒｒｕｐｔ関数との間の依存関係は出力されない。

以上のように、解析装置５００は、解析対象のタスクを指定する除外タスク５３０の入力を受け付けるタスク指定部５１１を更に備える。タスク指定部５１１は、除外タスク５３０で指定されたタスクに関する関数間の依存関係は解析せず、それ以外のタスクに関する関数間の依存関係を解析する。これにより、本来は依存関係がない割込み関数についての解析を除外することができ、動的解析処理において解析装置５００に加えられる負荷を低減させることができる。また、ユーザがソフトウェア変更時の影響を確認する工数を削減することができる。

実施の形態６．
図３９は、本発明の実施の形態６に係る解析装置６００の構成を示すブロック図である。解析装置６００は、実施の形態１の解析装置１００の構成に加えて、影響度補完部６１１を更に備える。

解析装置６００の動作の流れは、実施の形態１の図２のフローチャートが示す流れと同様であるが、動的解析ステップ（図２のＳ１０３）の中の動的依存関係を解析するステップ（図５のＳ１２４）のみが異なる。解析装置６００の動作を、図４０に示した動作ログ６２２と、図４１に示した動的依存関係解析スタック（第１スタック）６２３と、を用いて説明する。

図４２は、実施の形態６における動的依存関係を解析するステップの詳細な流れを示すフローチャートである。図９に示した実施の形態１のフローチャートと比較すると、図４２のフローチャートには、ステップＳ６４０およびステップＳ６４１が追加されている。

影響度補完部６１１は、動作ログ６２２の実行順１の「状態」欄にＩＮが記録されているか否かを判定する（Ｓ１４０、Ｓ１４１）。ＩＮが記録されていないと判定した場合、ステップＳ１４５へ進むが、ステップＳ１４５～Ｓ１４８の流れは図９に示した実施の形態１の流れと同様であるため、説明を省略する。

ステップＳ１４１においてＩＮが記録されていると判定した場合、動的依存関係解析部１１は、第１スタック６２３に関数が格納されているか否かを判定する（Ｓ１４２）。格納されていないと判定した場合、ステップＳ１４４に進む。

ステップＳ１４２において第１スタック６２３に関数が格納されていると判定した場合、影響度補完部６１１は、現在の実行順の関数依存関係が動的依存関係に登録されているか否かを判定する（Ｓ６４０）。具体的には、影響度補完部６１１は、第１スタック６２３に格納された関数を依存元とし、動作ログ６２２の現在の実行順の関数を依存先とした関数依存関係が動的依存関係に登録されているか否かを判定する。

現在の実行順の関数依存関係が動的依存関係に登録されていると判定した場合、影響度補完部６１１は、その関数依存関係についての依存強度値をインクリメントする（Ｓ６４１）。依存強度値は、２つの関数間の依存の強度を示す値である。依存強度値が大きいほど関数間の依存強度が強いことを意味する。依存強度値の初期値は例えば０である。依存強度値をインクリメントした後、ステップＳ１４４に進む。

ステップＳ６４０において、現在の実行順の関数依存関係が動的依存関係に登録されていないと判定した場合、影響度補完部６１１は、現在の実行順の関数依存関係を動的依存関係に登録する（Ｓ１４３）。登録した後、ステップＳ１４４に進む。

図４２に示した各ステップを行うことにより、図４３に示したような動的依存関係が得られ、動的依存関係データベース６１２に格納される。

次に、総合的依存関係解析部６１３（図３９参照）の動作について説明する。図４４に示すようなソースコード６２０に静的解析（図３参照）を行うと、図４５に示すような静的依存関係が静的依存関係データベース５に格納される。また、ソースコード６２０に動的解析を行うと、図４３に示したような動的依存関係が動的依存関係データベース６１２に格納される。

図４６は、総合的な依存関係を解析するステップの詳細な流れを示すフローチャートである。図１２に示した実施の形態１のフローチャートと比較すると、図４６のフローチャートには、ステップＳ６５３が追加されている。

総合的な依存関係を解析するステップでは、総合的依存関係解析部６１３は、静的依存関係データベース５に格納されている全ての依存関係を解析結果６１４に格納する（Ｓ１５０）。次に、総合的依存関係解析部６１３は、図４３に示すような動的依存関係データベース６１２のＮｏ．１の行に格納された依存関係を取得する（Ｓ１５１）。次に、総合的依存関係解析部６１３は、取得した依存関係が解析結果６１４の中に存在するか否かを判定する（Ｓ１５２）。存在しないと判定した場合、総合的依存関係解析部６１３は、取得した依存関係を解析結果６１４に格納し（Ｓ１５３）、次のステップＳ１５４に進む。

ステップＳ１５２において、取得した動的依存関係が解析結果６１４の中に存在すると判定した場合、取得した依存関係の依存強度値を解析結果に格納する（Ｓ６５３）。格納した後、ステップＳ１５４に進む。

ステップＳ１５４およびステップＳ１５５は実施の形態１と同様であるため、説明を省略する。

図４７は、総合的な依存関係を解析するステップを終えた後の解析結果６１４の一例を示す図である。

以上のように、解析装置６００では、依存強度値が付与された解析結果６１４を得ることができる。これにより、重み付けの指標が負荷された依存関係を得ることができる。したがって、ソフトウェアを変更した場合に効率的に変更の影響範囲を確認することができ、高精度にソフトウェアの構成要素間の依存関係を解析することができる。

実施の形態７．
図４８は、本発明の実施の形態７に係る解析装置７００の構成を示すブロック図である。解析装置７００は、総合的依存関係解析部７１３の動作と解析結果７１４の内容を除き、実施の形態１の解析装置１００と同様である。

実施の形態６と同様のソースコード６２０（図４４参照）を解析する例について説明する。ソースコード６２０に静的解析（図３参照）を行うと、実施の形態６と同様に図４５に示したような静的依存関係が静的依存関係データベース５に格納される。また、ソースコード６２０に動的解析を行うと、図４９に示すような動的依存関係が動的依存関係データベース１２に格納される。

図５０は、総合的な依存関係を解析するステップの詳細な流れを示すフローチャートである。まず、総合的依存関係解析部７１３は、静的依存関係データベース５に格納されている全ての依存関係を解析結果７１４に格納する（Ｓ１５０）。次に、総合的依存関係解析部７１３は、図４９に示すような動的依存関係データベース１２のＮｏ．１の行に格納された依存関係を取得する（Ｓ１５１）。次に、総合的依存関係解析部７１３は、取得した依存関係が解析結果７１４の中に存在するか否かを判定する（Ｓ１５２）。

存在すると判定した場合、総合的依存関係解析部７１３は、取得した依存関係の重要度値をインクリメントし、その結果を解析結果７１４に格納する（Ｓ７５３）。格納した後、次のステップＳ１５４に進む。ステップＳ１５２において、取得した依存関係が解析結果７１４の中に存在しないと判定した場合も、ステップＳ１５４に進む。

依存関係の重要度値は、その依存関係の重要度を示す値である。重要度値が大きいほどその依存関係がプログラムにとって重要であることを意味する。重要度値の初期値は例えば０である。

ステップＳ１５４およびステップＳ１５５は実施の形態１と同様であるため、説明を省略する。

図５１は、総合的な依存関係を解析するステップを終えた後の解析結果７１４の一例を示す図である。

以上のように、解析装置７００では、重要度値が付与された解析結果７１４を得ることができる。これにより、重み付けの指標が負荷された依存関係を得ることができる。したがって、ソフトウェアを変更した場合に効率的に変更の影響範囲を確認することができ、高精度にソフトウェアの構成要素間の依存関係を解析することができる。

実施の形態８．
図５２は、本発明の実施の形態８に係る解析装置８００の構成を示すブロック図である。解析装置８００は、実施の形態１の解析装置１００の構成に加えて、関数テーブル解析部８１６と、関数テーブル依存関係データベース（ＤＢ）８１７とを備える。図５２のソースコード８２０は、関数テーブルが含まれたソースコードの一例である。

図５３は、解析装置８００の動作の流れを示すフローチャートである。解析装置８００は、図２に示した実施の形態１の動作に加えて、関数テーブル内の関数の依存関係を解析するステップＳ８０６を更に含む。

まず、解析装置８００は、入力部１を介して、ソースコード８２０を読み込む（Ｓ１０１）。図５４は、ソースコード８２０の一例を示す図である。ソースコード８２０には、関数テーブルの記載が含まれている。関数テーブルは、本開示の「一括データ群」の一例である。

次に、図５３に示すように、解析装置８００は、ソースコード８２０に静的解析を実行し、静的依存関係を解析する（Ｓ１０２）。図５５は、ステップＳ１０２中において生成される静的解析結果データベース８０３の一例を示す図である。静的解析結果データベース８０３には、実施の形態１の図４ｂに示したような関数一覧８０３１と、ソースコード８２０内の文字列配列を示す文字列配列８０３２と、が含まれる。ソースコード８２０には複数の文字列配列８０３２が記載されている場合があり、静的解析結果データベース８０３には、複数の文字列配列８０３２が含まれてもよい。

図５３に戻り、静的依存関係を解析するステップＳ１０２の後、解析装置８００は、ソースコード２０に動的解析を実行し、動的依存関係を解析する（Ｓ１０３）。図５６は、ステップＳ１０３において得られた結果を格納する動的依存関係データベース１２の一例を示す図である。なお、ステップＳ１０２とステップＳ１０３の実行順は逆であってもよく、ステップＳ１０２の前にステップＳ１０３が実行されてもよい。

図５２に示したように、静的解析結果データベース８０３および動的依存関係データベース１２は、関数テーブル解析部８１６にも入力される。関数テーブル解析部８１６は、図５３に示すように、ステップＳ１０２およびステップＳ１０３の後、関数テーブル内の関数の依存関係を解析する（Ｓ８０６）。

図５７は、図５３に示した関数テーブル内の関数の依存関係を解析するステップＳ８０６の詳細な流れを示すフローチャートである。まず、関数テーブル解析部８１６は、動的依存関係データベース１２内の依存先関数が、静的解析結果データベース８０３内の文字列配列８０３２に登録された文字列のいずれかに一致するか否かを判定する（Ｓ８０７）。一致する場合は次のステップＳ８０８に進み、一致しない場合は関数テーブル内の関数の依存関係を解析するステップＳ８０６（図５３参照）を終える。図５５および図５６に示した例では、動的依存関係データベース１２内のｔｅｓｔ１関数が文字列配列８０３２に登録された文字列に一致するため、ステップＳ８０８に進むことになる。

次に、静的解析結果データベース８０３の文字列配列８０３２の配列要素番号に１を設定し、文字列配列８０３２の配列要素番号１について確認する（Ｓ８０８）。

次に、関数テーブル解析部８１６は、文字列配列８０３２の文字列のうち設定された配列要素番号に登録された文字列が、関数一覧８０３１の中にあるか否かを判定する（Ｓ８０９）。設定された配列要素番号に登録された文字列が関数一覧８０３１の中にない場合、関数テーブル内の関数の依存関係を解析するステップＳ８０６（図５３参照）を終える。

文字列配列８０３２の文字列のうち設定された配列要素番号に登録された文字列が関数一覧８０３１の中にある場合は、関数テーブル解析部８１６は、当該文字列配列８０３２の文字列を依存先とし、動的依存関係データベース１２の依存元関数を依存元とした依存関係を関数テーブル依存関係データベース８１７に格納する（Ｓ８１０）。ステップＳ８０９およびＳ８１０を、静的解析結果データベース８０３の文字列配列８０３２の全ての配列要素番号について行う（Ｓ８１１、Ｓ８１２）。

図５８ａは、関数テーブル内の関数の依存関係を解析するステップＳ８０６を終えた後の関数テーブル依存関係データベース８１７の一例を示す図である。関数テーブル依存関係データベース８１７が示しているのは、ソースコード８２０の特定の実行時には実行されなかったが、ランダム関数の戻り値によっては実行され得る呼出し先関数を含めた依存関係である。

すなわち、図５４に示したようなソースコード８２０をコンパイルして実行すると、ｍａｉｎ関数内で、ランダム関数であるｒａｎｄ関数の戻り値を使って、関数テーブルｔｅｓｔＴａｂｌｅ内に登録された関数が実行される。図５６に示した動的依存関係解析の結果では、ｔｅｓｔ１関数が実行されている。そこで、図５５に示した静的解析結果データベース８０３を確認すると、ｔｅｓｔ１関数を含む文字列配列８０３２には、ｔｅｓｔ２～４関数も含まれていることがわかる。したがって、ランダム関数の戻り値によっては、ｔｅｓｔ１関数の代わりにｔｅｓｔ２～４関数が実行され得ることがわかる。このような場合、ｔｅｓｔ２～４関数の内容が変更された場合にも、ｍａｉｎ関数への影響を考慮すべきである。実施の形態８の解析装置８００を用いると、以上のようにｔｅｓｔ２～４関数とｍａｉｎ関数との依存関係をも解析することができる。

図５８ｂは、関数テーブル内の関数の依存関係を解析するステップＳ８０６を終えた後の関数テーブル依存関係データベース８１７の他の例を示す図である。図５８ｂの表には、図５８ａの「依存元」欄および「依存先」欄に加えて、「影響度」欄が追加されている。

影響度は、関数テーブル解析部８１６によって、例えば関数テーブル内の関数の依存関係を解析するステップＳ８０６の中で算出される。例えば、関数テーブル解析部８１６は、図５７に示したステップＳ８０７において、動的依存関係データベース１２内の依存先関数が、静的解析結果データベース８０３内の文字列配列８０３２に登録された文字列のいずれかに一致すると判定した場合、当該文字列配列８０３２に登録されている文字列の数（Ｎ１）をカウントする。図５５に示した例では、Ｎ１＝４である。カウント結果は、影響度算出情報として関数テーブル依存関係データベース８１７に格納されてもよい。

次に、関数テーブル解析部８１６は、当該文字列配列８０３２に登録されている文字列のうち、動的依存関係データベース１２内の依存先関数に記録されているものの数（Ｎ２）をカウントする。図５５および図５６に示した例では、Ｎ２＝１である。カウント結果は、影響度算出情報として関数テーブル依存関係データベース８１７に格納されてもよい。

文字列配列８０３２に登録されている文字列のうち、動的依存関係データベース１２内の依存先関数に記録されているものについては、関数テーブル依存関係データベース８１７の影響度を１とする。図５８ｂでは、ｔｅｓｔ１関数についての影響度が１となっている。ｔｅｓｔ１関数は、実際の動的解析において実行されているため、ｍａｉｎ関数との依存関係が強いと考えられるからである。

文字列配列８０３２に登録されている文字列のうち、動的依存関係データベース１２内の依存先関数に記録されているもの以外については、影響度Ｘは、上記のＮ１およびＮ２を用いて、次の式（１）によって算出される。

図５５および図５６に示した例では、Ｎ１＝４、Ｎ２＝１であるから、図５８ｂでは、ｔｅｓｔ２関数、ｔｅｓｔ３関数およびｔｅｓｔ４関数についての影響度Ｘは、式（１）より０．２５となる。影響度Ｘは、関数テーブルの中の関数の数に応じて、依存関係に均等に割り付けられた割合値を示している。

関数テーブル内の関数の依存関係を解析するステップＳ８０６を終えた後、総合的な依存関係を解析するステップＳ８０４が実行される。ステップＳ８０４では、図５９に示すように、静的依存関係データベース５に格納された情報と、動的依存関係データベース１２に格納された情報と、関数テーブル依存関係データベース８１７に格納された情報と、を統合した解析結果８１４が得られる。

以上のように、解析装置８００は、動的依存関係解析部１１の解析結果において他の関数と依存関係を有するとされた関数が、ソフトウェアの関数テーブルに含まれる場合、関数テーブル内の全ての関数と当該他の関数との間に依存関係があることを示す解析結果を生成する。

従来技術では、ポインタを介する関数テーブルによる依存関係は、静的解析によっては解析できなかった。また、従来の動的解析では、関数テーブルへの依存関係のうち実行された関数への依存関係は解析できるものの、未実行の関数への依存関係は解析できなかった。これに対して、解析装置８００は、プログラムが関数テーブルに登録されている一部の関数を実行した場合、関数テーブルに登録されている他の関数に対する依存関係を解析することができる。これにより、ソフトウェアを変更した場合に効率的に変更の影響範囲を確認することができ、高精度にソフトウェアの構成要素間の依存関係を解析することができる。

実施の形態９．
図６０は、本発明の実施の形態９に係る解析システム１０００の構成を示すブロック図である。解析システム１０００は、解析装置９００と、外部装置９５０とを含む。本発明の解析機能は、実施の形態１の解析装置１００（図１参照）のように１つの装置内の構成要素のみで実現される必要はなく、複数の装置が協働することによって実現されてもよい。

実施の形態９では、ソースコード２０は、解析装置９００にだけでなく、外部装置９５０にも入力される。外部装置９５０は、ソースコード２０を読み込む入力部９５１を備える。さらに、外部装置９５０は、実施の形態１の解析装置１００と同様のコード加工部６と、コンパイル部７と、実行部８と、動的解析部９と、動的解析結果データベース１０とを備える。外部装置９５０は、動的解析結果データベース１０に格納されたデータを出力する出力部９５２を更に備える。

外部装置９５０は、図５に示す修正コードを作成するステップＳ１２０と、修正コードをコンパイルして実行プログラムに変換するステップＳ１２１と、ログ生成ステップＳ１２２と、ログを動的解析結果データベース１０に格納するステップＳ１２３とを行う。動的解析結果データベース１０に格納されたデータは、出力部９５２を介して解析装置９００に出力される。

外部装置９５０の出力部９５２から出力されたデータは、解析装置９００の第２入力部９１６に入力される。

解析装置９００は、実施の形態１の解析装置１００と異なり、コード加工部６、コンパイル部７、実行部８、動的解析部９、および動的解析結果データベース１０を備えていない。これらの構成要素が実現していた機能は、外部装置９５０によって実現されるからである。これらの構成要素以外については、解析装置９００は、実施の形態１の解析装置１００と同様の構成要素を備える。

このように、本発明の解析機能を実現する構成要素は、複数の装置によって実現されてもよい。これにより、例えば、処理能力の高いコンピュータに、処理負荷の高い動的解析を担当させることができる。

また、上記の様に動的解析を行う部分を担当する装置を設けるだけでなく、例えば、静的解析結果データベース３、動的解析結果データベース１０、静的依存関係データベース５および動的依存関係データベース５等のデータベースが、解析装置９００の外部の記憶装置に格納されてもよい。このような外部の記憶装置は、例えばネットワークを介して解析装置９００および外部装置９５０と通信可能な外部サーバであってもよい。

変形例１．
以上の実施の形態１～９では、動的解析として、プログラムを一度だけ実行する例について説明した。しかしながら、本発明はこれに限定されず、プログラムを複数回実行して動作ログを併合または蓄積する動的解析が行われてもよい。

図６１ａは、実行部８（図１参照）によって、ステップＳ１２２（図５参照）において特定の環境で特定の入力データを与えて実行プログラムを実行して得られた動作ログ２２ａを示す図である。図６１ｂは、他の環境でまたは他の入力データを与えて実行プログラムを実行することにより得られた動作ログ２２ｂを示す図である。図６１ａおよび図６１ｂに示すように、同じプログラムであっても、異なる実行パスを経由した場合、異なる動作ログが出力される。

動作ログ２２ａおよび２２ｂは、動的解析結果データベース１０に格納される。動作ログ２２ａに基づいて動的依存関係を解析するステップＳ１２４（図９参照）を行うと、図６２ａに示すような動的依存関係１４ａが得られる。一方、動作ログ２２ｂに基づいて動的依存関係を解析するステップＳ１２４を行うと、図６２ｂに示すような動的依存関係１４ｂが得られる。動的依存関係１４ａと動的依存関係１４ｂとを併せることにより、図６２ｃに示すような動的依存関係１４ｃが得られる。

このようにして、様々な実行パスを経由してプログラムを解析することができ、精度の高い解析を実現することができる。

変形例２．
以上の実施の形態１～９では、出力部１５から解析結果を出力する解析装置について説明した。解析結果を出力する代わりに、本発明の解析装置は、解析結果をユーザに表示する表示部を備えてもよい。表示部には、最終的な総合的依存関係解析の結果だけでなく、静的構造解析結果、静的依存関係解析結果、動的解析結果および動的依存関係解析結果が表示されてもよい。表示部は、例えば液晶ディスプレイ、有機ＥＬディスプレイ、プロジェクタである。これにより、ユーザは、表示部に表示された解析結果を確認することにより、関数間の依存関係を把握することができる。例えば、依存先の関数を変更した場合、表示部に表示された依存元の関数を確認することにより、効率良くかつ高精度にソフトウェア開発を行うことができる。

本明細書では、本発明の実施の形態および変形例を説明した。しかしながら、上記の説明は本発明の例示である。上記の実施の形態および変形例には、本発明の範囲を逸脱することなく種々の改良や変形を加えることができる。また、各実施の形態および変形例は、適宜組み合わせることができる。

１ 入力部、２ 静的解析部、３ 静的解析結果データベース、４ 静的依存関係解析部、５ 静的依存関係データベース、５ 動的依存関係データベース、６ コード加工部、７ コンパイル部、８ 実行部、９ 動的解析部、１０ 動的解析結果データベース、１１ 動的依存関係解析部、１２ 動的依存関係データベース、１３ 総合的依存関係解析部、１４ 解析結果、１５ 出力部、２０ ソースコード、２１ 修正コード、２２ 動作ログ、２３ 動的依存関係解析スタック（第１スタック）、１００ 解析装置。

Claims (14)

1. ソフトウェアのソースコードの構造を静的に解析し、前記ソフトウェアのオブジェクト間の依存関係を解析する第１解析部と、
   前記ソースコードが示すプログラムを実行して前記オブジェクトの動作に関する第１情報を取得し、前記第１情報に基づいて前記オブジェクト間の依存関係を解析する第２解析部と、を備え、
   前記第１解析部の解析結果と、前記第２解析部の解析結果と、に基づいて、前記オブジェクト間の依存関係を解析し、
   前記第２解析部の解析結果において他のオブジェクトと依存関係を有するとされたオブジェクトが、前記ソフトウェアの一括データ群に含まれる場合、前記一括データ群の全てと前記他のオブジェクトとの間に依存関係があることを示す解析結果を生成するソフトウェア解析装置。
2. ソフトウェアのソースコードの構造を静的に解析し、前記ソフトウェアのオブジェクト間の依存関係を解析する第１解析部と、
   前記ソースコードが示すプログラムを実行して前記オブジェクトの動作に関する第１情報を取得し、前記第１情報に基づいて前記オブジェクト間の依存関係を解析する第２解析部と、を備え、
   前記第１解析部の解析結果と、前記第２解析部の解析結果と、に基づいて、前記オブジェクト間の依存関係を解析し、
   前記第２解析部が取得する前記第１情報は、前記オブジェクトの実行順を示す第２情報を含み、
   前記第２情報は、オブジェクトから他のオブジェクトへの遷移を示す情報を含み、
   前記第２解析部は、前記第２情報を前記ソースコードが示すプログラムの実行途中から取得した場合、呼出し先のオブジェクトから呼出し元のオブジェクトへの遷移を示す情報に基づいて、前記オブジェクト間の依存関係を補完する、ソフトウェア解析装置。
3. ソフトウェアのソースコードの構造を静的に解析し、前記ソフトウェアのオブジェクト間の依存関係を解析する第１解析部と、
   前記ソースコードが示すプログラムを実行して前記オブジェクトの動作に関する第１情報を取得し、前記第１情報に基づいて前記オブジェクト間の依存関係を解析する第２解析部と、を備え、
   前記第１解析部の解析結果と、前記第２解析部の解析結果と、に基づいて、前記オブジェクト間の依存関係を解析し、
   前記第１解析部の解析結果のうち前記第２解析部の解析結果の中に存在しない依存関係を、前記第２解析部の解析結果に加えた解析結果を生成する第３解析部を更に備えた、ソフトウェア解析装置。
4. 前記第２解析部が取得する前記第１情報は、前記オブジェクトの実行順を示す第２情報を含む、請求項１又は３に記載のソフトウェア解析装置。
5. 前記第２解析部は、他のオブジェクトを呼び出すオブジェクトと、呼び出される前記他のオブジェクトと、の間に依存関係があることを示す解析結果を生成する、請求項１～４のいずれかに記載のソフトウェア解析装置。
6. 前記第２解析部は、メッセージを送信したオブジェクトと、前記メッセージを受信したオブジェクトと、の間に依存関係があることを示す解析結果を生成する、請求項１～５のいずれかに記載のソフトウェア解析装置。
7. 前記第２解析部は、前記ソースコードが示すプログラムがアクセスした共有メモリのアドレスと、アクセスした時刻と、に基づいて、前記オブジェクト間の依存関係を解析する、請求項１～６のいずれかに記載のソフトウェア解析装置。
8. 前記ソフトウェア解析装置は、解析対象のタスクを指定する指示の入力を受け付けるタスク指定部を更に備え、
   前記第２解析部は、指定された前記タスクに関する前記オブジェクト間の依存関係のみを解析する、請求項１～７のいずれかに記載のソフトウェア解析装置。
9. 前記第２解析部による解析過程における前記オブジェクトの実行回数に応じた重要度値を含む解析結果を生成する、
   請求項１～８のいずれかに記載のソフトウェア解析装置。
10. 前記オブジェクト間の依存関係の影響の程度を示す影響度値を算出し、
    前記影響度値は、前記一括データ群の中のデータと前記他のオブジェクトとの間の依存関係に対して、前記一括データ群の中のデータの数に応じて均等に割り付けられた割合値である、請求項１に記載のソフトウェア解析装置。
11. 前記一括データ群の中のデータのうち前記第２解析部の解析結果において前記他のオブジェクトと依存関係を有するとされたオブジェクトと、前記他のオブジェクトと、の間の依存関係に対して、前記一括データ群の中の他のデータと前記他のオブジェクトとの間の依存関係に付与された前記影響度値よりも高い影響度値を付与する、
    請求項１０に記載のソフトウェア解析装置。
12. 前記第１解析部の解析結果、前記第２解析部の解析結果、並びに、前記第１解析部の解析結果および前記第２解析部の解析結果に基づいて解析された前記オブジェクト間の依存関係のうち少なくとも１つを表示する表示装置を更に備えた、
    請求項１～１１のいずれかに記載のソフトウェア解析装置。
13. ソフトウェアのソースコードの構造を静的に解析し、前記ソフトウェアのオブジェクト間の依存関係を解析する第１解析ステップと、
    前記ソースコードが示すプログラムを実行して前記オブジェクトの動作に関する第１情報を取得し、前記第１情報に基づいて前記オブジェクト間の依存関係を解析する第２解析ステップと、
    前記第１解析ステップの解析結果と、前記第２解析ステップの解析結果と、に基づいて、前記オブジェクト間の依存関係を解析するステップと、
    前記第２解析ステップの解析結果において他のオブジェクトと依存関係を有するとされたオブジェクトが、前記ソフトウェアの一括データ群に含まれる場合、前記一括データ群の全てと前記他のオブジェクトとの間に依存関係があることを示す解析結果を生成するステップと、
    を含むソフトウェア解析方法。
14. 請求項１３に記載のソフトウェア解析方法をコンピュータに実行させるためのソフトウェア解析プログラム。

Images