JP2021179748A - 管理プログラム、管理方法及び管理装置 - Google Patents

Abstract

【課題】効率的な開発環境を整える管理プログラム、管理方法及び管理装置を提供する。【解決手段】１つ又は複数のスキーマ定義を呼び出す複数のＡＰＩ定義を有するＷｅｂＡＰＩにおける各スキーマ定義から各スキーマ定義で示される各スキーマにおける上位スキーマと下位スキーマとの参照関係を抽出する。ＡＰＩ定義から各ＡＰＩ定義で示される各ＡＰＩに対する各スキーマの呼び出し関係を抽出する。参照関係及び呼び出し関係を基に、各ＡＰＩによる上位スキーマの呼び出しに連動する下位スキーマの呼び出しの関係性を求める。各ＡＰＩの呼び出し回数と関係性に基づいて、各スキーマの呼び出し回数を算出する。【選択図】図１５

Description

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

ソフトウェアの機能をネットワーク越しに外部から利用できるようにするApplication Programming Interface（ＡＰＩ）の一形態として、ＷｅｂＡＰＩがある。開発者には、ＷｅｂＡＰＩを介して自分が開発した機能を公開するＷｅｂＡＰＩ提供者と、ＷｅｂＡＰＩを介して他人が公開した機能を利用するＷｅｂＡＰＩ利用者という２つの立場がある。

ＷｅｂＡＰＩ提供者は、自分が提供した機能の強化、バクの修正などの理由でＷｅｂＡＰＩを修正する場合がある。ＡＰＩは、そのＡＰＩで利用されるデータの構造を示す情報であるスキーマを有する。そして、ＷｅｂＡＰＩ提供者は、ＡＰＩを修正する場合、スキーマを修正する場合がある。このようにＷｅｂＡＰＩ提供者によりＷｅｂＡＰＩに対してスキーマ修正のような非互換な修正が加えられた場合、利用者は、その修正に対応しなければ、修正が加えられたＷｅｂＡＰＩを利用する自分のソフトウェアが正常に動作しなくなるおそれがある。例えば、スキーマ修正は、Required属性のついた要素であるスキーマの必須要素に対する修正、追加又は削除が行われた場合に、非互換な修正となる。また、スキーマ修正のうちRequired属性のない要素であるオプション要素の修正及び削除は、その要素を利用する場合に利用者は影響を受け、オプション要素の追加の場合は、利用者は影響を受けない。

従来のライブラリで提供されるＡＰＩについては、ＡＰＩ利用者がライブラリを取得して、ＡＰＩの実行前にローカルでＡＰＩ利用コードをコンパイルする際に、ＡＰＩの不一致を検出することが可能であった。

これに対して、ＷｅｂＡＰＩは、ネットワーク越しに文字列を送信することでＡＰＩ呼び出しを行うという規則に準ずるが、他の規則に関しては不確定である。そのため、ＷｅｂＡＰＩ利用者は、事前のコンパイルチェックを行うことは困難であり、ＡＰＩを実行するまでＡＰＩの不一致を検出することは難しい。このようなことから、ＷｅｂＡＰＩは生ものであるといわれることがある。以上のような理由から、ＷｅｂＡＰＩ提供者は、ＷｅｂＡＰＩ利用者に影響のあるＡＰＩ変更は可能な限りさけることが好ましい。

そこで、ＷｅｂＡＰＩ利用者に影響のあるＡＰＩ変更を避けるために、スキーマの重要度によって変更の影響度を判定し得るようにすることが好ましい。そして、各スキーマの利用頻度を算出することで、スキーマの重要度を知ることができる。

ＷｅｂＡＰＩを利用する技術として、アプリケーションが送信したＡＰＩリクエストの履歴とＡＰＩリクエストの内容の遷移とに基づいて算出した安定度に応じて、アプリケーションからのＡＰＩアクセス可能回数を設定する従来技術がある。また、ＡＰＩ群の構造として、階層構造を有するスキーマ定義や関数のライブラリを含ませる従来技術がある。また、ＷｅｂアプリケーションのＤＯＭツリーを読み込み、ＤＯＭツリーの各要素の属性を解析してＷｅｂアプリケーションに対して行われたユーザ操作を検出して記録する従来技術がある。また、ＡＰＩ仕様書からパラメータ名などの情報を抽出し、抽出した情報がＡＰＩ規約に基づくスキーマ定義ルールファイルを満たすか否かを判定することで、そのＡＰＩがＡＰＩ規約に沿っていることを確認する従来技術がある。

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

しかしながら、ＡＰＩで利用されるスキーマは階層化される場合がある。階層化されたスキーマを有するＡＰＩの場合、ＡＰＩで利用されるスキーマをすべて展開してログに記録すると、記録量が膨大になってしまう。スキーマの利用状態のログの記録量が膨大になった場合、各スキーマの利用頻度の算出が困難となる。また、ＡＰＩ定義を利用した場合、親スキーマは特定可能であるが、階層化された子スキーマを特定するにはスキーマ定義の参照が行われるため、スキーマの階層が深い場合スキーマの特定が困難となる。そのため、単にＡＰＩ定義を利用する方法では、各スキーマの利用頻度を算出することは困難である。以上のように、従来のスキーマの利用頻度を求める方法では、修正による影響を抑えた適切なＷｅｂＡＰＩの提供や変更の可能性が少ないスキーマを用いたＷｅｂＡＰＩの利用が難しく、効率的な開発環境を整えることは困難である。

