JP7082284B2 - 分析支援方法および分析支援プログラム - Google Patents

Description

本発明は分析支援方法および分析支援プログラムに関する。

現在、様々な情報処理を行うコンピュータシステムが利用されている。コンピュータシステムは、プログラムを実行することで、プログラムに応じた所定の機能を実現する。コンピュータシステムでは、多数のプログラムやデータが利用され得る。幾つかのプログラムによる機能が連携することもある。

また、コンピュータシステムの運用では、既存のプログラムの修正が行われることもある。この場合、例えば、ユーザは、修正対象のプログラムと、当該プログラムに関連する他のプログラムやデータに対して修正の作業を行うことになる。しかし、利用されているプログラムやデータの数が多くプログラム間の関連が複雑であるほど、互いに関連性のあるプログラムを見出すことは容易ではない。

そこで、例えば、ソースプログラムを関数、変数などを単位に複数の部品プログラムに分割し、各部品プログラム間の部品相互関係の情報を登録するソフトウェア開発支援システムの提案がある。提案のソフトウェア開発支援システムは、ある部品プログラムを更新する際、部品相互関係の情報により部品プログラムの更新の影響する範囲を判定する。

また、ソフトウェアをその構成要素となるエンティティの集合として扱い、ソフトウェアの理解が容易な程度の部分集合（例えば、機能、タスクおよび業務などに沿ったクラスタ）に分割する分割装置の提案もある。

更に、プログラム関連図を構成する大量のプログラムを業務用データ項目に基づきグループ化することで、可読性を向上し、業務観点でのプログラム関連把握の作業時間を短縮するプログラム関連分析装置の提案もある。

特開平９－１０１８８０号公報 特開２０１４－２４１０７１号公報 特開２０１０－１０２６６４号公報

ここで、システムの運用では、ユーザの要望に応じて、保守を行う他のユーザにより、プログラムのロジックが改変されることがある。このとき、保守を行う他のユーザは、要望元のユーザに対し、改変箇所を提示する。ところが、指定されたロジックに関する設計文書や改変履歴文書が失われていることがある。この場合、保守を行う他のユーザによる改変箇所の特定が難しいことがある。

特に、システムにおける複数のロジックがデータベースなどを格納する複数の記憶部に格納されたデータを基に処理を行うことがある。例えば、あるロジックの処理結果は記憶部を介して他のロジックの処理に影響し得る。そこで、記憶部とロジックとの関係を考慮して、ロジックの変更箇所を特定する仕組みをどのようにして実現するかが問題となる。

１つの側面では、本発明は、変更箇所の特定を可能にする分析支援方法および分析支援プログラムを提供することを目的とする。

１つの態様では、複数のロジックと複数の記憶部とを有する業務システムの分析を支援する分析支援方法が提供される。この分析支援方法では、コンピュータが、業務システムを使用する第１のユーザにより指示されたロジックの業務システムによる実行に伴って、複数の記憶部に格納されたデータの読出しおよび書込みに関する動作履歴情報を取得し、動作履歴情報およびロジックのソースコードの解析に応じて、読出しが行われた記憶部と書込みが行われた他の記憶部とのロジックによる関係を特定し、関係に基づいて、業務システムを改変する第２のユーザにより改変すべき改変対象ロジックを特定し、改変対象ロジックを第１のユーザに提示する。

また、１つの態様では、分析支援プログラムが提供される。

１つの側面では、変更箇所の特定を可能にする。

第１の実施の形態の情報処理システムを示す図である。 分析支援装置の処理例を示す図である。 第２の実施の形態の情報処理システムの例を示す図である。 分析サーバのハードウェア例を示すブロック図である。 ＤＢを介した業務ロジックの連携の例を示す図である。 変更確認箇所のＳＥによる特定例を示す図である。 動的束縛によるデータ伝搬関係の例を示す図である。 分析サーバの機能例を示すブロック図である。 ＤＢ間のデータ伝搬関係の分析範囲の例を示す図である。 ソースコード内のデータ伝搬関係の追跡例を示す図である。 業務ロジックのソースコードの例を示す図である。 インタフェースを実装する複数のクラスの例を示す図である。 スタックトレースの例を示す図である。 カラム変数管理テーブルの例を示す図である。 データ伝搬関係テーブルの例を示す図である。 変更確認箇所表示画面の例を示す図である。 データ伝搬関係推定例を示すフローチャートである。 変数伝搬関係の分析例を示すフローチャートである。 ＤＢカラム値の読出し／書込み間の伝搬関係の特定例を示すフローチャートである。 業務ロジック変更時の変更箇所特定例を示すフローチャートである。 呼出しメソッドの特定例を示す図である。 スタックトレースによる実装メソッドの特定例を示す図である。 変数の伝搬関係の追跡例を示す図である。 変数の伝搬関係の追跡例（続き）を示す図である。

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

図１は、第１の実施の形態の情報処理システムを示す図である。
第１の実施の形態の情報処理システムは、分析支援装置１０、業務システム２０および端末装置３０，４０を有する。分析支援装置１０、業務システム２０および端末装置３０，４０はネットワーク５０に接続されている。

分析支援装置１０は、業務システム２０の分析を支援する。業務システム２０は、１以上の情報処理装置によって構成される。業務システム２０は、アプリケーション（業務アプリケーション）を実行し、当該アプリケーションによる機能を端末装置３０に提供する。端末装置３０は、ユーザ６０により利用される。ユーザ６０は、業務システム２０を使用して、ユーザ６０（あるいは、ユーザ６０が属する組織）の業務を行う。以下に登場するユーザ６０は、同一人物でなくてもよく、例えば、業務システム２０を使用する組織に属する任意の人物と考えてもよい。端末装置４０は、ユーザ７０により利用される。ユーザ７０は、業務システム２０の保守を行うＳＥ（System Engineer）などの保守員である。ユーザ７０は、保守を行う事業者に所属する任意の人物と考えてもよい。例えば、ユーザ７０は、ユーザ６０の要望に応じて、業務システム２０が実行するアプリケーションのプログラムを改変することで、業務システム２０の改変を行う。

業務システム２０は、複数のロジックと複数の記憶部とを有する。ロジックは、アプリケーションにより提供される機能の一単位である。ロジックは、記憶部に記憶されたデータを読出して処理し、処理結果を記憶部に書込む。ロジックは、１つのプログラムに対応してもよいし、プログラム内の１つの関数に対応してもよい。関数は、プログラム内の１つの処理単位であり、例えば、メソッド、手続き、セクションなどの他の名称で呼ばれることもある。業務システム２０における複数のロジックはロジックＬ１，Ｌ２，Ｌ３，・・・を含む。ユーザ６０によるアプリケーションの改変要望は、例えば、ロジック単位で行われる。

業務システム２０における記憶部は、ロジックにより処理されるデータを記憶する記憶デバイス、または、当該記憶デバイスに確保されたデータ格納領域である。記憶デバイスとしては、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）などを用いることができる。例えば、１つの記憶部は、データベース（ＤＢ：DataBase）を有する。ＤＢは、例えば、データ項目として複数のカラムを有する関係ＤＢ（ＲＤＢ：Relational DB）である。１つの記憶部は、ＤＢにおける１つのテーブルでもよい。ただし、ＤＢは、複数のデータ項目を識別できるようにデータフォーマットが規定されていればよく、ツリー型やオブジェクト型などの他の種類のＤＢでもよい。業務システム２０における複数の記憶部は、記憶部Ｍ１，Ｍ２，Ｍ３，・・・を含む。

ここで、あるロジックを改変する場合、当該ロジックの改変によって、当該ロジックと記憶部を介して連携する他のロジックに影響が及ぶことがある。例えば、あるロジックの改変により、あるテーブルにおけるあるデータ項目に対して既存の値域に属さない値が設定されるようになった場合に、当該テーブルを用いる他のロジックにおいて当該データ項目に関する処理を追加または改変すべき場合がある。ユーザ６０の要望によりロジックを改変する場合、ユーザ７０は、改変による他のロジックへの影響を特定し、ユーザ６０に予め報告することが望ましい。そこで、分析支援装置１０は、ロジック改変時に改変箇所を提示可能にする機能を提供する。

分析支援装置１０は、記憶部１１と処理部１２とを有する。記憶部１１は、ＲＡＭ（Random Access Memory）などの揮発性記憶装置でもよいし、ＨＤＤやフラッシュメモリなどの不揮発性記憶装置でもよい。処理部１２は、例えば、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）などのプロセッサである。ただし、処理部１２は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの特定用途の電子回路を含んでもよい。プロセッサは、ＲＡＭなどのメモリ（記憶部１１でもよい）に記憶されたプログラムを実行する。当該プロセッサが実行するプログラムには分析支援プログラムが含まれる。複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うことがある。

記憶部１１は、業務システム２０により実行されるアプリケーションのソースコード１３を記憶する。ソースコード１３は、例えば、オブジェクト指向言語などの高級言語で記述されている。例えば、ソースコード１３は、複数のファイル（ソースファイル）に分けられていてもよい。また、記憶部１１は、業務システム２０によるアプリケーション実行に伴う動作履歴情報１４を記憶する。動作履歴情報１４は、記憶部Ｍ１，Ｍ２，Ｍ３，・・・に格納されたデータの読出しおよび書込みに関する情報である。動作履歴情報１４は、アプリケーション実行時において実際に実行されたロジックの履歴（例えば、関数の呼出スタック）を含む。

処理部１２は、ユーザ６０により指示されたロジックの業務システム２０による実行に伴って動作履歴情報１４を取得し、記憶部１１に格納する。処理部１２は、動作履歴情報１４およびロジックのソースコード（ソースコード１３の一部のコードでもよい）の解析に応じて、記憶部Ｍ１，Ｍ２，Ｍ３，・・・のうち、読出しが行われた記憶部と書込みが行われた他の記憶部とのロジックによる関係を特定する。処理部１２は、当該ロジックを介した記憶部間の関係を示す情報を記憶部１１に格納する。処理部１２は、当該関係に基づいて、ユーザ７０により改変すべき改変対象ロジックを特定し、改変対象ロジックをユーザ６０に提示する。

例えば、処理部１２は、改変対象ロジックを示す画面３１の情報を端末装置３０に送信し、端末装置３０のディスプレイに画面３１を表示させることで、改変対象ロジックをユーザ６０に提示する。例えば、画面３１は、ロジックＬ１，Ｌ２，Ｌ３，・・・のうち、改変対象ロジックとしてロジックＬ１，Ｌ２を示す。

次に、分析支援装置１０による改変対象ロジックの特定の処理例を説明する。
図２は、分析支援装置の処理例を示す図である。
一例として、ロジックＬ１および記憶部Ｍ１，Ｍ２を挙げる。ロジックＬ１は記憶部Ｍ１からのデータの読出し、および、記憶部Ｍ２へのデータの書込みを行う。記憶部Ｍ１は、テーブルＴ１を記憶する。テーブルＴ１は、データ項目Ｃ１，Ｃ２を有する。記憶部Ｍ２は、テーブルＴ２を記憶する。テーブルＴ２は、データ項目Ｃ３，Ｃ４を有する。また、ロジックＬ１は、変数Ｘ，Ｙ，Ａ，Ｂを有する。

処理部１２は、ロジックＬ１のソースコードに基づいて、変数Ｘに対してデータ項目Ｃ１の値が代入されることを検出する。例えば、ロジックＬ１のソースコードにデータ項目Ｃ１の識別情報が明記されていれば、処理部１２は、当該ソースコードにより変数Ｘとデータ項目Ｃ１との対応関係を特定できる。処理部１２は、他の変数Ｙ，Ａ，Ｂについても同様に、データ項目Ｃ２，Ｃ３，Ｃ４との対応関係を特定できる。

一方、ロジックＬ１は、例えば、オブジェクト型データと関係型データとを相互に変換するＯ／Ｒ（Object / Relational）マッパーなどのＤＢアクセス用のライブラリモジュールを利用して各記憶部にアクセスすることもある。ライブラリの挙動はソースコード外部の設定ファイルで定義されることがあり、こうしたライブラリモジュールのソースコードを分析支援装置１０が有していないことがある。この場合、ソースコードレベルで見るとライブラリの内部処理がブラックボックスとなる。そこで、処理部１２は、次のようにして変数Ｘ，Ｙ，Ａ，Ｂそれぞれに対応するデータ項目を特定する。

