JP6721548B2

JP6721548B2 - 設計確認装置及び設計確認方法

Info

Publication number: JP6721548B2
Application number: JP2017147448A
Authority: JP
Inventors: 真吾小俣
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2017-07-31
Filing date: 2017-07-31
Publication date: 2020-07-15
Anticipated expiration: 2037-07-31
Also published as: JP2019028723A

Description

本発明は、ＡＰＩの設計ルールを規定し、ＡＰＩ設計書がルールに準拠しているか否か確認する技術に関する。

近年、様々なネットワークサービスがアプリケーションプログラミングインタフェース（ＡＰＩ）という形で提供されている。

ＡＰＩ設計に関する技術として、非特許文献１，２の技術が知られている。非特許文献１は、所定の仕様に準じたＡＰＩ設計書の作成を支援する技術である。

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

"Swagger Editor"、［online］、SmartBear Software、［平成29年6月21日検索］、インターネット〈 URL：http://swagger.io/swagger-editor/〉 "API Blueprint"、［online］、api blueprint、［平成29年6月21日検索］、インターネット〈 URL：https://apiblueprint.org/〉菊間、外３名、「大規模通信ソフト開発における要求仕様書からの試験項目作成自動化に関する検討」、第１１回ネットワークソフトウェア研究会、電子情報通信学会、２０１６年

非特許文献１の技術は、構文／文法的なエラーを検出することはできるが、ＡＰＩの設計ルールを独自に設定／カスタマイズすることはできない。また、ＡＰＩで使用するメソッドがＣＲＵＤ（Ｃｒｅａｔｅ，Ｒｅａｄ，Ｕｐｄａｔｅ，Ｄｅｌｅｔｅ）の考え方に従っているか等、メソッドの使用用途の違いや矛盾によって生じるエラーを検出することはできない。非特許文献３は、仕様書を解析する技術であるが、ＲＥＳＴＡＰＩの領域で使用可能なメソッドが限定的である特徴を活かした解析についての言及はない。

本発明は、上記に鑑みてなされたものであり、ＡＰＩの設計ルールをカスタマイズ可能とし、設計ルールに対する準拠性確認の負担を軽減することを目的とする。

第１の本発明に係る設計確認装置は、アプリケーションプログラミングインタフェースを設計する際のルールを記述した設計ルールを入力する設計ルール入力手段と、前記設計ルールを解析してチェックポリシーを作成する設計ルール解析手段と、アプリケーションプログラミングインタフェースの設計書を入力し、前記チェックポリシーに基づいて前記設計ルールに準拠しているか否かを判定する設計書チェック手段と、を有することを特徴とする。

第２の本発明に係る設計確認方法は、設計確認装置によって実行される設計確認方法であって、アプリケーションプログラミングインタフェースを設計する際のルールを記述した設計ルールを入力するステップと、前記設計ルールを解析してチェックポリシーを作成するステップと、アプリケーションプログラミングインタフェースの設計書を入力し、前記チェックポリシーに基づいて前記設計ルールに準拠しているか否かを判定するステップと、を有することを特徴とする。

本発明によれば、ＡＰＩの設計ルールをカスタマイズ可能とし、設計ルールに対する準拠性確認の負担を軽減することができる。

本実施形態の設計確認装置１の構成を示す機能ブロック図である。ＡＰＩ記述ルールの例を示す図である。ＡＰＩ設計書の例を示す図である。

以下、本発明の実施の形態について図面を用いて説明する。

図１は、本実施形態の設計確認装置１の構成を示す機能ブロック図である。同図に示す設計確認装置１は、ＡＰＩ記述ルール入力部１１、ＡＰＩ記述ルール解析部１２、チェックポリシー設定部１３、準拠性チェック処理部１４、ＡＰＩ設計エディタ部１５、及びＡＰＩ記述ルール設定方式入力部１６を備える。設計確認装置１が備える各部は、演算処理装置、記憶装置等を備えたコンピュータにより構成して、各部の処理がプログラムによって実行されるものとしてもよい。このプログラムは設計確認装置１が備える記憶装置に記憶されており、磁気ディスク、光ディスク、半導体メモリ等の記録媒体に記録することも、ネットワークを通して提供することも可能である。以下、設計確認装置１の各部について説明する。