また、アプリケーションが送信したＡＰＩリクエストの履歴とＡＰＩリクエストの内容の遷移とに基づいて算出した安定度を算出する従来技術であっても、ＡＰＩリクエストの回数はわかるが、各スキーマの利用頻度までは特定困難である。また、階層構造を有するスキーマ定義を含むＡＰＩ群、ＤＯＭツリーの各要素の属性を解析、ＡＰＩの各要素のスキーマ定義ルールファイルを用いたチェックなどといった従来技術では、各スキーマへのアクセス頻度は考慮されていない。そのため、これらの従来技術を用いても、各スキーマの利用頻度を特定することは困難である。したがって、効率的な開発環境を整えることは困難である。

開示の技術は、上記に鑑みてなされたものであって、効率的な開発環境を整える管理プログラム、管理方法及び管理装置を提供することを目的とする。

本願の開示する管理プログラム、管理方法及び管理装置の一つの態様において、１つ又は複数のスキーマ定義を呼び出す複数のＡＰＩ定義を有するＷｅｂＡＰＩにおける各前記スキーマ定義から各前記スキーマ定義で示される各スキーマにおける上位スキーマと下位スキーマとの参照関係を抽出する。前記ＡＰＩ定義から各前記ＡＰＩ定義で示される各ＡＰＩに対する各前記スキーマの呼び出し関係を抽出する。前記参照関係及び前記呼び出し関係を基に、各前記ＡＰＩによる前記上位スキーマの呼び出しに連動する前記下位スキーマの呼び出しの関係性を求める。各前記ＡＰＩの呼び出し回数と前記関係性に基づいて、各前記スキーマの呼び出し回数を算出する。

１つの側面では、本発明は、効率的な開発環境を整えることができる。

図１は、実施例に係るＡＰＩ管理装置を含む情報処理システムのイメージ図である。 図２は、ＡＰＩ管理装置のブロック図である。 図３Ａは、ＡＰＩ定義ファイルの一例を示す図である。 図３Ｂは、ＡＰＩ定義ファイルのシンタックスの一例を示す図である。 図４は、ＡＰＩ定義ファイルにおけるＡＰＩ定義及びスキーマ定義を模式的に表した図である。 図５は、ＡＰＩ管理テーブルの一例を示す図である。 図６は、利用スキーマ対応テーブルの一例を表す図である。 図７は、階層構造テーブルの一例の図である。 図８は、重要度テーブルの一例を表す図である。 図９は、ＡＰＩ定義から直接呼び出された回数を表す図である。 図１０は、直接及び間接的に呼び出し元となるＡＰＩを表す図である。 図１１は、実施例に係るＡＰＩ管理装置により算出される各スキーマの重要度を表す図である。 図１２は、各スキーマの重要度の第１の報知例を表す図である。 図１３は、各スキーマの重要度の第２の報知例を表す図である。 図１４は、各スキーマの重要度の第３の報知例を表す図である。 図１５は、実施例に係るＡＰＩ管理装置によるスキーマ重要度決定処理のフローチャートである。

以下に、本願の開示する管理プログラム、管理方法及び管理装置の実施例を図面に基づいて詳細に説明する。なお、以下の実施例により本願の開示する管理プログラム、管理方法及び管理装置が限定されるものではない。

図１は、実施例に係るＡＰＩ管理装置を含む情報処理システムのイメージ図である。図１に示すように、ＷｅｂＡＰＩを用いた情報処理システムでは、ＷｅｂＡＰＩ提供はＰ１、ＷｅｂＡＰＩ利用者Ｐ２及びＷｅｂＡＰＩ利用者Ｐ３が存在する。

ＷｅｂＡＰＩ提供者Ｐ１は、ＷｅｂＡＰＩを開発して、インターネットなどのネットワーク１を経由して、ＷｅｂＡＰＩ提供プログラム５を用いて開発したＷｅｂＡＰＩをＷｅｂＡＰＩ利用者Ｐ２及びＰ３に提供する。また、ＷｅｂＡＰＩ提供者Ｐ１は、開発したＷｅｂＡＰＩに関するＡＰＩ仕様公開ページやOpen API Specification（ＯＡＳ）を、ファイル２を用いてネットワーク１を介して提供する。ＯＡＳは、ＡＰＩの仕様を記述するフォーマットである。ファイル２には、ＡＰＩ定義などが含まれる。

ＷｅｂＡＰＩ提供プログラム５は、ＷｅｂＡＰＩ利用プログラム６及び７から参照される。ＷｅｂＡＰＩ提供プログラム５に含まれる各ＷｅｂＡＰＩがＷｅｂＡＰＩ利用プログラム６及び７により呼び出された履歴は、ＷｅｂＡＰＩ呼出ログ４として保存される。

本実施例に係るＡＰＩ管理装置１００は、ファイル２からＡＰＩ定義を取得する。また、ＡＰＩ管理装置１００は、ＷｅｂＡＰＩ呼出ログ４を取得する。そして、ＡＰＩ管理装置１００は、ＡＰＩ定義及びＷｅｂＡＰＩ呼出ログ４を用いて、ＷｅｂＡＰＩに含まれる各スキーマの重要度を求める。ＷｅｂＡＰＩ提供者Ｐ１は、ファイル３を用いてスキーマの重要度が示されたＯＡＳをネットワーク１を介して提供する。

さらに、ＷｅｂＡＰＩ提供者Ｐ１は、自分が開発したＷｅｂＡＰＩを修正する場合に、ＡＰＩ管理装置１００により求められたＷｅｂＡＰＩの各スキーマの重要度を用いて、どのような修正を加えるかを決定する。そして、ＷｅｂＡＰＩ提供者Ｐ１は、決定した修正をＷｅｂＡＰＩに加えて、ＷｅｂＡＰＩ提供プログラム５に反映させる。また、ＷｅｂＡＰＩ提供者Ｐ１は、ファイル２にも修正を反映させる。