まず、変数Ｘについて説明する。処理部１２は、ロジックＬ１のソースコードに関する静的解析を行うことで、ＤＢアクセス用のライブラリモジュールの関数を呼出して当該関数の返り値を変数Ｘに代入する命令文を検出する。そして、処理部１２は、当該命令文の実行ログを動作履歴情報１４から抽出し、変数Ｘに代入された返り値を特定する。更に、処理部１２は、動作履歴情報１４に含まれるＤＢアクセス用のライブラリモジュールが発行したクエリとその実行結果のログから、特定した返り値を実行結果として取得したときに読み出されたテーブルとデータ項目とを抽出する。

例えば、処理部１２は、ロジックＬ１の実行ログから変数Ｘに代入された返り値ａを特定する。この場合、処理部１２は、ライブラリモジュールが実行結果ａを取得したときのクエリ（ｓｅｌｅｃｔ文など）により読出し対象となったテーブルＴ１のデータ項目Ｃ１を、記憶部Ｍ１に対するライブラリモジュールによるデータ操作のログから特定する。これにより、処理部１２は、変数Ｘを、テーブルＴ１のデータ項目Ｃ１から読出された値が代入される変数として特定する。同様に、処理部１２は、例えば、変数Ｙを、テーブルＴ１のデータ項目Ｃ２から読出された値が代入される変数として特定する。変数Ｘ，Ｙは、読出し側変数と呼ばれる。

次に、変数Ａについて説明する。処理部１２は、ロジックＬ１のソースコードに関する静的解析を行うことで、変数Ａを引数として用いて、ＤＢアクセス用のライブラリモジュールの関数を呼出す命令文を検出する。そして、処理部１２は、当該命令文の実行ログを動作履歴情報１４から抽出し、変数Ａにより指定された引数を特定する。更に、処理部１２は、動作履歴情報１４に含まれるＤＢアクセス用のライブラリモジュールが発行したクエリとその実行結果のログから、特定した引数を書込み値として書込んだときの書込み先テーブルとデータ項目とを抽出する。

例えば、処理部１２は、ロジックＬ１の実行ログから変数Ａに代入された引数ｂを特定する。この場合、処理部１２は、ライブラリモジュールが書込み値ｂを書き込んだときのクエリ（ｉｎｓｅｒｔ文など）により書込み先となったテーブルＴ２のデータ項目Ｃ３を、記憶部Ｍ２に対するライブラリモジュールによるデータ操作のログから特定する。これにより、処理部１２は、変数Ａを、テーブルＴ２のデータ項目Ｃ３に書込む値が代入される変数として特定する。同様に、処理部１２は、例えば、変数Ｂを、テーブルＴ２のデータ項目Ｃ４に書込む値が代入される変数として特定する。変数Ａ，Ｂは、書込み側変数と呼ばれる。

更に、処理部１２は、ロジックＬ１の静的解析および動的解析を組み合せて、読出し側変数から書込み側変数に対する変数の伝搬関係を分析する。具体的には、処理部１２は、ロジックＬ１のソースコードを参照して、読出し側変数に対する処理を辿る。このとき、当該ソースコード内で呼出される関数のソースコードも参照して、読出し側変数に対する処理を辿り、当該読出し側変数が影響を及ぼす他の変数を特定する。

ただし、呼出し対象の関数が動的束縛により実行時に決定されることもある。例えば、呼出し対象の関数がＪａｖａ（登録商標）におけるインタフェースを実装するクラスで定義されるメソッドである場合などである。１つのインタフェースは、複数のクラスに実装可能である。このため、複数のクラスにおいて、実装したインタフェース内の同名のメソッドが定義され得る。また、ロジックＬ１のソースコードに記述された当該メソッドを含むオブジェクトの生成コード（例えば、ｎｅｗ演算子によるインスタンス化）が不明なことがある。例えば、業務アプリケーションのフレームワーク内などに当該生成コードが隠蔽されており、ユーザ７０により閲覧・改変可能なユーザコード（例えば、ロジックＬ１のソースコード）に含まれていない場合が考えられる。この場合、処理部１２は、ロジックＬ１のソースコードのみからオブジェクトの生成元のクラスを特定できず、静的解析のみでは実際に実行されるメソッドを追跡できない。

そこで、処理部１２は、動作履歴情報１４に含まれる呼出スタックにより、ロジックＬ１を実行したときに実際に呼出されたメソッドを特定し、特定したメソッドのソースコードを参照して変数の伝搬関係の特定を継続する。そして、処理部１２は、ある読出し側変数により影響を受ける変数として、書込み側変数を特定すると、当該読出し側変数と書込み側変数とを対応付ける。

図２の例では、処理部１２は、読出し側変数Ｘによる影響が書込み側変数Ａに及ぶことを特定し、読出し側変数Ｘと書込み側変数Ａとを対応付ける。また、処理部１２は、読出し側変数Ｙによる影響が書込み側変数Ｂに及ぶことを特定し、読出し側変数Ｙと書込み側変数Ｂとを対応付ける。例えば、処理部１２は、読出し側変数Ｙによる影響が書込み側変数でない変数Ｃに及ぶことを検出することもある。しかし、変数Ｃは、書込み側変数ではないので、処理部１２は、読出し側変数Ｙと変数Ｃとの対応付けを行わない。

処理部１２は、上記の読出し側変数と書込み側変数との対応付けによりロジックＬ１による記憶部間の関係を特定する。例えば、読出し側変数Ｘには、テーブルＴ１におけるデータ項目Ｃ１から読み出された値が代入される。また、書込み側変数Ａには、テーブルＴ２におけるデータ項目Ｃ３に書込む値が代入される。よって、処理部１２は、ロジックＬ１による記憶部Ｍ１，Ｍ２の関係を特定する。

記憶部Ｍ１，Ｍ２の間の関係は、記憶部Ｍ１に記憶されたデータ項目Ｃ１と記憶部Ｍ２に記憶されたデータ項目Ｃ３とのロジックＬ１のソースコードに含まれる複数の変数（変数Ｘから変数Ａに至る複数の変数）を介した関係であると言える。なお、処理部１２は、読出し側変数Ｙと書込み側変数Ｂとの関係からも、ロジックＬ１による記憶部Ｍ１，Ｍ２の関係を特定できる。

こうして、処理部１２は、ロジックＬ１，Ｌ２，Ｌ３，・・・それぞれによる記憶部間の関係を特定し、当該関係を示す情報を記憶部１１に格納する。例えば、業務システム２０は、更に、ロジックＬ４および記憶部Ｍ４，Ｍ５，Ｍ６を有するとする。この場合に、処理部１２は、例えば、ロジックＬ２による記憶部Ｍ２，Ｍ６の関係、ロジックＬ３による記憶部Ｍ４，Ｍ５の関係、および、ロジックＬ４による記憶部Ｍ５，Ｍ６の関係を特定する。

処理部１２は、記憶部間の関係に基づいて、あるロジックの改変に対する改変対象ロジックを特定する。例えば、ユーザ６０により、ロジックＬ１の改変が要望された場合を考える。この場合、処理部１２は、特定した記憶部間の関係に基づいて、ロジックＬ１の改変の影響が及ぶロジックを特定する。例えば、上記の例では、ロジックＬ１は、記憶部Ｍ２へのデータ書込みを行う。記憶部Ｍ２に書き込まれたデータは、ロジックＬ２により処理される。したがって、処理部１２は、ロジックＬ１，Ｌ２を改変対象ロジックとして特定する。

処理部１２は、関数による変数の伝搬関係の情報に基づいて、ロジックＬ１，Ｌ２内の特定のコード部分（伝搬関係に関与する関数）を、改変対象ロジックとして特定してもよい。例えば、ロジックＬ１における改変対象として、データ項目Ｃ１または変数Ｘに関連する部分が指定されることもある。この場合、処理部１２は、ロジックＬ１のソースコードのうち、読出し側変数Ｘから書込み側変数Ａまでに辿った関数を改変対象ロジックとして特定してもよい。

更に、処理部１２は、ロジックＬ２に対して、データ項目Ｃ３に対する読出し側変数Ｚと、記憶部Ｍ６のデータ項目Ｃ５に対する書込み側変数Ｄとを対応付けているとする。この場合に、処理部１２は、ロジックＬ２のソースコードのうち、当該対応付けの際に辿った関数を改変対象ロジックとして特定してもよい。

処理部１２は、こうして特定した改変対象ロジックを示す画面３１の情報を端末装置３０に提供し、端末装置３０に画面３１を表示させることで、ユーザ６０に改変対象ロジックを提示する。

分析支援装置１０によれば、ユーザ６０により指示されたロジックの業務システム２０による実行に伴って、記憶部Ｍ１，Ｍ２，Ｍ３，・・・に格納されたデータの読出しおよび書込みに関する動作履歴情報１４が取得される。動作履歴情報１４およびロジックのコードの解析に応じて、読出しが行われた記憶部と書込みが行われた他の記憶部とのロジックによる関係が特定される。特定された当該関係に基づいて、業務システム２０を改変するユーザ７０により改変すべき改変対象ロジックが特定される。そして、改変対象ロジックがユーザ６０に提示される。

これにより、記憶部Ｍ１，Ｍ２，Ｍ３，・・・を介して連携する複数のロジックに関して、あるロジックの改変に伴う改変対象ロジックを適切に特定し、ユーザ６０に提示可能になる。特に、分析支援装置１０は、各ロジックのソースコードに対して、動的解析と静的解析とを組み合せることで、ロジックにおける変数の影響の伝搬を適切に追跡できる。このため、実行される手続きが動的束縛により決定される場合にも、あるロジックによる記憶部間の関係を特定可能になる。その結果、改変対象ロジックの抽出漏れを低減し、改変対象ロジックの抽出精度を向上させることができる。

こうして、分析支援装置１０によれば、業務システム２０で実行されるアプリケーションにおける変更対象箇所のユーザ６０，７０による適切な把握を支援できる。
［第２の実施の形態］
次に、第２の実施の形態を説明する。

図３は、第２の実施の形態の情報処理システムの例を示す図である。
第２の実施の形態の情報処理システムは、分析サーバ１００、ＤＢサーバ２００，２００ａ、業務サーバ３００，３００ａおよびクライアント４００，５００を含む。分析サーバ１００、ＤＢサーバ２００，２００ａ、業務サーバ３００，３００ａおよびクライアント５００は、ネットワーク８０に接続されている。ネットワーク８０はネットワーク９０に接続されている。ネットワーク８０，９０は、例えば、ＬＡＮ（Local Area Network）である。クライアント４００は、ネットワーク９０に接続されている。

ユーザ６００は、クライアント４００を操作して、業務サーバ３００，３００ａが実行する業務アプリケーションの機能を使用し、ユーザ６００が所属する組織の業務を行う。ここで、業務アプリケーションは、複数の業務ロジックを含む。業務ロジックは、１つのプログラムに対応してもよいし、関数やメソッドなどといったプログラム内の１つの処理単位に対応してもよい。業務ロジックを記述するプログラミング言語の一例としてＪａｖａを考える。ただし、業務ロジックは他のプログラミング言語により記述されてもよい。

ＳＥ７００は、クライアント５００を操作して、業務アプリケーションの改変を行う保守員である。具体的には、ＳＥ７００は、ユーザ６００の要望を受けて、業務アプリケーションにおける業務ロジックを変更する。例えば、ＳＥ７００は、業務アプリケーションの機能向上、業務に関する法改正対応、および、バグ修正などを目的として、ユーザ６００から業務ロジックの改変の要望を受ける。ＳＥ７００は、要望に応じて、改変対象の業務ロジックのプログラムを修正することで、当該業務ロジックの改変を行う。

ある業務ロジックの改変に伴って、ＤＢを介して当該業務ロジックと連携する他の業務ロジックが改変の影響を受けることがある。例えば、ある業務ロジックの改変に伴って、あるテーブルのデータ項目（カラムと言う）に既存の値域とは異なる値が設定される場合が考えられる。この場合、当該カラムの値（カラム値）を用いる他の業務ロジックも改変しなければ、当該他の業務ロジックの処理でエラーが発生し得る。

ＳＥ７００は、こうした他の業務ロジックへの改変の影響を予め分析し、その結果をユーザ６００に提示して、他の業務ロジックも改変すべきことを提言することが望ましい。ユーザ６００による影響箇所の改変の検討を促し、業務ロジック改変後の運用で発生し得るエラーを未然に防ぐためである。

