図面 (/)

技術 情報処理装置、仕様書作成方法及び仕様書作成プログラム

出願人 富士通株式会社
発明者 チョーダリーシュリダル木村功作関口敦二上原忠弘佐々木裕介上野優
出願日 2016年9月30日 (4年8ヶ月経過) 出願番号 2016-194423
公開日 2018年4月5日 (3年2ヶ月経過) 公開番号 2018-055625
状態 特許登録済
技術分野 ストアードプログラム
主要キーワード ジョイン インタフェースクラス 文字型 ウェブアプ 割引データ PCIエクスプレス ステータス値 シノニム
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2018年4月5日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

WebAP仕様書を簡単に作成すること。

解決手段

関係解析部11がクラス関係情報2に基づいて想定エンドポイントを生成する。また、ログ解析部13がアクセスログ3からクラス関係情報2を参照して名詞動詞情報を抽出し、実エンドポイント生成部16が名詞動詞情報の動詞HTTPメソッド名に変換し、名詞をパスに変換することで実エンドポイントを生成する。そして、マージ部18が実エンドポイントのうち関係解析部11により生成された想定エンドポイントに含まれるエンドポイントを仕様エンドポイントとして特定する。

概要

背景

API(Application Programming Interface)は、アプリケーション(以下、単に「アプリ」という)からデータ、機能を利用するために提供されるインタフェースであり、データの提供者あるいは機能の開発者によって作成され、公開される。既存のウェブアプリ(Webアプリ)にWebAPIを新たに設けることで、既存のウェブアプリのデータ、機能を他のアプリからWeb経由で物理的な場所を意識せずに使用することが可能となる。

図20は、WebAPIを説明するための図である。図20は、新規契約審査顧客情報変更等の機能を有し、サーバで動作するウェブアプリであるモバイル契約管理に顧客データを提供するWebAPI、契約データを提供するWebAPI、割引データを提供するWebAPIを設けた場合を示す。WebAPIの利用を含むロジックを他のアプリに組み込むことによって、モバイル契約管理の顧客データ、契約データ、割引データを他のアプリから利用することができる。他のアプリは、スマホ(スマートフォン)、タブレット、PC(Personal Computer)等で動作してもよい。

このようなWebAPIを用いることによって、今まで接触できなかった新たな顧客にもサービスを提供することができ、また、システム間でデータや処理を連携することで新たなサービスを提供することができる。

WebAPIを利用するためには、WebAPIの仕様について記載したWebAPI仕様書が必要になる。しかしながら、WebAPIを設けることによる効果がどのくらいあるかはWebAPIを設ける時点では不明であるため、少ないコストでWebAPI仕様書を簡単に作成することが望まれる。そこで、WebAPIを実装するとともに適切なコメントが記載されたソースコードからWebAPI仕様書を作成する技術がある。

なお、実行プログラムから出力された実行ログに基づいて、実際に実行されたオブジェクトとそのオブジェクトで使用するテーブルとの関係を示す設計書を作成する従来技術がある。

概要

WebAPI仕様書を簡単に作成すること。関係解析部11がクラス関係情報2に基づいて想定エンドポイントを生成する。また、ログ解析部13がアクセスログ3からクラス関係情報2を参照して名詞動詞情報を抽出し、実エンドポイント生成部16が名詞動詞情報の動詞HTTPメソッド名に変換し、名詞をパスに変換することで実エンドポイントを生成する。そして、マージ部18が実エンドポイントのうち関係解析部11により生成された想定エンドポイントに含まれるエンドポイントを仕様エンドポイントとして特定する。

目的

図20は、新規契約、審査、顧客情報変更等の機能を有し、サーバで動作するウェブアプリであるモバイル契約管理に顧客データを提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

既存のウェブアプリケーションクラス間の関係を表すクラス関係情報に基づいて、該関係から想定されるAP仕様情報である想定エンドポイントを生成する想定エンドポイント生成部と、前記ウェブアプリケーションを実行した際に出力されるアクセスログから、実行結果に基づくAPI仕様情報である実エンドポイントのもとになる動詞及び名詞を前記クラス関係情報を参照して抽出する抽出部と、前記抽出部により抽出された動詞をメソッド名に変換し、前記抽出部により抽出された名詞をパスに変換することにより前記実エンドポイントを生成する実エンドポイント生成部と、前記実エンドポイント生成部により生成された実エンドポイントのうち前記想定エンドポイント生成部により生成された想定エンドポイントに含まれるエンドポイントを前記ウェブアプリケーションのAPI仕様情報として特定する特定部を有することを特徴とする情報処理装置

請求項2

前記特定部により特定されたAPI仕様情報と前記ウェブアプリケーションの設計情報に基づいて、前記ウェブアプリケーションのAPI仕様書を作成する作成部をさらに有することを特徴とする請求項1に記載の情報処理装置。

請求項3