ＷｅｂＡＰＩ利用者Ｐ２は、ファイル２により提供されるＡＰＩ仕様公開ページやＯＡＳ提供などを用いて、ＷｅｂＡＰＩ提供プログラム５からＷｅｂＡＰＩを呼び出して利用するＷｅｂＡＰＩ利用プログラム６の開発を行う。この際、ＷｅｂＡＰＩ利用者Ｐ２は、ファイル２の情報とともに、ファイル３の情報を用いてＷｅｂＡＰＩに含まれる各スキーマの重要度を基に、ＷｅｂＡＰＩ利用プログラム６の開発を行う。これにより、ＷｅｂＡＰＩ利用者Ｐ２は、呼び出すＷｅｂＡＰＩに修正が加えられても影響が少ないＷｅｂＡＰＩ利用プログラム６を開発できる。

ＷｅｂＡＰＩ利用者Ｐ３は、ＷｅｂＡＰＩ提供プログラム５からＷｅｂＡＰＩを呼び出して利用するＷｅｂＡＰＩ利用プログラム７を使用する。本実施例の場合、ＷｅｂＡＰＩ利用プログラム７からの呼び出しが多く重要度が高いスキーマに対して修正が加えられることが少ないため、そのような重要度が高いスキーマを使用するＷｅｂＡＰＩ利用プログラム７は、安定動作が可能となる。

図２は、ＡＰＩ管理装置のブロック図である。次に、図２を参照して、ＡＰＩ管理装置１００について詳細に説明する。ＡＰＩ管理装置１００は、ＡＰＩ呼出ログ格納部１０１、ＡＰＩ定義ファイル格納部１０２、ＡＰＩ管理部１０３、スキーマ抽出部１０４、個別算出式生成部１０５、階層構造判定部１０６、伝搬部１０７、重要度算出部１０８及び報知部１０９を有する。

ＡＰＩ呼出ログ格納部１０１は、ＡＰＩ管理装置１００が取得したＷｅｂＡＰＩ呼出ログ４を格納する。上述したように、ＷｅｂＡＰＩ呼出ログ４には、ＷｅｂＡＰＩ利用プログラム６及び７による各ＡＰＩ定義に対する呼び出し履歴が含まれる。

ＡＰＩ定義ファイル格納部１０２は、ＡＰＩ管理装置１００がファイル２から取得した図３Ａに示すようなＡＰＩ定義ファイル２００が格納される。図３Ａは、ＡＰＩ定義ファイルの一例を示す図である。ＡＰＩ定義ファイル２００は、ＡＰＩ定義が格納される領域１２１、スキーマ定義が格納される領域１２２及び領域１２３を有する。

図３Ｂは、ＡＰＩ定義ファイルのシンタックスの一例を示す図である。図３Ｂに示すシンタックス１２５は、ＡＰＩ定義ファイル２００を記述したプログラムの一部である。シンタックス１２５における「paths」が領域１２１にあたり、複数のＡＰＩ定義を含む。また、「definitions」が領域１２２にあたり複数のスキーマ定義を含む。そして、「paths」に含まれる各ＡＰＩ定義において、各ＡＰＩ定義が利用するスキーマ定義が指定される。例えば、「paths」の中の行１２６により行１２７に記載された「pet」というスキーマ定義が呼びされる。

図４は、ＡＰＩ定義ファイルにおけるＡＰＩ定義及びスキーマ定義を模式的に表した図である。例えば、ＡＰＩ定義ファイル２００の領域１２１には、複数のＡＰＩ定義２０１が格納される。ここでは、ＡＰＩ定義ファイル２００に含まれる６つのＡＰＩ定義２０１により示されるＡＰＩをそれぞれＡＰＩ＃１〜＃６と表す。

また、ＡＰＩ定義ファイル２００の領域１２２には、複数のスキーマ定義２１０が格納される。ここでは、ＡＰＩ定義ファイル２００に含まれるスキーマ定義２１０で表される各スキーマを、スキーマ＃Ａ〜＃Ｃ、＃ａ〜＃ｃ、並びに、＃α及びβと表す。そして、図４において、重ねられたスキーマ定義２１０は、上に重なるスキーマ定義２１０で表されるスキーマが下のスキーマ定義２１０で表されるスキーマにおいて利用されることを表す。例えば、スキーマ＃Ａは、スキーマ＃ａを利用する。

また、各ＡＰＩ定義２０１は、そのＡＰＩが利用するスキーマのスキーマ定義２１０を含む。例えば、ＡＰＩ＃１は、スキーマ＃Ａ及び＃ｂを利用する。以下の説明では、この図４に模式的に示したＡＰＩ定義２０１を例に説明する。

ＡＰＩ管理部１０３は、ＷｅｂＡＰＩで利用されるＡＰＩ定義ファイル２００をＡＰＩ定義ファイル格納部１０２から取得する。次に、ＡＰＩ管理部１０３は、ＡＰＩ定義ファイル２００から、ＷｅｂＡＰＩで使用されるＡＰＩ定義２０１を抽出する。そして、ＡＰＩ管理部１０３は、抽出した各ＡＰＩ定義２０１で示されるそれぞれのＡＰＩを項目とする図５に示すＡＰＩ管理テーブル２２１を生成する。図５は、ＡＰＩ管理テーブルの一例を示す図である。ここでは、ＡＰＩ管理部１０３は、ＡＰＩ管理テーブル２２１にＡＰＩの識別情報としてＡＰＩ名であるＡＰＩ＃１〜＃６を登録する。

さらに、ＡＰＩ管理部１０３は、各ＡＰＩ＃１〜＃６のそれぞれの呼び出し回数を表す変数をＡＰＩ管理テーブル２２１に設定する。ここでは、ＡＰＩ＃１〜＃６のそれぞれの呼び出し回数について、ｘ、ｙ、ｚ、ｓ、ｔ、ｕを変数として設定する。