分析サーバ１００は、ＳＥ７００による改変対象の業務ロジックの分析を支援するサーバコンピュータである。分析サーバ１００は、ユーザ６００の要望に応じた業務ロジックの改変に伴ってＳＥ７００により改変すべき改変対象の業務ロジックを特定し、ユーザ６００に提示する処理を行う。以下では、「改変」を「変更」と言うことがある。

ＤＢサーバ２００，２００ａは、ＤＢを提供するサーバコンピュータである。ＤＢは、業務ロジックの処理に用いられる。ＤＢサーバ２００，２００ａは、複数のテーブルを記憶する。ここで、第２の実施の形態では、ＤＢとしてＲＤＢを考える。この場合、各業務ロジックによるＯ／Ｒマッパーのメソッドの呼出しに応じて、ＪＤＢＣ（Java DataBase Connectivity）のメソッドが呼出される。ＪＤＢＣは、関係データベースとコネクションを確立し、関係データベースに対してクエリを発行するモジュールである。ＪＤＢＣが呼出されると、ＤＢの各テーブルを操作するＳＱＬ文が出力される。

ここで、ＤＢとして、ＲＤＢの他にも、ＸＭＬ（Extensible Markup Language）データベースなどの他の種類のＤＢを使用してもよい。使用するＤＢは、複数のデータ項目が予め定義されており、所定のフォーマットのクエリによってデータ操作が行われるものであればよい。その場合、ＪＤＢＣに代えて、ＤＢの種類に応じたモジュールを用いてＤＢとのコネクションが確立される。

業務サーバ３００，３００ａは、業務アプリケーションを実行するサーバコンピュータである。業務サーバ３００，３００ａは、ＡＰ（APplication）サーバと呼ばれてもよい。例えば、業務サーバ３００，３００ａは、業務アプリケーションに含まれる複数の業務ロジックを分担して実行し、相互に連携して業務アプリケーションの機能をクライアント４００に提供する。

ここで、分析サーバ１００は、第１の実施の形態の分析支援装置１０の一例である。ＤＢサーバ２００，２００ａおよび業務サーバ３００，３００ａによるコンピュータシステムは、第１の実施の形態の業務システム２０の一例である。クライアント４００は、第１の実施の形態の端末装置３０の一例である。クライアント５００は、第１の実施の形態の端末装置４０の一例である。

図４は、分析サーバのハードウェア例を示すブロック図である。
分析サーバ１００は、ＣＰＵ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力信号処理部１０５、媒体リーダ１０６および通信ＩＦ（InterFace）１０７を有する。分析サーバ１００の各ハードウェアは、分析サーバ１００のバスに接続される。なお、ＣＰＵ１０１は、第１の実施の形態の処理部１２に対応する。ＲＡＭ１０２またはＨＤＤ１０３は、第１の実施の形態の記憶部１１に対応する。

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

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

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

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

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

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

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

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

ＤＢサーバ２００，２００ａ、業務サーバ３００，３００ａおよびクライアント４００，５００も、分析サーバ１００と同様のハードウェアにより実現される。
図５は、ＤＢを介した業務ロジックの連携の例を示す図である。

ＤＢサーバ２００，２００ａは、ＤＢ２１０，２２０，２３０，２４０，２５０を有する。例えば、ＤＢ２１０，２２０，２３０，２４０，２５０のうちの幾つかのＤＢがＤＢサーバ２００に属し、残りのＤＢがＤＢサーバ２００ａに属してもよい。ＤＢ２１０は、テーブル２１１，２１２を有する。ＤＢ２２０は、テーブル２２１，２２２を有する。ＤＢ２３０は、テーブル２３１，２３２を有する。ＤＢ２４０は、テーブル２４１，２４２を有する。ＤＢ２５０は、テーブル２５１，２５２を有する。

また、業務サーバ３００，３００ａは、業務ロジック３１０，３２０，３３０を有する。例えば、業務ロジック３１０，３２０，３３０のうちの幾つかの業務ロジックが業務サーバ３００に属し、残りの業務ロジックが業務サーバ３００ａに属してもよい。

業務ロジック３１０は、テーブル２１１，２１２のレコードの読出しを行う。業務ロジック３１０は、テーブル２２１，２２２，２３１，２３２へのレコードの書込みを行う。業務ロジック３２０は、テーブル２２１，２２２のレコードの読出しを行う。業務ロジック３２０は、テーブル２４１，２４２へのレコードの書込みを行う。業務ロジック３３０は、テーブル２３１，２３２のレコードの読出しを行う。業務ロジック３３０は、テーブル２５１，２５２へのレコードの書込みを行う。

このように、業務ロジック３１０，３２０は、ＤＢ２２０を介して非同期に連携する。また、業務ロジック３１０，３３０は、ＤＢ２３０を介して非同期に連携する。例えば、業務ロジック３１０のテーブル２１２のレコードを読み込んで実行される処理を変更する場合を考える。上記の例の場合、業務ロジック３１０は、ＤＢ２２０のテーブル２２１，２２２、および、ＤＢ２３０のテーブル２３１，２３２への書込みを行う。

このため、業務ロジック３１０に対する変更の影響が、ＤＢ２２０を介して業務ロジック３２０に及ぶ可能性もあるし、ＤＢ２３０を介して業務ロジック３３０に及ぶ可能性もある。業務ロジック３１０による書込み先のＤＢが増えると、業務ロジック３１０に対する変更の影響が及ぶ可能性のある業務ロジックが増すことになる。しかし、業務ロジック３１０の変更の影響の及ぶ範囲が不明であると、変更対象の業務ロジックを適切に絞り込めない。

図６は、変更確認箇所のＳＥによる特定例を示す図である。
ＳＥ７００が、ユーザ６００による業務ロジックの変更の要望を受け付け、受け付けた要望に応じて変更要否を確認すべき業務ロジックを特定することが考えられる。このとき、ＳＥ７００は、指定された業務ロジックに関する設計文書や改変履歴文書を参照して、変更対象の業務ロジックを特定し得る。しかし、設計文書や改変履歴文書が失われていると、ＳＥ７００は、変更対象の業務ロジックを特定することができない。また、設計文書や改変履歴文書が存在していたとしても、これら文書を閲覧して、変更対象の業務ロジックを特定することは容易ではない。

例えば、上記のように業務ロジック３１０を変更する場合に、当該変更が何れのＤＢに影響を及ぼし、当該ＤＢを介して業務ロジックに影響を及ぼすかを判断することは難しい。図６では、図５の例に加えて、更に、ＤＢ２６０のレコードの読出し、および、ＤＢ２７０へのレコードの書込みを行う業務ロジック３４０が例示されている。業務ロジック３１０は、ＤＢ２６０に対するレコードの書込みも行う。図６の例では、業務ロジック３１０の変更に伴って、業務ロジック３２０，３３０，３４０の何れを変更すべきであるかを適切に絞り込むことが難しい。

例えば、各業務ロジックのソースコードに対する静的解析により、業務ロジック内の変数の伝搬関係を追跡することで、当該業務ロジックによるＤＢ間（あるいはテーブル間）の関係を特定することも考えられる。しかし、ソースコードが動的束縛によるメソッド呼出しを含む場合、静的解析での変数の伝搬関係の追跡が困難になる。

図７は、動的束縛によるデータ伝搬関係の例を示す図である。
業務ロジック３１０は、メソッド３１１，３１２，３１３，３１４，３１５，３１６，３１７，３１８を呼出す。ここで、一例として、業務ロジック３１０は、勤怠管理における勤怠打刻管理に関する業務ロジックであるとする。

メソッド３１１は、例えば、テーブル２１１から第１の打刻時刻情報を検索するＤＢ検索を行う。メソッド３１２は、インタフェースにおける抽象メソッドであり、検索された情報を利用する処理のために用意されている。例えば、メソッド３１２に対する実際の呼出し候補のメソッドは、メソッド３１２ａ，３１２ｂ，３１２ｃである。

メソッド３１２ａは、検索された第１の打刻時刻情報に基づく勤怠打刻に関する所定の処理を実行するメソッドである。メソッド３１２ａの処理結果は、メソッド３１３，３１４を介して、メソッド３１５に渡される（ただし、メソッド３１３，３１４によりメソッド３１２ａの処理結果が更に加工されることもある）。メソッド３１５は、当該処理結果に応じた第２の打刻時刻情報をテーブル２２１に書込む処理を行う。

メソッド３１２ｂは、検索された第１の打刻時刻情報に基づく給与計算の処理を実行するメソッドである。メソッド３１２ｂの処理結果は、メソッド３１６を介して、メソッド３１７に渡される（ただし、メソッド３１６によりメソッド３１２ｂの処理結果が更に加工されることもある）。メソッド３１７は、当該処理結果に応じた給与の情報をテーブル２２２に書込む処理を行う。

メソッド３１２ｃは、検索された第１の打刻時刻情報の表示に関する処理を実行するメソッドである。メソッド３１２ｃの処理結果（例えば、表示画面の情報）は、メソッド３１８に渡される。メソッド３１８は、メソッド３１２ｃの処理結果をクライアント４００に提供し、当該処理結果をクライアント４００により表示させる。

上記のようにメソッド３１２に対して複数の実装候補（例えば、メソッド３１２ａ，３１２ｂ，３１２ｃ）が存在し、業務ロジック３１０の実行時に、動的束縛により実際に実装されるメソッドが決定される場合がある。この場合、業務ロジック３１０のソースコードに対する静的解析だけでは、メソッド３１２から先の変数の伝搬関係を辿るのが難しくなる。例えば、実装候補のメソッドを全て伝搬先として特定することも考えられるが、変更対象とすべきでない余計なメソッドまで特定されてしまうことになる。

そこで、分析サーバ１００は、業務ロジックにおいてインタフェースのように動的束縛によって呼出し先のメソッドが特定される場合にも、変数によるデータ伝搬関係を適切に辿り、業務ロジックによるＤＢ間の関係を特定可能にする。また、分析サーバ１００は、業務ロジックによるＤＢ間の関係に基づいて、変更対象の業務ロジックを適切に特定する機能を提供する。

図８は、分析サーバの機能例を示すブロック図である。
分析サーバ１００は、ソースコード記憶部１２０、動作ログ記憶部１３０、データ伝搬関係記憶部１４０、動作ログ取得部１５０、変数分析部１６０、データ伝搬関係分析部１７０および変更箇所分析部１８０を有する。

ソースコード記憶部１２０、動作ログ記憶部１３０およびデータ伝搬関係記憶部１４０は、ＲＡＭ１０２またはＨＤＤ１０３の記憶領域を用いて実現される。動作ログ取得部１５０、変数分析部１６０、データ伝搬関係分析部１７０および変更箇所分析部１８０は、ＲＡＭ１０２に記憶されたプログラムをＣＰＵ１０１が実行することで実現される。

ソースコード記憶部１２０は、業務ロジックのソースコードを記憶する。ソースコードのファイル（ソースファイル）は、業務ロジック毎に存在してもよい。一例として、ソースコードのプログラミング言語はＪａｖａである。

動作ログ記憶部１３０は、動作ログ取得部１５０が取得した業務サーバ３００，３００ａによる動作ログを記憶する。動作ログは、ＤＢ２１０，２２０，２３０，・・・に対するデータの読出しや書込みの履歴を含む。より具体的には、動作ログは、ＤＢアクセスログ、ＤＢアクセス時に呼出されたメソッドに関する呼出しログ、および、各業務ロジックの実行中におけるスタックトレースを含む。ＤＢアクセスログと呼出しログとは、ＤＢのカラムと当該カラムの値が代入される業務ロジック内の変数との対応関係の特定に用いられる。業務ロジックの実行中のスタックトレースは、業務ロジック内の変数の伝搬関係の追跡（静的解析で辿れない部分の動的解析による補間）に用いられる。

データ伝搬関係記憶部１４０は、データ伝搬関係分析部１７０により生成されたデータ伝搬関係テーブルを記憶する。データ伝搬関係テーブルは、伝搬元テーブル／カラムと、伝搬先テーブル／カラムとの業務ロジック毎の対応関係を示す情報である。

動作ログ取得部１５０は、業務サーバ３００，３００ａから業務ロジック３１０，３２０，３３０，・・・の実行時における動作ログを取得し、動作ログ記憶部１３０に格納する。

変数分析部１６０は、ソースコード記憶部１２０に記憶されたソースコードおよび動作ログ記憶部１３０に記憶された動作ログに基づいて、ＤＢのテーブルにおけるカラムと業務ロジックにおける変数との対応関係を分析する。また、変数分析部１６０は、業務ロジックにおける各変数の伝搬を分析する。各変数の伝搬は、第１のメソッドの第１の変数の影響を受ける、第１のメソッドから呼出される第２のメソッドの第２の変数との関係を示す。