前記抽出部は、前記アクセスログに含まれる名詞が前記クラス関係情報にクラス名として含まれる場合に、該名詞を前記実エンドポイントのもとになる名詞として抽出することを特徴とする請求項1又は2に記載の情報処理装置。

請求項4

前記想定エンドポイント生成部は、2つのクラスのクラス名のうち1つ又は2つを用いて生成される全てのURLから、該2つのクラス間の関係が一方向、双方向、基本集約複合集約、継承又は実現のいずれであるかと該2つのクラス間の多重度の関係とに基づいて想定されないURLを除外したURLを用いて前記想定エンドポイントを生成することを特徴とする請求項1、2又は3に記載の情報処理装置。

請求項5

前記アクセスログは、画面のアクセスログであることを特徴とする請求項1〜4のいずれか1つに記載の情報処理装置。

請求項6

コンピュータが、既存のウェブアプリケーションのクラス間の関係を表すクラス関係情報に基づいて、該関係から想定されるAPI仕様情報である想定エンドポイントを生成し、前記ウェブアプリケーションを実行した際に出力されるアクセスログから、実行結果に基づくAPI仕様情報である実エンドポイントのもとになる動詞及び名詞を前記クラス関係情報を参照して抽出し、抽出した動詞をメソッド名に変換し、抽出した名詞をパスに変換することにより前記実エンドポイントを生成し、生成した実エンドポイントのうち生成した想定エンドポイントに含まれるエンドポイントを前記ウェブアプリケーションのAPI仕様情報として特定する処理を実行することを特徴とする仕様書作成方法

請求項7

コンピュータに、既存のウェブアプリケーションのクラス間の関係を表すクラス関係情報に基づいて、該関係から想定されるAPI仕様情報である想定エンドポイントを生成し、前記ウェブアプリケーションを実行した際に出力されるアクセスログから、実行結果に基づくAPI仕様情報である実エンドポイントのもとになる動詞及び名詞を前記クラス関係情報を参照して抽出し、抽出した動詞をメソッド名に変換し、抽出した名詞をパスに変換することにより前記実エンドポイントを生成し、生成した実エンドポイントのうち生成した想定エンドポイントに含まれるエンドポイントを前記ウェブアプリケーションのAPI仕様情報として特定する処理を実行させることを特徴とする仕様書作成プログラム

技術分野

0001

本発明は、情報処理装置仕様書作成方法及び仕様書作成プログラムに関する。

背景技術

0002

API(Application Programming Interface)は、アプリケーション(以下、単に「アプリ」という)からデータ、機能を利用するために提供されるインタフェースであり、データの提供者あるいは機能の開発者によって作成され、公開される。既存のウェブアプリ(Webアプリ)にWebAPIを新たに設けることで、既存のウェブアプリのデータ、機能を他のアプリからWeb経由で物理的な場所を意識せずに使用することが可能となる。

0003

図20は、WebAPIを説明するための図である。図20は、新規契約審査顧客情報変更等の機能を有し、サーバで動作するウェブアプリであるモバイル契約管理に顧客データを提供するWebAPI、契約データを提供するWebAPI、割引データを提供するWebAPIを設けた場合を示す。WebAPIの利用を含むロジックを他のアプリに組み込むことによって、モバイル契約管理の顧客データ、契約データ、割引データを他のアプリから利用することができる。他のアプリは、スマホ(スマートフォン)、タブレット、PC(Personal Computer)等で動作してもよい。

0004

このようなWebAPIを用いることによって、今まで接触できなかった新たな顧客にもサービスを提供することができ、また、システム間でデータや処理を連携することで新たなサービスを提供することができる。

0005

WebAPIを利用するためには、WebAPIの仕様について記載したWebAPI仕様書が必要になる。しかしながら、WebAPIを設けることによる効果がどのくらいあるかはWebAPIを設ける時点では不明であるため、少ないコストでWebAPI仕様書を簡単に作成することが望まれる。そこで、WebAPIを実装するとともに適切なコメントが記載されたソースコードからWebAPI仕様書を作成する技術がある。

0006

なお、実行プログラムから出力された実行ログに基づいて、実際に実行されたオブジェクトとそのオブジェクトで使用するテーブルとの関係を示す設計書を作成する従来技術がある。

0007

特開2009−230618号公報

先行技術

0008

Swagger-maven-plugin、[平成28年9月12日検索]、インターネット<URL:http://kongchen.github.io/swagger-maven-plugin/>

発明が解決しようとする課題

0009

しかしながら、既存のウェブアプリのソースコードから、WebAPIを実装するとともに適切なコメントが記載されたソースコードを作成することは簡単ではないという問題がある。このため、WebAPIを実装するソースコードがなくてもWebAPI仕様書を簡単に作成することが望まれる。

0010

本発明は、1つの側面では、WebAPI仕様書を簡単に作成することを目的とする。

課題を解決するための手段

0011