その後、ＡＰＩ管理部１０３は、ＡＰＩ呼出ログ格納部１０１に格納されたＡＰＩ呼出ログ４を解析して各ＡＰＩの呼び出し回数を取得する。そして、ＡＰＩ管理部１０３は、ＡＰＩ管理テーブル２２１にＡＰＩ＃１〜＃６のそれぞれの呼び出し回数を登録する。

スキーマ抽出部１０４は、ＷｅｂＡＰＩで利用されるＡＰＩ定義ファイル２００をＡＰＩ定義ファイル格納部１０２から取得する。次に、スキーマ抽出部１０４は、ＡＰＩ定義ファイル２００から、ＡＰＩ＃１〜＃６のそれぞれで使用されるスキーマ定義２１０を抽出する。そして、スキーマ抽出部１０４は、ＡＰＩ定義２０１の識別情報であるＡＰＩ＃１〜＃６と抽出した各スキーマ定義２１０で示されるそれぞれのスキーマの識別情報を対応付ける図６に示す利用スキーマ対応テーブル２２２を生成する。図６は、利用スキーマ対応テーブルの一例を表す図である。例えば、ＡＰＩ管理部１０３は、ＡＰＩ＃１に、スキーマ＃Ａ及び＃ｂを対応付けて利用スキーマ対応テーブル２２２に登録する。

階層構造判定部１０６は、ＷｅｂＡＰＩで利用されるＡＰＩ定義ファイル２００をＡＰＩ定義ファイル格納部１０２から取得する。次に、階層構造判定部１０６は、ＡＰＩ定義ファイル２００から、ＡＰＩ定義ファイル２００で使用される全てのスキーマ定義２１０をそれぞれ抽出する。そして、階層構造判定部１０６は、各スキーマ定義２１０で表されるそれぞれのスキーマの識別情報毎の情報を表す図７に示す階層構造テーブル２２３を生成する。図７は、階層構造テーブルの一例の図である。

次に、階層構造判定部１０６は、階層構造テーブル２２３に登録したスキーマの中からスキーマを１つ選択する。そして、階層構造判定部１０６は、選択したスキーマのスキーマ定義２１０を解析してそのスキーマが下位スキーマを参照するか否かを判定する。

下位スキーマを参照しない場合、階層構造判定部１０６は、下位スキーマの不存在を示す値を、階層構造テーブル２２３における選択したスキーマの下位スキーマを表す項目に登録する。ここでは、階層構造判定部１０６は、下位スキーマの不存在を表す値として、ハイフン（−）を登録する。

これに対して、下位スキーマを参照する場合、階層構造判定部１０６は、その参照される下位スキーマの識別情報を、階層構造テーブル２２３における選択したスキーマの下位スキーマを表す項目に登録する。階層構造判定部１０６は、階層構造テーブル２２３に登録した全てのスキーマに対して下位スキーマの判定を実行する。この階層構造判定部１０６により判定される上位スキーマによる下位スキーマの参照を表す関係が、「参照関係」の一例にあたる。

個別算出式生成部１０５は、ＡＰＩによる各スキーマの利用状況から、ＡＰＩの呼び出し回数に応じた各スキーマの呼び出し回数を求める個別算出式を生成する。以下に、個別算出式生成部１０５による個別算出式の生成の詳細を説明する。

個別算出式生成部１０５は、利用スキーマ対応テーブル２２２をスキーマ抽出部１０４から取得する。また、個別算出式生成部１０５は、ＡＰＩ管理テーブル２２１からＡＰＩ＃１〜＃６のそれぞれの呼び出し回数を表す変数を取得する。

次に、個別算出式生成部１０５は、利用スキーマ対応テーブル２２２に登録されたＡＰＩの中から１つＡＰＩを選択する。次に、個別算出式生成部１０５は、選択したＡＰＩが利用するスキーマの呼び出し回数を表す式に、選択したＡＰＩの呼び出し回数を表す変数を加算する。個別算出式生成部１０５は、利用スキーマ対応テーブル２２２に登録された全てのＡＰＩについて、利用するスキーマの呼び出し回数を表す式への変数の加算を繰り返す。これにより、個別算出式生成部１０５は、全てのスキーマ＃Ａ〜＃Ｃ、＃ａ〜＃ｃ、並びに、＃α及びβのそれぞれの呼び出し回数を表す個別算出式を生成する。

例えば、スキーマ＃ＡはＡＰＩ＃１及びＡＰＩ＃３で利用されるため、個別算出式生成部１０５は、ＡＰＩ＃１の呼び出し回数を表す変数ｘとＡＰＩ＃３の呼び出し回数を表す変数ｚを加算したｘ＋ｚをスキーマ＃Ａの個別算出式とする。

個別算出式生成部１０５は、スキーマ＃Ａ〜＃Ｃ、＃ａ〜＃ｃ、並びに、＃α及びβのそれぞれの個別算出式を伝搬部１０７へ出力する。この個別算出式生成部１０５が、「呼出関係抽出部」の一例にあたる。また、各ＡＰＩとそのＡＰＩから呼び出されるスキーマとの対応関係が、「各ＡＰＩに対する各前記スキーマの呼び出し関係」の一例にあたる。

伝搬部１０７は、各スキーマ＃Ａ〜＃Ｃ、＃ａ〜＃ｃ、並びに、＃α及びβの個別算出式の入力を個別算出式生成部１０５から受ける。また、伝搬部１０７は、階層構造テーブル２２３を階層構造判定部１０６から取得する。そして、伝搬部１０７は、階層構造テーブル２２３の各スキーマに未伝搬フラグを設定する。