データ伝搬関係分析部１７０は、変数分析部１６０による各変数の伝搬の分析結果に基づいて、ＤＢのカラムのデータの読出し先の変数からＤＢのカラムにデータを書込む変数へのデータの伝搬関係を分析し、データ伝搬関係テーブルを生成する。データ伝搬関係分析部１７０は、データ伝搬関係テーブルをデータ伝搬関係記憶部１４０に格納する。

変更箇所分析部１８０は、変更対象業務ロジックの入力１８１に応じて、データ伝搬関係記憶部１４０に記憶されたデータ伝搬関係テーブルに基づき、業務ロジック３１０，３２０，３３０，・・・のうちの変更対象箇所を分析する。変更対象業務ロジックの入力１８１は、クライアント４００により行われてもよいし、クライアント５００により行われてもよい。変更対象業務ロジックの入力１８１は、入力デバイス１１２を用いて行われてもよい。変更箇所分析部１８０は、分析結果を示す変更確認箇所表示画面１８２を出力する。例えば、変更確認箇所表示画面１８２は、クライアント４００により表示される。

図９は、ＤＢ間のデータ伝搬関係の分析範囲の例を示す図である。
データ伝搬関係分析範囲Ｒ１は、業務ロジック３１０に対するデータ伝搬関係の分析範囲の例である。データ伝搬関係分析範囲Ｒ２は、業務ロジック３２０に対するデータ伝搬関係の分析範囲の例である。

ここで、業務ロジック３１０のデータの読出し元のテーブルは、テーブル２１１，２１２であるとする。業務ロジック３１０のデータの書込み先のテーブルは、テーブル２２１，２２２であるとする。この場合、データ伝搬関係分析範囲Ｒ１は、テーブル２１１，２１２からの読出し値が代入される変数を起点とし、テーブル２２１，２２２への書込み値が代入される変数を終点とする範囲となる。

また、業務ロジック３２０のデータ読出し元のテーブルは、テーブル２２１，２２２であるとする。業務ロジック３２０のデータ書込み先のテーブルは、テーブル２４１，２４２であるとする。この場合、データ伝搬関係分析範囲Ｒ２は、テーブル２２１，２２２からの読出し値が代入される変数を起点とし、テーブル２４１，２４２への書込み値が代入される変数を終点とする範囲となる。

他の業務ロジックのデータ伝搬関係分析範囲についても、同様に、テーブルからの読出し値が代入される変数が起点であり、テーブルへの書込み値が代入される変数が終点である。

図１０は、ソースコード内のデータ伝搬関係の追跡例を示す図である。
メソッドｍ１は、業務ロジック３１０に対応する最上位のメソッドである。メソッドｍ１は、テーブル２１１，２１２のデータの読出し時にメソッドｍ２，ｍ３を順に呼出す。

メソッドｍ３は、テーブル２１１からデータの読出しを行う際、ＪＤＢＣライブラリ群３０２におけるＤＢ読出し用（ＲＥＡＤ）のモジュール（ＪＤＢＣモジュール）を呼出す。例えば、ＪＤＢＣモジュールは、テーブル２１１に対するｓｅｌｅｃｔ文を出力し、読出したカラム値を変数ｊ１に代入する。メソッドｍ３の変数ｘには、返り値として、変数ｊ１に代入されたカラム値が代入される。

同様に、メソッドｍ３は、テーブル２１２からデータの読出しを行う際、ＪＤＢＣライブラリ群３０２におけるＲＥＡＤのＪＤＢＣモジュールを呼出す。例えば、ＪＤＢＣモジュールは、テーブル２１２に対するｓｅｌｅｃｔ文を出力し、読出したカラム値を変数ｊ２に代入する。メソッドｍ３の変数ｙには、返り値として、変数ｊ２に代入されたカラム値が代入される。

また、メソッドｍ１は、テーブル２２１，２２２へのデータの書込み時にメソッドｍ４，ｍ５を順に呼出す。
メソッドｍ５は、テーブル２２１へのデータの書込みを行う際、ＪＤＢＣライブラリ群３０２におけるＤＢ書込み用（ＷＲＩＴＥ）のＪＤＢＣモジュールを呼出す。例えば、メソッドｍ５は、書込み値を変数ａに代入し、当該書込み値を引数として、ＪＤＢＣモジュールを呼出す。ＪＤＢＣモジュールは、引数として指定された書込み値をＪＤＢＣモジュールの変数ｊ３に代入し、変数ｊ３に代入された書込み値をテーブル２２１に書込む。

同様に、メソッドｍ５はテーブル２２２へのデータの書込みを行う際、ＪＤＢＣライブラリ群３０２におけるＷＲＩＴＥのＪＤＢＣモジュールを呼出す。例えば、メソッドｍ５は、書込み値を変数ｂに代入し、当該書込み値を引数として、ＪＤＢＣモジュールを呼出す。ＪＤＢＣモジュールは、引数として指定された書込み値をＪＤＢＣモジュールの変数ｊ４に代入し、変数ｊ４に代入された書込み値をテーブル２２２に書込む。

例えば、テーブル２２１，２１２から読み出されたデータの他のテーブルへの影響を調べる場合、読み出されたデータが代入された変数（上記の例ではｘ，ｙ）による他の変数への影響をメソッドを辿ることで特定することが考えられる。しかし、呼出し対象のメソッドの中にインタフェースのように動的に内容が決定されるメソッドが存在すると、静的解析によるメソッドの追跡が難しくなる。

例えば、メソッドｍ２，ｍ４は、インタフェースのメソッドであり、実際に実行される実装メソッドは、業務ロジック３１０の実行時に動的に決定される。また、メソッドｍ２，ｍ４の実装メソッドを提供するオブジェクトの生成コードは、業務ロジック３１０内には記述されておらず、外部プログラム（例えば、業務アプリケーションのフレームワークなど）により提供される。このため、参照可能なソースコードの静的解析のみでは、メソッドｍ１からメソッドｍ２の呼出し関係およびメソッドｍ２からメソッドｍ３の呼出し関係を得ることは難しい。同様に、当該ソースコードの静的解析のみでは、メソッドｍ１からメソッドｍ４の呼出し関係およびメソッドｍ４からメソッドｍ５の呼出し関係を得ることは難しい。

そこで、変数分析部１６０は、業務ロジック３１０の動作ログに含まれるＤＢ読出し時のメソッド呼出し履歴を参照し、当該メソッド呼出し履歴に基づいて、実際に実装されたメソッドを決定する。例えば、変数分析部１６０は、メソッドｍ２の実装メソッドを決定することで、メソッドｍ１，ｍ２，ｍ３という呼出し関係を辿る。また、変数分析部１６０は、メソッドｍ４の実装メソッドを決定することで、メソッドｍ１，ｍ４，ｍ５という呼出し関係を辿る。これにより、例えば、変数分析部１６０は、変数ｘを起点、変数ａを終点とする、メソッドｍ１，ｍ２，ｍ３，ｍ４，ｍ５内の変数を介したデータ伝搬関係を得ることができる。また、例えば、変数分析部１６０は、変数ｙを起点、変数ｂを終点とする、メソッドｍ１，ｍ２，ｍ３，ｍ４，ｍ５内の変数を介したデータ伝搬関係を得ることができる。

図１１は、業務ロジックのソースコードの例を示す図である。
ソースコード１２１は、業務ロジック３１０のソースコードを示す。業務ロジック３１０は、一例として、勤怠打刻操作（出勤時や退勤時におけるタイムカードによる打刻の操作）に関する業務であるとする。ソースコード１２１は、ソースコード記憶部１２０に予め格納される。ソースコード記憶部１２０は、各業務ロジックに対応するソースコードを記憶する。

勤怠打刻操作に対応するメソッドは、「ｒｅｃｏｒｄＳｔａｒｔＷｏｒｋ」（１行目）である。メソッド「ｒｅｃｏｒｄＳｔａｒｔＷｏｒｋ」は、「ｒｅｃｏｒｄＰｏｒｔａｌＴｉｍｅ」（３行目）、「ｇｅｔＤａｔｅ」（７行目）、「ｆｉｎｄＦｏｒＫｅｙ」（９行目）、「ａｄｄＥｒｒｏｒＭｅｓｓａｇｅ」（１３行目）、「ｇｅｔＳｔｒｉｎｇＤａｔｅ」（１３行目）、「ｇｅｔＮａｍｅ」（１４行目）、「ｇｅｔＡｐｐｌｉｃａｔｉｏｎＥｎｔｉｔｙ」（１８行目）、「ｇｅｔＲｅｑｕｅｓｔＥｎｔｉｔｙ」（２０行目）、「ｇｅｔＷｏｒｋＴｙｐｅＥｎｔｉｔｙ」（２２行目）および「ｇｅｔＷｏｒｋＴｙｐｅ」（２２行目）などのメソッドを呼出す。

このうち、「ｆｉｎｄＦｏｒＫｅｙ」、「ｇｅｔＡｐｐｌｉｃａｔｉｏｎＥｎｔｉｔｙ」、「ｇｅｔＲｅｑｕｅｓｔＥｎｔｉｔｙ」、「ｇｅｔＷｏｒｋＴｙｐｅＥｎｔｉｔｙ」がインタフェースなどの動的に実装されるメソッドである。ソースコード１２１における所定の記述（例えば、「ｉｎｔｅｒｆａｃｅ …」の構文内に含まれるメソッドの記述（図示を省略している））により、インタフェースのメソッドであることが特定される。あるいは、ソースコード記憶部１２０は、インタフェースにより提供されるメソッドの情報を予め記憶していてもよい。後者の場合、変数分析部１６０は、ソースコード記憶部１２０に記憶されたインタフェースにより提供されるメソッドの情報を参照することで、ソースコード１２１内からインタフェースのメソッドを特定する。

変数分析部１６０は、ソースコード１２１の静的解析により、業務ロジック３１０における変数の伝搬の一部を分析可能である。例えば、７行目の記述によれば、変数「ｒｅｃｏｒｄＴｉｍｅ」は、メソッド「ｇｅｔＤａｔｅ」を介して、変数「ｔａｒｇｅｔＤａｔｅ」に伝搬する可能性がある。変数分析部１６０は、メソッド「ｇｅｔＤａｔｅ」のソースコードを参照することで、例えば、変数「ｒｅｃｏｒｄＴｉｍｅ」の影響が変数「ｔａｒｇｅｔＤａｔｅ」に伝搬することを特定する。この場合、変数「ｒｅｃｏｒｄＴｉｍｅ」は、変数「ｔａｒｇｅｔＤａｔｅ」に影響するとも言える。

一方、インタフェースのメソッドの場合、実際に呼出されるメソッドが不明であるため、静的解析のみでは変数間の伝搬を特定することが難しい。一例として、インタフェースのメソッド「ｇｅｔＲｅｑｕｅｓｔＥｎｔｉｔｙ」（２０行目）に着目する。ソースコード１２１の場合、メソッド「ｇｅｔＲｅｑｕｅｓｔＥｎｔｉｔｙ」の内容が不明であるため、変数「ｐｅｒｓｏｎａｌＩｄ」および「ｔａｒｇｅｔＤａｔｅ」によるオブジェクト「ｒｅｑｕｅｓｔＥｎｔｉｔｙ」への影響が不明である。

図１２は、インタフェースを実装する複数のクラスの例を示す図である。
クラス図９００は、インタフェース「ＲｅｑｕｅｓｔＵｔｉｌＢｅａｎＩｎｔｅｒｆａｃｅ」を実装する複数のクラスを例示する。ただし、クラス図９００では、属性の区画の記述が省略されている。

インタフェース「ＲｅｑｕｅｓｔＵｔｉｌＢｅａｎＩｎｔｅｒｆａｃｅ」は、メソッド「ｇｅｔＲｅｑｕｅｓｔＥｎｔｉｔｙ」を含む。インタフェース「ＲｅｑｕｅｓｔＵｔｉｌＢｅａｎＩｎｔｅｒｆａｃｅ」内では、メソッド「ｇｅｔＲｅｑｕｅｓｔＥｎｔｉｔｙ」の具体的な処理内容は記述されていない。

