JP2018181121A - 分析装置、分析プログラム及び分析方法 - Google Patents

Abstract

【課題】プログラム内に存在する再利用可能な範囲を特定することを目的とする。【解決手段】所定の業務アプリケーションの仕様を分析する分析装置であって、業務アプリケーションの実行においてアクセスされるデータベースのアクセス処理のログ情報を取得する取得部と、前記ログ情報に基づき、前記データベースのアクセス処理において連続する処理のうちの一部分であって、重複して実行される処理部分を抽出する第１の抽出部と、抽出した前記重複して実行される処理部分に含まれる処理のそれぞれを呼び出すメソッドを抽出する第２の抽出部と、抽出した前記メソッドから更新されるテーブルのうち、前記処理部分に含まれる処理のそれぞれを実行したときに更新されるテーブル以外の他のテーブルを更新しないメソッドに、ＡＰＩを設定し、利用可能とする設定部と、を有する分析装置が提供される。【選択図】図７

Description

本発明は、分析装置、分析プログラム及び分析方法に関する。

業務アプリケーションは、度重なる機能の追加により、プログラム及び使用するデータが複雑な関係となっていることがある。この場合、機能変更や追加等の保守がし難く、保守コストが増大する傾向にある。そこで、機能変更や追加等をするときに、既存の業務アプリケーションのデータを外部システムから活用する、Ｗｅｂ ＡＰＩ（Application Programming Interface）等のＡＰＩを利用することが行われている。

また、例えば、業務機能とプログラムとそれがアクセスするデータを対応付け、業務機能が実現する業務仕様の作成を支援する技術が知られている（例えば、特許文献１参照）。これによれば、受注登録業務や得意先登録業務等の業務機能を実現するために画面から入力する項目とプログラムの入出力項目とを解析し、業務間に存在する依存関係を抽出し、提示する。

特開２００９−１１６６３８号公報 特開２０１６−５７７２２号公報 特開２０１２−１２３５８２号公報 特開２００９−２３０６１８号公報 特開２０１３−２１８３８０号公報

しかし、特許文献１では、プログラムと入出力されるテーブルとの対応が業務機能単位で抽出されるに留まり、プログラム内に存在する再利用可能な範囲を特定することはできない。また、業務実行時にまとまってアクセスされるデータベース内のテーブル群を検出できない。そのため、業務アプリケーションのあるメソッドにＡＰＩを追加すると、どのような業務を実行するためにＳＱＬが発行され、データベース内のどのテーブルに影響があるかを把握することは困難である。

一方、業務アプリケーションは、機能追加をする時点で、該当システムの開発担当者がいないとか、ドキュメントの保守がされていない場合がある。この場合、ＡＰＩ提供側では、機能追加によってデータ間に不整合が起こらないように、どこにどのような粒度のＡＰＩを設ければ良いかが不明である。

そこで、１つの側面では、本発明は、プログラム内に存在する再利用可能な範囲を特定することを目的とする。

１つの実施態様では、所定の業務アプリケーションの仕様を分析する分析装置であって、業務アプリケーションの実行においてアクセスされるデータベースのアクセス処理のログ情報を取得する取得部と、前記ログ情報に基づき、前記データベースのアクセス処理において連続する処理のうちの一部分であって、重複して実行される処理部分を抽出する第１の抽出部と、抽出した前記重複して実行される処理部分に含まれる処理のそれぞれを呼び出すメソッドを抽出する第２の抽出部と、抽出した前記メソッドから更新されるテーブルのうち、前記処理部分に含まれる処理のそれぞれを実行したときに更新されるテーブル以外の他のテーブルを更新しないメソッドに、ＡＰＩを設定し、利用可能とする設定部と、を有する分析装置が提供される。

１つの側面では、本発明は、プログラム内に存在する再利用可能な範囲を特定することができる。

一実施形態に係るシステムのハードウェア構成の一例を示す図。 一実施形態に係る業務用ＤＢの一例を示す図。 一実施形態に係るＡＰサーバと分析装置の機能構成の一例を示す図。 一実施形態に係る動作ログ情報ＤＢに格納された実行テーブルの一例を示す図。 一実施形態に係る動作ログ情報ＤＢに格納された実行テーブルの一例を示す図。 一実施形態に係る動作ログ情報ＤＢに格納された実行テーブルの一例を示す図。 一実施形態に係る分析処理の一例を示すフローチャート。 一実施形態に係る類似度判定処理の一例を示すフローチャート。 一実施形態に係る類似度判定処理の結果の一例を示す図。 一実施形態に係る冗長部分の削除処理の一例を示すフローチャート。 一実施形態に係る冗長部分の削除処理の結果の一例を示す図。 一実施形態に係る冗長部分の削除処理の結果の一例を示す図。 一実施形態に係る部分ＳＱＬ列生成処理の一例を示すフローチャート。 一実施形態に係る部分ＳＱＬ列生成処理の結果の一例を示す図。 一実施形態に係る親メソッドの抽出例を説明するための図。 一実施形態に係るＡＰＩの設定テーブルの一例を示す図。

以下、本発明の実施形態について添付の図面を参照しながら説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複した説明を省く。

[はじめに]
業務アプリケーションは、機能追加をする時点で、該当システムの開発担当者がいないとか、ドキュメントの保守がされていない場合がある。この場合、ＡＰＩ提供側では、機能追加によってデータ間に不整合が起こらないような粒度のＡＰＩを設ける必要がある。

一方、業務アプリケーションがデータベース内のデータを利用する場合、業務に対応するまとまりを持つ複数のＳＱＬを発行することがある。そのようなＳＱＬを実行するクラス及びメソッドのかたまりは、上記のＡＰＩとしての粒度として適切で、ＡＰＩ追加の候補になると考えられる。

そこで、本実施形態に係るシステムは、業務アプリケーションのプログラム理解支援のリバースエンジニアリングに関し、既存業務アプリケーションのうち、データ間に不整合が起こらないような粒度のＳＱＬ処理を抽出し、抽出結果に基づきＡＰＩを設定し、本システムの内部及び外部から再利用可能とする。