伝搬部１０７は、階層構造テーブル２２３に登録されたスキーマ＃Ａ〜＃Ｃ、＃ａ〜＃ｃ、並びに、＃α及びβの中から、上位のスキーマが存在しないスキーマ又は上位のスキーマが全て未伝搬でないスキーマを１つ選択する。ここで、伝搬部１０７は、階層構造テーブル２２３の未伝搬フラグにより各スキーマが未伝搬か否かを判定する。

次に、伝搬部１０７は、選択したスキーマの伝搬後の読み出し回数を求める式、すなわち、個別算出式に上位のスキーマから伝搬された個別算出式を加算した式を、下位のスキーマの読み出し回数を求める式に伝搬させて加算する。ここで、いずれのスキーマにおいても、上位のスキーマからの式の伝搬が行われる前の読み出し回数を求める式は、個別算出式である。その後、伝搬部１０７は、選択したスキーマの階層構造テーブル２２３における未伝搬フラグを削除する。伝搬部１０７は、個別算出式の伝搬を上位のスキーマが存在しないスキーマ又は上位のスキーマが全て未伝搬でないスキーマがなくなるまで繰り返し、全てのスキーマ＃Ａ〜＃Ｃ、＃ａ〜＃ｃ、並びに、＃α及びβに個別算出式を伝搬させる。

伝搬部１０７は、加算結果がスキーマの実際の呼び出し回数を表す式であることから、算出した各加算結果をスキーマ＃Ａ〜＃Ｃ、＃ａ〜＃ｃ、並びに、＃α及びβのそれぞれの重要度の算出式とする。そして、伝搬部１０７は、スキーマ＃Ａ〜＃Ｃ、＃ａ〜＃ｃ、並びに、＃α及びβの識別情報と重要度の算出式との対応を表す図８に示す重要度テーブル２２４を生成する。図８は、重要度テーブルの一例を表す図である。この伝搬部１０７が、「呼出関係抽出部」の一例にあたる。そして、各スキーマの呼び出し回数を表す式が、「各ＡＰＩによる上位スキーマの呼び出しに連動する下位スキーマの呼び出しの関係性」の一例にあたる。

重要度算出部１０８は、重要度テーブル２２４を伝搬部１０７から取得する。また、重要度算出部１０８は、ＡＰＩ管理部１０３が保持するＡＰＩ管理テーブル２２１からＡＰＩ＃１〜＃６のそれぞれの呼び出し回数及びその変数を取得する。

次に、重要度算出部１０８は、取得した呼び出し回数を重要度テーブル２２４に登録された重要度の算出式に代入して、スキーマ＃Ａ〜＃Ｃ、＃ａ〜＃ｃ、並びに、＃α及びβのそれぞれの重要度を求める。その後、重要度算出部１０８は、スキーマ＃Ａ〜＃Ｃ、＃ａ〜＃ｃ、並びに、＃α及びβのそれぞれの重要度を重要度テーブル２２４に登録する。この重要度算出部１０８が、「呼出回数取得部」の一例にあたる。

ここで、図９〜図１１を参照して、スキーマ＃Ａ〜＃Ｃ、＃ａ〜＃ｃ、並びに、＃α及びβの重要度について説明する。図９は、ＡＰＩ定義から直接呼び出された回数を表す図である。図１０は、直接及び間接的に呼び出し元となるＡＰＩを表す図である。図１１は、実施例に係るＡＰＩ管理装置により算出される各スキーマの重要度を表す図である。

スキーマ＃Ａ〜＃Ｃ、＃ａ〜＃ｃ、並びに、＃α及びβがそれぞれ直接ＡＰＩから呼び出される回数を考えた場合、スキーマ＃Ａ〜＃Ｃ、＃ａ〜＃ｃ、並びに、＃α及びβの呼び出し回数は図９に示す値となる。この値を用いた大小は、スキーマ＃Ｃ＞スキーマ＃ｂ＞スキーマ＃Ａ＞スキーマ＃Ｂ＝スキーマ＃α＞スキーマ＃ｃ＞スキーマ＃ａ＞スキーマ＃βと表される。しかし、この値は個別算出式を用いて算出した呼び出し回数にあたり、この値には上位スキーマによる呼び出しが考慮されていない。そのため、上位のスキーマから呼び出される可能性があるスキーマの重要度が低く評価されてしまう。

また、ＡＰＩ定義２０１及びスキーマ定義２１０に基づく呼び出し関係を考えた場合、スキーマ＃Ａ〜＃Ｃ、＃ａ〜＃ｃ、並びに、＃α及びβを直接及び間接的な呼び出し元となるＡＰＩの重複を許した合計数は、図１０に示す値となる。図１０では、各スキーマの脇に呼び出し元となるＡＰＩ定義２０１を重複を許して表示し、さらにその合計数を示した。この値を用いた大小は、スキーマ＃β＞スキーマ＃ｃ＝スキーマ＃α＞スキーマ＃ａ＝スキーマ＃ｂ＞スキーマ＃Ａ＝スキーマ＃Ｃ＞スキーマ＃Ｂと表される。しかし、この値には実際の呼び出し回数が考慮されていない。そのため実際には多く利用されたスキーマの重要度が低く評価されてしまう。

そこで、本実施例に係るＡＰＩ管理装置１００では、直接ＡＰＩから呼び出される回数にＡＰＩ定義２０１及びスキーマ定義２１０に基づく呼び出し関係を加味して、実際の呼び出し回数を求める。その場合の値は、図１１に示すようなる。この場合、上位スキーマからの呼び出しも考慮した、スキーマ＃Ａ〜＃Ｃ、＃ａ〜＃ｃ、並びに、＃α及びβがそれぞれの実際の呼び出し回数を求めることができる。これにより、各スキーマの利用状態に応じた重要度を適切に評価することが可能となる。