1つの態様では、情報処理装置は、想定エンドポイント生成部と、抽出部と、実エンドポイント生成部と、特定部とを有する。想定エンドポイント生成部は、既存のウェブアプリケーションクラス間の関係を表すクラス関係情報に基づいて、該関係から想定されるAPI仕様情報である想定エンドポイントを生成する。抽出部は、ウェブアプリケーションを実行した際に出力されるアクセスログから、実行結果に基づくAPI仕様情報である実エンドポイントのもとになる動詞及び名詞をクラス関係情報を参照して抽出する。実エンドポイント生成部は、抽出部により抽出された動詞をメソッド名に変換し、抽出部により抽出された名詞をパスに変換することにより実エンドポイントを生成する。特定部は、実エンドポイント生成部により生成された実エンドポイントのうち想定エンドポイント生成部により生成された想定エンドポイントに含まれるエンドポイントをウェブアプリケーションのAPI仕様情報として特定する。

発明の効果

0012

1つの側面では、WebAPI仕様書を簡単に作成することができる。

図面の簡単な説明

0013

図1は、実施例に係る仕様書作成装置を説明するための図である。
図2は、実施例に係る仕様書作成装置の機能構成を示す図である。
図3は、クラス関係情報を表すクラス図の一例を示す図である。
図4は、クラス関係情報から想定エンドポイントを生成する際に用いられる表を示す図である。
図5は、図3に示したクラス図から生成される想定エンドポイントを示す図である。
図6は、AccountとOperatorから生成されるURLを説明するための図である。
図7は、想定エンドポイント記憶部の一例を示す図である。
図8は、図3に示したクラス図に対応するウェブアプリの画面遷移を示す図である。
図9は、画面アクセスログの一例を示す図である。
図10は、名詞動詞記憶部の一例を示す図である。
図11は、変換情報記憶部の一例を示す図である。
図12は、実エンドポイント記憶部の一例を示す図である。
図13は、仕様エンドポイント記憶部の一例を示す図である。
図14は、仕様書作成処理のフローを示すフローチャートである。
図15Aは、想定エンドポイントを生成する処理のフローを示す第1のフローチャートである。
図15Bは、想定エンドポイントを生成する処理のフローを示す第2のフローチャートである。
図16は、名詞動詞情報を生成する処理のフローを示すフローチャートである。
図17は、実エンドポイントを生成する処理のフローを示すフローチャートである。
図18は、仕様エンドポイントを生成する処理のフローを示すフローチャートである。
図19は、実施例に係る仕様書作成プログラムを実行するコンピュータハードウェア構成を示す図である。
図20は、WebAPIを説明するための図である。

0014

以下に、本願の開示する情報処理装置、仕様書作成方法及び仕様書作成プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。

0015

まず、実施例に係る仕様書作成装置について説明する。図1は、実施例に係る仕様書作成装置を説明するための図である。図1に示すように、実施例に係る仕様書作成装置は、クラス間の関係についての情報であるクラス関係情報2とアクセスログ3を用いてWebAPI仕様書を作成する。そして、ユーザは、WebAPI仕様書に基づいてWebAPIを使ってデータを要求し、応答を得る。要求応答7は、WebAPIを使ったデータの要求と応答を示す。

0016

クラス関係情報2は、クラス図で表される情報である。アクセスログ3は、ここでは、画面がアクセスされた際に出力されるログである。図1では、モバイル契約管理において、顧客情報を表示する画面8が表示されたときに出力されたログ(アクセスログ3の1行目)、表示された情報が変更されたときに出力されたログ(アクセスログ3の2行目)の例が示されている。

0017

要求応答7において、WebAPI Requestは、WebAPIを用いたデータの取得要求である。「GET /user/1」は、エンドポイントと呼ばれる。エンドポイントは、WebAPI仕様の基本となる情報である。エンドポイントには、HTTP(Hypertext Transfer Protocol)メソッド名とアクセス先のURL(Uniform Resource Locator)が含まれる。「GET」がHTTPメソッド名である。「/user/1」がアクセス先のURLである。このURLは、「1」で識別される顧客(user)の情報を指定している。「GET /user/1」は、「1」で識別される顧客の情報を取得することを表す。

0018

「HTTP/1.1」は、プロトコルを示す。「Host:」は、アクセス先のドメインを示す。ここでは、アクセス先は、「api.system.co.jp」である。「Accept:」は、応答として受け取れる形式を示す。ここでは、応答として受け取れる形式は、「application/json」である。

0019

WebAPI Responseは、データの取得要求に対する応答である。「200 OK」は、正常な応答であってステータス値が「200」であることを示す。「Content−Type:」は、応答内容の形式を示す。「charset=」は、文字コードを示す。ここでは、文字コードは、「UTF−8」である。{“name”:“Taro”,“sex”:“Male”,“birthday”:“1990/11/21”}は、得られたデータを示す。

0020