[システム構成／ハードウェア構成]
まず、一実施形態に係るシステムのハードウェア構成の一例について、図１を参照しながら説明する。図１は、一実施形態に係るシステムのハードウェア構成の一例を示す。本実施形態に係るシステムは、分析装置１０、アプリケーションサーバ(以下、「ＡＰサーバ」と表記する。)２０及びクライアント端末３０を有する。分析装置１０、ＡＰサーバ２０及びクライアント端末３０は、インターネット等のネットワーク４０を介して接続可能である。クライアント端末３０は、入出力装置３１に接続されてもよい。

クライアント端末３０は、Ｗｅｂブラウザを使用して、要求する業務の登録画面を表示する。本実施形態の例では、クライアント端末３０は、受注登録画面を表示する。受注登録画面には、商品として扱える一覧が表示されてもよい。

クライアント端末３０は、どのような電子機器であってもよく、一例としては、パーソナルコンピュータ、スマートフォン、ＰＤＡ（Personal Digital Assistants）、タブレット型端末、携帯電話、サーバ等が挙げられる。クライアント端末３０は、ＨＭＤ（Head Mount Display）、ＦＭＤ（Face Mount Display）等のウェアラブル機器であってもよい。

ユーザは、受注登録画面に対して、例えば得意先コード（以下、「ＣＤ」と表記する。）、商品ＣＤ、商品数量を入力する。ＡＰサーバ２０は、ユーザが画面から入力したデータ項目を受け付け、特定の業務アプリケーションを実行する。分析装置１０は、ＡＰサーバ２０にて実行された特定の業務アプリケーションの仕様を分析する。

ユーザは、クライアント端末３０の画面に直接、必要なデータ項目を入力してもよいし、クライアント端末３０と通信可能な入出力装置３１を使用して必要なデータ項目を入力してもよい。入出力装置３１は、どのような電子機器であってもよく、スマートフォン、タブレット型端末、ＨＭＤ、ＦＭＤ等であり得る。

（ＡＰサーバのハードウェア構成）
ＡＰサーバ２０は、業務アプリケーションを実行する。ＡＰサーバ２０は、プロセッサ２０１、入力インタフェース（以下、インタフェースを「Ｉ／Ｆ」と表記する。）２０２、通信Ｉ／Ｆ２０３及びメモリ２０４を有する。

メモリ２０４には、動作ログ情報ＤＢ２０５及び業務アプリケーションプログラム群２０６が記憶されている。動作ログ情報ＤＢ２０５は、プロセッサ２０１が実行した業務アプリケーションの動作履歴を示す動作ログ情報を記憶する。動作ログ情報ＤＢ２０５には、業務アプリケーションの実行においてアクセスされるデータベースのアクセス処理のログ情報（動作ログ情報）が含まれている。本実施形態では、業務アプリケーションの実行においてアクセスされるデータベースのアクセス処理の一例として、業務用データベース（以下、データベースを「ＤＢ」と表記する。）３００をアクセスする場合を例に挙げて説明する。

図２は、一実施形態に係る業務用ＤＢ３００の一例を示す。業務用ＤＢ３００には、利用者マスタテーブルＴ１、商品マスタテーブルＴ２、得意先マスタテーブルＴ３、在庫テーブルＴ４、受注明細テーブルＴ５、受注テーブルＴ６、ＥＤＩ（Electronic Data Interchange；電子データ交換）履歴テーブルＴ７等、業務アプリケーションがアクセスする各種テーブルが格納されている。業務用ＤＢ３００は、ＡＰサーバ２０に取り付けられたＨＤＤ（Hard Disk Drive）等の周辺機器に記憶されてもよいし、クラウド上の他のサーバ機器に記憶されてもよい。業務用ＤＢ３００は、リレーショナルデータベース（ＲＤＢ）の一例である。

なお、本実施形態では、動作ログ情報ＤＢ２０５及び業務アプリケーションプログラム群２０６はメモリ２０４に記憶されているが、業務用ＤＢ３００と同様に、ＡＰサーバ２０に取り付けられたＨＤＤ等の周辺機器や、クラウド上の記憶装置に記憶されてもよい。

プロセッサ２０１は、メモリ２０４に記憶された業務アプリケーションプログラム群２０６のうちの所定の業務アプリケーションを実行することで、所定の業務処理を実行する。所定の業務処理には、受注処理、在庫処理、伝票処理等、いかなる業務が含まれていてもよい。

（分析装置のハードウェア構成）
分析装置１０は、所定の業務アプリケーションの仕様を分析する機器である。分析装置１０は、ＣＰＵ（Central Processing Unit）１０１、入力Ｉ／Ｆ１０２、通信Ｉ／Ｆ１０３、表示Ｉ／Ｆ１０４、外部Ｉ／Ｆ１０５及びメモリ１０６を有する。

メモリ１０６には、分析用テーブル１０７、動作ログ抽出テーブル１０８、ＡＰＩ設定テーブル１０９及び分析プログラム１１０が記憶されている。分析用テーブル１０７は、業務アプリケーションの仕様を分析する際に使用する。動作ログ抽出テーブル１０８は、動作ログ情報ＤＢ２０５に蓄積された業務アプリケーションの動作ログ情報のうち、ＡＰサーバ２０から転送された分析対象の動作ログ情報を記憶する。ＡＰＩ設定テーブル１０９は、分析結果、再利用可能なＡＰＩの情報を記憶する。分析プログラム１１０は、分析装置１０が業務アプリケーションの仕様を分析する際に実行するプログラムである。

なお、本実施形態では分析用テーブル１０７、動作ログ抽出テーブル１０８、ＡＰＩ設定テーブル１０９及び分析プログラム１１０はメモリ１０６に記憶されているが、分析装置１０に取り付けられたＨＤＤ等の周辺機器に記憶されてもよいし、クラウド上の記憶装置に記憶されてもよい。

[機能構成]
次に、一実施形態に係るＡＰサーバ２０及び分析装置１０の機能構成の一例について、図３を参照しながら説明する。図３は、一実施形態に係るＡＰサーバ２０及び分析装置１０の機能構成の一例を示す。

（ＡＰサーバの機能構成）
ＡＰサーバ２０は、受付部２１、認証部２２、実行部２３、通信部２４及び記憶部２５を有する。ユーザは、クライアント端末３０に表示したログイン画面からユーザＩＤ及びパスワードを入力する。受付部２１は、入力したユーザＩＤ及びパスワードを受け付け、認証部２２は、受け付けたユーザＩＤ及びパスワードに基づき、正規のユーザであるかを認証する。