ＡＰＩ記述ルール入力部１１は、アノテーションや正規表現等の一般的なプログラミング言語、または、設計確認装置１が指定するＡＰＩ特有の記述様式に従って記載されたＡＰＩ記述ルールを入力する。入力したＡＰＩ記述ルールはＡＰＩ記述ルール解析部１２に送られる。ＡＰＩ記述ルールとは、例えば、ＡＰＩのリソース名、パラメータ名に使用してはいけない文字や文字列を規定したルール、及びＡＰＩで使用するメソッドの使用用途を規定したルールなどである。メソッドの使用用途は、ＲＥＳＴＡＰＩのメソッドが限定的な特徴を活かしてルールを規定できる。

ＡＰＩ記述ルール解析部１２は、システム運用者によって事前に規定された記述様式に従い、ＡＰＩ記述ルールを解析してチェックポリシーを決定する。決定されたチェックポリシーはチェックポリシー設定部１３に送られる。

チェックポリシー設定部１３で、システム運用者は、チェックポリシーに間違いのないことを確認する。チェックポリシーに間違いのないことが確認されると、チェックポリシー設定部１３は、チェックポリシーを準拠性チェック処理部１４に反映する。

準拠性チェック処理部１４は、ＡＰＩ設計者からＡＰＩ設計書の入力を受け付け、入力されたＡＰＩ設計書をチェックポリシーに基づいてチェックし、チェックポリシーに沿っていない非準拠箇所をＡＰＩ設計者に通知する。ＡＰＩ設計者は、設計確認装置１の備えるＡＰＩ設計エディタ部１５を用いてＡＰＩ設計書を入力してもよいし、設計確認装置１の提供するＡＰＩを用いてＡＰＩ設計書を送付してもよい。ＡＰＩ設計者がＡＰＩ設計エディタ部１５を用いたときは、ＡＰＩ設計書の非準拠箇所をＡＰＩ設計エディタ部１５に出力し、ＡＰＩ設計者に通知する。

ＡＰＩ記述ルール設定方式入力部１６は、システム運用者からＡＰＩ記述ルールの記述様式を入力する。ＡＰＩ記述ルール作成者は、ＡＰＩ記述ルール設定方式入力部１６で設定された記述様式に従ってＡＰＩ記述ルールを記載する。

なお、ＡＰＩ記述ルール入力部１１及び準拠性チェック処理部１４の機能をＡＰＩとして提供し、複数事業者で共通システムとして用いることで、複数事業者のＡＰＩ記述ルールに従ったチェックポリシーの統合が可能となる。

次に、ＡＰＩ記述ルールの例について説明する。

図２は、ＡＰＩ記述ルールの例を示す図である。同図のＡＰＩ記述ルールは、構文的記述ルールの規定例とメソッド使用ルールの規定例を含んでいる。

まず、構文的記述ルールの規定例について説明する。図２の例では、ＡＰＩのリソース名、パラメータ名に、アプリが動作する上でバグの原因となる恐れのある文字「％」，「：」，「￥」，「￥￥」（バックスラッシュ）の使用を禁止するルールが記載されている。具体的には、図２の２行目の“@NGcheck\Resource”は、設計確認装置１に設定された記述様式であり、ＡＰＩ設計書内の各ＡＰＩのリソース名に特定の文字、文字列が存在する場合にエラー情報を出力するルールである。また、４行目の“@NGcheck\Parameters”は、各ＡＰＩのパラメータ名に特定の文字、文字列が存在する場合にエラー情報を出力するルールである。３行目と５行目に、使用してはいけない文字、文字列が正規表現等で記述されている。

続いて、メソッド使用ルールの規定例について説明する。ＡＰＩ記述ルールとして、各メソッドの使用用途を表１のように規定したと仮定する。

本実施形態では、表１で規定したルールに反して用途に合っていないメソッドが使われている場合にエラー情報を出力する。図２の例では、８行目の“@NGcheck\Api”が、一つのエンドポイント毎のＡＰＩに関する設計（概要やメソッド）において、特定の条件に当てはまる記述が存在する場合にエラー情報を出力するルールである。９行目はエラー情報を出力するポリシーである。図２の例では、ＡＰＩ設計書に記載されるＡＰＩ説明文（ｄｅｓｃｒｉｐｔｉｏｎ部）に「更新」，「ｃｒｅａｔｅ」，「追加」，「ａｄｄ」，「削除」，「ｄｅｌｅｔｅ」のいずれかの記述があり、ＧＥＴメソッドを使用している場合にエラー情報を出力する。