次に、実施例に係る仕様書作成装置の機能構成について説明する。図2は、実施例に係る仕様書作成装置の機能構成を示す図である。図2に示すように、仕様書作成装置1は、関係解析部11と、想定エンドポイント記憶部12と、ログ解析部13と、名詞動詞記憶部14と、変換情報記憶部15と、実エンドポイント生成部16と、実エンドポイント記憶部17と、マージ部18とを有する。また、仕様書作成装置1は、仕様エンドポイント記憶部19と、作成部20とを有する。

0021

関係解析部11は、クラス関係情報2をファイルから入力し、クラス関係情報2に基づいて想定エンドポイントを生成する。ここで、想定エンドポイントとは、クラス関係情報2から想定されるエンドポイントである。図3は、クラス関係情報2を表すクラス図の一例を示す図である。図3において、四角クラスを表す。クラスの情報には、クラス名と、名前及び型とが含まれる。

0022

例えば、Accountという名前のクラスには、整数型の名前idと、文字型の名前nameが含まれる。<<interface>>は、クラスがインタフェースクラスであることを表す。例えば、Serviceという名前のクラスはインタフェースクラスである。

0023

クラス間のリンクは、クラス間の関係を表す。実線は、双方向の関係(BiDirected Association)を表す。→は、一方向の関係(Directed Association)を表す。矢頭が白のひし形である実線の矢印は、基本集約の関係(Basic Aggregation)を表す。矢頭が黒のひし形である実線の矢印は、複合集約の関係(Composition Aggregation)を表す。矢頭が白の三角である実線の矢印は、継承の関係(Inheritance)を表す。矢頭が白の三角である破線の矢印は、実現の関係(Realization)を表す。

0024

クラス間のリンクには多重度(multiplicity)に関する情報が付加される。多重度には、1(One)対1、1対多(*:Many)、多(*)対1、多(*)対多(*)がある。

0025

図4は、クラス関係情報2から想定エンドポイントを生成する際に用いられる表を示す図である。関係解析部11は、関係のある2つのクラスの名前のうち1つ又は2つを用いて生成可能な全てのURLを生成する。図4では、paとpbがクラス名である。クラス名に付加された「*」は、クラスがインタフェースクラスであることを示す。また、「:id」は、インスタンスを識別する識別子である。

0026

図4では、生成されるURLは1列目に示される。ただし、1列目は、paとpbがインタフェースクラスでない場合を示す。関係解析部11は、paがインタフェースクラスであるか否かを判定し、インタフェースクラスである場合には、paの名前に「*」を付加する。2列目は、paがインタフェースクラスである場合に生成されるURLを示す。

0027

そして、関係解析部11は、paの多重度を判定し、判定結果に基づいて、想定されないURLを除外する。図4では、3列目(paの多重度は1)又は4列目(paの多重度は多)において除外されるURLに対応する行は「×」で示される。例えば、paの多重度が1である場合には、「/pa/:id」を含むURLは想定されないので除外される。

0028

また、関係解析部11は、pbがインタフェースクラスであるか否かを判定し、インタフェースクラスである場合には、pbに「*」を付加する。5列目は、pbがインタフェースクラスである場合に生成されるURLを示す。そして、関係解析部11は、paとpbの間の関係及び多重度に基づいて、想定されないURLを除外する。

0029

図5は、図3に示したクラス図から生成される想定エンドポイントを示す図である。図3には9個のリンクがあり、図5では、9個のリンクについて両端のクラス名、除外されるURLが2〜10列目に示されている。例えば、AccountとOperatorはインタフェースクラスではなく、AccountとOperatorの関係は、継承の関係であるので、図4の18列目に基づき、/pa、/pa/:id、/pb、/pb/:id以外のURLは除外される。

0030

図6は、AccountとOperatorから生成されるURLを説明するための図である。図6(a)は、生成可能な全URLを示し、図6(b)は、AccountとOperatorの関係に基づいて想定されないURLを除外した後のURLを示す。なお、URLにおいては、クラス名の大文字小文字に変換される。また、クラス名は複数形に変換される。

0031

想定エンドポイント記憶部12は、関係解析部11により生成された想定エンドポイントを記憶する。図7は、想定エンドポイント記憶部12の一例を示す図である。図7は、図3に示したクラス図から生成されたURLを示す。図7に示す各URLと、GET、POST、PUT、DELETE、PATCH等のHTTPメソッド名のいずれかとの組合せが想定エンドポイントである。例えば、/accountsについては、GET /accounts、POST /accounts、PUT /accounts、DELETE /accounts、PATCH /accounts等が想定エンドポイントである。

0032

ログ解析部13は、アクセスログ3をファイルから入力し、アクセスログ3の各ログから動詞と動詞に対応する名詞とを抽出して名詞動詞情報として名詞動詞記憶部14に格納する。対応する名詞の数は、複数の場合があり、0の場合もある。ログ解析部13は、名詞を抽出する際にクラス関係情報2を参照して、クラス名を名詞として抽出する。

0033