正規のユーザである場合、本実施形態の例では、クライアント端末３０は、Ｗｅｂブラウザを使用して受注登録画面を表示する。ただし、表示される画面は、受注登録画面に限らず、他の業務に関する画面であってもよい。

ユーザは、受注登録画面に対して、例えば得意先コード（以下、「ＣＤ」と表記する。）、商品ＣＤ、商品数量を入力する。受付部２１は、ユーザが画面から入力したデータ項目を受け付ける。

実行部２３は、入力したデータ項目のいずれかを引数として業務アプリケーションプログラム群２０６のうち、特定の業務に関するアプリケーションプログラム(以下、「アプリケーション」ともいう。)を呼び出す。例えば、受注処理において、消しゴム及び鉛筆の受注をする場合、ユーザは、伝票明細に消しゴムを１０個、鉛筆を１００個と入力したとする。ＡＰサーバ２０は、入力したデータ項目に対して業務アプリケーションプログラム群２０６のうち、受注の業務アプリケーションを実行する。実行した結果、消しゴム１０個、鉛筆１００個という２つの受注明細が書かれた伝票が登録される。

このとき、ＡＰサーバ２０のプロセッサ２０１は、業務アプリケーションプログラム群２０６の中から受注業務アプリケーションを選び、実行する。実行部２３は、受注業務アプリケーションの実行により行われる受注処理において業務用ＤＢ３００にアクセスし、業務用ＤＢ３００の受注明細テーブルＴ５及び受注テーブルＴ６から必要な情報を読み出したり、受注明細テーブルＴ５及び受注テーブルＴ６を更新（書き込む）したりする動作が実行される。

例えば、受注処理において、使用される伝票本体が示す「受注」と伝票に書かれている内容を示す「受注明細」とは組になって扱われる。よって、受注処理において業務用ＤＢ３００にアクセスするとき、図２に示す受注テーブルＴ６と受注明細テーブルＴ５とは組になってアクセスされる。

このように、データベースのアクセス処理では、組にして同時に更新しなければならないテーブルが存在する。よって、特定の処理の場合、一方のテーブルのみにアクセスすることは、データの不整合が生じるためにできず、両方のテーブルにアクセスする必要がある。本実施形態では、以上のようにユーザによって画面入力されたデータ項目に基づき行われる処理の一連の流れを業務機能として定義し、この業務機能で利用される画面の集合をユーザからの主な入力とする。実行部２３は、ユーザによって画面入力されたデータ項目に基づき特定される業務アプリケーションを実行する。実行部２３は、ＥＤＩ受信によるデータ項目に基づき特定される業務アプリケーションを実行してもよい。

通信部２４は、クライアント端末３０又は分析装置１０と通信する。通信部２４は、複数のクライアント端末３０と通信することができる。

本実施形態では、予め、分析対象の業務アプリケーションに、ＳＱＬとスタックトレースを抽出するプローブを設置する。例えば業務アプリケーションがＪａｖａ（登録商標）で実装されている場合、プローブの設置には、公知のBytecode Injection技術を用いることができ、データベースアクセスを行う時に動作ログ情報を出力するようにバイトコードを変更する。例えば次の文献に記述されている方法が適用可能である。Cleve, Hainaut, "Dynamic Analysis of SQL Statements for Data-Intensive Applications Reverse Engineering", 2008.
プローブの設置により、業務アプリケーションにおいて、画面入力などをきっかけにして業務機能実行単位を実行するごとに、データベース（業務用ＤＢなど）に対して発行したＳＱＬ文と、スタックトレース(stack trace)からなる動作ログ情報が取得可能となる。スタックトレースは、ＳＱＬ文を発行したメソッドからメソッドの呼び出し関係をさかのぼったメソッド名一覧である。

ある業務機能実行単位で発行されたＳＱＬ文の列(ＳＱＬ列)を識別する手段としては、例えば業務アプリケーションがＪａｖａで実装されている場合は同一のスレッドＩＤで発行されたＳＱＬをその発行順にまとめることで識別できる。

記憶部２５は、動作ログ情報ＤＢ２０５を有する。実行部２３は、業務アプリケーション実行時に、業務アプリケーションに設置したプローブを用いて、ユーザの画面入力又はＥＤＩ受信ごとに発行されるＳＱＬ列とスタックトレースからなる動作ログ情報を抽出し、動作ログ情報ＤＢ２０５に記憶する。ＡＰサーバ２０は、動作ログ情報ＤＢ２０５にある程度蓄積された動作ログ情報を分析装置１０に一括して転送してもよいし、動作ログ情報が生成される度に分析装置１０に転送してもよい。

図４〜図６に、一実施形態に係る動作ログ情報を格納する動作ログ情報ＤＢ２０５内の実行テーブルの一例を示す。図４〜図６には、業務アプリケーション実行中に行われたデータベースアクセス処理において、動作ログ情報ＤＢ２０５に格納された所定のテーブルをアクセスしたときの動作ログ情報の一例を示す。動作ログ情報は、業務アプリケーションの画面ないしＥＤＩ受信の実行を単位とし、ＳＱＬとスタックトレースからなる。図４〜図６の例では、６回分の実行１〜６にかかる動作ログ情報を記憶した６つの実行テーブルが示されている。

なお、図４〜図６の例では、スタックトレースはＤＢアクセス用ライブラリ（ｆ．Ｄａｏクラス）を実行したときに取得した場合を示し、データベースドライバに関するスタックトレースは省略する。スタックトレースはクラス名＃メソッド名の並びで表記し、データベースアクセス側から呼び出し元への順に並んでいる。

以上に説明した機能構成のうち、受付部２１の機能は、例えば図１の入力Ｉ／Ｆ２０２により実現可能である。認証部２２の機能は、例えばプロセッサ２０１が所定の認証プログラムを実行することで実現可能である。実行部２３の機能は、例えばプロセッサ２０１が業務アプリケーションプログラム群２０６のうちの特定の業務アプリケーションを実行することで実現可能である。通信部２４の機能は、例えば通信Ｉ／Ｆ２０３により実現可能である。記憶部２５の機能は、例えばメモリ２０４により実現可能である。