図３に、ＡＰＩ設計書の例を示す。図３に示したＡＰＩでは、３行目にＧＥＴメソッドを使用することが記載されており、７行目のＡＰＩの説明欄に“Create”の記述がある。つまり、このＡＰＩは、リソースを新規に作成するＡＰＩにもかかわらずＧＥＴを用いている。したがって、このＡＰＩ設計書を設計確認装置１に入力した場合、用途に合っていないメソッドが使われている旨のエラー情報が出力される。

以上説明したように、本実施形態によれば、設計確認装置１が、ＡＰＩのリソース名、パラメータ名に使用してはいけない文字や文字列を規定したルール及びＡＰＩで使用するメソッドの使用用途を規定したルールを記述したＡＰＩ記述ルールを入力するＡＰＩ記述ルール入力部１１と、ＡＰＩ記述ルールを解析してチェックポリシーを決定するＡＰＩ記述ルール解析部１２と、ＡＰＩ設計者からＡＰＩ設計書の入力を受け付けて、入力されたＡＰＩ設計書をチェックポリシー基づいてチェックする準拠性チェック処理部１４を有することにより、ＡＰＩ設計ルールの設定／カスタマイズが可能となり、設計ルールに対する準拠性確認の負担を軽減できる。

本実施形態によれば、ＡＰＩ記述ルール入力部１１及び準拠性チェック処理部１４の機能をＡＰＩとして提供し、複数事業者で共通システムとして用いることで、複数事業者のＡＰＩ記述ルールに従ったチェックポリシーの統合が可能となる。

１…設計確認装置
１１…ＡＰＩ記述ルール入力部
１２…ＡＰＩ記述ルール解析部
１３…チェックポリシー設定部
１４…準拠性チェック処理部
１５…ＡＰＩ設計エディタ部
１６…ＡＰＩ記述ルール設定方式入力部

Claims

アプリケーションプログラミングインタフェースを設計する際のルールを記述した設計ルールを入力する設計ルール入力手段と、
前記設計ルールを解析してチェックポリシーを作成する設計ルール解析手段と、
アプリケーションプログラミングインタフェースの設計書を入力し、前記チェックポリシーに基づいて前記設計ルールに準拠しているか否かを判定する設計書チェック手段と、
を有することを特徴とする設計確認装置。
前記設計ルール入力手段は、複数の前記設計ルールを入力し、
前記設計ルール解析手段は、前記複数の設計ルールの解析結果を統合して前記チェックポリシーを作成することを特徴とする請求項１に記載の設計確認装置。
前記設計ルールは、使用禁止の文字及び文字列を規定することを特徴とする請求項１又は２に記載の設計確認装置。
前記設計ルールは、前記アプリケーションプログラミングインタフェースの使用するメソッドの使用用途を規定することを特徴とする請求項１乃至３のいずれかに記載の設計確認装置。
設計確認装置によって実行される設計確認方法であって、
アプリケーションプログラミングインタフェースを設計する際のルールを記述した設計ルールを入力するステップと、
前記設計ルールを解析してチェックポリシーを作成するステップと、
アプリケーションプログラミングインタフェースの設計書を入力し、前記チェックポリシーに基づいて前記設計ルールに準拠しているか否かを判定するステップと、
を有することを特徴とする設計確認方法。
前記設計ルールを入力するステップでは、複数の前記設計ルールを入力し、
前記チェックポリシーを作成するステップでは、前記複数の設計ルールの解析結果を統合して前記チェックポリシーを作成することを特徴とする請求項５に記載の設計確認方法。
前記設計ルールは、使用禁止の文字及び文字列を規定することを特徴とする請求項５又は６に記載の設計確認方法。
前記設計ルールは、前記アプリケーションプログラミングインタフェースの使用するメソッドを規定することを特徴とする請求項５乃至７のいずれかに記載の設計確認方法。