例えば、ログ解析部13は、画面アクセスログの各ログから動詞と動詞に対応する名詞とを抽出する。図8は、図3に示したクラス図に対応するウェブアプリの画面遷移を示す図である。図8において、四角は画面に対応するウェブページを示し、四角の上にウェブページのパス(画面名)が示されている。

0034

図9は、画面アクセスログの一例を示す図である。図9は、図8に示した画面遷移を行うウェブアプリを実行した場合の画面アクセスログである。図9(a)は、画面アクセスログを示し、図9(b)は、画面アクセスログから抽出されたエンドポイントであるログエンドポイントを示す。ログエンドポイントは、画面アクセスログの「“r=」以下から抽出される。例えば、1行目のログの「“r=」以下から、「POST /login.action」がログエンドポイントとして抽出される。

0035

名詞動詞記憶部14は、アクセスログ3から抽出された動詞と名詞をログエンドポイント毎に記憶する。図10は、名詞動詞記憶部14の一例を示す図である。図10に示すように、名詞動詞記憶部14は、ログエンドポイントと抽出された動詞と名詞とを対応付けて記憶する。図10では、名詞は最大3つまで記憶される。例えば、「POST /view−customer−info.action」からは、動詞として「view」が抽出され、名詞として「customer」が抽出される。

0036

変換情報記憶部15は、アクセスログ3から抽出される動詞とHTTPメソッド名を対応付ける情報を記憶する。図11は、変換情報記憶部15の一例を示す図である。図11に示すように、変換情報記憶部15は、動詞とHTTPメソッド名を対応付ける。例えば、動詞「View」、「List」、「Search」、「Succeed」は、HTTPメソッド名「GET」に対応付けられる。変換情報記憶部15が記憶する変換情報は、辞書シノニム(Synonym)を用いて作成される。

0037

実エンドポイント生成部16は、名詞動詞記憶部14が記憶する動詞のうち名詞を有する動詞について、変換情報記憶部15を参照して動詞をHTTPメソッドに変換し、名詞からパス(URL)を生成することで実エンドポイントを生成する。そして、実エンドポイント生成部16は、生成した実エンドポイントを実エンドポイント記憶部17に格納する。ここで、実エンドポイントとは、ウェブアプリが実際に実行されることによって出力するログから生成されるエンドポイントであることを表す。

0038

実エンドポイント記憶部17は、実エンドポイントを記憶する。図12は、実エンドポイント記憶部17の一例を示す図である。図12では、実エンドポイントがHTTPメソッドとパスに分けて記憶される。また、実エンドポイントは、対応画面情報によって画面と対応づけられる。例えば、図10に示した名詞動詞記憶部14の3行目のエンドポイントから、実エンドポイント記憶部17の3行目の実エンドポイント「GET /customer/:id」が実エンドポイント生成部16によって生成される。なお、「/:id」は、HTTPメソッド名が「GET」、「PUT」、「DELETE」、「PATCH」であるときに、実エンドポイント生成部16によって付加される。

0039

マージ部18は、想定エンドポイントと実エンドポイントをマージして、WebAPI仕様書に用いられる仕様エンドポイントを生成し、仕様エンドポイント記憶部19に格納する。具体的には、マージ部18は、実エンドポイントのうち想定エンドポイントに含まれるエンドポイントを仕様エンドポイントとする。

0040

仕様エンドポイント記憶部19は、仕様エンドポイントを記憶する。図13は、仕様エンドポイント記憶部19の一例を示す図である。図13では、仕様エンドポイントがパスとHTTPメソッドに分けて記憶される。また、仕様エンドポイントは、対応画面情報によって画面と対応づけられる。例えば、図12に示した実エンドポイント記憶部17の3行目の実エンドポイントは、パス「customer/:id」が図7に示した想定エンドポイントのURLの6行目にあるので、仕様エンドポイントとして生成される。なお、customer等の名詞の単数形と複数形の相違は無視される。

0041

作成部20は、仕様エンドポイントとウェブアプリ設計書4を用いてWebAPI仕様書5を作成する。WebAPI仕様書5には、リクエストに関する記載と応答に関する記載が含まれる。リクエストに関する記載には、エンドポイントに関する記載が含まれ、仕様エンドポイントが用いられる。応答に関する記載には、例えば、取得されるデータのスキーマが含まれ、データのスキーマは、ウェブアプリ設計書4から抽出される。

0042

次に、仕様書作成処理のフローについて説明する。図14は、仕様書作成処理のフローを示すフローチャートである。図14に示すように、仕様書作成装置1は、クラス関係情報2を用いて想定エンドポイントを生成し(ステップS1)、アクセスログ3から名詞動詞情報を生成する(ステップS2)。

0043

そして、仕様書作成装置1は、名詞動詞情報から実エンドポイントを生成し(ステップS3)、想定エンドポイントと実エンドポイントをマージして仕様エンドポイントを生成する(ステップS4)。そして、仕様書作成装置1は、仕様エンドポイントとウェブアプリ設計書4を用いてWebAPI仕様書5を作成する(ステップS5)。

