(57)【要約】【課題】ＷｅｂＡＰＩ仕様書を簡単に作成すること。【解決手段】関係解析部１１がクラス関係情報２に基づいて想定エンドポイントを生成する。また、ログ解析部１３がアクセスログ３からクラス関係情報２を参照して名詞動詞情報を抽出し、実エンドポイント生成部１６が名詞動詞情報の動詞をＨＴＴＰメソッド名に変換し、名詞をパスに変換することで実エンドポイントを生成する。そして、マージ部１８が実エンドポイントのうち関係解析部１１により生成された想定エンドポイントに含まれるエンドポイントを仕様エンドポイントとして特定する。【選択図】図２
2018055625.tif 000002
【特許請求の範囲】
【請求項１】
既存のウェブアプリケーションのクラス間の関係を表すクラス関係情報に基づいて、該関係から想定されるＡＰＩ仕様情報である想定エンドポイントを生成する想定エンドポイント生成部と、
前記ウェブアプリケーションを実行した際に出力されるアクセスログから、実行結果に基づくＡＰＩ仕様情報である実エンドポイントのもとになる動詞及び名詞を前記クラス関係情報を参照して抽出する抽出部と、
前記抽出部により抽出された動詞をメソッド名に変換し、前記抽出部により抽出された名詞をパスに変換することにより前記実エンドポイントを生成する実エンドポイント生成部と、
前記実エンドポイント生成部により生成された実エンドポイントのうち前記想定エンドポイント生成部により生成された想定エンドポイントに含まれるエンドポイントを前記ウェブアプリケーションのＡＰＩ仕様情報として特定する特定部
を有することを特徴とする情報処理装置。
【請求項２】
前記特定部により特定されたＡＰＩ仕様情報と前記ウェブアプリケーションの設計情報に基づいて、前記ウェブアプリケーションのＡＰＩ仕様書を作成する作成部をさらに有することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記抽出部は、前記アクセスログに含まれる名詞が前記クラス関係情報にクラス名として含まれる場合に、該名詞を前記実エンドポイントのもとになる名詞として抽出することを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記想定エンドポイント生成部は、２つのクラスのクラス名のうち１つ又は２つを用いて生成される全てのＵＲＬから、該２つのクラス間の関係が一方向、双方向、基本集約、複合集約、継承又は実現のいずれであるかと該２つのクラス間の多重度の関係とに基づいて想定されないＵＲＬを除外したＵＲＬを用いて前記想定エンドポイントを生成することを特徴とする請求項１、２又は３に記載の情報処理装置。
【請求項５】
前記アクセスログは、画面のアクセスログであることを特徴とする請求項１〜４のいずれか１つに記載の情報処理装置。
【請求項６】
コンピュータが、
既存のウェブアプリケーションのクラス間の関係を表すクラス関係情報に基づいて、該関係から想定されるＡＰＩ仕様情報である想定エンドポイントを生成し、
前記ウェブアプリケーションを実行した際に出力されるアクセスログから、実行結果に基づくＡＰＩ仕様情報である実エンドポイントのもとになる動詞及び名詞を前記クラス関係情報を参照して抽出し、
抽出した動詞をメソッド名に変換し、抽出した名詞をパスに変換することにより前記実エンドポイントを生成し、
生成した実エンドポイントのうち生成した想定エンドポイントに含まれるエンドポイントを前記ウェブアプリケーションのＡＰＩ仕様情報として特定する
処理を実行することを特徴とする仕様書作成方法。
【請求項７】
コンピュータに、
既存のウェブアプリケーションのクラス間の関係を表すクラス関係情報に基づいて、該関係から想定されるＡＰＩ仕様情報である想定エンドポイントを生成し、
前記ウェブアプリケーションを実行した際に出力されるアクセスログから、実行結果に基づくＡＰＩ仕様情報である実エンドポイントのもとになる動詞及び名詞を前記クラス関係情報を参照して抽出し、
抽出した動詞をメソッド名に変換し、抽出した名詞をパスに変換することにより前記実エンドポイントを生成し、
生成した実エンドポイントのうち生成した想定エンドポイントに含まれるエンドポイントを前記ウェブアプリケーションのＡＰＩ仕様情報として特定する
処理を実行させることを特徴とする仕様書作成プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、仕様書作成方法及び仕様書作成プログラムに関する。
【背景技術】
【０００２】
ＡＰＩ（Application  Programming  Interface）は、アプリケーション（以下、単に「アプリ」という）からデータ、機能を利用するために提供されるインタフェースであり、データの提供者あるいは機能の開発者によって作成され、公開される。既存のウェブアプリ（Ｗｅｂアプリ）にＷｅｂＡＰＩを新たに設けることで、既存のウェブアプリのデータ、機能を他のアプリからＷｅｂ経由で物理的な場所を意識せずに使用することが可能となる。
【０００３】
図２０は、ＷｅｂＡＰＩを説明するための図である。図２０は、新規契約、審査、顧客情報変更等の機能を有し、サーバで動作するウェブアプリであるモバイル契約管理に顧客データを提供するＷｅｂＡＰＩ、契約データを提供するＷｅｂＡＰＩ、割引データを提供するＷｅｂＡＰＩを設けた場合を示す。ＷｅｂＡＰＩの利用を含むロジックを他のアプリに組み込むことによって、モバイル契約管理の顧客データ、契約データ、割引データを他のアプリから利用することができる。他のアプリは、スマホ（スマートフォン）、タブレット、ＰＣ（Personal  Computer）等で動作してもよい。
【０００４】
このようなＷｅｂＡＰＩを用いることによって、今まで接触できなかった新たな顧客にもサービスを提供することができ、また、システム間でデータや処理を連携することで新たなサービスを提供することができる。
【０００５】
ＷｅｂＡＰＩを利用するためには、ＷｅｂＡＰＩの仕様について記載したＷｅｂＡＰＩ仕様書が必要になる。しかしながら、ＷｅｂＡＰＩを設けることによる効果がどのくらいあるかはＷｅｂＡＰＩを設ける時点では不明であるため、少ないコストでＷｅｂＡＰＩ仕様書を簡単に作成することが望まれる。そこで、ＷｅｂＡＰＩを実装するとともに適切なコメントが記載されたソースコードからＷｅｂＡＰＩ仕様書を作成する技術がある。
【０００６】
なお、実行プログラムから出力された実行ログに基づいて、実際に実行されたオブジェクトとそのオブジェクトで使用するテーブルとの関係を示す設計書を作成する従来技術がある。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００９−２３０６１８号公報
【非特許文献】
【０００８】
【非特許文献１】Swagger-maven-plugin、［平成２８年９月１２日検索］、インターネット＜URL:http://kongchen.github.io/swagger-maven-plugin/＞
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、既存のウェブアプリのソースコードから、ＷｅｂＡＰＩを実装するとともに適切なコメントが記載されたソースコードを作成することは簡単ではないという問題がある。このため、ＷｅｂＡＰＩを実装するソースコードがなくてもＷｅｂＡＰＩ仕様書を簡単に作成することが望まれる。
【００１０】
本発明は、１つの側面では、ＷｅｂＡＰＩ仕様書を簡単に作成することを目的とする。
【課題を解決するための手段】
【００１１】
１つの態様では、情報処理装置は、想定エンドポイント生成部と、抽出部と、実エンドポイント生成部と、特定部とを有する。想定エンドポイント生成部は、既存のウェブアプリケーションのクラス間の関係を表すクラス関係情報に基づいて、該関係から想定されるＡＰＩ仕様情報である想定エンドポイントを生成する。抽出部は、ウェブアプリケーションを実行した際に出力されるアクセスログから、実行結果に基づくＡＰＩ仕様情報である実エンドポイントのもとになる動詞及び名詞をクラス関係情報を参照して抽出する。実エンドポイント生成部は、抽出部により抽出された動詞をメソッド名に変換し、抽出部により抽出された名詞をパスに変換することにより実エンドポイントを生成する。特定部は、実エンドポイント生成部により生成された実エンドポイントのうち想定エンドポイント生成部により生成された想定エンドポイントに含まれるエンドポイントをウェブアプリケーションのＡＰＩ仕様情報として特定する。
【発明の効果】
【００１２】
１つの側面では、ＷｅｂＡＰＩ仕様書を簡単に作成することができる。
【図面の簡単な説明】
【００１３】
【図１】図１は、実施例に係る仕様書作成装置を説明するための図である。
【図２】図２は、実施例に係る仕様書作成装置の機能構成を示す図である。
【図３】図３は、クラス関係情報を表すクラス図の一例を示す図である。
【図４】図４は、クラス関係情報から想定エンドポイントを生成する際に用いられる表を示す図である。
【図５】図５は、図３に示したクラス図から生成される想定エンドポイントを示す図である。
【図６】図６は、ＡｃｃｏｕｎｔとＯｐｅｒａｔｏｒから生成されるＵＲＬを説明するための図である。
【図７】図７は、想定エンドポイント記憶部の一例を示す図である。
【図８】図８は、図３に示したクラス図に対応するウェブアプリの画面遷移を示す図である。
【図９】図９は、画面アクセスログの一例を示す図である。
【図１０】図１０は、名詞動詞記憶部の一例を示す図である。
【図１１】図１１は、変換情報記憶部の一例を示す図である。
【図１２】図１２は、実エンドポイント記憶部の一例を示す図である。
【図１３】図１３は、仕様エンドポイント記憶部の一例を示す図である。
【図１４】図１４は、仕様書作成処理のフローを示すフローチャートである。
【図１５Ａ】図１５Ａは、想定エンドポイントを生成する処理のフローを示す第１のフローチャートである。
【図１５Ｂ】図１５Ｂは、想定エンドポイントを生成する処理のフローを示す第２のフローチャートである。
【図１６】図１６は、名詞動詞情報を生成する処理のフローを示すフローチャートである。
【図１７】図１７は、実エンドポイントを生成する処理のフローを示すフローチャートである。
【図１８】図１８は、仕様エンドポイントを生成する処理のフローを示すフローチャートである。
【図１９】図１９は、実施例に係る仕様書作成プログラムを実行するコンピュータのハードウェア構成を示す図である。
【図２０】図２０は、ＷｅｂＡＰＩを説明するための図である。
【発明を実施するための形態】
【００１４】
以下に、本願の開示する情報処理装置、仕様書作成方法及び仕様書作成プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。
【実施例】
【００１５】
まず、実施例に係る仕様書作成装置について説明する。図１は、実施例に係る仕様書作成装置を説明するための図である。図１に示すように、実施例に係る仕様書作成装置は、クラス間の関係についての情報であるクラス関係情報２とアクセスログ３を用いてＷｅｂＡＰＩ仕様書を作成する。そして、ユーザは、ＷｅｂＡＰＩ仕様書に基づいてＷｅｂＡＰＩを使ってデータを要求し、応答を得る。要求応答７は、ＷｅｂＡＰＩを使ったデータの要求と応答を示す。
【００１６】
クラス関係情報２は、クラス図で表される情報である。アクセスログ３は、ここでは、画面がアクセスされた際に出力されるログである。図１では、モバイル契約管理において、顧客情報を表示する画面８が表示されたときに出力されたログ（アクセスログ３の１行目）、表示された情報が変更されたときに出力されたログ（アクセスログ３の２行目）の例が示されている。
【００１７】
要求応答７において、ＷｅｂＡＰＩ  Ｒｅｑｕｅｓｔは、ＷｅｂＡＰＩを用いたデータの取得要求である。「ＧＥＴ  ／ｕｓｅｒ／１」は、エンドポイントと呼ばれる。エンドポイントは、ＷｅｂＡＰＩ仕様の基本となる情報である。エンドポイントには、ＨＴＴＰ（Hypertext  Transfer  Protocol）メソッド名とアクセス先のＵＲＬ（Uniform  Resource  Locator）が含まれる。「ＧＥＴ」がＨＴＴＰメソッド名である。「／ｕｓｅｒ／１」がアクセス先のＵＲＬである。このＵＲＬは、「１」で識別される顧客（ｕｓｅｒ）の情報を指定している。「ＧＥＴ  ／ｕｓｅｒ／１」は、「１」で識別される顧客の情報を取得することを表す。
【００１８】
「ＨＴＴＰ／１．１」は、プロトコルを示す。「Ｈｏｓｔ：」は、アクセス先のドメインを示す。ここでは、アクセス先は、「ａｐｉ．ｓｙｓｔｅｍ．ｃｏ．ｊｐ」である。「Ａｃｃｅｐｔ：」は、応答として受け取れる形式を示す。ここでは、応答として受け取れる形式は、「ａｐｐｌｉｃａｔｉｏｎ／ｊｓｏｎ」である。
【００１９】
ＷｅｂＡＰＩ  Ｒｅｓｐｏｎｓｅは、データの取得要求に対する応答である。「２００  ＯＫ」は、正常な応答であってステータス値が「２００」であることを示す。「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：」は、応答内容の形式を示す。「ｃｈａｒｓｅｔ＝」は、文字コードを示す。ここでは、文字コードは、「ＵＴＦ−８」である。｛“ｎａｍｅ”：“Ｔａｒｏ”，“ｓｅｘ”：“Ｍａｌｅ”，“ｂｉｒｔｈｄａｙ”：“１９９０／１１／２１”｝は、得られたデータを示す。
【００２０】
次に、実施例に係る仕様書作成装置の機能構成について説明する。図２は、実施例に係る仕様書作成装置の機能構成を示す図である。図２に示すように、仕様書作成装置１は、関係解析部１１と、想定エンドポイント記憶部１２と、ログ解析部１３と、名詞動詞記憶部１４と、変換情報記憶部１５と、実エンドポイント生成部１６と、実エンドポイント記憶部１７と、マージ部１８とを有する。また、仕様書作成装置１は、仕様エンドポイント記憶部１９と、作成部２０とを有する。
【００２１】
関係解析部１１は、クラス関係情報２をファイルから入力し、クラス関係情報２に基づいて想定エンドポイントを生成する。ここで、想定エンドポイントとは、クラス関係情報２から想定されるエンドポイントである。図３は、クラス関係情報２を表すクラス図の一例を示す図である。図３において、四角はクラスを表す。クラスの情報には、クラス名と、名前及び型とが含まれる。
【００２２】
例えば、Ａｃｃｏｕｎｔという名前のクラスには、整数型の名前ｉｄと、文字型の名前ｎａｍｅが含まれる。＜＜ｉｎｔｅｒｆａｃｅ＞＞は、クラスがインタフェースクラスであることを表す。例えば、Ｓｅｒｖｉｃｅという名前のクラスはインタフェースクラスである。
【００２３】
クラス間のリンクは、クラス間の関係を表す。実線は、双方向の関係（BiDirected  Association）を表す。→は、一方向の関係（Directed  Association）を表す。矢頭が白のひし形である実線の矢印は、基本集約の関係（Basic  Aggregation）を表す。矢頭が黒のひし形である実線の矢印は、複合集約の関係（Composition  Aggregation）を表す。矢頭が白の三角である実線の矢印は、継承の関係（Inheritance）を表す。矢頭が白の三角である破線の矢印は、実現の関係（Realization）を表す。
【００２４】
クラス間のリンクには多重度（multiplicity）に関する情報が付加される。多重度には、１（One）対１、１対多（＊：Many）、多（＊）対１、多（＊）対多（＊）がある。
【００２５】
図４は、クラス関係情報２から想定エンドポイントを生成する際に用いられる表を示す図である。関係解析部１１は、関係のある２つのクラスの名前のうち１つ又は２つを用いて生成可能な全てのＵＲＬを生成する。図４では、ｐａとｐｂがクラス名である。クラス名に付加された「＊」は、クラスがインタフェースクラスであることを示す。また、「：ｉｄ」は、インスタンスを識別する識別子である。
【００２６】
図４では、生成されるＵＲＬは１列目に示される。ただし、１列目は、ｐａとｐｂがインタフェースクラスでない場合を示す。関係解析部１１は、ｐａがインタフェースクラスであるか否かを判定し、インタフェースクラスである場合には、ｐａの名前に「＊」を付加する。２列目は、ｐａがインタフェースクラスである場合に生成されるＵＲＬを示す。
【００２７】
そして、関係解析部１１は、ｐａの多重度を判定し、判定結果に基づいて、想定されないＵＲＬを除外する。図４では、３列目（ｐａの多重度は１）又は４列目（ｐａの多重度は多）において除外されるＵＲＬに対応する行は「×」で示される。例えば、ｐａの多重度が１である場合には、「／ｐａ／：ｉｄ」を含むＵＲＬは想定されないので除外される。
【００２８】
また、関係解析部１１は、ｐｂがインタフェースクラスであるか否かを判定し、インタフェースクラスである場合には、ｐｂに「＊」を付加する。５列目は、ｐｂがインタフェースクラスである場合に生成されるＵＲＬを示す。そして、関係解析部１１は、ｐａとｐｂの間の関係及び多重度に基づいて、想定されないＵＲＬを除外する。
【００２９】
図５は、図３に示したクラス図から生成される想定エンドポイントを示す図である。図３には９個のリンクがあり、図５では、９個のリンクについて両端のクラス名、除外されるＵＲＬが２〜１０列目に示されている。例えば、ＡｃｃｏｕｎｔとＯｐｅｒａｔｏｒはインタフェースクラスではなく、ＡｃｃｏｕｎｔとＯｐｅｒａｔｏｒの関係は、継承の関係であるので、図４の１８列目に基づき、／ｐａ、／ｐａ／：ｉｄ、／ｐｂ、／ｐｂ／：ｉｄ以外のＵＲＬは除外される。
【００３０】
図６は、ＡｃｃｏｕｎｔとＯｐｅｒａｔｏｒから生成されるＵＲＬを説明するための図である。図６（ａ）は、生成可能な全ＵＲＬを示し、図６（ｂ）は、ＡｃｃｏｕｎｔとＯｐｅｒａｔｏｒの関係に基づいて想定されないＵＲＬを除外した後のＵＲＬを示す。なお、ＵＲＬにおいては、クラス名の大文字は小文字に変換される。また、クラス名は複数形に変換される。
【００３１】
想定エンドポイント記憶部１２は、関係解析部１１により生成された想定エンドポイントを記憶する。図７は、想定エンドポイント記憶部１２の一例を示す図である。図７は、図３に示したクラス図から生成されたＵＲＬを示す。図７に示す各ＵＲＬと、ＧＥＴ、ＰＯＳＴ、ＰＵＴ、ＤＥＬＥＴＥ、ＰＡＴＣＨ等のＨＴＴＰメソッド名のいずれかとの組合せが想定エンドポイントである。例えば、／ａｃｃｏｕｎｔｓについては、ＧＥＴ  ／ａｃｃｏｕｎｔｓ、ＰＯＳＴ  ／ａｃｃｏｕｎｔｓ、ＰＵＴ  ／ａｃｃｏｕｎｔｓ、ＤＥＬＥＴＥ  ／ａｃｃｏｕｎｔｓ、ＰＡＴＣＨ  ／ａｃｃｏｕｎｔｓ等が想定エンドポイントである。
【００３２】
ログ解析部１３は、アクセスログ３をファイルから入力し、アクセスログ３の各ログから動詞と動詞に対応する名詞とを抽出して名詞動詞情報として名詞動詞記憶部１４に格納する。対応する名詞の数は、複数の場合があり、０の場合もある。ログ解析部１３は、名詞を抽出する際にクラス関係情報２を参照して、クラス名を名詞として抽出する。
【００３３】
例えば、ログ解析部１３は、画面アクセスログの各ログから動詞と動詞に対応する名詞とを抽出する。図８は、図３に示したクラス図に対応するウェブアプリの画面遷移を示す図である。図８において、四角は画面に対応するウェブページを示し、四角の上にウェブページのパス（画面名）が示されている。
【００３４】
図９は、画面アクセスログの一例を示す図である。図９は、図８に示した画面遷移を行うウェブアプリを実行した場合の画面アクセスログである。図９（ａ）は、画面アクセスログを示し、図９（ｂ）は、画面アクセスログから抽出されたエンドポイントであるログエンドポイントを示す。ログエンドポイントは、画面アクセスログの「“ｒ＝」以下から抽出される。例えば、１行目のログの「“ｒ＝」以下から、「ＰＯＳＴ  ／ｌｏｇｉｎ．ａｃｔｉｏｎ」がログエンドポイントとして抽出される。
【００３５】
名詞動詞記憶部１４は、アクセスログ３から抽出された動詞と名詞をログエンドポイント毎に記憶する。図１０は、名詞動詞記憶部１４の一例を示す図である。図１０に示すように、名詞動詞記憶部１４は、ログエンドポイントと抽出された動詞と名詞とを対応付けて記憶する。図１０では、名詞は最大３つまで記憶される。例えば、「ＰＯＳＴ  ／ｖｉｅｗ−ｃｕｓｔｏｍｅｒ−ｉｎｆｏ．ａｃｔｉｏｎ」からは、動詞として「ｖｉｅｗ」が抽出され、名詞として「ｃｕｓｔｏｍｅｒ」が抽出される。
【００３６】
変換情報記憶部１５は、アクセスログ３から抽出される動詞とＨＴＴＰメソッド名を対応付ける情報を記憶する。図１１は、変換情報記憶部１５の一例を示す図である。図１１に示すように、変換情報記憶部１５は、動詞とＨＴＴＰメソッド名を対応付ける。例えば、動詞「Ｖｉｅｗ」、「Ｌｉｓｔ」、「Ｓｅａｒｃｈ」、「Ｓｕｃｃｅｅｄ」は、ＨＴＴＰメソッド名「ＧＥＴ」に対応付けられる。変換情報記憶部１５が記憶する変換情報は、辞書のシノニム（Synonym）を用いて作成される。
【００３７】
実エンドポイント生成部１６は、名詞動詞記憶部１４が記憶する動詞のうち名詞を有する動詞について、変換情報記憶部１５を参照して動詞をＨＴＴＰメソッドに変換し、名詞からパス（ＵＲＬ）を生成することで実エンドポイントを生成する。そして、実エンドポイント生成部１６は、生成した実エンドポイントを実エンドポイント記憶部１７に格納する。ここで、実エンドポイントとは、ウェブアプリが実際に実行されることによって出力するログから生成されるエンドポイントであることを表す。
【００３８】
実エンドポイント記憶部１７は、実エンドポイントを記憶する。図１２は、実エンドポイント記憶部１７の一例を示す図である。図１２では、実エンドポイントがＨＴＴＰメソッドとパスに分けて記憶される。また、実エンドポイントは、対応画面情報によって画面と対応づけられる。例えば、図１０に示した名詞動詞記憶部１４の３行目のエンドポイントから、実エンドポイント記憶部１７の３行目の実エンドポイント「ＧＥＴ  ／ｃｕｓｔｏｍｅｒ／：ｉｄ」が実エンドポイント生成部１６によって生成される。なお、「／：ｉｄ」は、ＨＴＴＰメソッド名が「ＧＥＴ」、「ＰＵＴ」、「ＤＥＬＥＴＥ」、「ＰＡＴＣＨ」であるときに、実エンドポイント生成部１６によって付加される。
【００３９】
マージ部１８は、想定エンドポイントと実エンドポイントをマージして、ＷｅｂＡＰＩ仕様書に用いられる仕様エンドポイントを生成し、仕様エンドポイント記憶部１９に格納する。具体的には、マージ部１８は、実エンドポイントのうち想定エンドポイントに含まれるエンドポイントを仕様エンドポイントとする。
【００４０】
仕様エンドポイント記憶部１９は、仕様エンドポイントを記憶する。図１３は、仕様エンドポイント記憶部１９の一例を示す図である。図１３では、仕様エンドポイントがパスとＨＴＴＰメソッドに分けて記憶される。また、仕様エンドポイントは、対応画面情報によって画面と対応づけられる。例えば、図１２に示した実エンドポイント記憶部１７の３行目の実エンドポイントは、パス「ｃｕｓｔｏｍｅｒ／：ｉｄ」が図７に示した想定エンドポイントのＵＲＬの６行目にあるので、仕様エンドポイントとして生成される。なお、ｃｕｓｔｏｍｅｒ等の名詞の単数形と複数形の相違は無視される。
【００４１】
作成部２０は、仕様エンドポイントとウェブアプリ設計書４を用いてＷｅｂＡＰＩ仕様書５を作成する。ＷｅｂＡＰＩ仕様書５には、リクエストに関する記載と応答に関する記載が含まれる。リクエストに関する記載には、エンドポイントに関する記載が含まれ、仕様エンドポイントが用いられる。応答に関する記載には、例えば、取得されるデータのスキーマが含まれ、データのスキーマは、ウェブアプリ設計書４から抽出される。
【００４２】
次に、仕様書作成処理のフローについて説明する。図１４は、仕様書作成処理のフローを示すフローチャートである。図１４に示すように、仕様書作成装置１は、クラス関係情報２を用いて想定エンドポイントを生成し（ステップＳ１）、アクセスログ３から名詞動詞情報を生成する（ステップＳ２）。
【００４３】
そして、仕様書作成装置１は、名詞動詞情報から実エンドポイントを生成し（ステップＳ３）、想定エンドポイントと実エンドポイントをマージして仕様エンドポイントを生成する（ステップＳ４）。そして、仕様書作成装置１は、仕様エンドポイントとウェブアプリ設計書４を用いてＷｅｂＡＰＩ仕様書５を作成する（ステップＳ５）。
【００４４】
このように、仕様書作成装置１は、クラス関係情報２とアクセスログ３を用いてＷｅｂＡＰＩ仕様書５を作成することで、ＷｅｂＡＰＩを実装するソースコードがなくてもＷｅｂＡＰＩ仕様書を作成することができる。
【００４５】
次に、想定エンドポイントを生成する処理について説明する。図１５Ａ及び図１５Ｂは、想定エンドポイントを生成する処理のフローを示すフローチャートである。図１５Ａに示すように、関係解析部１１は、クラス関係情報２を用いてクラス図の中から関係ｅを１つ取り出し（ステップＳ１１）、ｅの両端のクラスをｐａ、ｐｂとする（ステップＳ１２）。
【００４６】
そして、関係解析部１１は、ｐａ、ｐｂの名前の組み合わせを列挙したＵＲＬリストＬを生成する（ステップＳ１３）。ＵＲＬリストＬは、例えば、図４の１列目に示したＵＲＬのリストである。そして、関係解析部１１は、ｐａがインタフェースクラスであるか否かを判定し（ステップＳ１４）、インタフェースクラスである場合には、ＵＲＬの中のｐａの名前に「＊」を付加する（ステップＳ１５）。そして、関係解析部１１は、ｐｂがインタフェースクラスであるか否かを判定し（ステップＳ１６）、インタフェースクラスである場合には、ＵＲＬの中のｐｂの名前に「＊」を付加する（ステップＳ１７）。なお、以降のステップＳ１９〜ステップＳ３９の処理では、「ｐａ」は「ｐａ＊」である場合を含み、「ｐｂ」は「ｐｂ＊」である場合を含むこととする。
【００４７】
そして、関係解析部１１は、ｐａの多重度を判定し（ステップＳ１８）、１である場合には、Ｌから／ｐａ／：ｉｄ、／ｐａ／：ｉｄ／ｐｂ、／ｐａ／：ｉｄ／ｐｂ／：ｉｄ、／ｐｂ／：ｉｄ／ｐａ／：ｉｄ、／ｐｂ／ｐａ／：ｉｄを削除する（ステップＳ１９）。一方、ｐａの多重度が多である場合には、関係解析部１１は、Ｌから／ｐａ／ｐｂ、／ｐａ／ｐｂ／：ｉｄ、／ｐｂ／ｐａ、／ｐｂ／ｐａ／：ｉｄを削除する（ステップＳ２０）。
【００４８】
そして、関係解析部１１は、ｅのタイプを判定し（ステップＳ２１）、一方向である場合には、Ｌから／ｐｂ／：ｉｄ／ｐａ、／ｐｂ／：ｉｄ／ｐａ／：ｉｄ、／ｐｂ／ｐａ、／ｐｂ／ｐａ／：ｉｄを削除する（ステップＳ２２）。そして、関係解析部１１は、ｅの多重度を判定し（ステップＳ２３）、１対１である場合には、Ｌから／ｐａ／：ｉｄ／ｐｂ／：ｉｄ、／ｐａ／ｐｂ／：ｉｄを削除し（ステップＳ２４）、ステップＳ４０へ進む。また、ｅの多重度が多対１である場合には、関係解析部１１は、Ｌから／ｐａ／：ｉｄ／ｐｂ／：ｉｄ、／ｐａ／ｐｂ／：ｉｄ、／ｐａ／ｐｂを削除し（ステップＳ２５）、ステップＳ４０へ進む。また、ｅの多重度が多対多である場合には、関係解析部１１は、Ｌから／ｐａ／ｐｂ／：ｉｄ、／ｐａ／ｐｂを削除し（ステップＳ２６）、ステップＳ４０へ進む。
【００４９】
また、ｅのタイプが双方向である場合には、関係解析部１１は、ｅの多重度を判定し（ステップＳ２７）、１対多である場合には、Ｌから／ｐｂ／：ｉｄ／ｐａ／：ｉｄ、／ｐｂ／ｐａ、／ｐｂ／ｐａ／：ｉｄを削除し（ステップＳ２８）、ステップＳ４０へ進む。また、１対１である場合には、関係解析部１１は、Ｌから／ｐａ／：ｉｄ／ｐｂ／：ｉｄ、／ｐａ／ｐｂ／：ｉｄ、／ｐｂ／：ｉｄ／ｐａ／：ｉｄ、／ｐｂ／ｐａ／：ｉｄを削除し（ステップＳ２９）、ステップＳ４０へ進む。また、多対１である場合には、関係解析部１１は、Ｌから／ｐａ／：ｉｄ／ｐｂ／：ｉｄ、／ｐａ／ｐｂ／、／ｐａ／ｐｂ／：ｉｄを削除し（ステップＳ３０）、ステップＳ４０へ進む。また、多対多である場合には、関係解析部１１は、Ｌから／ｐａ／ｐｂ、／ｐａ／ｐｂ／：ｉｄ、／ｐｂ／ｐａ／、／ｐｂ／ｐａ／：ｉｄを削除し（ステップＳ３１）、ステップＳ４０へ進む。
【００５０】
また、ｅのタイプが基本集約である場合には、図１５Ｂに示すように、関係解析部１１は、Ｌから／ｐｂ／：ｉｄ／ｐａ、／ｐｂ／：ｉｄ／ｐａ／：ｉｄ、／ｐｂ／ｐａ、／ｐｂ／ｐａ／：ｉｄを削除する（ステップＳ３２）。そして、関係解析部１１は、ｅの多重度を判定し（ステップＳ３３）、１対１である場合には、Ｌから／ｐａ／：ｉｄ／ｐｂ／：ｉｄ、／ｐａ／ｐｂ／：ｉｄを削除する（ステップＳ３４）。そして、関係解析部１１は、ステップＳ４０へ進む。
【００５１】
また、ｅのタイプが複合集約である場合には、関係解析部１１は、Ｌから／ｐｂ／：ｉｄ／ｐａ、／ｐｂ／：ｉｄ／ｐａ／：ｉｄ、／ｐｂ／ｐａ、／ｐｂ／ｐａ／：ｉｄ、／ｐｂ、／ｐｂ／：ｉｄを削除する（ステップＳ３５）。そして、関係解析部１１は、ｅの多重度を判定し（ステップＳ３６）、１対１である場合には、Ｌから／ｐａ／：ｉｄ／ｐｂ／：ｉｄ、／ｐａ／ｐｂ／：ｉｄを削除する（ステップＳ３７）。そして、関係解析部１１は、ステップＳ４０へ進む。
【００５２】
また、ｅのタイプが継承である場合には、関係解析部１１は、Ｌから／ｐａ／：ｉｄ／ｐｂ、／ｐａ／：ｉｄ／ｐｂ／：ｉｄ、／ｐａ／ｐｂ、／ｐａ／ｐｂ／：ｉｄ、／ｐｂ／：ｉｄ／ｐａ、／ｐｂ／：ｉｄ／ｐａ／：ｉｄ、／ｐｂ／ｐａ、／ｐｂ／ｐａ／：ｉｄを削除する（ステップＳ３８）。そして、関係解析部１１は、ステップＳ４０へ進む。
【００５３】
また、ｅのタイプが実現である場合には、関係解析部１１は、ｐａの親との関係をｅとし（ステップＳ３９）、ステップＳ２１に戻る。
【００５４】
そして、関係解析部１１は、Ｌに含まれるＵＲＬを想定エンドポイント記憶部１２に書き加え（ステップＳ４０）、ｅがまだ残っているか否かを判定する（ステップＳ４１）。そして、関係解析部１１は、ｅがまだ残っている場合には、ステップＳ１１に戻る。
【００５５】
一方、ｅが残っていない場合には、関係解析部１１は、想定エンドポイント記憶部１２に、インタフェースクラスに基づいてジョイン（join）可能な２つのＵＲＬがあれば、２つのＵＲＬをジョインする（ステップＳ４２）。例えば、「／ｘ／ｙ＊」と「／ｙ＊／ｚ」があれば、関係解析部１１は、２つのＵＲＬをジョインして「／ｘ／ｚ」とする。そして、関係解析部１１は、想定エンドポイント記憶部１２から「クラス名＊」を含むＵＲＬを削除する（ステップＳ４３）。ステップＳ４２とステップＳ４３の処理によって、関係解析部１１は、想定エンドポイント記憶部１２が記憶するＵＲＬからインタフェースクラス名を含むＵＲＬを取り除くことができる。
【００５６】
このように、関係解析部１１は、２つのクラスの間の関係毎に関係のタイプ及び多重度に基づいてＵＲＬを生成することで、想定エンドポイントを生成することができる。
【００５７】
次に、名詞動詞情報を生成する処理のフローについて説明する。図１６は、名詞動詞情報を生成する処理のフローを示すフローチャートである。図１６に示すように、ログ解析部１３は、既存ウェブアプリのアクセスログ３からログを１つ取り出す（ステップＳ５１）。
【００５８】
そして、ログ解析部１３は、ログから動詞を抽出して名詞動詞記憶部１４に格納する（ステップＳ５２）。そして、ログ解析部１３は、ログにクラス名と同じ名詞がある場合には、名詞を動詞に対応付けて名詞動詞記憶部１４に格納する（ステップＳ５３）。
【００５９】
そして、ログ解析部１３は、ログがまだ残っているか否かを判定し（ステップＳ５４）、残っている場合には、ステップＳ５１に戻り、残っていない場合には、処理を終了する。
【００６０】
このように、ログ解析部１３がアクセスログ３から名詞動詞情報を生成することで、実エンドポイント生成部１６は実エンドポイントを生成することができる。
【００６１】
次に、実エンドポイントを生成する処理のフローについて説明する。図１７は、実エンドポイントを生成する処理のフローを示すフローチャートである。図１７に示すように、実エンドポイント生成部１６は、名詞動詞記憶部１４が記憶する動詞のうち名詞が対応付けられている動詞を１つ選択する（ステップＳ６１）。
【００６２】
そして、実エンドポイント生成部１６は、選択した動詞を変換情報記憶部１５を参照してＨＴＴＰメソッド名に変換する（ステップＳ６２）。そして、実エンドポイント生成部１６は、選択した動詞に対応付けられた名詞を「／」で結合しパスを生成する（ステップＳ６３）。
【００６３】
そして、実エンドポイント生成部１６は、ＨＴＴＰメソッド名とパスを用いて実エンドポイントを生成し、実エンドポイント記憶部１７に格納する（ステップＳ６４）。そして、実エンドポイント生成部１６は、名詞が対応付けられている動詞が残っているか否かを判定し（ステップＳ６５）、残っている場合には、ステップＳ６１に戻り、残っていない場合には、処理を終了する。
【００６４】
このように、実エンドポイント生成部１６は、名詞動詞情報を用いて実エンドポイントを生成することで、仕様エンドポイントの候補を生成することができる。
【００６５】
次に、仕様エンドポイントを生成する処理のフローについて説明する。図１８は、仕様エンドポイントを生成する処理のフローを示すフローチャートである。図１８に示すように、マージ部１８は、実エンドポイント記憶部１７から実エンドポイントを１つ取り出す（ステップＳ７１）。
【００６６】
そして、マージ部１８は、取り出した実エンドポイントが想定エンドポイント記憶部１２が記憶する想定エンドポイントに含まれるか否かを判定し（ステップＳ７２）、含まれない場合には、ステップＳ７４に進む。
【００６７】
一方、取り出した実エンドポイントが想定エンドポイント記憶部１２が記憶する想定エンドポイントに含まれる場合には、マージ部１８は、実エンドポイントを仕様エンドポイントとして仕様エンドポイント記憶部１９に格納する（ステップＳ７３）。
【００６８】
そして、マージ部１８は、実エンドポイントが残っているか否かを判定し（ステップＳ７４）、残っている場合には、ステップＳ７１に戻り、残っていない場合には、処理を終了する。
【００６９】
このように、マージ部１８が仕様エンドポイントを生成することで、仕様書作成装置１は、ＷｅｂＡＰＩ仕様書５を作成することができる。
【００７０】
上述してきたように、実施例では、関係解析部１１がクラス関係情報２に基づいて想定エンドポイントを生成する。また、ログ解析部１３がアクセスログ３からクラス関係情報２を参照して名詞動詞情報を抽出し、実エンドポイント生成部１６が名詞動詞情報の動詞をＨＴＴＰメソッド名に変換し、名詞をパスに変換することで実エンドポイントを生成する。そして、マージ部１８が実エンドポイントのうち関係解析部１１により生成された想定エンドポイントに含まれるエンドポイントを仕様エンドポイントとして特定する。したがって、仕様書作成装置１は、仕様エンドポイントをＷｅｂＡＰＩ仕様に関する情報として活用することができる。
【００７１】
また、実施例では、作成部２０が仕様エンドポイントとウェブアプリ設計書４に基づいてＷｅｂＡＰＩ仕様書５を作成する。したがって、仕様書作成装置１は、ＷｅｂＡＰＩ仕様書５を自動的に作成することができる。
【００７２】
また、実施例では、ログ解析部１３は、名詞動詞情報の名詞のうちクラス関係情報２にクラス名として含まれる名詞だけをパスとして用いる。したがって、実エンドポイント生成部１６は、クラス関係情報２と整合のとれた実エンドポイントを生成することができる。
【００７３】
また、実施例では、関係解析部１１は、２つのクラスの間の関係のタイプ及び２つのクラスの間の多重度に基づいて、想定されないＵＲＬを除外して想定エンドポイントを生成する。したがって、仕様書作成装置１は、想定できないＡＰＩをＷｅｂＡＰＩ仕様書５から除外することができる。
【００７４】
また、実施例では、画面アクセスログに基づく実エンドポイントを想定エンドポイントと比較することで、設計者は、クラス関係情報２のうち画面が作成されていないクラスを把握することができ、画面の不足を見つけることができる。
【００７５】
なお、実施例では、仕様書作成装置１について説明したが、仕様書作成装置１が有する構成をソフトウェアによって実現することで、同様の機能を有する仕様書作成プログラムを得ることができる。そこで、仕様書作成プログラムを実行するコンピュータについて説明する。
【００７６】
図１９は、実施例に係る仕様書作成プログラムを実行するコンピュータのハードウェア構成を示す図である。図１９に示すように、コンピュータ５０は、メインメモリ５１と、ＣＰＵ（Central  Processing  Unit）５２と、ＬＡＮ（Local  Area  Network）インタフェース５３と、ＨＤＤ（Hard  Disk  Drive）５４とを有する。また、コンピュータ５０は、スーパーＩＯ（Input  Output）５５と、ＤＶＩ（Digital  Visual  Interface）５６と、ＯＤＤ（Optical  Disk  Drive）５７とを有する。
【００７７】
メインメモリ５１は、プログラムやプログラムの実行途中結果などを記憶するメモリである。ＣＰＵ５２は、メインメモリ５１からプログラムを読み出して実行する中央処理装置である。ＣＰＵ５２は、メモリコントローラを有するチップセットを含む。
【００７８】
ＬＡＮインタフェース５３は、コンピュータ５０をＬＡＮ経由で他のコンピュータに接続するためのインタフェースである。ＨＤＤ５４は、プログラムやデータを格納するディスク装置であり、スーパーＩＯ５５は、マウスやキーボードなどの入力装置を接続するためのインタフェースである。ＤＶＩ５６は、液晶表示装置を接続するインタフェースであり、ＯＤＤ５７は、ＤＶＤの読み書きを行う装置である。
【００７９】
ＬＡＮインタフェース５３は、ＰＣＩエクスプレス（ＰＣＩｅ）によりＣＰＵ５２に接続され、ＨＤＤ５４及びＯＤＤ５７は、ＳＡＴＡ（Serial  Advanced  Technology  Attachment）によりＣＰＵ５２に接続される。スーパーＩＯ５５は、ＬＰＣ（Low  Pin  Count）によりＣＰＵ５２に接続される。
【００８０】
そして、コンピュータ５０において実行される仕様書作成プログラムは、ＤＶＤに記憶され、ＯＤＤ５７によってＤＶＤから読み出されてコンピュータ５０にインストールされる。あるいは、仕様書作成プログラムは、ＬＡＮインタフェース５３を介して接続された他のコンピュータシステムのデータベースなどに記憶され、これらのデータベースから読み出されてコンピュータ５０にインストールされる。そして、インストールされた仕様書作成プログラムは、ＨＤＤ５４に記憶され、メインメモリ５１に読み出されてＣＰＵ５２によって実行される。
【符号の説明】
【００８１】
１    仕様書作成装置
２    クラス
３    アクセスログ
４    ウェブアプリ設計書
５    ＷｅｂＡＰＩ仕様書
７    要求応答
８    画面
１１    関係解析部
１２    想定エンドポイント記憶部
１３    ログ解析部
１４    名詞動詞記憶部
１５    変換情報記憶部
１６    実エンドポイント生成部
１７    実エンドポイント記憶部
１８    マージ部
１９    仕様エンドポイント記憶部
２０    作成部
５０    コンピュータ
５１    メインメモリ
５２    ＣＰＵ
５３    ＬＡＮインタフェース
５４    ＨＤＤ
５５    スーパーＩＯ
５６    ＤＶＩ
５７    ＯＤＤ
【図１】
2018055625.tif 000003
【図２】
2018055625.tif 000004
【図３】
2018055625.tif 000005
【図４】
2018055625.tif 000006
【図５】
2018055625.tif 000007
【図６】
2018055625.tif 000008
【図７】
2018055625.tif 000009
【図８】
2018055625.tif 000010
【図９】
2018055625.tif 000011
【図１０】
2018055625.tif 000012
【図１１】
2018055625.tif 000013
【図１２】
2018055625.tif 000014
【図１３】
2018055625.tif 000015
【図１４】
2018055625.tif 000016
【図１５Ａ】
2018055625.tif 000017
【図１５Ｂ】
2018055625.tif 000018
【図１６】
2018055625.tif 000019
【図１７】
2018055625.tif 000020
【図１８】
2018055625.tif 000021
【図１９】
2018055625.tif 000022
【図２０】
2018055625.tif 000023