図２に戻って説明を続ける。報知部１０９は、重要度算出部１０８が有する重要度テーブル２２４を参照して、スキーマ＃Ａ〜＃Ｃ、＃ａ〜＃ｃ、並びに、＃α及びβのそれぞれの重要度を取得する。そして、報知部１０９は、スキーマ＃Ａ〜＃Ｃ、＃ａ〜＃ｃ、並びに、＃α及びβのそれぞれの重要度をモニタなどに表示することで、ＷｅｂＡＰＩ提供者Ｐ１などに報知する。また、報知部１０９は、スキーマ＃Ａ〜＃Ｃ、＃ａ〜＃ｃ、並びに、＃α及びβのそれぞれの重要度が示されたＯＡＳを提供するファイル３を生成する。

図１２は、各スキーマの重要度の第１の報知例を表す図である。報知部１０９は、例えば、ＷｅｂＡＰＩ提供者Ｐ１がＷｅｂＡＰＩに修正を加える際に、図１２に示すように変更の対象とされたスキーマの重要度が高い場合に影響範囲が大きいことを表す警告を通知する。図１２では、「pet」という名のスキーマの記述３０１が、ＷｅｂＡＰＩ提供者Ｐ１により記述３０２へ変更される。このとき、報知部１０９は、変更対象のスキーマである「pet」の重要度を重要度テーブル２２４から取得する。そして、報知部１０９は、その重要度が重要度テーブル２２４に登録された全てのスキーマの重要度の上から所定数の範囲に入っていた場合に、ＷｅｂＡＰＩ提供者Ｐ１の作業用端末のモニタにメッセージ３０３を表示する。この場合、報知部１０９は、メッセージ３０３として、重要度が高いことを表す警告文とともに、各スキーマの重要度を並べて表示する。

これにより、ＷｅｂＡＰＩ提供者Ｐ１は、そのスキーマの変更の影響範囲が大きいため、その変更の回避が推奨されることを確認できるとともに、影響の少ないスキーマを確認することができ、代替となる他の影響の少ないスキーマを選択することが可能となる。このメッセージ３０３は、他にも、ＷｅｂＡＰＩ利用者Ｐ２がＷｅｂＡＰＩを利用する際に表示しても良い。

図１３は、各スキーマの重要度の第２の報知例を表す図である。報知部１０９は、例えば図１３に示すような重要度表示３２０をモニタに表示するなどして、ＷｅｂＡＰＩ提供者Ｐ１やＷｅｂＡＰＩ利用者Ｐ２に提供する。重要度表示３２０に示すように、報知部１０９は、スキーマの階層構造を有効グラフで表現する。この場合、報知部１０９は、各スキーマを有効グラフにおけるノードとして表す。さらに、報知部１０９は、重要度を各ノードの大きさで表す。

これにより、報知部１０９は、変更時の影響範囲が大きいスキーマをＷｅｂＡＰＩ提供者Ｐ１やＷｅｂＡＰＩ利用者Ｐ２に提供する。ＷｅｂＡＰＩ提供者Ｐ１及びＷｅｂＡＰＩ利用者Ｐ２は、ＷｅｂＡＰＩに含まれる各スキーマの変更による影響範囲を視認でき、容易に影響範囲を把握することができる。また、ＷｅｂＡＰＩ提供者Ｐ１及びＷｅｂＡＰＩ利用者Ｐ２は、影響の少ないスキーマを確認することができ、代替となる他の影響の少ないスキーマを選択することが可能となる。

図１４は、各スキーマの重要度の第３の報知例を表す図である。報知部１０９は、例えば、ＷｅｂＡＰＩ利用者Ｐ２がＷｅｂＡＰＩを利用する際に、図１４に示すように、モニタに表示されたＷｅｂＡＰＩを記述したシンタックス３３０にスキーマの重要度に応じた表示を加える。例えば、報知部１０９は、各スキーマの重要度を重要度テーブル２２４から取得する。そして、報知部１０９は、重要度に応じて、重要度が高い方から低い方へ赤から青に段階的に色が変わるように、シンタックス３３０における各スキーマを表す記述に配色を行う。さらに、報知部１０９は、各色の意味を表す配色情報３３３をモニタに表示させる。例えば、記述３３１で指定されるスキーマの重要度が高い場合に、報知部１０９は、記述３３１を赤色にする。また、例えば、記述３３１で指定されるスキーマの重要度が低い場合に、報知部１０９は、記述３３２を青色にする。さらに、報知部１０９は、赤色の重要度が高く、青色の重要度が低いことを表す配色情報３３３をモニタに表示させる。

これにより、報知部１０９は、重要度が低いスキーマの変更される可能性が高いことを報知する。ＷｅｂＡＰＩ利用者Ｐ２は、各スキーマの重要度によりそれぞれのスキーマの変更される可能性の高低を確認することができる。これにより、ＷｅｂＡＰ利用者Ｐ２は、変更される可能性が低いスキーマを用いて開発を行うことができ、安定したプログラムを開発することが可能となる。この表示は、他にも、ＷｅｂＡＰＩ提供者Ｐ１がＷｅｂＡＰＩを修正する際に表示しても良い。

次に、図１５を参照して、実施例に係るＡＰＩ管理装置１００によるスキーマ重要度決定処理の流れについて説明する。図１５は、実施例に係るＡＰＩ管理装置によるスキーマ重要度決定処理のフローチャートである。