（分析装置の機能構成）
分析装置１０は、取得部１１、解析部１２、第１の抽出部１３、第２の抽出部１４、設定部１５、表示処理部１６、通信部１７及び記憶部１８を有する。取得部１１は、業務アプリケーションの実行においてアクセスされるデータベースのアクセス処理の動作ログ情報を取得する。本実施形態では、取得部１１は、ＡＰサーバ２０から転送された、動作ログＤＢ２０５に蓄積された動作ログ情報を取得する。解析部１２は、業務機能毎に業務の実行状態を解析する。

第１の抽出部１３は、動作ログ情報に基づき、業務用ＤＢ３００のアクセス処理において連続する処理のうちの一部分であって、重複して実行される処理部分を抽出する。第１の抽出部１３は業務用ＤＢ３００のアクセス処理の連続する処理のうちの一部分が、所定の閾値以上一致する場合、前記重複して実行される処理部分として抽出してもよい。

第２の抽出部１４は、抽出した、重複して実行される処理部分に含まれる処理のそれぞれを呼び出すメソッドを抽出する。

設定部１５は、抽出したメソッドから更新されるテーブルのうち、前記重複して実行される処理部分に含まれる処理のそれぞれを実行したときに更新されるテーブル以外の他のテーブルを更新しないメソッドに、ＡＰＩ（Application Program Interface）を設定し、本システムの内部及び外部から利用可能とする。

表示処理部１６は、分析結果を表示する処理を行う。表示処理部１６は、設定したＡＰＩをＷｅｂブラウザ等を用いてクライアント端末３０のディスプレイ等に表示し、ユーザに利用可能とする。通信部１７は、ＡＰサーバ２０及びクライアント端末３０と通信する。

記憶部１８は、分析した情報を分析用テーブル１０７に記憶する。また、記憶部１８は、ＡＰサーバ２０から転送された動作ログ情報を記憶する。また、記憶部１８は、分析の結果、設定部１５が設定したＡＰＩに関する情報を記憶する。さらに、記憶部１８は、所定の業務アプリケーションの仕様を分析するための分析プログラム１１０を記憶する。

以上に説明した機能構成のうち、取得部１１の機能は、例えば図１の入力Ｉ／Ｆ１０２により実現可能である。解析部１２、第１の抽出部１３、第２の抽出部１４及び設定部１５の機能は、例えばＣＰＵ１０１が分析プログラム１１０を実行することで実現可能である。表示設定部１６の機能は、例えば表示Ｉ／Ｆ１０４により実現可能である。通信部１７の機能は、例えば通信Ｉ／Ｆ１０３により実現可能である。記憶部１８の機能は、例えばメモリ１０７により実現可能である。

本実施形態に係るシステムでは、画面ないしＥＤＩ受信の実行を一単位として、単位毎に発行されたＳＱＬ列から重複して実行される部分ＳＱＬ命令列(以下、「部分ＳＱＬ列」ともいう。)を抽出し、部分ＳＱＬ列をまとめて実行する共通の親メソッドを、スタックトレースを用いて抽出する。この親メソッドが、部分ＳＱＬ列でアクセスするテーブル以外を更新しないとき、この親メソッドを再利用の候補とし、ＡＰＩを設置する。

部分ＳＱＬ列とは、業務アプリケーションから特定の業務の塊で実行される処理部分をいい、２個以上のＳＱＬから構成され、どういうＳＱＬが連続して実行されるかを示す。言い換えれば、部分ＳＱＬ列とは、データベースアクセス処理の連続する処理のうちの一部分であって、特定の業務の塊で実行される処理部分をいう。親メソッドとは、部分ＳＱＬ列のそれぞれを呼び出すメソッドをいう。つまり、部分ＳＱＬ列に含まれるすべてのＳＱＬは、同じ親メソッドから呼び出される関係にある。

［分析処理］
次に、本実施形態に係る分析処理について説明する。本実施形態では、Ｊａｖａで実装された業務アプリケーションを想定し、あるメソッドがデータベースにアクセスしたときに、ＳＱＬ文とメソッドでのスタックトレースを取得するプローブを設定しておく。また、業務アプリケーションが用いるテーブル名Ｔ１〜Ｔ７・・・が持つカラム名を図２に示す。テーブル名は、テーブルの業務的な意味を示す。

本実施形態に係る分析処理の一例について図７を参照して説明する。図７は、一実施形態に係る分析処理の一例を示したフローチャートである。以下の処理は、分析装置１０により実行される。

本処理が開始されると、取得部１１は、ＡＰサーバ２０から画面毎のＳＱＬ列とスタックトレースを有する動作ログ情報を取得する（ステップＳ１）。次に、解析部１２は、取得したＳＱＬを解析し、第１の抽出部１３は、取得したＳＱＬ文間の類似度を判断し、類似しているＳＱＬ文はそれらを代表とするＳＱＬ文と置き換え、代表ＳＱＬ列を作る（ステップＳ２）。

次に、第１の抽出部１３は、代表ＳＱＬ列から重複部分を示す冗長部分を削除する（ステップＳ３）。次に、第１の抽出部１３は、得られた重複のない、つまり、冗長を削除した代表ＳＱＬ列から２個以上のＳＱＬが連続する部分ＳＱＬ列を抽出する（ステップＳ４）。

次に、第２の抽出部１４は、部分ＳＱＬ列ごとに、ステップＳ６以降の処理を繰り返し実行する（ステップＳ５）。ステップＳ６〜Ｓ７では、第２の抽出部１４は、動作ログ抽出テーブル１０８に格納された動作ログ情報のうち、部分ＳＱＬ列に対応するＳＱＬ列を用いて、ＳＱＬに対応するスタックトレースを検索する。このとき、第２の抽出部１４は、それらに共通して最初に現れる（ライブラリではなく）業務アプリケーションのメソッド（親メソッド）を検出する。業務アプリケーションのメソッドであるか否かは、例えば業務アプリケーションで用いるpackage名やnamespace名をあらかじめ与えておき、あるメソッドが属するクラスが上記のpackage名やnamespace名から始まるものか否かにより判断できる。