0044

このように、仕様書作成装置1は、クラス関係情報2とアクセスログ3を用いてWebAPI仕様書5を作成することで、WebAPIを実装するソースコードがなくてもWebAPI仕様書を作成することができる。

0045

次に、想定エンドポイントを生成する処理について説明する。図15A及び図15Bは、想定エンドポイントを生成する処理のフローを示すフローチャートである。図15Aに示すように、関係解析部11は、クラス関係情報2を用いてクラス図の中から関係eを1つ取り出し(ステップS11)、eの両端のクラスをpa、pbとする(ステップS12)。

0046

そして、関係解析部11は、pa、pbの名前の組み合わせを列挙したURLリストLを生成する(ステップS13)。URLリストLは、例えば、図4の1列目に示したURLのリストである。そして、関係解析部11は、paがインタフェースクラスであるか否かを判定し(ステップS14)、インタフェースクラスである場合には、URLの中のpaの名前に「*」を付加する(ステップS15)。そして、関係解析部11は、pbがインタフェースクラスであるか否かを判定し(ステップS16)、インタフェースクラスである場合には、URLの中のpbの名前に「*」を付加する(ステップS17)。なお、以降のステップS19〜ステップS39の処理では、「pa」は「pa*」である場合を含み、「pb」は「pb*」である場合を含むこととする。

0047

そして、関係解析部11は、paの多重度を判定し(ステップS18)、1である場合には、Lから/pa/:id、/pa/:id/pb、/pa/:id/pb/:id、/pb/:id/pa/:id、/pb/pa/:idを削除する(ステップS19)。一方、paの多重度が多である場合には、関係解析部11は、Lから/pa/pb、/pa/pb/:id、/pb/pa、/pb/pa/:idを削除する(ステップS20)。

0048

そして、関係解析部11は、eのタイプを判定し(ステップS21)、一方向である場合には、Lから/pb/:id/pa、/pb/:id/pa/:id、/pb/pa、/pb/pa/:idを削除する(ステップS22)。そして、関係解析部11は、eの多重度を判定し(ステップS23)、1対1である場合には、Lから/pa/:id/pb/:id、/pa/pb/:idを削除し(ステップS24)、ステップS40へ進む。また、eの多重度が多対1である場合には、関係解析部11は、Lから/pa/:id/pb/:id、/pa/pb/:id、/pa/pbを削除し(ステップS25)、ステップS40へ進む。また、eの多重度が多対多である場合には、関係解析部11は、Lから/pa/pb/:id、/pa/pbを削除し(ステップS26)、ステップS40へ進む。

0049

また、eのタイプが双方向である場合には、関係解析部11は、eの多重度を判定し(ステップS27)、1対多である場合には、Lから/pb/:id/pa/:id、/pb/pa、/pb/pa/:idを削除し(ステップS28)、ステップS40へ進む。また、1対1である場合には、関係解析部11は、Lから/pa/:id/pb/:id、/pa/pb/:id、/pb/:id/pa/:id、/pb/pa/:idを削除し(ステップS29)、ステップS40へ進む。また、多対1である場合には、関係解析部11は、Lから/pa/:id/pb/:id、/pa/pb/、/pa/pb/:idを削除し(ステップS30)、ステップS40へ進む。また、多対多である場合には、関係解析部11は、Lから/pa/pb、/pa/pb/:id、/pb/pa/、/pb/pa/:idを削除し(ステップS31)、ステップS40へ進む。

0050

また、eのタイプが基本集約である場合には、図15Bに示すように、関係解析部11は、Lから/pb/:id/pa、/pb/:id/pa/:id、/pb/pa、/pb/pa/:idを削除する(ステップS32)。そして、関係解析部11は、eの多重度を判定し(ステップS33)、1対1である場合には、Lから/pa/:id/pb/:id、/pa/pb/:idを削除する(ステップS34)。そして、関係解析部11は、ステップS40へ進む。

0051

また、eのタイプが複合集約である場合には、関係解析部11は、Lから/pb/:id/pa、/pb/:id/pa/:id、/pb/pa、/pb/pa/:id、/pb、/pb/:idを削除する(ステップS35)。そして、関係解析部11は、eの多重度を判定し(ステップS36)、1対1である場合には、Lから/pa/:id/pb/:id、/pa/pb/:idを削除する(ステップS37)。そして、関係解析部11は、ステップS40へ進む。

0052

また、eのタイプが継承である場合には、関係解析部11は、Lから/pa/:id/pb、/pa/:id/pb/:id、/pa/pb、/pa/pb/:id、/pb/:id/pa、/pb/:id/pa/:id、/pb/pa、/pb/pa/:idを削除する(ステップS38)。そして、関係解析部11は、ステップS40へ進む。

0053

また、eのタイプが実現である場合には、関係解析部11は、paの親との関係をeとし(ステップS39)、ステップS21に戻る。