ＡＰＩ管理部１０３は、ＡＰＩ定義ファイル２００をＡＰＩ定義ファイル格納部１０２から取得する。次に、ＡＰＩ管理部１０３は、ＡＰＩ定義ファイル２００から、ＷｅｂＡＰＩで使用されるＡＰＩ定義２０１を抽出する。そして、ＡＰＩ管理部１０３は、抽出した各ＡＰＩ定義２０１で示されるそれぞれのＡＰＩを項目とするＡＰＩ管理テーブル２２１を生成する。さらに、ＡＰＩ管理部１０３は、各ＡＰＩ定義２０１に呼び出し回数を表す変数を割り当てる（ステップＳ１）。

スキーマ抽出部１０４は、ＡＰＩ定義ファイル２００をＡＰＩ定義ファイル格納部１０２から取得する。次に、スキーマ抽出部１０４は、ＡＰＩ定義ファイル２００に含まれるスキーマ定義２１０から各ＡＰＩ定義ファイル２００で使用されるスキーマを抽出する（ステップＳ２）。そして、スキーマ抽出部１０４は、利用スキーマ対応テーブル２２２を生成する。

階層構造判定部１０６は、ＡＰＩ定義ファイル２００をＡＰＩ定義ファイル格納部１０２から取得する。次に、階層構造判定部１０６は、ＡＰＩ定義ファイル２００から、ＡＰＩ定義ファイル２００で使用される全てのスキーマ定義２１０を個別抽出する（ステップＳ３）。そして、階層構造判定部１０６は、階層構造テーブル２２３を生成する。

次に、階層構造判定部１０６は、階層構造テーブル２２３に登録したスキーマの中から下位スキーマを未抽出のスキーマを１つ選択する（ステップＳ４）。

次に、階層構造判定部１０６は、選択したスキーマが下位スキーマを参照するか否かを判定する（ステップＳ５）。

選択したスキーマが下位スキーマを参照する場合（ステップＳ５：肯定）、階層構造判定部１０６は、その参照される下位スキーマを階層構造テーブル２２３に登録する（ステップＳ６）。

これに対して、選択したスキーマが下位スキーマを参照しない場合（ステップＳ５：否定）、階層構造判定部１０６は、下位スキーマの不存在を示す値を階層構造テーブル２２３に登録する（ステップＳ７）。

次に、階層構造判定部１０６は、下位スキーマが未抽出のスキーマがないか否かを判定する（ステップＳ８）。下位スキーマが未抽出のスキーマが残っている場合（ステップＳ８：否定）、階層構造判定部１０６は、ステップＳ４へ戻る。

これに対して、下位スキーマが未抽出のスキーマがない場合（ステップＳ８：肯定）、個別算出式生成部１０５は、利用スキーマ対応テーブル２２２をスキーマ抽出部１０４から取得する。また、個別算出式生成部１０５は、ＡＰＩ管理テーブル２２１から各ＡＰＩのそれぞれの呼び出し回数を表す変数を取得する。次に、個別算出式生成部１０５は、利用スキーマ対応テーブル２２２に登録されたＡＰＩの中から１つＡＰＩを選択する（ステップＳ９）。

次に、個別算出式生成部１０５は、選択したＡＰＩが利用するスキーマの呼び出し回数を表す式に、選択したＡＰＩの呼び出し回数を表す変数を加算する（ステップＳ１０）。

次に、個別算出式生成部１０５は、全てのＡＰＩを用いた個別算出式の生成処理が終了したか否かを判定する（ステップＳ１１）。個別算出式の生成に用いていないＡＰＩが残っている場合（ステップＳ１１：否定）、個別算出式生成部１０５は、ステップＳ９へ戻る。

これに対して、全てのＡＰＩを用いた個別算出式の生成処理が終了した場合（ステップＳ１１：肯定）、伝搬部１０７は、個別算出式の入力を個別算出式生成部１０５から取得する。また、伝搬部１０７は、階層構造テーブル２２３を階層構造判定部１０６から取得する。そして、伝搬部１０７は、階層構造テーブル２２３の各スキーマに未伝搬フラグを設定する（ステップＳ１２）。

次に、伝搬部１０７は、階層構造テーブル２２３に登録されたスキーマの中から、上位のスキーマが存在しないスキーマ又は上位のスキーマが全て未伝搬でないスキーマを１つ選択する（ステップＳ１３）。

次に、伝搬部１０７は、選択したスキーマの呼び出し回数を求める式を下位のスキーマに伝搬させて、下位のスキーマの呼び出し回数を求める式に加算する（ステップＳ１４）。

その後、伝搬部１０７は、選択したスキーマの階層構造テーブル２２３における未伝搬フラグを削除する（ステップＳ１５）。

伝搬部１０７は、個別算出式の伝搬を上位のスキーマが存在しないスキーマ又は上位のスキーマが全て未伝搬でないスキーマがないという選択条件に一致するスキーマが存在するか否かを判定する（ステップＳ１６）。選択条件に一致するスキーマが残っている場合（ステップＳ１６：肯定）、伝搬部１０７は、ステップＳ１３へ戻る。

これに対して、選択条件に一致するスキーマが存在しない場合（ステップＳ１６：否定）、重要度算出部１０８は、重要度テーブル２２４を伝搬部１０７から取得する。また、重要度算出部１０８は、ＡＰＩ管理部１０３が保持するＡＰＩ管理テーブル２２１からＡＰＩのそれぞれの呼び出し回数を取得する（ステップＳ１７）。

次に、重要度算出部１０８は、取得した呼び出し回数を重要度テーブル２２４に登録された重要度の算出式に代入して各スキーマの重要度を算出する（ステップＳ１８）。その後、重要度算出部１０８は、各スキーマの重要度を重要度テーブル２２４に登録する。