次に、第２の抽出部１４は、検出した親メソッドがＡＰＩ設定候補か否かを判定する（ステップＳ８）。例えば、第２の抽出部１４は、検出した親メソッドが１つだけ存在する場合は、その親メソッドがＡＰＩ設定候補であると判定する。

ある部分ＳＱＬ列に対して、対応する複数の親メソッドが検出されている場合、同じ部分ＳＱＬ列を異なる実装部分で発行することを意味する。この場合、第２の抽出部１４は、部分ＳＱＬ列が同じなので、類似した業務処理をしていると推定する。このとき、どのメソッドがＡＰＩ設定に適切かはユーザが別途検討・判断を行い、いずれかを選択するようにしてもよい。この場合、第２の抽出部１４は、選択された親メソッドがＡＰＩ設定候補であると判定してもよい。

ステップＳ８において、第２の抽出部１４は、親メソッドがＡＰＩ設定候補でないと判定した場合、すべての部分ＳＱＬ列についてステップＳ５以降の処理が終了した場合には、本処理を終了する。一方、すべての部分ＳＱＬについてステップＳ５以降の処理が終了していない場合には、ステップＳ５に戻り、ステップＳ以降の処理を繰り返す。

第２の抽出部１４は、親メソッドがＡＰＩ設定候補であると判定した場合、部分ＳＱＬ列の各ＳＱＬをｐａｒｓｅ（静的解析）し、アクセス対象となるテーブル名とアクセス種別（ＣＲＵＤ；Create/Read/Update/Delete）を抽出する（ステップＳ９）。

次に、第２の抽出部１４は、部分ＳＱＬ列以外のＳＱＬのスタックトレースのうち、上記で検出した親メソッドを含むものを選択する（ステップＳ１０）。これは親メソッドを実行するときに、着目部分ＳＱＬ列以外の他のＳＱＬも実行することを意味する。

次に、設定部１５は、そのＳＱＬ実行で書き込み（Ｃ／Ｕ／Ｄ）アクセスされるテーブルが上記の部分ＳＱＬ列でアクセスするテーブルであるかを判定する（ステップＳ１１）。設定部１５は、ＳＱＬが部分ＳＱＬ列でアクセスするテーブル以外には書き込まないと判定した場合、このメソッドを実行しても部分ＳＱＬ列がアクセスするテーブル以外に影響を及ぼさないため、この親メソッドを呼び出すＡＰＩを設定する（ステップＳ１２）。

ＡＰＩは、例えばＲＥＳＴを用い、親メソッドのソースコードから引数と戻り値を抽出し、例えばそれらのＪＳＯＮ形式をそれぞれＡＰＩの入力と出力とする。ＡＰＩが実行されるとＪＳＯＮ形式のデータをオブジェクトに変換し、親メソッドの引数として実行し、戻り値をＪＳＯＮ形式に変換したものをＡＰＩの戻り値として返す。

なお部分ＳＱＬ列毎の処理は、例えば部分ＳＱＬ列の出現回数の多い順に優先して行ってもよい。以上の処理を、ステップＳ４にて抽出した部分ＳＱＬ列のそれぞれについて行った後、本処理を終了する。

［類似度判定処理］
次に、図７のステップＳ２で実行する本実施形態に係る類似度の判定処理の一例について図８を参照して説明する。図８は、一実施形態に係る類似度判定処理の一例を示したフローチャートである。

類似度判定処理では、解析部１２は、ＳＱＬ文にリテラルが含まれている場合、それをバインド変数（：１など）に置換する（ステップＳ２１）。例えば、ＳＱＬ文が{SELECT A,B FROM T1 WHERE A=10 AND B=20}の場合、バインド変数（:1、:2）にて、{SELECT A,B FROM T1 WHERE A=:1 AND B=:2}と置き換えてもよい。バインド変数（?）にて、{SELECT A,B FROM T1 WHERE A=? AND B=?}と置き換えてもよい。

次に、解析部１２は、取得した動作ログ情報に含まれるＳＱＬ文を種類（ＳＥＬＥＣＴ／ＩＮＳＥＲＴ／ＵＰＤＡＴＥ／ＤＥＬＥＴＥ）ごとに分類し（ステップＳ２２）、分類した種類毎にそれぞれ以下の処理を実行する（ステップＳ２３）。

まず、解析部１２は、クラスタを格納する領域を生成する（ステップＳ２４）。次に、解析部１２は、ＳＱＬ文ごとに、ＳＱＬ文をスペース、「，」、「（」、「）」で区切り、ＳＱＬ文内の単語の集合を抽出する（ステップＳ２５）。このとき、解析部１２は、同一単語は１個のみ抽出する。解析部１２は、クラスタが存在するかを判定する（ステップＳ２６）。解析部１２は、クラスタがまだ登録されていないときは、クラスタが存在しないと判定し、新たにクラスタを作成し、ＳＱＬと対応する単語の集合を登録し（ステップＳ２７）、ステップＳ２８に進む。一方、解析部１２は、クラスタが登録されているときは、クラスタが存在すると判定し、そのままステップＳ２８に進む。ステップＳ２８では、ステップＳ２９〜Ｓ３２の処理をすべてのクラスタについて、クラスタ毎に繰り返し実行する。

つまり、解析部１２は、クラスタ内のＳＱＬ毎に、当該ＳＱＬの単語の一致する個数を勘定し、単語の一致数と単語の個数の大きい方との比の最大値を計算する（ステップＳ２９）。第１の抽出部１３は、最大値が予め定められている閾値（例えば０．９５）以上と判定した場合、当該ＳＱＬは類似していると判定し、当該ＳＱＬはそのクラスタに属すると判断し追加する。一方、第１の抽出部１３は、最大値が閾値未満と判定した場合、新たにクラスタを作成し、当該ＳＱＬと単語の集合を登録する。