例えば、クラス「ＲｅｑｕｅｓｔＵｔｉｌＢｅａｎ」、「ＲｅｑｕｅｓｔＵｔｉｌＢｅａｎ２」、「ＲｅｑｕｅｓｔＵｔｉｌＢｅａｎ３」、・・・という複数のクラスが、インタフェース「ＲｅｑｕｅｓｔＵｔｉｌＢｅａｎＩｎｔｅｒｆａｃｅ」を実装する。各クラスは、同じ名称のメソッド「ｇｅｔＲｅｑｕｅｓｔＥｎｔｉｔｙ」を提供するが、クラス毎に当該メソッドの記述内容は異なる。このため、ソースコード１２１の静的解析だけでは、ソースコード１２１の２０行目のメソッド「ｇｅｔＲｅｑｕｅｓｔＥｎｔｉｔｙ」として実際に呼出されたメソッドの記述内容を特定することはできない。

図１３は、スタックトレースの例を示す図である。
スタックトレース１３１は、業務ロジック３１０の実行時におけるメソッドの呼出し履歴である。スタックトレース１３１の例では、下の行ほど古い時刻であり、上の行ほど新しい時刻である。例えば、スタックトレース１３１の１３行目および１４行目は、ユーザ６００による所定のＧＵＩ（Graphical User Interface）での操作に対応する。また、例えば、スタックトレース１３１の２行目および３行目は、ＪＤＢＣライブラリ群３０２によるＤＢアクセスに対応する。

例えば、メソッド「ｇｅｔＲｅｑｕｅｓｔＥｎｔｉｔｙ」に着目すると、スタックトレース１３１の６行目に当該メソッドが記録されている。具体的には、「ｊｐ．ｍｏｓｐ．ｔｉｍｅ．ｂｅａｎ．ｉｍｐｌ．ＲｅｑｕｅｓｔＵｔｉｌＢｅａｎ．ｇｅｔＲｅｑｕｅｓｔＥｎｔｉｔｙ」という記録がある。すなわち、スタックトレース１３１によれば、業務ロジック３１０の実行時において、クラス「ＲｅｑｕｅｓｔＵｔｉｌＢｅａｎ」のオブジェクトによって提供されるメソッド「ｇｅｔＲｅｑｕｅｓｔＥｎｔｉｔｙ」が呼出されたことが分かる。変数分析部１６０は、当該クラスに含まれるメソッドのソースコードを参照することで、変数「ｐｅｒｓｏｎａｌＩｄ」および「ｔａｒｇｅｔＤａｔｅ」によるオブジェクト「ｒｅｑｕｅｓｔＥｎｔｉｔｙ」への影響を分析することが可能となる。

図１４は、カラム変数管理テーブルの例を示す図である。
カラム変数管理テーブル１３２は、動作ログ記憶部１３０に記憶される。カラム変数管理テーブル１３２は、勤怠打刻操作の業務ロジック３１０に対して取得された情報である。動作ログ記憶部１３０は、業務ロジック毎に、カラム変数管理テーブル１３２を記憶する。カラム変数管理テーブル１３２は、Ｒ／Ｗ（Read/Write）区分、変数、テーブル、カラムおよびスタックトレースの項目を含む。

Ｒ／Ｗ区分の項目には、テーブルからの読出し（Ｒｅａｄ）か、テーブルへの書込み（Ｗｒｉｔｅ）かを示す情報が登録される。変数の項目には、読出しまたは書込み対象のテーブルのカラムに対する変数の変数名と、当該変数を含むオブジェクトのオブジェクト名とを示す情報が登録される。ここで、カラム変数管理テーブル１３２では、オブジェクト名は、括弧記号で括って記述される。テーブルの項目には、読出し対象または書込み対象のテーブルの名称が登録される。カラムの項目には、読出し対象または書込み対象のカラムの名称が登録される。スタックトレースの項目には、該当の変数を用いた処理が行われたときのメソッドの呼出し関係を示すスタックトレースのファイル名が登録される。

例えば、カラム変数管理テーブル１３２には、Ｒ／Ｗ区分が「Ｒｅａｄ」、変数が「ｐｅｒｓｏｎａｌＩｄ（ＲｅｑｕｅｓｔＥｎｔｉｔｙ）」、テーブルが「ｔｍｄ＿ｈｏｌｉｄａｙ＿ｒｅｑｕｅｓｔ」、カラムが「ｐｅｒｓｏｎａｌ＿ｉｄ」、スタックトレースが「Ｓ１」というレコードが登録されている。このレコードは、テーブル「ｔｍｄ＿ｈｏｌｉｄａｙ＿ｒｅｑｕｅｓｔ」のカラム「ｐｅｒｓｏｎａｌ＿ｉｄ」の読出し値が、業務ロジック３１０のオブジェクト「ＲｅｑｕｅｓｔＥｎｔｉｔｙ」に含まれる変数「ｐｅｒｓｏｎａｌＩｄ」に代入されることを示す。また、当該レコードに対応するテーブル読出しが実行された時間帯を含む所定範囲の期間において取得されたスタックトレースのファイル名が「Ｓ１」であることを示す。例えば、ファイル名「Ｓ１」のスタックトレースは、スタックトレース１３１に相当する。

また、カラム変数管理テーブル１３２には、Ｒ／Ｗ区分が「Ｒｅａｄ」、変数が「ｅｎｄＴｉｍｅ（ＲｅｑｕｅｓｔＥｎｔｉｔｙ）」、テーブルが「ｔｍｄ＿ｈｏｌｉｄａｙ＿ｒｅｑｕｅｓｔ」、カラムが「ｅｎｄ＿ｔｉｍｅ」、スタックトレースが「Ｓ１」というレコードが登録されている。このレコードは、テーブル「ｔｍｄ＿ｈｏｌｉｄａｙ＿ｒｅｑｕｅｓｔ」のカラム「ｅｎｄ＿ｔｉｍｅ」の読出し値が、業務ロジック３１０のオブジェクト「ＲｅｑｕｅｓｔＥｎｔｉｔｙ」に含まれる変数「ｅｎｄＴｉｍｅ」に代入されることを示す。また、当該レコードに対応するテーブル読出しが実行された時間帯を含む所定範囲の期間において取得されたスタックトレースのファイル名が「Ｓ１」であることを示す。

また、カラム変数管理テーブル１３２には、Ｒ／Ｗ区分が「Ｗｒｉｔｅ」、変数が「ｒｅｓｔＥｎｄ（ＴｍｄＲｅｓｔＤｔｏ）」、テーブルが「ｔｍｄ＿ｒｅｓｔ」、カラムが「ｒｅｓｔ＿ｅｎｄ」、スタックトレースが「Ｓ２」というレコードが登録されている。このレコードは、テーブル「ｔｍｄ＿ｒｅｓｔ」のカラム「ｒｅｓｔ＿ｅｎｄ」への書込み値が、業務ロジック３１０のオブジェクト「ＴｍｄＲｅｓｔＤｔｏ」に含まれる変数「ｒｅｓｔＥｎｄ」に代入されることを示す。また、当該レコードに対応するテーブル書込みが実行された時間帯を含む所定範囲の期間において取得されたスタックトレースのファイル名が「Ｓ２」であることを示す。

ここで、変数分析部１６０は、動作ログに含まれるＤＢアクセスログおよびＤＢアクセス時に呼出されたメソッドに関する呼出しログに基づいて、業務ロジック３１０に対するカラム変数管理テーブル１３２を、次のようにして生成する。

一例として、オブジェクト「ＲｅｑｕｅｓｔＥｎｔｉｔｙ」の変数「ｐｅｒｓｏｎａｌＩｄ」に着目する。業務ロジック３１０は、例えば、Ｏ／Ｒマッパーを利用して各ＤＢにアクセスする。ライブラリの挙動はソースコード外部の設定ファイルで定義されることがあり、こうしたライブラリモジュールのソースコードを分析サーバ１００は有していない。この場合、ソースコードレベルで見るとライブラリの内部処理がブラックボックスとなる。

そこで、まず、変数分析部１６０は、業務ロジック３１０のソースコード１２１に関する静的解析を行うことで、ＪＤＢＣモジュールを呼出して当該ＪＤＢＣモジュールの返り値をオブジェクト「ＲｅｑｕｅｓｔＥｎｔｉｔｙ」の変数「ｐｅｒｓｏｎａｌＩｄ」に代入する命令文を検出する。そして、変数分析部１６０は、当該命令文の実行ログをメソッドに関する呼出しログから抽出し、当該変数「ｐｅｒｓｏｎａｌＩｄ」に代入された返り値を特定する。更に、変数分析部１６０は、ＤＢアクセスログに含まれるＪＤＢＣモジュールが発行したＳＱＬ文とその実行結果のログから、特定した返り値を実行結果として取得したときに読み出されたテーブルとカラムとを抽出する。

例えば、変数分析部１６０は、業務ロジック３１０の実行ログからオブジェクト「ＲｅｑｕｅｓｔＥｎｔｉｔｙ」の変数「ｐｅｒｓｏｎａｌＩｄ」に代入された返り値αを特定する。この場合、変数分析部１６０は、ＪＤＢＣモジュールが実行結果αを取得したときのＳＱＬ文（ｓｅｌｅｃｔ文など）により読出し対象となったテーブル「ｔｍｄ＿ｈｏｌｉｄａｙ＿ｒｅｑｕｅｓｔ」のカラム「ｐｅｒｓｏｎａｌ＿ｉｄ」を、ＤＢアクセスログから特定する。これにより、変数分析部１６０は、オブジェクト「ＲｅｑｕｅｓｔＥｎｔｉｔｙ」の変数「ｐｅｒｓｏｎａｌＩｄ」を、テーブル「ｔｍｄ＿ｈｏｌｉｄａｙ＿ｒｅｑｕｅｓｔ」のカラム「ｐｅｒｓｏｎａｌ＿ｉｄ」から読み出された値が代入される変数として特定する。同様に、変数分析部１６０は、例えば、オブジェクト「ＲｅｑｕｅｓｔＥｎｔｉｔｙ」の変数「ｅｎｄＴｉｍｅ」を、テーブル「ｔｍｄ＿ｈｏｌｉｄａｙ＿ｒｅｑｕｅｓｔ」のカラム「ｅｎｄ＿ｔｉｍｅ」から読み出された値が代入される変数として特定する。この場合、オブジェクト「ＲｅｑｕｅｓｔＥｎｔｉｔｙ」の変数「ｐｅｒｓｏｎａｌＩｄ」および「ｅｎｄＴｉｍｅ」を読出し側変数と呼べる。変数分析部１６０は、読出し側変数に対して、Ｒ／Ｗ区分「Ｒｅａｄ」を設定する。

次に、オブジェクト「ＴｍｄＲｅｓｔＤｔｏ」の変数「ｒｅｓｔＥｎｄ」について説明する。変数分析部１６０は、業務ロジック３１０のソースコード１２１に関する静的解析を行うことで、オブジェクト「ＴｍｄＲｅｓｔＤｔｏ」の変数「ｒｅｓｔＥｎｄ」を引数として用いて、ＪＤＢＣモジュールを呼出す命令文を検出する。そして、変数分析部１６０は、当該命令文の実行ログをメソッドに関する呼出しログから抽出し、当該変数「ｒｅｓｔＥｎｄ」により指定された引数を特定する。更に、変数分析部１６０は、ＤＢアクセスログに含まれるＪＤＢＣモジュールが発行したクエリとその実行結果のログから、特定した引数を書込み値として書き込んだときの書込み先テーブルとカラムとを抽出する。

例えば、変数分析部１６０は、業務ロジック３１０の実行ログからオブジェクト「ＴｍｄＲｅｓｔＤｔｏ」の変数「ｒｅｓｔＥｎｄ」に代入された引数βを特定する。この場合、変数分析部１６０は、ＪＤＢＣモジュールが書込み値βを書き込んだときのＳＱＬ文（ｉｎｓｅｒｔ文など）により書込み先となったテーブル「ｔｍｄ＿ｒｅｓｔ」のカラム「ｒｅｓｔ＿ｅｎｄ」を、ＤＢアクセスログから特定する。これにより、変数分析部１６０は、オブジェクト「ＴｍｄＲｅｓｔＤｔｏ」の変数「ｒｅｓｔＥｎｄ」を、テーブル「ｔｍｄ＿ｒｅｓｔ」のカラム「ｒｅｓｔ＿ｅｎｄ」に書込む値が代入される変数として特定する。この場合、オブジェクト「ＴｍｄＲｅｓｔＤｔｏ」の変数「ｒｅｓｔＥｎｄ」を書込み側変数と呼べる。変数分析部１６０は、書込み側変数に対して、Ｒ／Ｗ区分「Ｗｒｉｔｅ」を設定する。