報知部１０９は、重要度テーブル２２４を重要度算出部１０８から取得する。その後、報知部１０９は、各スキーマの重要度に応じた報知を実行する（ステップＳ１９）。

以上に説明したように、本実施例に係るＡＰＩ管理装置は、ＷｅｂＡＰＩに含まれる各ＡＰＩの呼び出し回数、並びに、ＡＰＩ定義及びスキーマ定義を用いて各スキーマの実際の呼び出し回数に応じた重要度を求める。そして、ＡＰＩ管理装置は、求めた重要度をＷｅｂＡＰＩの提供者及び利用者に通知する。この場合、ＡＰＩの呼び出し履歴をログとして保持すればよく、スキーマ毎の呼び出し履歴を保持しなくてもよいため、スキーマを階層化した場合にもログの記録量を少なく抑えることができる。そのため、ログの検索処理の短縮が可能となり、各スキーマの利用頻度の算出が容易に行え、確度の高い重要度を容易に求めることができる。そして、確度の高い重要度に応じた報知を行うことで、各スキーマの変更による影響範囲を通知することができ、修正による影響を抑えた適切なＷｅｂＡＰＩの提供や、変更の可能性が少ないスキーマを用いたＷｅｂＡＰＩの利用が可能となる。したがって、本実施例に係るＡＰＩ管理装置を用いることで、効率的な開発環境を整えることが可能となる。

１００ ＡＰＩ管理装置
１０１ ＡＰＩ呼出ログ格納部
１０２ ＡＰＩ定義ファイル格納部
１０３ ＡＰＩ管理部
１０４ スキーマ抽出部
１０５ 個別算出式生成部
１０６ 階層構造判定部
１０７ 伝搬部
１０８ 重要度算出部
１０９ 報知部
Ｐ１ ＷｅｂＡＰＩ提供者
Ｐ２，Ｐ３ ＷｅｂＡＰＩ利用者

Claims (8)

1. １つ又は複数のスキーマ定義を呼び出す複数のＡＰＩ定義を有するＷｅｂＡＰＩにおける各前記スキーマ定義から各前記スキーマ定義で示される各スキーマにおける上位スキーマと下位スキーマとの参照関係を抽出し、
   前記ＡＰＩ定義から各前記ＡＰＩ定義で示される各ＡＰＩに対する各前記スキーマの呼び出し関係を抽出し、
   前記参照関係及び前記呼び出し関係を基に、各前記ＡＰＩによる前記上位スキーマの呼び出しに連動する前記下位スキーマの呼び出しの関係性を求め、
   各前記ＡＰＩの呼び出し回数と前記関係性に基づいて、各前記スキーマの呼び出し回数を算出する
   処理をコンピュータに実行させることを特徴とする管理プログラム。
2. 前記関係性は、各前記ＡＰＩが呼び出された場合に、各前記ＡＰＩから前記上位スキーマを介して呼び出される前記下位スキーマを示し、
   各前記ＡＰＩから直接呼び出される回数及び前記下位スキーマとして呼び出される回数を合計した値を各前記スキーマの前記呼び出し回数とする
   処理をコンピュータに実行させることを特徴とする請求項１に記載の管理プログラム。
3. 各前記スキーマの呼び出し回数が多いほど高くなるように重要度を設定し、前記重要度を報知する処理をコンピュータにさらに実行させることを特徴とする請求項１又は２に記載の管理プログラム。
4. 前記ＷｅｂＡＰＩにおける特定のスキーマが修正される場合に、前記特定のスキーマの重要度を報知する処理をコンピュータに実行させることを特徴とする請求項３に記載の管理プログラム。
5. 前記重要度が高いほど表示サイズが大きくなるように、前記ＷｅｂＡＰＩに含まれる各前記スキーマを表示装置に表示させる処理をコンピュータに実行させることを特徴とする請求項３に記載の管理プログラム。
6. 前記ＷｅｂＡＰＩを表すプログラムを表示する場合に、前記重要度に応じた色付けを前記プログラム内で記述される前記スキーマ定義毎に行う処理をコンピュータに実行させることを特徴とする請求項３に記載の管理プログラム。
7. １つ又は複数のスキーマ定義を呼び出す複数のＡＰＩ定義を有するＷｅｂＡＰＩにおける各前記スキーマ定義から各前記スキーマ定義で示される各スキーマにおける上位スキーマと下位スキーマとの参照関係を抽出し、
   前記ＡＰＩ定義から各前記ＡＰＩ定義で示される各ＡＰＩに対する各前記スキーマの呼び出し関係を抽出し、
   前記参照関係及び前記呼び出し関係を基に、各前記ＡＰＩによる前記上位スキーマの呼び出しに連動する前記下位スキーマの呼び出しの関係性を求め、
   各前記ＡＰＩの呼び出し回数と前記関係性に基づいて、各前記スキーマの呼び出し回数を算出する
   ことを特徴とする管理方法。
8. １つ又は複数のスキーマ定義を呼び出す複数のＡＰＩ定義を有するＷｅｂＡＰＩにおける各前記スキーマ定義から各前記スキーマ定義で示される各スキーマにおける上位スキーマと下位スキーマとの参照関係を抽出する階層構造判定部と、
   前記ＡＰＩ定義から各前記ＡＰＩ定義で示される各ＡＰＩに対する各前記スキーマの呼び出し関係を抽出する呼出関係抽出部と、
   前記参照関係及び前記呼び出し関係を基に、各前記ＡＰＩによる前記上位スキーマの呼び出しに連動する前記下位スキーマの呼び出しの関係性を求める関係性取得部と、
   各前記ＡＰＩの呼び出し回数と前記関係性に基づいて、各前記スキーマの呼び出し回数を算出する呼出回数算出部と
   を備えたことを特徴とする管理装置。

Images