(57)【要約】【課題】複数のＷｅｂサービスを組み合わせてアプリケーションを構築する際に、全Ｗｅｂサービスの連携関係を分析し得る、情報分析装置、情報分析方法、及びプログラムを提供する。【解決手段】情報分析装置１は、Ｗｅｂサービスの呼び出しに利用可能なライブラリに関する情報を用い、分析対象Ｗｅｂサービスのビジネスロジックから、Ｗｅｂサービスが外部との通信に利用するインタフェース情報２２を抽出するインタフェース情報抽出部１１と、インタフェース情報２２から、呼び出される別のＷｅｂサービスのＷＳＤＬファイル２４を特定するインタフェース検証部１４と、ＷＳＤＬファイル２４を用いて別のＷｅｂサービスの実装プロジェクトを特定し、これを対象として通信コードを検索する通信コード検索部１５と、実装プロジェクトを対象としてビジネスロジックを検索するビジネスロジック検索部１６とを備えている。【選択図】図１
2011014098.tif 000002
【特許請求の範囲】
【請求項１】
Ｗｅｂサービス間の連携関係を分析するための情報分析装置であって、
Ｗｅｂサービスの呼び出しに利用可能なライブラリに関する情報を用いて、分析対象となるＷｅｂサービスのビジネスロジックから、前記分析対象となるＷｅｂサービスが外部との通信に利用するインタフェース情報を抽出する、インタフェース情報抽出部と、
抽出された前記インタフェース情報に基づいて、前記分析対象となるＷｅｂサービスから呼び出される前記別のＷｅｂサービスのＷＳＤＬファイルを特定する、インタフェース検証部と、
特定された前記ＷＳＤＬファイルを用いて、前記別のＷｅｂサービスの実装プロジェクトを特定し、特定した前記実装プロジェクトに対して通信コードの検索を行う、通信コード検索部と、
特定された前記実装プロジェクトに基づき、前記別のＷｅｂサービスのビジネスロジックを検索する、ビジネスロジック検索部と、
を備えている、ことを特徴とする情報分析装置。
【請求項２】
前記ライブラリに関する情報が、前記ライブラリのパッケージ構成を特定する情報と、前記ライブラリの設定情報とを含み、
前記ライブラリの設定情報が、更に、前記ライブラリを用いて生成されるソースコードの命名規則、及び前記ソースコードに付与されるコメントを少なくとも含む、請求項１に記載の情報分析装置。
【請求項３】
前記通信コード検索部が、前記ライブラリの設定情報に基づいて、前記実装プロジェクトに対して通信コードの検索を行う、請求項２に記載の情報分析装置。
【請求項４】
前記ビジネスロジック判定部が、特定された前記実装プロジェクトがビジネスロジックの実装コードを含まない場合に、ビジネスロジックのソースコード、又はビジネスロジックの候補となるバイナリコードを検索する、請求項１〜３のいずれかに記載の情報分析装置。
【請求項５】
前記分析対象となるＷｅｂサービスによって呼び出される全てのＷｅｂサービスを特定し、前記分析対象となるＷｅｂサービス及び前記全てのＷｅｂサービスにおけるＷｅｂサービス間の呼び出し関係を管理する、呼出関係管理部を更に備えている、請求項１〜４のいずれかに記載の情報分析装置。
【請求項６】
前記インタフェース情報抽出部が、前記ビジネスロジック検索部によって検索されたビジネスロジックから、更に、前記呼び出されるＷｅｂサービスが外部との通信に利用するインタフェース情報を抽出する、請求項１〜５のいずれかに記載の情報分析装置。
【請求項７】
Ｗｅｂサービス間の連携関係を分析するための情報分析方法であって、
（ａ）Ｗｅｂサービスの呼び出しに利用可能なライブラリに関する情報を用いて、分析対象となるＷｅｂサービスのビジネスロジックから、前記分析対象となるＷｅｂサービスが外部との通信に利用するインタフェース情報を抽出する、ステップと、
（ｂ）前記（ａ）のステップで抽出された前記インタフェース情報に基づいて、前記分析対象となるＷｅｂサービスから呼び出される前記別のＷｅｂサービスのＷＳＤＬファイルを特定する、ステップと、
（ｃ）前記（ｂ）のステップで特定された前記ＷＳＤＬファイルを用いて、前記別のＷｅｂサービスの実装プロジェクトを特定し、特定した前記実装プロジェクトに対して通信コードの検索を行う、ステップと、
（ｄ）前記（ｃ）のステップで特定された前記実装プロジェクトに基づき、前記別のＷｅ
ｂサービスのビジネスロジックを検索する、ステップと、
を有する、ことを特徴とする情報分析方法。
【請求項８】
前記ライブラリに関する情報が、前記ライブラリのパッケージ構成を特定する情報と、前記ライブラリの設定情報とを含み、
前記ライブラリの設定情報が、更に、前記ライブラリを用いて生成されるソースコードの命名規則、及び前記ソースコードに付与されるコメントを少なくとも含む、請求項７に記載の情報分析方法。
【請求項９】
前記（ｃ）のステップにおいて、前記ライブラリの設定情報に基づいて、前記実装プロジェクトに対して通信コードの検索を行う、請求項８に記載の情報分析方法。
【請求項１０】
前記（ｄ）のステップにおいて、前記（ｃ）のステップで特定された前記実装プロジェクトがビジネスロジックの実装コードを含まない場合に、ビジネスロジックのソースコード、又はビジネスロジックの候補となるバイナリコードを検索する、請求項７〜９のいずれかに記載の情報分析方法。
【請求項１１】
（ｅ）前記分析対象となるＷｅｂサービスと、それによって呼び出されるＷｅｂサービスとの関係を特定する呼出リストを生成する、ステップを更に備えている、請求項７〜１０のいずれかに記載の情報分析方法。
【請求項１２】
前記（ａ）〜（ｅ）のステップの実行後に、前記（ｄ）のステップによって検索されたビジネスロジックを対象として、再度、前記（ａ）〜（ｅ）のステップを実行する、請求項１１に記載の情報分析方法。
【請求項１３】
Ｗｅｂサービス間の連携関係の分析を、コンピュータによって実行するためのプログラムであって、
前記コンピュータに、
（ａ）Ｗｅｂサービスの呼び出しに利用可能なライブラリに関する情報を用いて、分析対象となるＷｅｂサービスのビジネスロジックから、前記分析対象となるＷｅｂサービスが外部との通信に利用するインタフェース情報を抽出する、ステップと、
（ｂ）前記（ａ）のステップで抽出された前記インタフェース情報に基づいて、前記分析対象となるＷｅｂサービスから呼び出される前記別のＷｅｂサービスのＷＳＤＬファイルを特定する、ステップと、
（ｃ）前記（ｂ）のステップで特定された前記ＷＳＤＬファイルを用いて、前記別のＷｅｂサービスの実装プロジェクトを特定し、特定した前記実装プロジェクトに対して通信コードの検索を行う、ステップと、
（ｄ）前記（ｃ）のステップで特定された前記実装プロジェクトに基づき、前記別のＷｅｂサービスのビジネスロジックを検索する、ステップと、
を実行させる、ことを特徴とするプログラム。
【請求項１４】
前記ライブラリに関する情報が、前記ライブラリのパッケージ構成を特定する情報と、前記ライブラリの設定情報とを含み、
前記ライブラリの設定情報が、更に、前記ライブラリを用いて生成されるソースコードの命名規則、及び前記ソースコードに付与されるコメントを少なくとも含む、請求項１３に記載のプログラム。
【請求項１５】
前記（ｃ）のステップにおいて、前記ライブラリの設定情報に基づいて、前記実装プロジェクトに対して通信コードの検索を行う、請求項１４に記載のプログラム。
【請求項１６】
前記（ｄ）のステップにおいて、前記（ｃ）のステップで特定された前記実装プロジェクトがビジネスロジックの実装コードを含まない場合に、ビジネスロジックのソースコード、又はビジネスロジックの候補となるバイナリコードを検索する、請求項１３〜１５のいずれかに記載のプログラム。
【請求項１７】
（ｅ）前記分析対象となるＷｅｂサービスと、それによって呼び出されるＷｅｂサービスとの関係を特定する呼出リストを生成する、ステップを、更に前記コンピュータに実行させる、請求項１３〜１６のいずれかに記載のプログラム。
【請求項１８】
前記（ａ）〜（ｅ）のステップの実行後に、前記コンピュータに、前記（ｄ）のステップによって検索されたビジネスロジックを対象として、再度、前記（ａ）〜（ｅ）のステップを実行させる、請求項１７に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂサービス間の連携関係の分析に用いられる、情報分析装置、情報分析方法、及びこれらを実現するためのプログラムに関する。
【背景技術】
【０００２】
近年、インターネットの急速な発展により、Ｗｅｂサービス技術が注目されている。Ｗｅｂサービス技術は、ＸＭＬ（eXtensible Markup Language）形式のファイルのやり取りによって、ネットワーク上でＷｅｂサーバが提供するサービスを利用する技術であり、利用可能なサービスは「Ｗｅｂサービス」と呼ばれている。
【０００３】
Ｗｅｂサービスにおいては、その利用技術に焦点が置かれており、Ｗｅｂサービスの呼び出しを容易に行えるようにするため、ＷＳＤＬ（Web Service Description Language）に代表される多くのコード生成技術が提案されている。また、Ｗｅｂサービスを用いることによってソフトウェアの品質分析を可能にする分析技術や、この分析技術を搭載した装置も開発されている。更に、Ｗｅｂサービスが公開され、再利用されることにより、アプリケーション開発におけるコストの削減が図られると期待されている。
【０００４】
また、Ｗｅｂ上でのサービスの提供においては、アプリケーションの機能をＷｅｂサービス技術によって実装することが主流となっている（例えば、特許文献１参照。）。そして、複数のＷｅｂサービスを組み合わせることによって、アプリケーションを開発することが多くなっている。例えば、依存関係の少ないＷｅｂサービス同士を組み合わせることによって、アプリケーションを構築した場合は、Ｗｅｂサービスの更新及び追加が容易となる。この場合、Ｗｅｂサービス内容を容易に変更することが可能なアプリケーションの構築の実現が期待できる。
【０００５】
また、複数のＷｅｂサービスを組み合わせるための技術としては、サービスバス（ＥＳＢ：Enterprise Service Bus）を利用して、アプリケーションを連携させる技術が知られている。更に、このような技術としては、プロセス言語（ＷＳ−ＢＰＥＬ（Web Service - Business Process Execution Language）など）を利用した技術も知られている（例えば、特許文献２参照）。
【０００６】
これらの技術によれば、連携の方法や呼び出し方向等、Ｗｅｂサービス間の連携に関する設定をＷｅｂサービス自体から独立させて定義することができる。よって、Ｗｅｂサービス間の連携の把握及び管理を容易に行えるようにすることができる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００５−７８３３９号公報
【特許文献２】特開２００８−３７０９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ところで、複数のＷｅｂサービスを組み合わせたアプリケーションの開発においては、利用対象となるＷｅｂサービスが別のＷｅｂサービスをどの程度利用しているのかを把握することが重要である。これは、利用の程度が、システム全体のパフォーマンスや安定性に影響するためであるからである。
【０００９】
しかしながら、上記特許文献１に開示された技術によって把握できる利用関係は、ＷｅｂサービスリクエスタからＷｅｂサービスを呼び出す場合、又はＷｅｂサービスからＷｅｂサービスを呼び出す場合などの１対１での呼び出し関係までである。
【００１０】
例えば、Ｗｅｂサービスから直接Ｗｅｂサービスを呼び出す場合は、実装ソースコード中に、直接、呼出しコードが記述されるが、ＷＳＤＬからサービスの実装ソースコードを辿って呼び出しコードを解読することは不可能である。従って、上記特許文献１に開示された技術によって、連携している外部のＷｅｂサービスが更に連携している別のＷｅｂサービスを把握し、管理することは困難である。
【００１１】
また、上記特許文献２に開示されたプロセス言語を用いた場合や、サービスバス用いた場合であっても、同様であり、これらの場合でも、連携しているＷｅｂサービスが更に連携しているＷｅｂサービスを把握することは困難である。
【００１２】
本発明の目的は、上記問題を解消し、複数のＷｅｂサービスを組み合わせてアプリケーションを構築する際において、全てのＷｅｂサービスの連携関係を分析し得る、情報分析装置、情報分析方法、及びプログラムを提供することにある。
【課題を解決するための手段】
【００１３】
上記目的を達成するために、本発明における情報分析装置は、Ｗｅｂサービス間の連携関係を分析するための情報分析装置であって、
Ｗｅｂサービスの呼び出しに利用可能なライブラリに関する情報を用いて、分析対象となるＷｅｂサービスのビジネスロジックから、前記分析対象となるＷｅｂサービスが外部との通信に利用するインタフェース情報を抽出する、インタフェース情報抽出部と、
抽出された前記インタフェース情報に基づいて、前記分析対象となるＷｅｂサービスから呼び出される前記別のＷｅｂサービスのＷＳＤＬファイルを特定する、インタフェース検証部と、
特定された前記ＷＳＤＬファイルを用いて、前記別のＷｅｂサービスの実装プロジェクトを特定し、特定した前記実装プロジェクトに対して通信コードの検索を行う、通信コード検索部と、
特定された前記実装プロジェクトに基づき、前記別のＷｅｂサービスのビジネスロジックを検索する、ビジネスロジック検索部と、
を備えている、ことを特徴とする。
【００１４】
また、上記目的を達成するため、本発明における情報分析方法は、Ｗｅｂサービス間の連携関係を分析するための情報分析方法であって、
（ａ）Ｗｅｂサービスの呼び出しに利用可能なライブラリに関する情報を用いて、分析対象となるＷｅｂサービスのビジネスロジックから、前記分析対象となるＷｅｂサービスが外部との通信に利用するインタフェース情報を抽出する、ステップと、
（ｂ）前記（ａ）のステップで抽出された前記インタフェース情報に基づいて、前記分析対象となるＷｅｂサービスから呼び出される前記別のＷｅｂサービスのＷＳＤＬファイルを特定する、ステップと、
（ｃ）前記（ｂ）のステップで特定された前記ＷＳＤＬファイルを用いて、前記別のＷｅｂサービスの実装プロジェクトを特定し、特定した前記実装プロジェクトに対して通信コードの検索を行う、ステップと、
（ｄ）前記（ｃ）のステップで特定された前記実装プロジェクトに基づき、前記別のＷｅｂサービスのビジネスロジックを検索する、ステップと、
を有する、ことを特徴とする。
【００１５】
更に、上記目的を達成するため、本発明におけるプログラムは、Ｗｅｂサービス間の連
携関係の分析を、コンピュータによって実行するためのプログラムであって、
前記コンピュータに、
（ａ）Ｗｅｂサービスの呼び出しに利用可能なライブラリに関する情報を用いて、分析対象となるＷｅｂサービスのビジネスロジックから、前記分析対象となるＷｅｂサービスが外部との通信に利用するインタフェース情報を抽出する、ステップと、
（ｂ）前記（ａ）のステップで抽出された前記インタフェース情報に基づいて、前記分析対象となるＷｅｂサービスから呼び出される前記別のＷｅｂサービスのＷＳＤＬファイルを特定する、ステップと、
（ｃ）前記（ｂ）のステップで特定された前記ＷＳＤＬファイルを用いて、前記別のＷｅｂサービスの実装プロジェクトを特定し、特定した前記実装プロジェクトに対して通信コードの検索を行う、ステップと、
（ｄ）前記（ｃ）のステップで特定された前記実装プロジェクトに基づき、前記別のＷｅｂサービスのビジネスロジックを検索する、ステップと、
を実行させる、ことを特徴とする。
【発明の効果】
【００１６】
以上のように、本発明における、情報分析装置、情報分析方法、及びプログラムによれば、複数のＷｅｂサービスを組み合わせてアプリケーションを構築する際において、全てのＷｅｂサービスの連携関係を分析することができる。
【図面の簡単な説明】
【００１７】
【図１】図１は、実施の形態１における情報分析装置の概略構成を示すブロック図である。
【図２】図２（ａ）は、実施の形態１で利用されるライブラリのパッケージ情報の一例を示す図、図２（ｂ）は、実施の形態１で利用されるライブラリ設定情報の一例を示す図、図２（ｃ）は、実施の形態１で利用されるビジネスロジックの検索ルールの一例を示す図である。
【図３】図３は、実施の形態１における情報分析装置の動作を示すフロー図である。
【図４】図４は、実施の形態１における情報分析装置を構成するインタフェース検証部の動作を示すフロー図である。
【図５】図５は、実施の形態１における情報分析装置を構成する通信コード検索部及びビジネスロジック検索部の動作を示すフロー図である。
【図６】図６は、実施の形態２における情報分析装置の概略構成を示すブロック図である。
【図７】図７は、実施の形態２における情報分析装置によって分析されたＷｅｂサービス間の依存関係を概念的に示す図である。
【発明を実施するための形態】
【００１８】
（発明の概要）
Ｗｅｂサービスの作成においては、通常、最初に、Ｗｅｂサービス作成ツールを利用して、ビジネスロジック部分の開発が行われ、その後、ＷＳＤＬが作成される。また、別の場合では、最初に、ＷＳＤＬが作成され、次に、ＷＳＤＬからビジネスロジックを記述するためのスケルトンが作成され、その後、ビジネスロジック部分が作成される。これらのＷｅｂサービスの作成において注意すべきは、いずれの場合であっても、ＷＳＤＬとビジネスロジックとには直接の関係があるとは言えないということである。
【００１９】
一方、このように機械的に生成された、ＷＳＤＬ、及びビジネスロジックのスケルトンは、作成ツールに固有の命名規則に従って作成されている。よって、人の目で一つずつ確認しながら、両者の関係を類推すれば、両者の関係を整理することは可能かもしれないが、この場合であっても、両者の明確な対応関係を特定することは困難である。
【００２０】
このような問題に対処するため、本発明は、複数のＷｅｂサービスを組み合わせて、アプリケーションを構築する場合において、分析対象となるＷｅｂサービスのインタフェース情報（呼び出し箇所）を起点として、全てのＷｅｂサービスの呼び出し関係を分析する。
【００２１】
具体的には、本発明では、先ず、Ｗｅｂサービスの呼び出しに利用可能なライブラリに関する情報に基づき、分析の起点として、分析対象となるＷｅｂサービスのインタフェース情報が取得される。ライブラリに関する情報としては、例えば、ライブラリのパッケージ構成を特定する情報や、ライブラリを用いて生成されるソースコードの命名規則等が挙げられる。
【００２２】
そして、インタフェース情報から、分析対象となるＷｅｂサービスによって呼び出されるＷｅｂサービスのＷＳＤＬファイルが特定される。更に、このＷＳＤＬファイルからサービス実装プロジェクト（実装コード）も特定される。続いて、特定されたサービス実装プロジェクトの中から通信部分（ビジネスロジック以外のコード）が特定され、更に、ビジネスロジックのソースコードも特定される。
【００２３】
また、特定されたビジネスロジック内に別のＷｅｂサービスの呼び出しが存在する場合は、さらに分析が継続される。この分析は、Ｗｅｂサービスの呼び出しが無くなるか、ソースコードの分析が不可能な外部サービスに到達するまで、実行される。
【００２４】
この結果、あるＷｅｂサービスを起点とした全てのＷｅｂサービスの呼び出し関係の洗い出しが可能となり、Ｗｅｂサービスの安定性を評価することが可能となる。また、このような分析の結果は、システム全体に対する外部のＷｅｂサービスの利用率の上限を決定する際において、指標となる。
【００２５】
（実施の形態１）
以下、本発明の実施の形態１における情報分析装置、情報分析方法、及びプログラムについて、図１〜図５を参照しながら説明する。最初に、本実施の形態１における情報分析装置１の概略構成について図１を用いて説明する。図１は、実施の形態１における情報分析装置の概略構成を示すブロック図である。
【００２６】
図１に示す情報分析装置１は、Ｗｅｂサービス間の連携関係を分析するための装置である。図１に示すように、情報分析装置１は、インタフェース情報抽出部１１と、インタフェース検証部１４と、通信コード検索部１５と、ビジネスロジック検索部１６とを備えている。
【００２７】
インタフェース情報抽出部１１は、Ｗｅｂサービスの呼び出しに利用可能なライブラリに関する情報を用いて、分析対象となるＷｅｂサービスのビジネスロジック２１から、このＷｅｂサービスが外部との通信に利用するインタフェース情報２２を抽出する。
【００２８】
本実施の形態において、Ｗｅｂサービスの呼び出しに利用可能なライブラリに関する情報としては、ライブラリのパッケージ構成を特定する情報（パッケージ情報）３１と、ライブラリの設定情報（ライブラリ設定情報）３２とが挙げられる。
【００２９】
従って、インタフェース情報抽出部１１が、ビジネスロジック２１と、パッケージ情報３１及びライブラリ設定情報３２とを対比することにより、インタフェース情報２２として、例えば、ＷＳＤＬファイル、ＷＳＤＬファイルの作成に必要となる構成要素等が抽出される。なお、この場合のＷＳＤＬファイルは、分析対象となるＷｅｂサービスが呼び出
す別のＷｅｂサービスのＷＳＤＬファイルである。インタフェース情報２２は、分析対象となるＷｅｂサービスが別のＷｅｂサービスを呼び出すために利用する情報である。
【００３０】
インタフェース検証部１４は、抽出されたインタフェース情報２２から、分析対象となるＷｅｂサービスから呼び出される別のＷｅｂサービスのＷＳＤＬファイル２４を特定する。以下、この特定されたＷＳＤＬファイル２４を特定ＷＳＤＬファイル２４とする場合もある。通信コード検索部１５は、特定ＷＳＤＬファイル２４を用いて、呼出の対象となる別のＷｅｂサービスの実装プロジェクトを特定する。更に、通信コード検索部１５は、特定した実装プロジェクトに対して通信コードの検索を実行する。
【００３１】
ビジネスロジック検索部１６は、通信コード検索部１５によって特定された実装プロジェクトに基づき、呼出の対象となる別のＷｅｂサービスのビジネスロジックを検索する。また、ビジネスロジック検索部１６によって検索されたビジネスロジックも、更に、インタフェース情報抽出部１１によるインタフェース情報２２の抽出対象となり、更に呼び出されるＷｅｂサービスについて検証が行われる。
【００３２】
このように、情報分析装置１は、あるＷｅｂサービスを起点として、全てのＷｅｂサービスの呼び出し関係を洗い出すことができる。情報分析装置１によれば、複数のＷｅｂサービスを組み合わせてアプリケーションを構築する際において、全てのＷｅｂサービスの連携関係を分析することができる。
【００３３】
ここで、図１に加えて、更に図２（ａ）〜図２（ｃ）を用いて、より具体的に情報分析装置１の構成について説明する。図２（ａ）は、実施の形態１で利用されるライブラリのパッケージ情報の一例を示す図である。図２（ｂ）は、実施の形態１で利用されるライブラリ設定情報の一例を示す図である。図２（ｃ）は、実施の形態１で利用されるビジネスロジックの検索ルールの一例を示す図である。
【００３４】
本実施の形態１においては、図１に示すように、分析装置１は、呼出構造分析部１０と、インタフェース・ビジネスロジック分析部１３とを備えている。呼出構造分析部１０は、分析対象となるＷｅｂサービスが別のＷｅｂサービスを呼び出すための呼び出し構造を分析する。呼出構造分析部１０は、既述したインタフェース情報抽出部１１と、ライブラリ利用部分抽出部１２とを備えている。
【００３５】
インタフェース・ビジネスロジック分析部１３は、分析対象となるＷｅｂサービスによって呼び出されるＷｅｂサービスを対象として、そのインタフェースとビジネスロジックとを分析する。インタフェース・ビジネスロジック分析部１３は、記述したインタフェース検証部１４、通信コード検索部１５、及びビジネスロジック検索部１６に加えて、呼出関係管理部１７を備えている。
【００３６】
また、図１に示すように、分析装置１には、処理情報記憶装置２と、設定情報記憶装置３とが接続されている。処理情報記憶装置２は、既に述べた、分析対象となるＷｅｂサービスのビジネスロジック２１、インタフェース情報２２、及び特定ＷＳＤＬファイル２４に加え、抽出ソースコード２３及びサービス呼出リスト２５を記憶する。抽出ソースコード２３及びサービス呼出リスト２５の具体例については後述する。設定情報記憶装置３は、既に述べた、パッケージ情報３１及びライブラリ設定情報３２に加えて、ビジネスロジックの検索ルール３３を記憶する。
【００３７】
本実施の形態１では、インタフェース情報抽出部１１は、先ず、設定情報記憶装置３から、パッケージ情報３１及びライブラリ設定情報３２を読み出し、処理情報記憶装置２から、分析対象となるＷｅｂサービスのビジネスロジック２１を読み出す。
【００３８】
図２（ａ）に示すように、パッケージ情報３１は、Ｗｅｂサービスの呼び出しに利用可能なライブラリのパッケージ構成を特定する情報である。図２（ｂ）に示すように、ライブラリ設定情報３２は、ライブラリを用いて生成されるソースコードの命名規則を含んでいる。また、ライブラリ設定情報３２は、ソースコードに付与されるコメントを含んでいても良い。
【００３９】
また、本実施の形態１では、ビジネスロジック２１は、分析対象となるＷｅｂサービスのビジネスロジックであって、ソースコードによって構成されている。ビジネスロジック２１には、ＷＳＤＬファイルが含まれている場合もある。
【００４０】
そして、インタフェース情報抽出部１１は、ビジネスロック２１を構成するソースコードを、パッケージ情報３１及びライブラリ設定情報３２に照らし合わせ、ソースコードからインタフェース情報２２を抽出する。インタフェース情報２２は、分析対象となるＷｅｂサービスが外部との通信に利用する情報である。インタフェース情報２２の分析により、分析対象となるＷｅｂサービスによって呼び出される別のＷｅｂサービスの特定が可能となる。
【００４１】
ライブラリ利用部分抽出部１２は、抽出されたインタフェース情報２２から、Ｗｅｂサービスライブラリを利用するソースコード、又は、生成される通信部分のモジュールを利用するソースコード２３を抽出する。また、ライブラリ利用部分抽出部１２は、抽出したソースコード（抽出ソースコード）２３を、分析単位となるモジュール毎に分割し、それぞれを処理情報記憶装置２に格納させる。なお、本実施の形態１では、分析単位とはコンパイルの単位をいう。
【００４２】
インタフェース検証部１４は、本実施の形態１では、先ず、処理情報記憶装置２にアクセスし、インタフェース情報２２及び抽出ソースコード２３を取得する。次に、インタフェース検証部１４は、分析対象となるＷｅｂサービスによって構築されるアプリケーションで利用される全てのＷＳＤＬファイルを取得する。具体的には、このようなＷＳＤＬファイルとしては、既に処理情報記憶装置２に登録されているＷＳＤＬファイル２４や、実行環境に配備されて実行可能なＷｅｂサービス、及び分析対象となるＷｅｂサービスの内部プロジェクトに存在するＷＳＤＬファイルが挙げられる。
【００４３】
そして、インタフェース検証部１４は、インタフェース情報２２と、これらＷＳＤＬファイルとを比較し、抽出ソースコード２３によって利用されるＷｅｂサービスのＷＳＤＬファイルを特定する。また、インタフェース検証部１４は、特定したＷＳＤＬファイル（特定ＷＳＤＬファイル）２４を、処理情報記憶装置２に格納させる。
【００４４】
通信コード検索部１５は、既に述べたように、特定ＷＳＤＬファイル２４から、呼び出されるＷｅｂサービスの実装プロジェクト（サービス実装プロジェクト）を特定し、特定したサービス実装プロジェクトに対して通信コードの検索を実行する。本実施の形態１では、通信コード検索部１５は、ライブラリ設定情報３２を参照しながら、特定したサービス実装プロジェクト内部におけるＷｅｂサービスの通信部分のコードを特定する。このとき、通信コード検索部１５が、通信コードを検索できなかった場合、つまり、呼び出されるＷｅｂサービスの実装プロジェクトを発見できなかった場合は、呼び出されるＷｅｂサービスは外部サービスとして処理される。
【００４５】
ビジネスロジック検索部１６は、既に述べたように、通信コード検索部１５によって特定されたサービス実装プロジェクトから、ビジネスロジックを検索する。本実施の形態１では、ビジネスロジック検索部１６は、特定したビジネスロジックを処理情報記憶装置２
に格納させる。
【００４６】
また、このように新たなビジネスロジックが処理情報記憶部２に格納されると、インタフェース情報抽出部１１は、新たなビジネスロジックに対してインタフェース情報２２の抽出を実行する。この後、ライブラリ利用部分抽出部１２、インタフェース検証部１４、及び通信コード検索部１５による処理が行われる。本実施の形態１では、ビジネスロジックの特定により、Ｗｅｂサービスの呼び出し分析が再帰的に実行される。
【００４７】
ところで、Ｗｅｂサービスによっては、特定された実装プロジェクトと、ビジネスロジックの実装コードとが、別々のプロジェクトである場合がある。この場合、ビジネスロジックはコンパイル済みの実行クラスのみを含む。そして、この場合においては、本実施の形態１では、ビジネスロジック検索部１６は、予め設定されたビジネスロジックの検索ルール３３に従って、ビジネスロジックのソースコード、又はビジネスロジックの候補となるバイナリコードを検索する。また、後者においては、ビジネスロジック検索部１６は、更にバイナリコード内のパッケージ情報から、ビジネスロジックのソースコードを検索する。
【００４８】
なお、図２（ｃ）に示すビジネスロジックの検索ルール３３には、ビジネスロジックを構成する実装コードが含まれている。図２（ｃ）に示す検索ルール３３が利用される場合は、ビジネスロジック検索部１６は、通信コード検索部１５によって特定された実装プロジェクトと、検索ルール３３とを対比し、ビジネスロジックの実装コードを特定する。
【００４９】
呼出関係管理部１７は、分析対象となるＷｅｂサービスによって呼び出される全てのＷｅｂサービスを特定する。そして、呼出関係管理部１７は、インタフェース情報２２と、ビジネスロジック２１とに基づいて、分析対象となるＷｅｂサービス及び全てのＷｅｂサービスにおけるＷｅｂサービス間の呼び出し関係を管理する。
【００５０】
具体的には、呼出関係管理部１７は、上述した処理が一通り終了すると、処理情報記憶装置２にアクセスし、新たに特定されたＷＳＤＬファイル（特定ＷＳＤＬファイル）２４を取得する。そして、呼出関係管理部１７は、特定ＷＳＤＬファイル２４に基づいて、分析対象となったＷｅｂサービスの呼び出し関係を呼出リスト２５に登録する。また、登録される呼び出し関係としては、特定ＷＳＤＬファイル２４を含むインタフェース情報２２と、その抽出元となったビジネスロジックとの組みデータが挙げられる。
【００５１】
なお、このとき、既に、分析対象となったＷｅｂサービスを呼び出しているＷｅｂサービスが存在し、既に、このＷｅｂサービスの呼び出し関係が呼び出しリスト２５に登録されている場合は、呼出関係管理部１７は、呼出リスト２５を更新する。呼出関係管理部１７は、Ｗｅｂサービス間の呼び出し関係を、呼出リスト２５によって管理している。
【００５２】
また、ＥＳＢ、ＢＰＥＬ等を用いた場合では、Ｗｅｂサービス間の呼び出し関係自体が定義されている。本実施の形態１における情報処理装置１は、ＥＳＢ、ＢＰＥＬ等を用いたＷｅｂサービスを分析対象としていない。情報処理装置１は、Ｗｅｂサービス間の依存関係を特定する情報を定義情報として有していないソースコードを、分析対象としている。
【００５３】
次に、本発明の実施の形態１における情報処理装置１の動作について図３〜図５を用いて説明する。先ず、図３を用いて、情報処理装置１の全体の動作について説明する。図３は、実施の形態１における情報分析装置の動作を示すフロー図である。なお、本実施の形態１における情報処理方法は、情報処理装置１を動作させることによって実行される。よって、情報処理方法の説明は、情報処理装置１の動作の説明に代える。また、以下の説明
では、適宜、図１、図２（ａ）、図２（ｂ）、及び図２（ｃ）を参酌する。
【００５４】
図３に示すように、先ず、インタフェース情報抽出部１１は、パッケージ情報及びライブラリ設定情報３２を用いて、分析対象となるＷｅｂサービスのビジネスロジック２１から、インタフェース情報２２を抽出する（ステップＡ１）。更に、インタフェース情報抽出部１は、抽出されたインタフェース情報２２を処理情報記憶装置２に格納させる。
【００５５】
次に、ライブラリ利用部分抽出部１２は、インタフェース情報２２から、Ｗｅｂサービスライブラリを利用するソースコード、又は、生成される通信部分のモジュールを利用するソースコード２３を抽出する（ステップＡ２）。また、ライブラリ利用部分抽出部１２は、抽出したソースコード２３を、処理情報記憶装置２に格納させる。
【００５６】
次に、インタフェース検証部１４は、インタフェース情報２２から、分析対象となるＷｅｂサービスから呼び出される別のＷｅｂサービスのＷＳＤＬファイル２４を特定する（ステップＡ３）。続いて、通信コード検索部１５は、特定ＷＳＤＬファイル２４を用いて、呼出の対象となる別のＷｅｂサービスの実装プロジェクトを特定し、特定したサービス実装プロジェクトに対して通信コードの検索を実行する（ステップＡ４）。
【００５７】
次に、ビジネスロジック検索部１６は、ステップＡ４で特定された実装プロジェクトに基づき、ビジネスロジックの検索ルール３３に従って、呼出の対象となる別のＷｅｂサービスのビジネスロジックを検索する（ステップＡ５）。ステップＡ５において検索されたビジネスロジックは、処理情報記憶部２に格納され、更に、インタフェース情報抽出部１１によるインタフェース情報２２の抽出対象となる。
【００５８】
その後、呼出関係管理部１７は、ステップＡ４で特定されたＷＳＤＬファイル２４を取得し、これに基づいて、ステップＡ１〜Ａ４で分析対象となったＷｅｂサービスの呼び出し関係を呼出リスト２５に登録する（ステップＡ６）。
【００５９】
なお、ステップＡ１〜Ａ６は、ステップＡ５において検索されたビジネスロジック内に別のサービスの呼び出しが存在する場合は、再度実行される。ステップＡ１〜Ａ６は、Ｗｅｂサービスの呼び出しが無くなるか、ソースコードの分析が不可能な外部サービスに到達するまで、繰り返し実行される。
【００６０】
ここで、上述したステップＡ３について、図４を用いて、具体的に説明する。図４は、実施の形態１における情報分析装置を構成するインタフェース検証部の動作を示すフロー図である。
【００６１】
図４に示すように、先ず、インタフェース検証部１４は、処理情報記憶装置２にアクセスし、インタフェース情報２２及び抽出ソースコード２３を取得する（ステップＢ１）。次に、インタフェース検証部１４は、分析対象となるＷｅｂサービスによって構築されるアプリケーションで利用される全てのＷＳＤＬファイルを取得する（ステップＢ２）。
【００６２】
具体的には、ステップＢ２では、インタフェース検証部１４は、分析対象となるＷｅｂサービスの内部プロジェクトに含まれるＷＳＤＬファイル、既に処理情報記憶装置２に登録されているＷＳＤＬファイル等を取得する。また、分析対象となるＷｅｂサービスと連携していないが、インタフェース検証部１４が参照する外部のＷｅｂサービスが存在する場合は、取得されるＷＳＤＬファイルは、このＷｅｂサービスのＷＳＤＬファイルであっても良い。
【００６３】
次に、インタフェース検証部１４は、ステップＢ２で取得されたインタフェース情報２
２と、ステップＢ２で取得されたＷＳＤＬファイルとを比較する。そして、インタフェース検証部１４は、抽出ソースコード２３に基づき、分析対象となるＷｅｂサービスの呼び出しコードから、呼び出されているＷｅｂサービスが実際に公開しているＷＳＤＬファイルを特定する（ステップＢ３）。
【００６４】
続いて、インタフェース検証部１４は、ステップＢ３で特定した特定ＷＳＤＬファイル２４が、既に、処理情報記憶装置２に格納されているかどうかを確認する（ステップＢ４）。ステップＢ４の判定の結果、既に格納済みの場合は、ステップＢ６が実行される。一方、ステップＢ４の判定の結果、既に格納済みでない場合は、インタフェース検証部１４は、ステップＢ３で特定した特定したＷＳＤＬファイルを、処理情報記憶部装置２に格納させ、登録させる（ステップＢ５）。
【００６５】
次に、インタフェース検証部１４は、ステップＢ３で特定された特定ＷＳＤＬファイル２４を含むインタフェース情報２２が、呼び出し関係として、呼出リスト２５に既に登録されているかどうかを判定する（ステップＢ６）。
【００６６】
ステップＢ６の判定の結果、インタフェース情報２２が登録されていない場合は、インタフェース検証部１４は、呼出関係管理部１７にそのことを通知する（ステップＢ７）。そして、ステップＢ７の実行後、呼出関係管理部１７は、ステップＢ３で特定されたＷＳＤＬファイル２４を含むインタフェース情報２２と、その抽出元となったビジネスロジックとの組みデータを、呼び出し関係として、呼出リスト２５に登録する。
【００６７】
また、ステップＢ６の判定の結果、インタフェース情報２２が登録されている場合は、特定ＷＳＤＬファイル２４によって循環呼び出しが実行されることになる。このため、インタフェース検証部１４は、特定ＷＳＤＬファイル２４を含むインタフェース情報２２を、循環呼出情報として、循環呼出リスト（図示せず）に登録する。
【００６８】
ステップＢ７またはＢ８の終了により、インタフェース検証部１４での処理、即ち、ステップＡ３は終了する。なお、後述する図７に、呼出リスト２５及び循環呼出リストに登録されているインタフェース情報２２を示す。
【００６９】
また、上述したステップＡ４〜Ａ６について、図５を用いて、具体的に説明する。図５は、実施の形態１における情報分析装置を構成する通信コード検索部及びビジネスロジック検索部の動作を示すフロー図である。
【００７０】
図５に示すように、先ず、通信コード検索部１５は、処理情報記憶装置２にアクセスし、特定ＷＳＤＬファイル２４を取得する（ステップＣ１）。次に、通信コード検索部１５は、特定ＷＳＤＬファイル２４によって呼び出されるＷｅｂサービスの内部プロジェクトを全て取得する。そして、通信コード検索部１５は、各プロジェクトの設定ファイルを参照しながら、Ｗｅｂサービスの作成ができない種類のプロジェクトを振るいにかけ、サービス実装プロジェクトのみを抽出する（ステップＣ２）。
【００７１】
次に、通信コード検索部１５は、ステップＣ２で抽出した各プロジェクトを対象として、Ｗｅｂサービスの定義ファイル（Ｗｅｂサービス定義ファイル）の検索を行い、Ｗｅｂサービス定義ファイルが存在しているかどうかを判定する（ステップＣ３）。なお、Ｗｅｂサービス定義ファイルが存在しているかどうかは、Ｗｅｂサービスが利用するＷｅｂサービス標準仕様から判定することができるため、通信コード検索部１５は、ステップＣ３では、Ｗｅｂサービス標準仕様を調査する。
【００７２】
ステップＣ３の判定の結果、Ｗｅｂサービス定義ファイルが存在しない場合は、サービ
ス実装プロジェクトのソースコード内に定義情報が定義されている。よって、この場合、通信コード検索部１５は、ステップＣ２で抽出されたサービス実装プロジェクトのソースコードを対象として、Ｗｅｂサービスの定義名及び名前空間の検索を実行する（ステップＣ１１）。そして、これにより、通信コード検索部１５は、定義名及び名前空間を有するサービス実装プロジェクトを特定する。
【００７３】
また、ステップＣ１１が実行されると、通信コード検索部１５は、特定したサービス実装プロジェクトのソースを対象として、Ｗｅｂサービスとして公開されているオペレーションの検索を実行する（ステップＣ１２）。そして、ステップＣ１２により、サービス実装プロジェクト内部のビジネスロジックの記述部分が特定される。その後、ステップＣ１３が実行される。
【００７４】
一方、ステップＣ３の判定の結果、Ｗｅｂサービス定義ファイルが存在する場合は、通信コード検索部１５は、Ｗｅｂサービス定義ファイルを参照して、サービス実装プロジェクト内のＷＳＤＬファイルの格納場所を特定する（ステップＣ４）。
【００７５】
次に、通信コード検索部１５は、ステップＣ４で特定された格納場所に格納されているＷＳＤＬファイルと、インタフェース情報２２をキーにして取得された特定ＷＳＤＬファイルファイル２４とを比較する。そして、ステップＣ２で抽出されたサービス実装プロジェクトの中から、分析対象となるＷｅｂサービスが呼び出すＷｅｂサービスの実装プロジェクトを特定する（ステップＣ５）。
【００７６】
次に、通信コード検索部１５は、ＷＳＤＬファイルと実装クラスとの対応関係のパターンが定義されたライブラリ設定情報３２を取得する（ステップＣ６）。そして、通信コード検索部１５は、ライブラリ設定情報３２を参照して、ステップＣ５で特定された実装プロジェクト内に含まれるソースコードを、通信部分のみのコードと、ビジネスロジックのコードとに分類する（ステップＣ７）。
【００７７】
なお、ステップＣ７において、通信コード検索部１５が、通信部分のみのコードを発見できなかった場合は、サービス実装プロジェクト内に、別のＷｅｂサービスの実装を発見できなかったことに相当するため、呼び出されるＷｅｂサービス自体は外部サービスとして処理される。
【００７８】
次に、ビジネスロジック検索部１６は、ステップＣ５で特定された実装プロジェクトの中に、ビジネスロジックが存在するかどうかを判定する（ステップＣ８）。なお、ステップＣ８の判定が行われるのは、ビジネスロジックはコンパイル済みの実行クラスのみを含む場合もあるためである。
【００７９】
ステップＣ８の判定の結果、ビジネスロジックが存在する場合は、ステップＣ１３が実行される。一方、ステップＣ８の判定の結果、ビジネスロジックが存在しない場合は、ビジネスロジック検索部１６は、ビジネスロジックの検索ルール３３を取得する（ステップＣ９）。そして、ビジネスロジック検索部１６は、実装プロジェクトを対象として、検索ルール３３を参照しながら、ビジネスロジックのソースコード、又はビジネスロジックの候補となるバイナリコードの検索を実行する（ステップＣ１０）。
【００８０】
ステップＣ１０において、ビジネスロジックの候補となるバイナリフコードとしては、例えば、ライブラリファイルや、コンパイル済みのファイルが挙げられる。また、バイナリコードが検索された場合は、ビジネスロジック検索部１６は、更に、検索されたバイナリコードから、ビジネスロジックのパッケージ情報を取得し、続いて、パッケージ情報からビジネスロジックのソースコードを検索する。
【００８１】
その後、呼出関係管理部１７は、ステップＡ３（Ｂ３）で特定された特定ＷＳＤＬファイル２４に基づいて、分析対象となったＷｅｂサービスの呼び出し関係を呼出リスト２５に追加登録する（ステップＣ１３）。具体的には、ステップＣ１３では、既述したように、呼出関係管理部１７は、特定ＷＳＤＬファイル２４を含むインタフェース情報２２と、その抽出元となったビジネスロジックとの組みデータを、呼び出し関係として、呼出リスト２５に登録する。
【００８２】
また、本実施の形態１におけるプログラムは、コンピュータに、図３に示すステップＡ１〜Ａ６実行させるプログラムであれば良い。このプログラムをコンピュータにインストールし、実行することによって、本実施の形態における情報分析装置１及び情報分析方法を実現することができる。
【００８３】
この場合、コンピュータのＣＰＵ（Central Processing Unit）は、インタフェース情報抽出部１１、ライブラリ利用部分抽出部１２、インタフェース検証部１４、通信コード検索部１５、ビジネスロジック検索部１６、及び呼出関係管理部１７として機能し、処理を行なう。また、処理情報記憶装置２及び設定情報記憶装置３は、本実施の形態におけるプログラムがインストールされるコンピュータ、又はこれとは別のネットワーク等によって接続されたコンピュータに備えられたハードディスク等の記憶装置によって実現できる。
【００８４】
以上のように、本実施の形態１では、呼び出し対象となるＷｅｂサービスの実装プロジェクトにおけるビジネスロジックの有無により、Ｗｅｂサービス自体が外部サービスであるのか、又は内部サービスであるのかが識別される。これにより、Ｗｅｂサービスが他のＷｅｂサービスにどの程度依存しているのかを把握することが容易となる。
【００８５】
また、本実施の形態１によれば、Ｗｅｂサービス間の呼出管理が行われ、内部サービスであれば呼び出しの循環が検出される。よって、Ｗｅｂサービス毎の保守性の低下の危険性等に関する情報を得ることが容易となる。更に、制御範囲外である外部のＷｅｂサービスへの依存によるシステム全体のリスクを可視化することも可能となるため、Ｗｅｂサービスの設計の見直しの機会を設けることや、Ｗｅｂサービスの品質の特性について定量的な評価を行うことなどが可能となる。
【００８６】
（実施の形態２）
次に、本発明の実施の形態２における情報分析装置、情報分析方法、及びプログラムについて、図６及び図７を参照しながら説明する。図６は、実施の形態２における情報分析装置の概略構成を示すブロック図である。図７は、実施の形態２における情報分析装置によって分析されたＷｅｂサービス間の依存関係を概念的に示す図である。
【００８７】
図６に示すように、本実施の形態２における情報分析装置４０は、呼出構造分析部１０及びインタフェース・ビジネスロジック分析部１３に加えて、呼出分析部１８を備えている。また、呼出分析部１８は、依存関係分析部１９を備えている。この点以外については、情報分析装置４０は、図１に示した情報分析装置１と同様に構成されている。以下に、実施の形態１との相違点を中心に説明する。
【００８８】
依存関係分析部１９は、処理情報記憶部２にアクセスし、呼出リスト２５を取得する。そして、依存関係分析部１９は、分析対象となるＷｅｂサービスのビジネスロジックを起点にして、そこから呼び出されるＷｅｂサービスを全て抽出し、Ｗｅｂサービス間の依存関係を分析する。
【００８９】
具体的には、依存関係分析部１９は、アプリケーションを構成する内部プロジェクトと、内部プロジェクトがＷｅｂサービスを呼び出すためのインタフェース情報（ＩＦ情報）と、呼び出されるＷｅｂサービスのビジネスロジックとの関係を分析する。そして、依存関係分析部１９は、依存関係の分析結果として、図７に示すような相関図を作成する。図７に示す相関図は、依存関係の分析結果２６として、処理情報記憶装置２によって記憶される。
【００９０】
図７から、呼出リスト２５では、ビジネスロジックは、インタフェース情報に結び付けられて管理されていることが分かる。また、例えば、「ＩＦ情報（１）〜（３）」のように、ＩＦ情報は、Ｗｅｂサービスの呼び出し元からの呼び出しの順に管理されている。更に、例えば、「ＩＦ情報（１）循環フラグ」のように、循環呼び出しが存在している場合は、そのことが明記されている。そして、循環呼び出しの存在の明記により、以降の分析が省略可能であることが示される。
【００９１】
このように、本実施の形態２によれば、情報分析装置４０の利用者は、Ｗｅｂサービスの呼び出し関係を容易に把握することができる。そして、利用者は、Ｗｅｂサービスの呼び出し数に基づいたＷｅｂサービスの安定性だけでなく、内部サービスと外部サービスとの利用比率に基づいた安定性を把握することも容易となる。なお、本実施の形態２を用いた場合も、実施の形態１で述べた効果を得ることもできる。
【００９２】
また、本実施の形態２においても、情報分析方法は、情報分析装置４０を動作させることによって実行される。更に、本実施の形態２におけるプログラムは、図３に示したステップＡ１〜Ａ６に加えて、依存関係の分析ステップを、更にコンピュータに実行させるものであれば良い。
【産業上の利用可能性】
【００９３】
本発明によれば、複数のＷｅｂサービスを組み合わせたアプリケーション開発において、提供又は利用可能なＷｅｂサービスの外部依存度から、それらＷｅｂサービスの安定度を評価することができるようになる。
【００９４】
例えば、Ｗｅｂサービスの利用基準を設けることで、Ｗｅｂサービスの呼び出しを行うアプリケーションが基準を満たしているかどうかの評価を行うことができる。同様に、Ｗｅｂサービスを提供する場合に、そのＷｅｂサービスの品質レベルが基準を満たしているかどうかを定量的に評価することもできる。
【００９５】
本発明は、上述した評価が可能になる点から、複数のＷｅｂサービスを組み合わせたアプリケーションの開発に有用であり、又、開発の統制に用いることもできる。
【符号の説明】
【００９６】
１  情報分析装置
２  処理情報記憶装置
３  設定情報記憶装置
１０  呼出構造分析部
１１  インタフェース情報抽出部
１２  ライブラリ利用部分抽出部
１３  インタフェース・ビジネスロジック分析部
１４  インタフェース検証部
１５  通信コード検索部
１６  ビジネスロジック検索部
１７  呼出関係管理部
１８  呼出分析部
１９  依存関係分析部
２１  分析対象ｗｅｂサービスのビジネスロジック
２２  インタフェース情報
２３  抽出ソースコード
２４  特定ＷＳＤＬファイル
２５  呼出リスト
２６  依存関係の分析結果
３１  パッケージ情報
３２  ライブラリ設定情報
３３  ビジネスロジックの検索ルール
【図１】
2011014098.tif 000003
【図２】
2011014098.tif 000004
【図３】
2011014098.tif 000005
【図４】
2011014098.tif 000006
【図５】
2011014098.tif 000007
【図６】
2011014098.tif 000008
【図７】
2011014098.tif 000009