更に、変数分析部１６０は、業務ロジック３１０によるＤＢからのデータの読出しと、ＤＢへのデータの書込みとが行われた時間帯に取得されたスタックトレースのファイル名を、それぞれの変数に対応付けて、カラム変数管理テーブル１３２に記録する。

図１５は、データ伝搬関係テーブルの例を示す図である。
データ伝搬関係テーブル１４１は、データ伝搬関係記憶部１４０に記憶される。データ伝搬関係テーブル１４１は、業務、伝搬元テーブル、伝搬元カラム、伝搬先テーブルおよび伝搬先カラムの項目を含む。

業務の項目には、業務ロジックに対応するメソッド名が登録される。伝搬元テーブルの項目には、当該業務ロジックにより読出しの対象となるテーブル（伝搬元テーブル）の名称が登録される。伝搬元カラムの項目には、伝搬元テーブルにおける読出しの対象となるカラム（伝搬元カラム）の名称が登録される。伝搬先テーブルの項目には、当該業務ロジックにより書込みの対象となるテーブル（伝搬先テーブル）の名称が登録される。伝搬先カラムの項目には、伝搬先テーブルにおける書込み対象となるカラム（伝搬先カラム）の名称が登録される。ここで、伝搬先テーブルおよび伝搬先カラムの項目には、該当の業務ロジックにより、伝搬元テーブルおよび伝搬元カラムからの影響を受けるテーブル／カラムが、伝搬先テーブル／伝搬先カラムとして登録される。

例えば、データ伝搬関係テーブル１４１には、業務が「ｒｅｃｏｒｄＳｔａｒｔＷｏｒｋ」、伝搬元テーブルが「ｔｍｄ＿ｈｏｌｉｄａｙ＿ｒｅｑｕｅｓｔ」、伝搬元カラムが「ｅｎｄ＿ｔｉｍｅ」、伝搬先テーブルが「ｔｍｄ＿ｒｅｓｔ」、伝搬先カラムが「ｒｅｓｔ＿ｅｎｄ」というレコードが登録されている。このレコードは、業務ロジック「ｒｅｃｏｒｄＳｔａｒｔＷｏｒｋ」により、伝搬元テーブル「ｔｍｄ＿ｈｏｌｉｄａｙ＿ｒｅｑｕｅｓｔ」の伝搬元カラム「ｅｎｄ＿ｔｉｍｅ」の影響が伝搬先テーブル「ｔｍｄ＿ｒｅｓｔ」の伝搬先カラム「ｒｅｓｔ＿ｅｎｄ」に伝搬することを示す。

また、データ伝搬関係テーブル１４１には、業務が「ｔｗｅＣａｌｃＷｏｒｋ」、伝搬元テーブルが「ｔｍｄ＿ｒｅｓｔ」、伝搬元カラムが「ｒｅｓｔ＿ｅｎｄ」、伝搬先テーブルが「ｓｌｍｇ＿ｒｇｓ」、伝搬先カラムが「ｍｍ＿ｓｌｒｙ」というレコードが登録されている。このレコードは、業務ロジック「ｔｗｅＣａｌｃＷｏｒｋ」により、伝搬元テーブル「ｔｍｄ＿ｒｅｓｔ」の伝搬元カラム「ｒｅｓｔ＿ｅｎｄ」の影響が伝搬先テーブル「ｓｌｍｇ＿ｒｇｓ」の伝搬先カラム「ｍｍ＿ｓｌｒｙ」に伝搬することを示す。

図１６は、変更確認箇所表示画面の例を示す図である。
変更確認箇所表示画面１８２は、データ伝搬関係テーブル１４１に基づいて、変更箇所分析部１８０により出力される。変更確認箇所表示画面１８２は、クライアント４００またはクライアント５００のディスプレイにより表示されてもよい。変更確認箇所表示画面１８２は、業務ロジック表示領域Ｆ１、変更確認箇所表示領域Ｆ２およびＤＢ間関係表示領域Ｆ３を有する。

業務ロジック表示領域Ｆ１は、業務アプリケーションにおける変更確認の対象箇所のイメージを表示する領域である。当該イメージは、変更確認の対象箇所となる業務ロジックのアイコンと、当該業務ロジックにより読出しまたは書込みの対象となるテーブルのアイコンとを含む。

業務ロジック表示領域Ｆ１の例では、業務ロジックによる読出しおよび書込みの関係が矢印画像によって表される。例えば、テーブルを起点とし、業務ロジックを終点とする矢印画像は、業務ロジックによるテーブルからのデータの読出しを示す。また、業務ロジックを起点とし、テーブルを終点とする矢印画像は、業務ロジックによるテーブルへのデータの書込みを示す。

ここで、図１６の例では、「業務ロジックａａ」および「業務ロジックｂｂ」が変更確認の対象箇所である。また、「テーブルｘｘ」は「業務ロジックａａ」による読出し対象テーブルである。「テーブルｙｙ」は「業務ロジックａａ」による書込み対象テーブルである。「テーブルｙｙ」は「業務ロジックｂｂ」による読出し対象テーブルでもある。「テーブルｚｚ」は「業務ロジックｂｂ」による書込み対象テーブルである。

なお、業務ロジック表示領域Ｆ１では、業務アプリケーションに含まれる複数の業務ロジックと、業務ロジックにより対応関係を有する複数のテーブルとが表示され、その中で、変更確認の対象箇所が強調表示されてもよい。

変更確認箇所表示領域Ｆ２は、変更確認の対象箇所となる業務ロジックのリストを表示する領域である。例えば、変更確認箇所表示領域Ｆ２には、「業務ロジックａａ」および「業務ロジックｂｂ」を示すリストが表示される。

ＤＢ間関係表示領域Ｆ３は、変更確認対象の業務ロジックによるＤＢ間関係のリストを表示する領域である。例えば、ＤＢ間関係表示領域Ｆ３には、読出し元の「テーブルｘｘ」と書込み先の「テーブルｙｙ」との関係が表示される。また、ＤＢ間関係表示領域Ｆ３には、読出し元の「テーブルｙｙ」と書込み先の「テーブルｚｚ」との関係が表示される。更に、ＤＢ間関係表示領域Ｆ３には、読出し元の「テーブルｘｘ」と書込み先の「テーブルｚｚ」との関係が表示される。これらのうち、３つ目の関係は、「テーブルｙｙ」を介した、「テーブルｘｘ」と「テーブルｚｚ」との関係を示している。

データ伝搬関係テーブル１４１には、伝搬元カラムと伝搬先カラムとの情報も登録されている。このため、変更箇所分析部１８０は、ＤＢにおけるテーブル間の関係に加えて、テーブルにおけるカラム間の関係を、ＤＢ間関係表示領域Ｆ３に含めてもよい。

次に、分析サーバ１００による処理手順を説明する。
図１７は、データ伝搬関係推定例を示すフローチャートである。
（Ｓ１０）動作ログ取得部１５０は、調査する業務ロジックを選択する。例えば、業務アプリケーションに含まれる複数の業務ロジック（メソッド名）とソースファイル名とのリストが動作ログ記憶部１３０に予め格納される。動作ログ取得部１５０は、動作ログ記憶部１３０に記憶された当該リストから未調査の業務ロジックを１つ選択する。

（Ｓ１１）動作ログ取得部１５０は、選択した業務ロジックの動作ログを業務サーバ３００，３００ａから取得する。動作ログ取得部１５０は、取得した動作ログを、動作ログ記憶部１３０に格納する。これにより、動作ログ記憶部１３０に、該当の業務ロジックに対するスタックトレースと、カラム変数管理テーブルとが格納される。動作ログ取得部１５０は、カラム変数管理テーブルの作成方法として、図１４で例示した方法を用いることができる。

（Ｓ１２）変数分析部１６０は、業務ロジックの静的解析による変数伝搬関係の分析を行う。当該分析の処理の詳細は後述される。
（Ｓ１３）データ伝搬関係分析部１７０は、ＤＢカラム値の読出し／書込み間の伝搬関係の特定を行う。当該特定の処理の詳細は後述される。

（Ｓ１４）動作ログ取得部１５０は、全ての業務ロジックを調査済であるか否かを判定する。全ての業務ロジックを調査済の場合、ステップＳ１５に処理が進む。全ての業務ロジックを調査済でない場合、ステップＳ１０に処理が進む。

（Ｓ１５）データ伝搬関係分析部１７０は、ＤＢ間のデータ伝搬関係を出力する。具体的には、データ伝搬関係分析部１７０は、データ伝搬関係テーブル１４１を生成し、データ伝搬関係記憶部１４０に格納する。そして、処理が終了する。

図１８は、変数伝搬関係の分析例を示すフローチャートである。
変数伝搬関係の分析は、ステップＳ１２で実行される。
（Ｓ２０）変数分析部１６０は、ソースコード記憶部１２０から、選択した業務ロジックのソースコードを取得する。例えば、前述のように、業務ロジックと当該業務ロジックのソースコードが記述されたソースファイル名とを示すリストが動作ログ取得部１５０に予め格納される。変数分析部１６０は、当該情報を参照して、選択した業務ロジックに対するソースコードを取得する。

（Ｓ２１）変数分析部１６０は、ソースコードを参照して、選択した業務ロジックについて静的解析の基点となるメソッド（基点メソッド）を選択する。該当の業務ロジックに対して最初にステップＳ２１を実行する場合、変数分析部１６０は、選択した業務ロジックに対応するメソッド名のメソッド（当該業務ロジックにおける最上位のメソッド）を基点として選択する。それ以後は、変数分析部１６０は、以下の手順で順次特定される呼出しメソッドを順番に選択する。

（Ｓ２２）変数分析部１６０は、ソースコードを参照して、基点メソッドからの呼出しメソッドを１つ選択する。
（Ｓ２３）変数分析部１６０は、特定した呼出しメソッドがインタフェースなどの動的に実装されるメソッドであるか否かを判定する。動的に実装されるメソッドの場合、ステップＳ２４に処理が進む。動的に実装されるメソッドではなく、静的解析により単一の呼出しメソッドを特定できる場合、ステップＳ２７に処理が進む。ここで、静的解析により単一の呼出しメソッドを特定できる場合、その呼出しメソッドは、ステップＳ２１による基点メソッドの選択候補となる。

（Ｓ２４）変数分析部１６０は、選択した業務ロジックに対応するスタックトレース上に該当のメソッドで示される命令があるか否かを判定する。ある場合、ステップＳ２５に処理が進む。ない場合、ステップＳ２６に処理が進む。

（Ｓ２５）変数分析部１６０は、スタックトレースに基づいて実装メソッドを特定する。当該実装メソッドは、ステップＳ２１における基点メソッドの選択候補となる。そして、ステップＳ２７に処理が進む。

（Ｓ２６）変数分析部１６０は、可能性のある実装メソッドを全て特定する。例えば、変数分析部１６０は、該当のメソッド名を有する全てのクラスのソースコードを、ソースコード記憶部１２０から特定する。当該実装メソッドは、ステップＳ２１における基点メソッドの選択候補となる。そして、ステップＳ２７に処理が進む。

（Ｓ２７）変数分析部１６０は、現在の基点メソッドからの呼出しメソッドを全て確認済であるか否かを判定する。全て確認済の場合、ステップＳ２８に処理が進む。全て確認済でない場合、ステップＳ２２に処理が進む。

（Ｓ２８）変数分析部１６０は、選択した業務ロジックに関する全てのメソッドを確認したか否かを判定する。当該全てのメソッドを確認した場合、ステップＳ２９に処理が進む。当該全てのメソッドを確認していない場合、ステップＳ２１に処理が進む。なお、「全てのメソッド」とは、選択した業務ロジックのソースコードに含まれるメソッド、当該メソッドを介して呼出される配下のメソッド（他のソースコードに記述されていることもある）を含む。

ステップＳ２１～Ｓ２８を繰り返し実行することで、変数分析部１６０は、選択した業務ロジックの最上位のメソッドを頂点として、その配下のメソッドの関係を表す情報を生成する。変数分析部１６０は、例えば、選択した業務ロジックの最上位のメソッドを頂点とし、その配下のメソッドが、最上位のメソッドからの呼出し順に応じた階層に属するツリー構造を得る。ここで、最上位のメソッドの配下のメソッドは、最上位のメソッドから直接呼出されるメソッド、および、最上位のメソッドから直接呼出されたメソッドを介して間接的に呼出されるメソッドを含む。