例えば、図４に示す動作ログ情報のうち、動作ログ情報のログ１とログ２の類似度計算を行う場合を示す。ログ１とログ２のＳＱＬをそれぞれ単語に分解すると、次のような単語の集合になる。
ログ１のＳＱＬの単語＝{SELECT,*,FROM,T1,WHERE,ユーザID,=,:1}
ログ２のＳＱＬの単語＝{SELECT,*,FROM,T2,WHERE,商品名,LIKE,:1}
このとき両者に共通する単語が５個、単語数の多い方が８個であるため、類似度は次のように計算される。
類似度=５／ｍａｘ（８，８）＝０．６２５
閾値を０．９５とすると、ログ１とログ２のＳＱＬの類似度は閾値未満であるため、類似していないと判断されるので、ログ１とログ２のＳＱＬは別のクラスタに属する。これをすべてのログについて行うと図９のように１０個のクラスタに分割される。各クラスタを代表する代表ＳＱＬのＩＤとして、各クラスタに含まれるログ＃の最小値を使うことにする。

なお、類似度を計算するときに、ＳＱＬ文内に出現する単語をテーブル名とそれ以外に分類し、テーブル名が一致した場合には重みを多くしてもよい。

全てのクラスタについてのステップＳ２８の繰り返し処理後、第１の抽出部１３は、クラスタごとに、例えば一番初めに登録したＳＱＬを代表ＳＱＬに選出し（ステップＳ３３）、本処理を終了する。

以上、本実施形態に係る類似度の判定処理について説明した。図４〜図６に示す実行１〜６の動作ログ情報について、本実施形態に係る類似度の判定方法により類似度を判定した結果を図９に示す。分析用テーブル１０７には、１０個のＳＱＬクラスタが生成される。各ＳＱＬクラスタには、完全一致又は類似（すなわち閾値以上一致）する動作ログ情報が振り分けられている。また、代表ＳＱＬには、各ＳＱＬクラスタに属する動作ログ情報のうちの一番初めに登録された動作ログ情報が選択されている。図９では、動作ログ情報の一例として動作ログのＩＤが示されている。

［冗長部分の削除処理］
次に、図７のステップＳ３で実行する本実施形態に係る冗長部分の削除処理の一例について図１０を参照して説明する。図１０は、一実施形態に係る冗長部分の削除処理の一例を示したフローチャートである。

冗長部分の削除処理では、ステップＳ４１〜Ｓ４７の処理を、すべての代表ＳＱＬ列について、代表ＳＱＬ列毎に繰り返し実行する（ステップＳ４０）。まず、第１の抽出部１３は、ＳＱＬを代表ＳＱＬで置換したものを対象に、同じ代表ＳＱＬが連続する部分を１個だけに置換する。図１１（Ａ）の「ＳＱＬ列を代表ＳＱＬで置換」した分析用テーブル１０７には、図９の動作ログ情報のＩＤを代表ＳＱＬの動作ログ情報のＩＤで置換した結果を示す。

次に、第１の抽出部１３は、代表ＳＱＬ列の繰り返し部分を探すため、部分列の長さＬを、代表ＳＱＬ列の長さ／２から２まで、長い方から順にステップＳ４３〜Ｓ４７を繰り返し実行する。

ステップＳ４３において、開始点を１から代表ＳＱＬ列の長さ／２まで変化させたとき、第１の抽出部１３は、開始点から長さＬのＳＱＬ列と、（開始点＋Ｌ）から長さＬのＳＱＬ列が同じか比較する(ステップＳ４４)。第１の抽出部１３は、同じであると判定した場合、繰り返し部分を削除する(ステップＳ４５)。この処理を開始点を１から代表ＳＱＬ列の長さ／２まで変化させて繰り返し行う。

例えば、図１１（Ａ）の例では、 動作ログ情報８〜１８に対応する代表ＳＱＬのＩＤ（１，３，１０，１０，１２，１３，１４，１２，１３，１４，１８）では「１０」が連続していることが検出される。この重複を削除した結果を、図１１（Ｂ）の「連続する代表ＳＱＬを削除」に示す。

ステップＳ４３〜Ｓ４７を繰り返し実行した後、第１の抽出部１３は、冗長部分を削除した結果、ある代表部分ＳＱＬ列が他の代表部分ＳＱＬ列と同一になった場合は、どちらかの代表ＳＱＬ列を削除し(ステップＳ４７)、本処理を終了する。

例えば、図１１（Ｂ）の「連続する代表ＳＱＬを削除」に示す動作ログ情報８〜１８と動作ログ情報２５〜３５ではそれぞれ（１２，１３，１４）が繰り返されていることが検出される。よって、この繰り返しが削除される。その結果を、図１１（Ｃ）の「繰り返し部分の代表ＳＱＬを削除」した後の分析用テーブル１０７に示す。

その結果、図１１（Ｃ）の「繰り返し部分の代表ＳＱＬを削除」の動作ログ情報３６〜４０は動作ログ情報２５〜３５と同じ代表ＳＱＬを持つ。よって、ある代表部分ＳＱＬ列が他の代表部分ＳＱＬ列と同一になった場合は、どちらかの代表ＳＱＬ列を削除する。本実施形態では、動作ログ情報３６〜４０を削除した結果を、図１２（Ｄ）の「同一代表ＳＱＬ列を削除」に示す。図１２（Ｄ）では、分析用テーブル１０７から、動作ログ情報３６〜４０が削除されている。

［部分ＳＱＬ列生成処理］
次に、図７のステップＳ４で実行する本実施形態に係る部分ＳＱＬ列生成処理の一例について図１３を参照して説明する。図１３は、一実施形態に係る部分ＳＱＬ列生成処理の一例を示したフローチャートである。

部分ＳＱＬ列生成処理では、まず、第１の抽出部１３は、冗長部分を削除した代表ＳＱＬ列のうち、最も長い長さをＬｍａｘとする（ステップＳ５０）。例えば、図１２（Ｄ）では、代表ＳＱＬ列のうち、最も長い長さを示すＬｍａｘに「７」が設定される。

次に、第１の抽出部１３は、長さＬをＬｍａｘから２までとし、ステップＳ５２及びＳ５３を繰り返し実行する(ステップＳ５１)。第１の抽出部１３は、代表ＳＱＬ列から長さＬの部分ＳＱＬ列を抽出し(ステップＳ５２)、抽出した部分ＳＱＬ列がすべての代表ＳＱＬ列で何カ所存在するかを勘定する(ステップＳ５３)。長さＬをＬｍａｘから２まで繰り返し実行した後、本処理を終了する。