0054

そして、関係解析部11は、Lに含まれるURLを想定エンドポイント記憶部12に書き加え(ステップS40)、eがまだ残っているか否かを判定する(ステップS41)。そして、関係解析部11は、eがまだ残っている場合には、ステップS11に戻る。

0055

一方、eが残っていない場合には、関係解析部11は、想定エンドポイント記憶部12に、インタフェースクラスに基づいてジョイン(join)可能な2つのURLがあれば、2つのURLをジョインする(ステップS42)。例えば、「/x/y*」と「/y*/z」があれば、関係解析部11は、2つのURLをジョインして「/x/z」とする。そして、関係解析部11は、想定エンドポイント記憶部12から「クラス名*」を含むURLを削除する(ステップS43)。ステップS42とステップS43の処理によって、関係解析部11は、想定エンドポイント記憶部12が記憶するURLからインタフェースクラス名を含むURLを取り除くことができる。

0056

このように、関係解析部11は、2つのクラスの間の関係毎に関係のタイプ及び多重度に基づいてURLを生成することで、想定エンドポイントを生成することができる。

0057

次に、名詞動詞情報を生成する処理のフローについて説明する。図16は、名詞動詞情報を生成する処理のフローを示すフローチャートである。図16に示すように、ログ解析部13は、既存ウェブアプリのアクセスログ3からログを1つ取り出す(ステップS51)。

0058

そして、ログ解析部13は、ログから動詞を抽出して名詞動詞記憶部14に格納する(ステップS52)。そして、ログ解析部13は、ログにクラス名と同じ名詞がある場合には、名詞を動詞に対応付けて名詞動詞記憶部14に格納する(ステップS53)。

0059

そして、ログ解析部13は、ログがまだ残っているか否かを判定し(ステップS54)、残っている場合には、ステップS51に戻り、残っていない場合には、処理を終了する。

0060

このように、ログ解析部13がアクセスログ3から名詞動詞情報を生成することで、実エンドポイント生成部16は実エンドポイントを生成することができる。

0061

次に、実エンドポイントを生成する処理のフローについて説明する。図17は、実エンドポイントを生成する処理のフローを示すフローチャートである。図17に示すように、実エンドポイント生成部16は、名詞動詞記憶部14が記憶する動詞のうち名詞が対応付けられている動詞を1つ選択する(ステップS61)。

0062

そして、実エンドポイント生成部16は、選択した動詞を変換情報記憶部15を参照してHTTPメソッド名に変換する(ステップS62)。そして、実エンドポイント生成部16は、選択した動詞に対応付けられた名詞を「/」で結合しパスを生成する(ステップS63)。

0063

そして、実エンドポイント生成部16は、HTTPメソッド名とパスを用いて実エンドポイントを生成し、実エンドポイント記憶部17に格納する(ステップS64)。そして、実エンドポイント生成部16は、名詞が対応付けられている動詞が残っているか否かを判定し(ステップS65)、残っている場合には、ステップS61に戻り、残っていない場合には、処理を終了する。

0064

このように、実エンドポイント生成部16は、名詞動詞情報を用いて実エンドポイントを生成することで、仕様エンドポイントの候補を生成することができる。

0065

次に、仕様エンドポイントを生成する処理のフローについて説明する。図18は、仕様エンドポイントを生成する処理のフローを示すフローチャートである。図18に示すように、マージ部18は、実エンドポイント記憶部17から実エンドポイントを1つ取り出す(ステップS71)。

0066

そして、マージ部18は、取り出した実エンドポイントが想定エンドポイント記憶部12が記憶する想定エンドポイントに含まれるか否かを判定し(ステップS72)、含まれない場合には、ステップS74に進む。

0067

一方、取り出した実エンドポイントが想定エンドポイント記憶部12が記憶する想定エンドポイントに含まれる場合には、マージ部18は、実エンドポイントを仕様エンドポイントとして仕様エンドポイント記憶部19に格納する(ステップS73)。

0068

そして、マージ部18は、実エンドポイントが残っているか否かを判定し(ステップS74)、残っている場合には、ステップS71に戻り、残っていない場合には、処理を終了する。

0069

このように、マージ部18が仕様エンドポイントを生成することで、仕様書作成装置1は、WebAPI仕様書5を作成することができる。

0070

上述してきたように、実施例では、関係解析部11がクラス関係情報2に基づいて想定エンドポイントを生成する。また、ログ解析部13がアクセスログ3からクラス関係情報2を参照して名詞動詞情報を抽出し、実エンドポイント生成部16が名詞動詞情報の動詞をHTTPメソッド名に変換し、名詞をパスに変換することで実エンドポイントを生成する。そして、マージ部18が実エンドポイントのうち関係解析部11により生成された想定エンドポイントに含まれるエンドポイントを仕様エンドポイントとして特定する。したがって、仕様書作成装置1は、仕様エンドポイントをWebAPI仕様に関する情報として活用することができる。