（Ｓ２９）変数分析部１６０は、業務ロジック内の変数伝搬関係を記録する。具体的には、変数分析部１６０は、ステップＳ２１～Ｓ２８を実行することで取得したメソッド間の呼出し関係を基に各メソッドのソースコードを参照し、各メソッドに含まれる変数間の関係を得る。例えば、変数分析部１６０は、第１のメソッドが第１の変数の代入値を引数として第２のメソッドを呼出し、当該引数の第２のメソッドによる処理結果が第２のメソッド内の第２の変数に代入される場合、第１の変数と第２の変数に伝搬関係があると判断する。そして、変数分析部１６０は、第１のメソッドおよび第１の変数の組と、第２のメソッドおよび第２の変数との組との間に、第１の変数が第２の変数に影響を与えるという関係をもつことを、中間データとしてＲＡＭ１０２に格納する。変数分析部１６０は、他のメソッドと変数との組についても同様にして変数伝搬関係を記録する。例えば、第２の変数が第３のメソッドの第３の変数に影響を与える関係をもつこともある。その場合、変数分析部１６０は、第１の変数の影響が、第２の変数を介して、第３の変数に伝搬するという関係を記録する。変数分析部１６０は、こうして連鎖的に伝搬する各メソッドの変数間の影響を記録する。そして、処理が終了する。

例えば、変数分析部１６０は、ソースコード１２１の中に、呼出し先のメソッド（関数）の複数の候補のうちの１つが業務ロジック３１０の実行時に呼出されることを示す命令文を検出する。すると、変数分析部１６０は、業務ロジック３１０が実行されたときのスタックトレース１３１に基づいて、複数の候補のうち業務ロジック３１０の実行時に呼出されるメソッドを特定し、当該メソッドによる変数間の関係を特定する。

図１９は、ＤＢカラム値の読出し／書込み間の伝搬関係の特定例を示すフローチャートである。
ＤＢカラム値の読出し／書込み間の伝搬関係の特定は、ステップＳ１３で実行される。

（Ｓ３０）データ伝搬関係分析部１７０は、動作ログ記憶部１３０に記憶されたカラム変数管理テーブルを参照して、ＤＢのカラム値の読出し先の変数を１つ選択する。カラム変数管理テーブル１３２の例において、Ｒ／Ｗ区分が「Ｒｅａｄ」である変数が、ＤＢのカラム値の読出し先の変数（読出し側変数）である。

（Ｓ３１）データ伝搬関係分析部１７０は、変数分析部１６０により作成された変数の伝搬関係を示す中間データに基づいて、ステップＳ３０で選択した変数の影響を分析する。データ伝搬関係分析部１７０は、分析の結果として、選択した変数により影響を受ける全ての他の変数を得る。

（Ｓ３２）データ伝搬関係分析部１７０は、選択した変数（読出し側変数）がＤＢのカラムに値を書込む変数（すなわち、書込み側変数）に影響があるか否かを判定する。影響がある場合、ステップＳ３３に処理が進む。影響がない場合、ステップＳ３４に処理が進む。例えば、カラム変数管理テーブル１３２を用いる場合、ステップＳ３１で得られた影響先の他の変数に、カラム変数管理テーブル１３２でＲ／Ｗ区分が「Ｗｒｉｔｅ」である変数（書込み側変数）が含まれる場合、書込み側変数に影響があることになる。一方、当該他の変数に、書込み側変数が含まれない場合、書込み側変数に影響がないことになる。

（Ｓ３３）データ伝搬関係分析部１７０は、読出し対象カラムと書込み対象カラムの間の選択した業務ロジックによる影響関係を示す情報を作成し、データ伝搬関係記憶部１４０に格納する。具体的には、データ伝搬関係分析部１７０は、業務ロジックに対応するメソッド名と、伝搬元テーブル／カラムと、伝搬先テーブル／カラムとの対応関係を示すレコードをデータ伝搬関係テーブル１４１に登録する。

（Ｓ３４）データ伝搬関係分析部１７０は、選択した業務ロジックのカラム変数管理テーブルを参照して、ＤＢのカラム値の読出し先の全ての変数を確認したか否かを判定する。全ての変数を確認した場合、処理が終了する。全ての変数を確認していない場合、ステップＳ３０に処理が進む。

変更箇所分析部１８０は、変更対象の業務ロジックの入力１８１に応じて、データ伝搬関係テーブル１４１に基づき、業務アプリケーションにおける変更箇所特定の処理を実行する。

図２０は、業務ロジック変更時の変更箇所特定例を示すフローチャートである。
（Ｓ４０）変更箇所分析部１８０は、変更対象の業務ロジックの入力１８１を受け付ける。例えば、変更対象の業務ロジックは、ユーザ６００により、ＳＥ７００に対して指示される。ＳＥ７００は、クライアント５００または入力デバイス１１２を用いて、分析サーバ１００に対して入力１８１を与える。入力１８１は、変更対象の業務ロジックのメソッド名を含む。変更箇所分析部１８０は、入力１８１により指定された業務ロジックを変更確認箇所の１つとする。

（Ｓ４１）変更箇所分析部１８０は、データ伝搬関係テーブル１４１を参照して、指示された業務ロジックの変更に対して直接影響を受けるＤＢのカラムの組（伝搬元テーブル／伝搬元カラムと伝搬先テーブル／伝搬先カラムとの組）を特定する。

（Ｓ４２）変更箇所分析部１８０は、ＤＢのカラムの組を１つ選択する。具体的には、変更箇所分析部１８０は、ステップＳ４１で特定した伝搬元テーブル／伝搬元カラムと、伝搬先テーブル／伝搬先カラムとの組を１つ選択する。

（Ｓ４３）変更箇所分析部１８０は、選択したＤＢのカラムの組に関わる業務ロジックを変更確認箇所に追加する。具体的には、変更箇所分析部１８０は、ステップＳ４２で選択した組に含まれる伝搬先カラムを伝搬元カラムとしてもつ他の業務ロジックを変更確認箇所に追加する。また、変更箇所分析部１８０は、他の業務ロジックに対する伝搬先カラムを伝搬元カラムとしてもつ業務ロジックがあれば当該業務ロジックも変更確認箇所として追加し、同様にして、連鎖的に変更確認対象の業務ロジックを決定する。

（Ｓ４４）変更箇所分析部１８０は、ステップＳ４１で特定した全てのカラムの組（業務ロジック変更で直接影響を受けるカラムの組）を確認したか否かを判定する。ステップＳ４１で特定した全てのカラムの組を確認した場合、ステップＳ４５に処理が進む。ステップＳ４１で特定した全てのカラムの組を確認していない場合、ステップＳ４２に処理が進む。

（Ｓ４５）変更箇所分析部１８０は、ステップＳ４１～Ｓ４４の処理結果に基づいて変更確認箇所表示画面１８２を生成し、変更確認箇所表示画面１８２を出力する。これにより、変更箇所分析部１８０は、変更確認箇所をユーザ６００に提示する。例えば、変更確認箇所表示画面１８２は、クライアント４００のディスプレイに表示されて、ユーザ６００に提示されてもよい。あるいは、変更確認箇所表示画面１８２は、クライアント５００のディスプレイまたはディスプレイ１１１に表示されて、ユーザ６００に提示されてもよい。そして、処理が終了する。

このように、変更箇所分析部１８０は、ユーザ６００により改変が希望される業務ロジックの指定を受け付ける。そして、変更箇所分析部１８０は、データ伝搬関係テーブル１４１に基づいて、当該業務ロジックと当該業務ロジックの改変の影響を受ける他の業務ロジックとを改変対象の業務ロジックとして特定する。

変更箇所分析部１８０は、改変対象の業務ロジックにおいて、ＤＢ間を関連付ける複数の変数の少なくとも１つを有するメソッド（関数）を改変対象ロジックとして特定してもよい。より具体的には、ステップＳ４５では、変更箇所分析部１８０は、変数分析部１６０によるメソッドの呼出し関係および変数の伝搬関係に基づいて、メソッドに関する情報を変更確認対象箇所として出力してもよい。

例えば、変更箇所分析部１８０は、変更確認箇所表示画面１８２の内容に加えて、伝搬元テーブル／伝搬元カラムと伝搬先テーブル／伝搬先カラムとを関連付けるメソッドを、変更確認対象として出力することが考えられる。すなわち、変更箇所分析部１８０は、図１０で例示されたように、伝搬元テーブル／伝搬元カラムと伝搬先テーブル／伝搬先カラムとを関連付けるメソッド間の呼出し関係や当該メソッドの変数による影響の伝搬を示す画像を更に出力してもよい。このようにすると、ユーザ６００に対し、変更確認箇所として、より詳細な情報を提示することができる。また、ＳＥ７００による変更確認箇所の詳細な特定を支援することができる。

次に、図１８のステップＳ２２で説明した呼出しメソッドの特定例を説明する。
図２１は、呼出しメソッドの特定例を示す図である。
ソースコード１２１において、業務ロジック３１０（勤怠打刻操作）に対応する最上位のメソッドは、「ｒｅｃｏｒｄＳｔａｒｔＷｏｒｋ」（１行目）である。「ｒｅｃｏｒｄＳｔａｒｔＷｏｒｋ」が業務ロジック３１０に対応するメソッド名である。

メソッド「ｒｅｃｏｒｄＳｔａｒｔＷｏｒｋ」は、「ｒｅｃｏｒｄＰｏｒｔａｌＴｉｍｅ」（３行目）、「ｇｅｔＤａｔｅ」（７行目）、「ｆｉｎｄＦｏｒＫｅｙ」（９行目）、「ａｄｄＥｒｒｏｒＭｅｓｓａｇｅ」（１３行目）、「ｇｅｔＳｔｒｉｎｇＤａｔｅ」（１３行目）、「ｇｅｔＮａｍｅ」（１４行目）、「ｇｅｔＡｐｐｌｉｃａｔｉｏｎＥｎｔｉｔｙ」（１８行目）、「ｇｅｔＲｅｑｕｅｓｔＥｎｔｉｔｙ」（２０行目）、「ｇｅｔＷｏｒｋＴｙｐｅＥｎｔｉｔｙ」（２２行目）および「ｇｅｔＷｏｒｋＴｙｐｅ」（２２行目）などのメソッドを呼出す。したがって、基点メソッドを「ｒｅｃｏｒｄＳｔａｒｔＷｏｒｋ」とする場合、当該基点メソッドから呼出されるこれらのメソッドが呼出しメソッドとなる。

変数分析部１６０は、呼出しメソッドが複数の場合、複数の呼出しメソッドから１つずつ選択して、ステップＳ２２～Ｓ２７を繰り返し実行する。このうち、「ｆｉｎｄＦｏｒＫｅｙ」、「ｇｅｔＡｐｐｌｉｃａｔｉｏｎＥｎｔｉｔｙ」、「ｇｅｔＲｅｑｕｅｓｔＥｎｔｉｔｙ」、「ｇｅｔＷｏｒｋＴｙｐｅＥｎｔｉｔｙ」がインタフェースなどの動的に実装されるメソッドである。したがって、これらメソッドに対しては、ステップＳ２４の判定に応じてステップＳ２５またはステップＳ２６の何れかを実行することで、実装メソッドを特定する。

図２２は、スタックトレースによる実装メソッドの特定例を示す図である。
例えば、ソースコード１２１におけるメソッド「ｇｅｔＲｅｑｕｅｓｔＥｎｔｉｔｙ」に着目すると、スタックトレース１３１の６行目に、「ｇｅｔＲｅｑｕｅｓｔＥｎｔｉｔｙ」を呼出したことが記録されている。変数分析部１６０は、スタックトレース１３１に基づいて、メソッド「ｇｅｔＲｅｑｕｅｓｔＥｎｔｉｔｙ」に関して、業務ロジック３１０で実際に呼出されるメソッドを提供するクラス「ＲｅｑｕｅｓｔＵｔｉｌＢｅａｎ」を特定する。このため、変数分析部１６０はクラス「ＲｅｑｕｅｓｔＵｔｉｌＢｅａｎ」のソースコードを参照することで、当該クラスにおけるメソッド「ｇｅｔＲｅｑｕｅｓｔＥｎｔｉｔｙ」の定義内容を確認し、変数の伝搬関係を追跡することが可能になる。