図１２（Ｄ）に示した冗長性を削除した代表ＳＱＬ列を用い、部分ＳＱＬ列の長さごとに部分ＳＱＬ列を生成してその発生回数を勘定した結果を図１４に示す。図１２（Ｄ）で最も長い代表ＳＱＬ列は７なので、部分ＳＱＬ列の長さを７から開始すると、動作ログ情報８〜１８の（１，３，１０，１２，１３，１４，１８）の発生回数は１回と勘定される。部分ＳＱＬ列の長さを６に設定すると、動作ログ情報８〜１８と動作ログ情報１９〜２４に（３，１０，１２，１３，１４，１８）が計２回存在する。よって、この場合、分析用テーブル１０７の発生回数は２となる。以下同様に部分ＳＱＬ列の長さを２まで行う。なお、図１４では部分ＳＱＬ列の長さ３以降の結果は省略する。

以上の処理を実行した後、第２の抽出部１４は、抽出した部分ＳＱＬ列に対応するＳＱＬ列を用いて、図７のステップＳ７の処理を実行する。例えば、発生回数が３回だった部分ＳＱＬ列（１２，１３，１４，１８）を例に、親メソッドの選択の具体例を説明する。前もって、業務アプリケーションで用いられるｐａｃｋａｇｅ名は"ｆ"であることを把握していると仮定する。

上記部分ＳＱＬ列の代表ＳＱＬに対応する元の動作ログ情報でのスタックトレースを図１５に示す。部分ＳＱＬ列を生成する際に繰り返しなど冗長部分を削除しているため、当該部分ＳＱＬ列に対応する元の動作ログ情報はログ１２〜１８、ログ２１〜２４、ログ２５〜３４、ログ３６〜３９の４個の列に対応する。

スタックトレースは直近に実行されたメソッドが一番左に、それを呼び出したメソッドが右になるよう並べられている。第２の抽出部１４は、業務アプリケーションのメソッドのうち、すべてに出現する最初のメソッドとして、図１５のＰに示す「ｆ．Ｒｅｇｉｓｔｅｒ．Ｈｅａｄｅｒ＃伝票登録」を抽出し、これを親メソッドとして選択する。

第２の抽出部１４は、検出した親メソッドが１つだけ存在する場合は、その親メソッドがＡＰＩ設定候補であると判定し、呼び出す部分ＳＱＬ列の各ＳＱＬがアクセスするテーブル名とアクセス種別を抽出する。部分ＳＱＬ列（１２，１３，１４，１８）がアクセスするテーブルとＣＲＵＤを、対応するＳＱＬをｐａｒｓｅして抽出した結果を図１６のＡＰＩ設定テーブル１０９に示す。これによれば、親メソッドが呼び出す各ＳＱＬによってテーブルＴ４、Ｔ５、Ｔ６が更新されることが分かる。

一方、「ｆ．Ｒｅｇｉｓｔｅｒ．Ｈｅａｄｅｒ＃伝票登録」をスタックトレースに持つＳＱＬは、図５と図６に示す実行３〜６に対応する動作ログ情報に存在するが、図１６のＡＰＩ設定テーブル１０９に示すテーブルＴ４、Ｔ５、Ｔ６以外には変更を行わない。

よって、この場合、図７のステップＳ１１に示すように、親メソッドから実行されるＳＱＬが、部分ＳＱＬ列がアクセスするテーブル以外にも書き込むか否かの判定において、「ＮＯ」と判定される。以上より、抽出された親メソッドはＡＰＩの設定先として適当であると判断される。つまり、選択された親メソッドが呼び出す部分ＳＱＬ列は、共通で良く使われているＳＱＬであり、その部分ＳＱＬ列のそれぞれがアクセスするテーブルは、親メソッドの対象業務の性質からまとめてアクセスされるテーブルを含み、かつ、部分ＳＱＬ列を実行したときに想定外のテーブルが書き換わらないという条件を満たす。よって、このような条件を満たす親メソッドに対して、他社の再利用可能なようにＡＰＩが設定される。

なお、本発明で得られる親メソッドで実行される業務機能には、業務を利用する際に必要となる認証機能やａｕｄｉｔ（監査）記録機能が含まれない可能性がある。そのため、ＡＰＩは、外部サービス用の認証機能やａｕｄｉｔ機能と本発明で得られる業務機能を組み合わせて使う。

以上に説明したように、一実施形態に係るシステムによれば、プログラム内に存在する再利用可能な範囲を特定することができる。これにより、従来手段では把握が困難であった、業務アプリケーションの内部のみで使われていた機能にＡＰＩを追加して、別機能から再利用することを可能にする。

以上、分析装置、分析プログラム及び分析方法を上記実施形態により説明したが、本発明に係る分析装置、分析プログラム及び分析方法は上記実施形態に限定されるものではなく、本発明の範囲内で種々の変形及び改良が可能である。また、上記実施形態及び変形例が複数存在する場合、矛盾しない範囲で組み合わせることができる。

例えば、上記実施形態では、複数の部分ＳＱＬが抽出され得る。抽出された複数の部分ＳＱＬのうち、どの部分ＳＱＬを採用するかは、出現回数の多い順に優先してもよい。また、他には、例えば、「受注」に関してＡＰＩを追加したい場合には、「受注」に使用されているテーブルは、システム開発者であれば用語等から分かるので、そのテーブルを使っているオブジェクトやメソッドを探すことは本件の方法を使えば簡単にできる。このようにして抽出した親メソッドを優先してもよい。

上記実施形態では、リレーショナルデータベース（ＲＤＢ）を例に挙げて、データベースアクセス処理について説明したが、本発明に係るシステムは、これに限らず、あらゆるデータベースに対して適用可能である。