0071

また、実施例では、作成部20が仕様エンドポイントとウェブアプリ設計書4に基づいてWebAPI仕様書5を作成する。したがって、仕様書作成装置1は、WebAPI仕様書5を自動的に作成することができる。

0072

また、実施例では、ログ解析部13は、名詞動詞情報の名詞のうちクラス関係情報2にクラス名として含まれる名詞だけをパスとして用いる。したがって、実エンドポイント生成部16は、クラス関係情報2と整合のとれた実エンドポイントを生成することができる。

0073

また、実施例では、関係解析部11は、2つのクラスの間の関係のタイプ及び2つのクラスの間の多重度に基づいて、想定されないURLを除外して想定エンドポイントを生成する。したがって、仕様書作成装置1は、想定できないAPIをWebAPI仕様書5から除外することができる。

0074

また、実施例では、画面アクセスログに基づく実エンドポイントを想定エンドポイントと比較することで、設計者は、クラス関係情報2のうち画面が作成されていないクラスを把握することができ、画面の不足を見つけることができる。

0075

なお、実施例では、仕様書作成装置1について説明したが、仕様書作成装置1が有する構成をソフトウェアによって実現することで、同様の機能を有する仕様書作成プログラムを得ることができる。そこで、仕様書作成プログラムを実行するコンピュータについて説明する。

0076

図19は、実施例に係る仕様書作成プログラムを実行するコンピュータのハードウェア構成を示す図である。図19に示すように、コンピュータ50は、メインメモリ51と、CPU(Central Processing Unit)52と、LAN(Local Area Network)インタフェース53と、HDD(Hard Disk Drive)54とを有する。また、コンピュータ50は、スーパーIO(Input Output)55と、DVI(Digital Visual Interface)56と、ODD(Optical Disk Drive)57とを有する。

0077

メインメモリ51は、プログラムやプログラムの実行途中結果などを記憶するメモリである。CPU52は、メインメモリ51からプログラムを読み出して実行する中央処理装置である。CPU52は、メモリコントローラを有するチップセットを含む。

0078

LANインタフェース53は、コンピュータ50をLAN経由で他のコンピュータに接続するためのインタフェースである。HDD54は、プログラムやデータを格納するディスク装置であり、スーパーIO55は、マウスキーボードなどの入力装置を接続するためのインタフェースである。DVI56は、液晶表示装置を接続するインタフェースであり、ODD57は、DVDの読み書きを行う装置である。

0079

LANインタフェース53は、PCIエクスプレスPCIe)によりCPU52に接続され、HDD54及びODD57は、SATA(Serial Advanced Technology Attachment)によりCPU52に接続される。スーパーIO55は、LPC(Low Pin Count)によりCPU52に接続される。

実施例

0080

そして、コンピュータ50において実行される仕様書作成プログラムは、DVDに記憶され、ODD57によってDVDから読み出されてコンピュータ50にインストールされる。あるいは、仕様書作成プログラムは、LANインタフェース53を介して接続された他のコンピュータシステムデータベースなどに記憶され、これらのデータベースから読み出されてコンピュータ50にインストールされる。そして、インストールされた仕様書作成プログラムは、HDD54に記憶され、メインメモリ51に読み出されてCPU52によって実行される。

0081

1仕様書作成装置
2クラス
3アクセスログ
4ウェブアプリ設計書
5 WebAPI仕様書
7要求応答
8画面
11 関係解析部
12 想定エンドポイント記憶部
13ログ解析部
14名詞動詞記憶部
15変換情報記憶部
16 実エンドポイント生成部
17 実エンドポイント記憶部
18マージ部
19仕様エンドポイント記憶部
20 作成部
50コンピュータ
51メインメモリ
52 CPU
53LANインタフェース
54 HDD
55スーパーIO
56DVI
57ODD

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 株式会社トラスト・テクノロジーの「 プログラミング装置、およびプログラム」が 公開されました。( 2021/04/01)

    【課題・解決手段】画像処理アルゴリズムに代表されるプログラムの作成や編集中のプログラムの妥当性を容易に確認することができるプログラミング装置、およびプログラムを提供する。プログラミング装置は、ユーザ操... 詳細

  • 株式会社デンソークリエイトの「 設計支援ツール」が 公開されました。( 2021/04/01)

    【課題】所定の約束事に縛られることなく、自由にメタモデルやメタモデルを構成するメタクラスを変更できる。そのうえで、各工程のメタモデル間の関係をトレース情報として用いることができるようにする。【解決手段... 詳細

  • 株式会社デンソークリエイトの「 設計支援ツール」が 公開されました。( 2021/04/01)

    【課題】所定の約束事に縛られることなく、自由にメタモデルやメタモデルを構成するメタクラスを変更する事ができるようにする。【解決手段】システム開発の要件定義、論理設計、制御設計、及び物理設計と、ソフトウ... 詳細

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