図２３は、変数の伝搬関係の追跡例を示す図である。
ソースコード１２１の２０行目によれば、メソッド「ｇｅｔＲｅｑｕｅｓｔＥｎｔｉｔｙ」の出力は、ＲｅｑｕｅｓｔＥｎｔｉｔｙ型のオブジェクト「ｒｅｑｕｅｓｔＥｎｔｉｔｙ」である。オブジェクト「ｒｅｑｕｅｓｔＥｎｔｉｔｙ」のソースコード１２２によれば、当該オブジェクトは、ｆｉｅｌｄ変数として、「ｐｅｒｓｏｎａｌＩｄ」および「ｅｎｄＴｉｍｅ」を含む。なお、変数「ｐｅｒｓｏｎａｌＩｄ」および「ｅｎｄＴｉｍｅ」は、カラム変数管理テーブル１３２におけるテーブル「ｔｍｄ＿ｈｏｌｉｄａｙ＿ｒｅｑｕｅｓｔ」に対する読出し側変数に相当している。

例えば、クラス「ＲｅｑｕｅｓｔＵｔｉｌＢｅａｎ」のメソッド「ｇｅｔＲｅｑｕｅｓｔＥｎｔｉｔｙ」のソースコードに基づき、次の変数間の関係を検出する。変数分析部１６０は、メソッド「ｒｅｃｏｒｄＳｔａｒｔＷｏｒｋ」の変数「ｐｅｒｓｏｎａｌＩｄ」が、オブジェクト「ＲｅｑｕｅｓｔＥｎｔｉｔｙ」の変数「ｐｅｒｓｏｎａｌＩｄ」に影響することを検出する。変数分析部１６０はメソッド「ｒｅｃｏｒｄＳｔａｒｔＷｏｒｋ」の変数「ｔａｒｇｅｔＤａｔｅ」が、オブジェクト「ｒｅｑｕｅｓｔＥｎｔｉｔｙ」の変数「ｅｎｄＴｉｍｅ」に影響することを検出する。

こうして、実装メソッドが動的に決定される場合にも、変数分析部１６０は、変数の伝搬関係を追跡することができる。
次に、オブジェクト「ｒｅｑｕｅｓｔＥｎｔｉｔｙ」に格納された変数の伝搬関係の追跡を例示する。

図２４は、変数の伝搬関係の追跡例（続き）を示す図である。
ソースコード１２１の２５行目によれば、「ｒｅｑｕｅｓｔＥｎｔｉｔｙ」を引数としてメソッド「ｇｅｔＥｎｄＴｉｍｅ」が呼出される。メソッド「ｇｅｔＥｎｄＴｉｍｅ」の処理結果は、メソッド「ｒｅｇｉｓｔＲｅｓｔ」により、オブジェクト「ｒｅｓｔＬｉｓｔ」に格納される。メソッド「ｇｅｔＥｎｄＴｉｍｅ」および「ｒｅｇｉｓｔＲｅｓｔ」のソースコードによれば、「ｒｅｑｕｅｓｔＥｎｔｉｔｙ」のｆｉｅｌｄ変数である「ｐｅｒｓｏｎａｌＩｄ」の値および「ｅｎｄＴｉｍｅ」の値がオブジェクト「ｒｅｓｔＬｉｓｔ」の２つのｆｉｅｌｄ変数に影響を及ぼす。例えば、オブジェクト「ｒｅｓｔＬｉｓｔ」の第１の変数に、「ｒｅｑｕｅｓｔＥｎｔｉｔｙ」の変数「ｐｅｒｓｏｎａｌＩｄ」の値（あるいは、加工された値）が代入される。また、オブジェクト「ｒｅｓｔＬｉｓｔ」の第２の変数に、「ｒｅｑｕｅｓｔＥｎｔｉｔｙ」の変数「ｅｎｄＴｉｍｅ」の値（あるいは、加工された値）が代入される。

そして、ソースコード１２１の２７行目によれば、オブジェクト「ｒｅｓｔＬｉｓｔ」のｆｉｅｌｄ変数の値が、オブジェクト「ｒｅｓｔＤｔｏ」のｆｉｅｌｄ変数に代入される。例えば、オブジェクト「ｒｅｓｔＤｔｏ」は、ｆｉｅｌｄ変数として、「ｒｅｓｔＥｎｄ」を含む。そして、「ｒｅｓｔＬｉｓｔ」の第２の変数の値が、「ｒｅｓｔＤｔｏ」の変数「ｒｅｓｔＥｎｄ」に代入される。すなわち、当該変数「ｒｅｓｔＥｎｄ」はオブジェクト「ｒｅｑｕｅｓｔＥｎｔｉｔｙ」がもつ変数「ｅｎｄＴｉｍｅ」と伝搬関係にある。

更に、ソースコード１２１の２９行目によれば、「ｒｅｓｔＤｔｏ」を引数としてメソッド「ｒｅｇｉｓｔ」が呼出される。メソッド「ｒｅｇｉｓｔ」のソースコードによれば、「ｒｅｓｔＤｔｏ」がもつ変数「ｒｅｓｔＥｎｄ」の値は、オブジェクト「ＴｍｄＲｅｓｔＤｔｏ」のｆｉｅｌｄ変数である「ｒｅｓｔＥｎｄ」に代入される。すなわち、オブジェクト「ｒｅｓｔＤｔｏ」の変数「ｒｅｓｔＥｎｄ」は、オブジェクト「ＴｍｄＲｅｓｔＤｔｏ」の変数「ｒｅｓｔＥｎｄ」と伝搬関係にある。

なお、図２４で例示したメソッドにおいて、実装メソッドが動的に決定されるものがある場合、変数分析部１６０は、当該メソッドについて、前述のようにスタックトレースに基づいて、実装メソッドを特定する。

ここで、オブジェクト「ＴｍｄＲｅｓｔＤｔｏ」の変数「ｒｅｓｔＥｎｄ」は、カラム変数管理テーブル１３２に登録された書込み側変数に相当する。したがって、上記の変数伝搬の分析により、変数分析部１６０は、オブジェクト「ＲｅｑｕｅｓｔＥｎｔｉｔｙ」の変数「ｅｎｄＴｉｍｅ」に代入される値が、オブジェクト「ＴｍｄＲｅｓｔＤｔｏ」の変数「ｒｅｓｔＥｎｄ」に影響することを特定する。

データ伝搬関係分析部１７０は、変数分析部１６０により特定された変数間の影響の情報とカラム変数管理テーブル１３２とを参照することで、例えば、伝搬元テーブル「ｔｍｄ＿ｈｏｌｉｄａｙ＿ｒｅｑｕｅｓｔ」、伝搬元カラム「ｅｎｄ＿ｔｉｍｅ」、伝搬先テーブル「ｔｍｄ＿ｒｅｓｔ」、伝搬先カラム「ｒｅｓｔ＿ｅｎｄ」の業務ロジック３１０（ｒｅｃｏｒｄＳｔａｒｔＷｏｒｋ）による関係を特定する。そして、データ伝搬関係分析部１７０は、特定した関係をデータ伝搬関係テーブル１４１に登録する。

ここで、データ伝搬関係テーブル１４１が得られている場合に、変更対象の業務ロジックとして、分析サーバ１００に対して、業務ロジック３１０（ｒｅｃｏｒｄＳｔａｒｔＷｏｒｋ）が指示されたとする。この場合、変更箇所分析部１８０は、データ伝搬関係テーブル１４１に基づいて、「ｒｅｃｏｒｄＳｔａｒｔＷｏｒｋ」に対応する伝搬元テーブル／伝搬元カラムと伝搬先テーブル／伝搬先カラムとを特定する（ステップＳ４１，Ｓ４２に相当）。そして、変更箇所分析部１８０は、データ伝搬関係テーブル１４１を参照して、特定した伝搬先テーブル／伝搬先カラムが、伝搬元テーブル／伝搬元カラムとして登録されているレコードを検索する。図１５のデータ伝搬関係テーブル１４１の例では、業務「ｔｗｅＣａｌｃＷｏｒｋ」のレコードが該当する。すなわち、変更箇所分析部１８０は、業務ロジック３１０の変更に伴って、業務ロジック「ｔｗｅＣａｌｃＷｏｒｋ」も変更確認箇所として特定する（ステップＳ４３に相当）。

なお、変更箇所分析部１８０は、ステップＳ４３では、業務ロジック「ｔｗｅＣａｌｃＷｏｒｋ」の伝搬先テーブル「ｓｌｍｇ＿ｒｇｓ」の伝搬先カラム「ｍｍ＿ｓｌｒｙ」を伝搬元テーブル／伝搬元カラムとしてもつ他の業務ロジックを更に検索する。こうして、変更箇所分析部１８０は、ＤＢのテーブルを介して関連する業務ロジックを変更確認箇所として連鎖的に特定していく。そして、変更箇所分析部１８０は、特定した変更確認箇所の一覧を示す変更確認箇所表示画面１８２を出力する。

分析サーバ１００によれば、ＤＢ２１０，２２０，２３０，・・・を介して連携する複数の業務ロジックに関して、ある業務ロジックの変更に伴う変更対象ロジックを適切に特定し、ユーザ６００に提示可能になる。特に、分析サーバ１００は、各業務ロジックのソースコードに対して、静的解析と動的解析とを組み合せることで、静的解析で追跡できない変数の伝搬を動的解析により補間して、業務ロジックにおける変数の影響の伝搬を適切に追跡できる。このため、実行される手続きが動的束縛により決定される場合にも、ある業務ロジックによるＤＢ間の関係を特定可能になる。その結果、変更対象ロジックの抽出漏れを低減し、変更対象ロジックの抽出精度を向上させることができる。

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

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

１０ 分析支援装置
１１，Ｍ１，Ｍ２，Ｍ３，・・・ 記憶部
１２ 処理部
１３ ソースコード
１４ 動作履歴情報
２０ 業務システム
３０，４０ 端末装置
３１ 画面
５０ ネットワーク
６０，７０ ユーザ
Ｌ１，Ｌ２，Ｌ３，・・・ ロジック

Claims (6)

1. 複数のロジックと複数の記憶部とを有する業務システムの分析を支援する分析支援方法であって、コンピュータが、
   前記業務システムを使用する第１のユーザにより指示されたロジックの前記業務システムによる実行に伴って、前記複数の記憶部に格納されたデータの読出しおよび書込みに関する動作履歴情報を取得し、
   前記動作履歴情報および前記ロジックのソースコードの解析に応じて、前記読出しが行われた記憶部と前記書込みが行われた他の記憶部との前記ロジックによる関係を特定し、
   前記関係に基づいて、前記業務システムを改変する第２のユーザにより改変すべき改変対象ロジックを特定し、前記改変対象ロジックを前記第１のユーザに提示する、
   分析支援方法。
2. 前記関係は、前記記憶部に記憶された第１のデータ項目と前記他の記憶部に記憶された第２のデータ項目との前記ソースコードに含まれる複数の変数を介した前記関係である、
   請求項１記載の分析支援方法。
3. 前記関係の特定では、前記ソースコードの中に、呼出し先の関数の複数の候補のうちの１つが前記ロジックの実行時に呼出されることを示す命令文を検出すると、前記ロジックが実行されたときのスタックトレースに基づいて、前記複数の候補のうち前記ロジックの実行時に呼出される関数を特定し、当該関数による変数間の関係を特定する、
   請求項２記載の分析支援方法。
4. 前記改変対象ロジックの特定では、前記複数の変数の少なくとも１つを有する関数を前記改変対象ロジックとして特定する、
   請求項２または３記載の分析支援方法。
5. 前記改変対象ロジックの特定では、改変対象の第１のロジックが指定されると、前記関係に基づいて、前記第１のロジックの改変の影響を受ける第２のロジックを前記改変対象ロジックとして特定する、
   請求項１乃至４の何れか１項に記載の分析支援方法。
6. 複数のロジックと複数の記憶部とを有する業務システムの分析を支援する分析支援プログラムであって、コンピュータに、
   前記業務システムを使用する第１のユーザにより指示されたロジックの前記業務システムによる実行に伴って、前記複数の記憶部に格納されたデータの読出しおよび書込みに関する動作履歴情報を取得し、
   前記動作履歴情報および前記ロジックのソースコードの解析に応じて、前記読出しが行われた記憶部と前記書込みが行われた他の記憶部との前記ロジックによる関係を特定し、
   前記関係に基づいて、前記業務システムを改変する第２のユーザにより改変すべき改変対象ロジックを特定し、前記改変対象ロジックを前記第１のユーザに提示する、
   処理を実行させる分析支援プログラム。

Images