以上の説明に関し、更に以下の項を開示する。
（付記１）
所定の業務アプリケーションの仕様を分析する分析装置であって、
業務アプリケーションの実行においてアクセスされるデータベースのアクセス処理のログ情報を取得する取得部と、
前記ログ情報に基づき、前記データベースのアクセス処理において連続する処理のうちの一部分であって、重複して実行される処理部分を抽出する第１の抽出部と、
抽出した前記重複して実行される処理部分に含まれる処理のそれぞれを呼び出すメソッドを抽出する第２の抽出部と、
抽出した前記メソッドから更新されるテーブルのうち、前記重複して実行される処理部分に含まれる処理のそれぞれを実行したときに更新されるテーブル以外の他のテーブルを更新しないメソッドに、ＡＰＩ（Application Program Interface）を設定し、利用可能とする設定部と、
を有する分析装置。
（付記２）
前記第１の抽出部は、前記データベースのアクセス処理において連続する処理のうちの一部分が、所定の閾値以上一致する場合、前記重複して実行される処理部分として抽出する、
付記１に記載の分析装置。
（付記３）
所定の業務アプリケーションの仕様を分析する処理をコンピュータに実行させるための分析プログラムであって、
業務アプリケーションの実行においてアクセスされるデータベースのアクセス処理のログ情報を取得する処理と、
前記ログ情報に基づき、前記データベースのアクセス処理において連続する処理のうちの一部分であって、重複して実行される処理部分を抽出する処理と、
抽出した前記重複して実行される処理部分に含まれる処理のそれぞれを呼び出すメソッドを抽出する処理と、
抽出した前記メソッドから更新されるテーブルのうち、前記重複して実行される処理部分に含まれる処理のそれぞれを実行したときに更新されるテーブル以外の他のテーブルを更新しないメソッドに、ＡＰＩ（Application Program Interface）を設定し、利用可能とする処理と、を有する分析プログラム。
（付記４）
前記データベースのアクセス処理において連続する処理のうちの一部分が、所定の閾値以上一致する場合、前記重複して実行される処理部分として抽出する、
付記３に記載の分析プログラム。
（付記５）
所定の業務アプリケーションの仕様を分析することをコンピュータが実行する分析方法であって、
業務アプリケーションの実行においてアクセスされるデータベースのアクセス処理のログ情報を取得し、
前記ログ情報に基づき、前記データベースのアクセス処理において連続する処理のうちの一部分であって、重複して実行される処理部分を抽出し、
抽出した前記重複して実行される処理部分に含まれる処理のそれぞれを呼び出すメソッドを抽出し、
抽出した前記メソッドから更新されるテーブルのうち、前記重複して実行される処理部分に含まれる処理のそれぞれを実行したときに更新されるテーブル以外の他のテーブルを更新しないメソッドに、ＡＰＩ（Application Program Interface）を設定し、利用可能とする、分析方法。
（付記６）
前記データベースのアクセス処理において連続する処理のうちの一部分が、所定の閾値以上一致する場合、前記重複して実行される処理部分として抽出する、
付記５に記載の分析方法。

１０ 分析装置
１１ 取得部
１２ 解析部
１３ 第１の抽出部
１４ 第２の抽出部
１５ 設定部
１６ 表示処理部
１７ 通信部
１８ 記憶部
２０ ＡＰサーバ
２１ 受付部
２２ 認証部
２３ 実行部
２４ 通信部
２５ 記憶部
３０ クライアント端末
１０１ ＣＰＵ
１０２ 入力Ｉ／Ｆ
１０３ 通信Ｉ／Ｆ
１０４ 表示Ｉ／Ｆ
１０５ 外部Ｉ／Ｆ
１０６ メモリ
１０７ 分析用テーブル
１０８ 動作ログ抽出テーブル
１０９ ＡＰＩ設定テーブル
１１０ 分析プログラム
２０１ プロセッサ
２０２ 入力Ｉ／Ｆ
２０３ 通信Ｉ／Ｆ
２０４ メモリ
２０５ 動作ログ情報ＤＢ
２０６ 業務アプリケーションプログラム群
３００ 業務用ＤＢ

Claims (4)

1. 所定の業務アプリケーションの仕様を分析する分析装置であって、
   業務アプリケーションの実行においてアクセスされるデータベースのアクセス処理のログ情報を取得する取得部と、
   前記ログ情報に基づき、前記データベースのアクセス処理において連続する処理のうちの一部分であって、重複して実行される処理部分を抽出する第１の抽出部と、
   抽出した前記重複して実行される処理部分に含まれる処理のそれぞれを呼び出すメソッドを抽出する第２の抽出部と、
   抽出した前記メソッドから更新されるテーブルのうち、前記重複して実行される処理部分に含まれる処理のそれぞれを実行したときに更新されるテーブル以外の他のテーブルを更新しないメソッドに、ＡＰＩ（Application Program Interface）を設定し、利用可能とする設定部と、
   を有する分析装置。
2. 前記第１の抽出部は、前記データベースのアクセス処理において連続する処理のうちの一部分が、所定の閾値以上一致する場合、前記重複して実行される処理部分として抽出する、
   請求項１に記載の分析装置。
3. 所定の業務アプリケーションの仕様を分析する処理をコンピュータに実行させるための分析プログラムであって、
   業務アプリケーションの実行においてアクセスされるデータベースのアクセス処理のログ情報を取得する処理と、
   前記ログ情報に基づき、前記データベースのアクセス処理において連続する処理のうちの一部分であって、重複して実行される処理部分を抽出する処理と、
   抽出した前記重複して実行される処理部分に含まれる処理のそれぞれを呼び出すメソッドを抽出する処理と、
   抽出した前記メソッドから更新されるテーブルのうち、前記重複して実行される処理部分に含まれる処理のそれぞれを実行したときに更新されるテーブル以外の他のテーブルを更新しないメソッドに、ＡＰＩ（Application Program Interface）を設定し、利用可能とする処理と、を有する分析プログラム。
4. 所定の業務アプリケーションの仕様を分析することをコンピュータが実行する分析方法であって、
   業務アプリケーションの実行においてアクセスされるデータベースのアクセス処理のログ情報を取得し、
   前記ログ情報に基づき、前記データベースのアクセス処理において連続する処理のうちの一部分であって、重複して実行される処理部分を抽出し、
   抽出した前記重複して実行される処理部分に含まれる処理のそれぞれを呼び出すメソッドを抽出し、
   抽出した前記メソッドから更新されるテーブルのうち、前記重複して実行される処理部分に含まれる処理のそれぞれを実行したときに更新されるテーブル以外の他のテーブルを更新しないメソッドに、ＡＰＩ（Application Program Interface）を設定し、利用可能とする、分析方法。

Images