(57)【特許請求の範囲】
【請求項１】
オペレーションシステムの所定の管理対象の種別と所定の他の管理対象の種別とが所定の関係を有する場合、前記所定の管理対象の種別が保持するリソースデータ項目を、前記他の管理対象の種別を一意に識別するリソースＵＲＩ（Uniform Resource Identifier）が記載されるリストの追加、または、前記他の管理対象の種別が保持するリソースデータ項目の追加により更新することで、前記所定の管理対象のリソースデータ項目を設計する第１の設計手段と、
前記所定の管理対象の種別に基づくＵＲＩに各種別の間で共通して付与される共通ＵＲＩを追加することで、前記管理対象の種別を識別するためのリソースＵＲＩを設計する第２の設計手段と
を備えたことを特徴とするシステム間インタフェース設計装置。
【請求項２】
前記関係は、
（１）前記所定の管理対象の種別と前記他の管理対象の種別とが結び付きを有することを示す関連、
（２）前記所定の管理対象の種別と前記他の管理対象の種別とが、全体および一部の関係を有することを示す集約、
（３）前記所定の管理対象の種別と前記他の管理対象の種別とが、互いに不可欠な構成要素としての結び付きを有することを示すコンポジション、および、
（４）前記所定の管理対象の種別と前記他の管理対象の種別の一方が他方を汎化することを示す汎化
を含み、
前記第１の設計手段は、
前記所定の管理対象の種別と前記他の管理対象の種別とが、前記関連、前記集約、前記コンポジションの関係を有する場合、前記所定の管理対象の種別が保持するリソースデータ項目に対し、前記他の管理対象の種別を一意に識別するＵＲＩが記載されるリストを追加することで、前記所定の管理対象のリソースデータ項目を設計し、
前記所定の管理対象の種別と前記他の管理対象の種別とが、前記他の管理対象の種別が前記所定の管理対象の種別を汎化する関係を有する場合、前記所定の管理対象の種別が保持するリソースデータ項目に対し、前記他の管理対象の種別が保持するリソースデータ項目を追加することで、前記所定の管理対象のリソースデータ項目を設計する
ことを特徴とする請求項１に記載のシステム間インタフェース設計装置。
【請求項３】
前記関係は、
（１）前記所定の管理対象の種別と前記他の管理対象の種別とが結び付きを有することを示す関連、
（２）前記所定の管理対象の種別と前記他の管理対象の種別とが、全体および一部の関係を有することを示す集約、
（３）前記所定の管理対象の種別と前記他の管理対象の種別とが、互いに不可欠な構成要素としての結び付きを有することを示すコンポジション、および、
（４）前記所定の管理対象の種別と前記他の管理対象の種別の一方が他方を汎化することを示す汎化
を含み、
前記第１の設計手段は、
前記所定の管理対象の種別と前記他の管理対象の種別とが、前記関連、前記集約の関係を有する場合、前記所定の管理対象の種別が保持するリソースデータ項目に対し、前記他の管理対象の種別を一意に識別するＵＲＩが記載されるリストを追加することで、前記所定の管理対象のリソースデータ項目を設計し、
前記所定の管理対象の種別と前記他の管理対象の種別とが、前記他の管理対象の種別が前記所定の管理対象の種別を汎化する関係を有する場合、前記所定の管理対象の種別が保持するリソースデータ項目に対し、前記他の管理対象の種別が保持するリソースデータ項目を追加することで、前記所定の管理対象のリソースデータ項目を設計し、
前記所定の管理対象の種別と前記他の管理対象の種別とが、前記コンポジションにおける、前記所定の管理対象の種別が前記他の管理対象の不可欠な構成要素であることを示す関係を有する場合、前記所定の管理対象の種別に基づくＵＲＩに、前記共通ＵＲＩ、および前記他の管理対象の種別に基づくＵＲＩを追加することで、前記管理対象の種別を識別するためのリソースＵＲＩを設計する
ことを特徴とする請求項１に記載のシステム間インタフェース設計装置。
【請求項４】
システム間インタフェース設計装置に適用されるシステム間インタフェース設計方法であって、
オペレーションシステムの所定の管理対象の種別と所定の他の管理対象の種別とが所定の関係を有する場合、前記所定の管理対象の種別が保持するリソースデータ項目を、前記他の管理対象の種別を一意に識別するリソースＵＲＩ（Uniform Resource Identifier）が記載されるリストの追加、または、前記他の管理対象の種別が保持するリソースデータ項目の追加により更新することで、前記所定の管理対象のリソースデータ項目を設計し、
前記所定の管理対象の種別に基づくＵＲＩに各種別の間で共通して付与される共通ＵＲＩを追加することで、前記管理対象の種別を識別するためのリソースＵＲＩを設計する
ことを特徴とするシステム間インタフェース設計方法。
【請求項５】
前記関係は、
（１）前記所定の管理対象の種別と前記他の管理対象の種別とが結び付きを有することを示す関連、
（２）前記所定の管理対象の種別と前記他の管理対象の種別とが、全体および一部の関係を有することを示す集約、
（３）前記所定の管理対象の種別と前記他の管理対象の種別とが、互いに不可欠な構成要素としての結び付きを有することを示すコンポジション、および、
（４）前記所定の管理対象の種別と前記他の管理対象の種別の一方が他方を汎化することを示す汎化
を含み、
前記所定の管理対象の種別と前記他の管理対象の種別とが、前記関連、前記集約、前記コンポジションの関係を有する場合、前記所定の管理対象の種別が保持するリソースデータ項目に対し、前記他の管理対象の種別を一意に識別するＵＲＩが記載されるリストを追加することで、前記所定の管理対象のリソースデータ項目を設計し、
前記所定の管理対象の種別と前記他の管理対象の種別とが、前記他の管理対象の種別が前記所定の管理対象の種別を汎化する関係を有する場合、前記所定の管理対象の種別が保持するリソースデータ項目に対し、前記他の管理対象の種別が保持するリソースデータ項目を追加することで、前記所定の管理対象のリソースデータ項目を設計する
ことを特徴とする請求項４に記載のシステム間インタフェース設計方法。
【請求項６】
前記関係は、
（１）前記所定の管理対象の種別と前記他の管理対象の種別とが結び付きを有することを示す関連、
（２）前記所定の管理対象の種別と前記他の管理対象の種別とが、全体および一部の関係を有することを示す集約、
（３）前記所定の管理対象の種別と前記他の管理対象の種別とが、互いに不可欠な構成要素としての結び付きを有することを示すコンポジション、および、
（４）前記所定の管理対象の種別と前記他の管理対象の種別の一方が他方を汎化することを示す汎化
を含み、
前記所定の管理対象の種別と前記他の管理対象の種別とが、前記関連、前記集約の関係を有する場合、前記所定の管理対象の種別が保持するリソースデータ項目に対し、前記他の管理対象の種別を一意に識別するＵＲＩが記載されるリストを追加することで、前記所定の管理対象のリソースデータ項目を設計し、
前記所定の管理対象の種別と前記他の管理対象の種別とが、前記他の管理対象の種別が前記所定の管理対象の種別を汎化する関係を有する場合、前記所定の管理対象の種別が保持するリソースデータ項目に対し、前記他の管理対象の種別が保持するリソースデータ項目を追加することで、前記所定の管理対象のリソースデータ項目を設計し、
前記所定の管理対象の種別と前記他の管理対象の種別とが、前記コンポジションにおける、前記所定の管理対象の種別が前記他の管理対象の不可欠な構成要素であることを示す関係を有する場合、前記所定の管理対象の種別に基づくＵＲＩに、前記共通ＵＲＩ、および前記他の管理対象の種別に基づくＵＲＩを追加することで、前記管理対象の種別を識別するためのリソースＵＲＩを設計する
ことを特徴とする請求項４に記載のシステム間インタフェース設計方法。
【請求項７】
請求項１乃至請求項３のいずれかに記載のシステム間インタフェース設計装置の一部分として動作するコンピュータに用いられるプログラムであって、
前記コンピュータを、前記第１の設計手段および前記第２の設計手段として機能させるためのシステム間インタフェース設計処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、システム間インタフェース設計装置、システム間インタフェースの設計方法およびシステム間インタフェース設計処理プログラムに関する。
【背景技術】
【０００２】
分散型システムを連携させるシステム間インタフェースの設計思想の一つに、REST APIが挙げられる。REST APIは、Uniform Resource Identifier（URI）で一意に識別されるリソース（資源）をHyperText Transfer Protocol（HTTP）で規定されたメソッド（GET, POST, PUT, DELETEなど）で操作するものである。  
このREST APIは、（１）すべてのリソースが独自の一意なURIを持つことによる「アドレス可能性」、（２）複数種類のリソースが相互にリンクされることによる「接続性」、（３）標準化されたHTTPのメソッドを利用することによる「統一インタフェース」、（４）サーバが以前のリクエスト情報を保持しないことによる「ステートレス性」などの特徴を持つ。
【０００３】
REST APIは、Webサービスを想定したインタフェースの設計思想である。ただし、ネットワークを運用管理するためのシステム（以下、オペレーションシステム）においても、ネットワーク、当該ネットワークを構成する装置（例えばスイッチやルータ）、当該装置に付随する物理ポート等の管理対象をリソースとして扱うことで、REST APIに則したインタフェースを設計することができる、また、例えば非特許文献１に開示されるような、インタフェース設計のガイドラインも公開されている。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】TeleManagement Forum GB983, "REST API Design Guidelines," Version 1.0.1, October 2013.
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、どのようなURIによってリソースを識別し、これらのリソースがどのようなデータ項目を保持するかは、インタフェースの設計者に委ねられている。そのため、REST APIに則したURIやデータ項目を設計するためのスキルが設計者において不足している場合、インタフェースの設計に時間がかかることが懸念される。
【０００６】
本発明の目的は、インタフェース設計のスキルレス化と設計期間の短縮を実現できるシステム間インタフェース設計装置およびシステム間インタフェースの設計方法を提供することである。
【課題を解決するための手段】
【０００７】
上記目的を達成するために、この発明の実施形態におけるシステム間インタフェース設計装置の第１の態様は、オペレーションシステムの所定の管理対象の種別と所定の他の管理対象の種別とが所定の関係を有する場合、前記所定の管理対象の種別が保持するリソースデータ項目を、前記他の管理対象の種別を一意に識別するリソースＵＲＩが記載されるリストの追加、または、前記他の管理対象の種別が保持するリソースデータ項目の追加により更新することで、前記所定の管理対象のリソースデータ項目を設計する第１の設計手段と、前記所定の管理対象の種別に基づくＵＲＩに各種別の間で共通して付与される共通ＵＲＩを追加することで、前記管理対象の種別を識別するためのリソースＵＲＩを設計する第２の設計手段とを有する装置を提供する。
【０００８】
上記構成のシステム間インタフェース設計装置の第２の態様は、第１の態様において、前記関係は、（１）前記所定の管理対象の種別と前記他の管理対象の種別とが結び付きを有することを示す関連、（２）前記所定の管理対象の種別と前記他の管理対象の種別とが、全体および一部の関係を有することを示す集約、（３）前記所定の管理対象の種別と前記他の管理対象の種別とが、互いに不可欠な構成要素としての結び付きを有することを示すコンポジション、および、（４）前記所定の管理対象の種別と前記他の管理対象の種別の一方が他方を汎化することを示す汎化を含み、前記第１の設計手段は、前記所定の管理対象の種別と前記他の管理対象の種別とが、前記関連、前記集約、前記コンポジションの関係を有する場合、前記所定の管理対象の種別が保持するリソースデータ項目に対し、前記他の管理対象の種別を一意に識別するＵＲＩが記載されるリストを追加することで、前記所定の管理対象のリソースデータ項目を設計し、前記所定の管理対象の種別と前記他の管理対象の種別とが、前記他の管理対象の種別が前記所定の管理対象の種別を汎化する関係を有する場合、前記所定の管理対象の種別が保持するリソースデータ項目に対し、前記他の管理対象の種別が保持するリソースデータ項目を追加することで、前記所定の管理対象のリソースデータ項目を設計するシステムを提供する。
【０００９】
上記構成のシステム間インタフェース設計装置の第３の態様は、第１の態様において、前記関係は、（１）前記所定の管理対象の種別と前記他の管理対象の種別とが結び付きを有することを示す関連、（２）前記所定の管理対象の種別と前記他の管理対象の種別とが、全体および一部の関係を有することを示す集約、（３）前記所定の管理対象の種別と前記他の管理対象の種別とが、互いに不可欠な構成要素としての結び付きを有することを示すコンポジション、および、（４）前記所定の管理対象の種別と前記他の管理対象の種別の一方が他方を汎化することを示す汎化を含み、前記第１の設計手段は、前記所定の管理対象の種別と前記他の管理対象の種別とが、前記関連、前記集約の関係を有する場合、前記所定の管理対象の種別が保持するリソースデータ項目に対し、前記他の管理対象の種別を一意に識別するＵＲＩが記載されるリストを追加することで、前記所定の管理対象のリソースデータ項目を設計し、前記所定の管理対象の種別と前記他の管理対象の種別とが、前記他の管理対象の種別が前記所定の管理対象の種別を汎化する関係を有する場合、前記所定の管理対象の種別が保持するリソースデータ項目に対し、前記他の管理対象の種別が保持するリソースデータ項目を追加することで、前記所定の管理対象のリソースデータ項目を設計し、前記所定の管理対象の種別と前記他の管理対象の種別とが、前記コンポジションにおける、前記所定の管理対象の種別が前記他の管理対象の不可欠な構成要素であることを示す関係を有する場合、前記所定の管理対象の種別に基づくＵＲＩに、前記共通ＵＲＩ、および前記他の管理対象の種別に基づくＵＲＩを追加することで、前記管理対象の種別を識別するためのリソースＵＲＩを設計するシステムを提供する。
【００１０】
本発明の実施形態におけるシステム間インタフェース設計方法の第１の態様は、システム間インタフェース設計装置に適用されるシステム間インタフェース設計方法であって、オペレーションシステムの所定の管理対象の種別と所定の他の管理対象の種別とが所定の関係を有する場合、前記所定の管理対象の種別が保持するリソースデータ項目を、前記他の管理対象の種別を一意に識別するリソースＵＲＩが記載されるリストの追加、または、前記他の管理対象の種別が保持するリソースデータ項目の追加により更新することで、前記所定の管理対象のリソースデータ項目を設計し、前記所定の管理対象の種別に基づくＵＲＩに各種別の間で共通して付与される共通ＵＲＩを追加することで、前記管理対象の種別を識別するためのリソースＵＲＩを設計する方法を提供する。
【００１１】
上記のシステム間インタフェース設計方法の第２の態様は、第１の態様において、前記関係は、（１）前記所定の管理対象の種別と前記他の管理対象の種別とが結び付きを有することを示す関連、（２）前記所定の管理対象の種別と前記他の管理対象の種別とが、全体および一部の関係を有することを示す集約、（３）前記所定の管理対象の種別と前記他の管理対象の種別とが、互いに不可欠な構成要素としての結び付きを有することを示すコンポジション、および、（４）前記所定の管理対象の種別と前記他の管理対象の種別の一方が他方を汎化することを示す汎化を含み、前記所定の管理対象の種別と前記他の管理対象の種別とが、前記関連、前記集約、前記コンポジションの関係を有する場合、前記所定の管理対象の種別が保持するリソースデータ項目に対し、前記他の管理対象の種別を一意に識別するＵＲＩが記載されるリストを追加することで、前記所定の管理対象のリソースデータ項目を設計し、前記所定の管理対象の種別と前記他の管理対象の種別とが、前記他の管理対象の種別が前記所定の管理対象の種別を汎化する関係を有する場合、前記所定の管理対象の種別が保持するリソースデータ項目に対し、前記他の管理対象の種別が保持するリソースデータ項目を追加することで、前記所定の管理対象のリソースデータ項目を設計する方法を提供する。
【００１２】
上記のシステム間インタフェース設計方法の第３の態様は、第１の態様において、前記関係は、（１）前記所定の管理対象の種別と前記他の管理対象の種別とが結び付きを有することを示す関連、（２）前記所定の管理対象の種別と前記他の管理対象の種別とが、全体および一部の関係を有することを示す集約、（３）前記所定の管理対象の種別と前記他の管理対象の種別とが、互いに不可欠な構成要素としての結び付きを有することを示すコンポジション、および、（４）前記所定の管理対象の種別と前記他の管理対象の種別の一方が他方を汎化することを示す汎化を含み、前記所定の管理対象の種別と前記他の管理対象の種別とが、前記関連、前記集約の関係を有する場合、前記所定の管理対象の種別が保持するリソースデータ項目に対し、前記他の管理対象の種別を一意に識別するＵＲＩが記載されるリストを追加することで、前記所定の管理対象のリソースデータ項目を設計し、前記所定の管理対象の種別と前記他の管理対象の種別とが、前記他の管理対象の種別が前記所定の管理対象の種別を汎化する関係を有する場合、前記所定の管理対象の種別が保持するリソースデータ項目に対し、前記他の管理対象の種別が保持するリソースデータ項目を追加することで、前記所定の管理対象のリソースデータ項目を設計し、前記所定の管理対象の種別と前記他の管理対象の種別とが、前記コンポジションにおける、前記所定の管理対象の種別が前記他の管理対象の不可欠な構成要素であることを示す関係を有する場合、前記所定の管理対象の種別に基づくＵＲＩに、前記共通ＵＲＩ、および前記他の管理対象の種別に基づくＵＲＩを追加することで、前記管理対象の種別を識別するためのリソースＵＲＩを設計する方法を提供する。
【００１３】
本発明の実施形態におけるシステム間インタフェース設計処理プログラムの態様は、第１乃至第３の態様のいずれかにおけるシステム間インタフェース設計装置の一部分として動作するコンピュータに用いられるプログラムであって、前記コンピュータを、前記第１の設計手段および前記第２の設計手段として機能させるためのプログラムを提供する。
【発明の効果】
【００１４】
本発明によれば、インタフェース設計のスキルレス化と設計期間の短縮を実現するが可能になる。
【図面の簡単な説明】
【００１５】
【図１】本発明の実施形態におけるシステム間インタフェース設計装置の構成例を示す図。
【図２】本発明の実施形態におけるシステム間インタフェース設計装置のリソース設計部の動作の一例を示すフローチャート。
【図３】本発明の実施形態におけるシステム間インタフェース設計装置による、情報の種別の処理の一例を示すフローチャート。
【図４】本発明の実施形態におけるシステム間インタフェース設計装置による、データ項目の処理の一例を示すフローチャート。
【図５】本発明の実施形態におけるシステム間インタフェース設計装置による、関係性の処理の一例を示すフローチャート。
【図６】本発明の実施形態におけるシステム間インタフェース設計装置による、共通URIの処理の一例を示すフローチャート。
【図７】本発明の実施形態におけるシステム間インタフェース設計装置により処理する、管理対象の種別、各管理対象の種別が保持するデータ項目、各管理対象の種別間の関係性の一例を示す図。
【図８】本発明の実施形態におけるシステム間インタフェース設計装置における、管理対象の種別の一例を示す図。
【図９】本発明の実施形態におけるシステム間インタフェース設計装置により処理する、管理対象の種別が保持するデータ項目の一例を示す図。
【図１０】本発明の実施形態におけるシステム間インタフェース設計装置により処理する、管理対象の種別間の関係性の一例を示す図。
【図１１】本発明の実施形態におけるシステム間インタフェース設計装置により処理する、共通URIの一例を示す図。
【図１２】本発明の実施形態におけるシステム間インタフェース設計装置による、関係性の処理の具体例を示すフローチャート。
【図１３】本発明の実施形態におけるシステム間インタフェース設計装置のリソースURI保持部が保持する情報の一例を示す図。
【図１４】本発明の実施形態におけるシステム間インタフェース設計装置のリソースデータ項目保持部が保持する情報の一例を示す図。
【図１５】本発明の実施形態におけるシステム間インタフェース設計装置による、関係性の処理の変形例を示すフローチャート。
【図１６】本発明の実施形態におけるシステム間インタフェース設計装置のリソースURI保持部が保持する情報の一例を示す図。
【図１７】本発明の実施形態におけるシステム間インタフェース設計装置のリソースデータ項目保持部が保持する情報の一例を示す図。
【発明を実施するための形態】
【００１６】
以下、図面を用いて本発明の実施の形態について詳細に説明する。  
図１は、本発明の実施形態におけるシステム間インタフェース設計装置の構成例を示す図である。  
図１に示すように、本発明の実施形態におけるシステム間インタフェース設計装置１０は、リソース設計部１１、リソースURI保持部１２、リソースデータ項目保持部１３を有する。リソースURI保持部１２、リソースデータ項目保持部１３は、例えば不揮発性メモリなどの記憶媒体である。
【００１７】
リソース設計部１１は、（１）オペレーションシステムの管理対象の種別、（２）管理対象の種別が保持するデータ項目、（３）管理対象の種別間の関係性、（４）全リソースに共通的に付与されるURI（以下、共通URI）を入力データとして、REST APIにおけるリソースのURIとデータ項目とを設計する。
【００１８】
リソース設計部１１は、リソースのURIの設計結果をリソースURI保持部１２に格納し、リソースのデータ項目の設計結果をリソースデータ項目保持部１３に格納する。各入力データは、システム間インタフェースの設計者が本発明の実施形態におけるシステム間インタフェース設計装置１０に入力するものとする。
【００１９】
図２は、本発明の実施形態におけるシステム間インタフェース設計装置のリソース設計部の動作の一例を示すフローチャートである。  
図２に示した例では、まず、リソース設計部１１は、（１）管理対象の種別、（２）管理対象の種別が保持するデータ項目、（３）管理対象の種別間の関係性、（４）共通URIを入力データとして読み込む（Ｓ１）。
【００２０】
その後、リソース設計部１１は、それぞれの入力データに対して処理を行なうことで、各管理対象の種別のリソースURIとリソースデータ項目とを設計する。詳しくは、リソース設計部１１は、管理対象の種別に対する処理を行ない（Ｓ２）、管理対象の種別が保持するデータ項目に対する処理を行ない（Ｓ３）、管理対象の種別間の関係性に対する処理として、リソースURIやリソースデータ項目の更新を行ない（Ｓ４）、共通URIに対する処理を行なう（Ｓ５）。
【００２１】
そして、リソース設計部１１は、リソースURIの設計結果をリソースURI保持部１２に格納（書き込み）し、リソースデータ項目の設計結果をリソースデータ項目保持部１３に格納する（Ｓ６）。
【００２２】
次に、Ｓ２に該当する、管理対象の種別の処理の詳細について説明する。  
図３は、本発明の実施形態におけるシステム間インタフェース設計装置による、管理対象の種別の処理の一例を示すフローチャートである。  
この例では、まず、リソース設計部１１は、全ての管理対象の種別について、設計対象である、各種別のリソースURIの一部として“/管理対象の種別/{id}”を設定する（Ｓ２Ａ）。URIにおいて、“/”は、リソースの階層構造を表現するものである。また、URIにおいて、{id}は、各種別の管理対象を一意に識別するための識別子である。インタフェースの設計では、この識別子を変数として扱う。  
以上により、各管理対象の種別について、この種別の管理対象を一意に識別するためのリソースURIの一部が設計される。ただし、ここで設計したリソースURIは、以降の工程で更新されて、各種別の最終的な設計対象であるリソースURIとなる。
【００２３】
次に、Ｓ３に該当する、管理対象の種別が保持するデータ項目の処理の詳細について説明する。  
図４は、本発明の実施形態におけるシステム間インタフェース設計装置による、管理対象の種別が保持するデータ項目の処理の一例を示すフローチャートである。  
本例では、リソース設計部１１は、全ての管理対象の種別について、各種別のリソースデータ項目として、入力データから得られる当該管理対象の種別が保持するデータ項目を設定する（Ｓ３Ａ）。  
これにより、各管理対象の種別について、この種別の管理対象が保持するデータ項目が設計される。なお、リソースURIと同様に、ここで設計したリソースデータ項目は、最終的なリソースデータ項目の設計のために以降の工程で更新される場合がある。
【００２４】
次に、Ｓ４に該当する、管理対象の種別間の関係性の処理の詳細について説明する。  
図５は、本発明の実施形態におけるシステム間インタフェース設計装置による、管理対象の種別間の関係性の処理の一例を示すフローチャートである。  
本例では、リソース設計部１１は、全ての管理対象の種別が持つ、他種別へのそれぞれの関係性に対して、関係性毎に予め定めた処理を行う（Ｓ４Ａ）。この処理は、「リソースURIの更新」、「リソースデータ項目の更新」、「処理なし」の３種類のいずれかに分類されるが、具体的な処理の内容については予め定められるものとする。具体的な処理の内容を記載した例については、後述する図１２や図１５などを用いて説明する。
【００２５】
次に、Ｓ５に該当する、共通URIの処理の詳細について説明する。  
図６は、本発明の実施形態におけるシステム間インタフェース設計装置による、共通URIの処理の一例を示すフローチャートである。  
共通URIは、全てのリソースに共通的に付与されるURIであり、本例では、リソース設計部１１は、全ての管理対象の種別について、Ｓ２で設定した、当該種別のリソースURIの前段に共通URIを挿入する（Ｓ５Ａ）。これによって、共通URIが全てのリソースに付与される。
【００２６】
以下では、図面を用いて本発明の実施形態について詳細に説明する。  
図７は、本発明の実施形態におけるシステム間インタフェース設計装置により処理する、管理対象の種別、管理対象の種別が保持するデータ項目、管理対象の種別間の関係性の一例を示す図である。  
この図７では、管理対象の種別をクラスとし、各管理対象の種別が保持するデータ項目をクラスの属性とし、各管理対象の関係性をクラス間の関係性（関連(association)、集約(aggregation)、コンポジション(composition)、汎化(generalization)）として、統一モデリング言語（UML(Unified Modeling Language)）のクラス図で表現している。
【００２７】
関連は、所定の管理対象の種別と所定の他の管理対象の種別とが結び付きを有することを示す。  
集約は、所定の管理対象の種別と他の管理対象の種別が全体および一部の関係を有することを示す。  
コンポジションは、上記の関連の一種で、所定の管理対象の種別と他の管理対象の種別とが、互いに不可欠な構成要素としての結び付きを有することを示す。  
汎化は、所定の管理対象の種別と他の管理対象の種別との一方が他方を汎化することを示す。
【００２８】
各クラスは管理対象の種別を表す。“Network”クラスはネットワークを表現する管理対象の種別とし、“Hardware”クラスはハードウェアを表現する管理対象の種別とし、“Switch”クラスはネットワークスイッチ（以下、スイッチと称することがある）を表現する管理対象の種別とし、“Router”クラスはルータを表現する管理対象の種別とし、“PhysicalPort”クラスは、ネットワークスイッチやルータが有する物理ポートを表現する管理対象の種別とする。
【００２９】
各クラスの属性は、各管理対象の種別が保持するデータ項目を表す。具体的には、図７に示すように、“Network”クラスは、ネットワークを識別するための識別子（id）、ネットワーク名（name）、ネットワークの管理者（operator）等を属性として保持する。  
“Hardware”クラスは、ハードウェアを識別するための識別子（id）、ハードウェア名（name）、縦×横×高さ（size）、重量（weight）等を属性として保持する。  
“Switch”クラスは、スイッチ種別（switchType）等を属性として保持する。  
“Router”クラスは、ルータ種別（routerType）等を属性として保持する。  
“PhysicalPort”クラスは、物理ポートを識別するための識別子（id）や、ポート名（name）等を属性として保持する。
【００３０】
上記のように、各管理対象の種別（“Network”クラス、“Hardware”クラス、“PhysicalPort”クラス）は、データ項目に当該種別の管理対象を一意に識別するための識別子（id）を含む。  
一方、上記のように“Switch”クラスの属性と“Router”クラスの属性とには識別子が含まれていない。これは、これらのクラスの汎化先の“Hardware”から継承される属性（id, name, size, weight）を省略しているためである。
【００３１】
また、各クラスの関係性は、各管理対象の種別間の関係性を表す。本例では、ネットワークは、スイッチとルータとで構成されるものとして、図７に示すように、“Network”クラスと“Switch”クラスとの間の関係性、および当該“Network”クラスと“Router”クラスとの間の関係性を“集約”と定義する。
ハードウェアは、スイッチとルータを汎化したものであるとして、図７に示すように、“Hardware”クラスと“Switch”クラスとの間の関係性、および当該“Hardware”クラスと“Router”クラスとの間の関係性を“汎化”と定義する。
【００３２】
スイッチとルータは、互いに接続されるものとして、図７に示すように、“Switch”クラスと“Router”クラスとの間の関係性を“関連”と定義する。
【００３３】
スイッチとルータは、不可欠な構成要素として複数の物理ポートを有すものとして、図７に示すように、“Switch”クラスと“PhysicalPort”クラスとの間の関係性、および“Router”クラスと“PhysicalPort”クラスとの間の関係性を“コンポジション”と定義する。  
なお、“関連”、“集約”、“コンポジション”には多重度が定義されるが、本実施形態では用いないため説明を割愛する。
【００３４】
図８は、本発明の実施形態におけるシステム間インタフェース設計装置における、管理対象の種別の一例を示す図である。この図８は、図７で示した例の管理対象の種別を表形式で表したものである。  
本例では、リソース設計部１１は、“Network”、“Hardware”、“Switch”、“Router”、“PhysicalPort”を管理対象の種別としてＳ１にて入力する。
【００３５】
図９は、本発明の実施形態におけるシステム間インタフェース設計装置により処理する、管理対象の種別が保持するデータ項目の一例を示す図である。この図９は、図７で示した例の管理対象の種別が保持するデータ項目を表形式で表したものである。  
本例では、リソース設計部１１は、各管理対象の種別が保持するデータ項目、つまり“Network”が保持するデータ項目（id, name, operator）、“Hardware”が保持するデータ項目（id, name, size, weight）、“Switch”が保持するデータ項目（switchType）、“Router”が保持するデータ項目（routerType）、“PhysicalPort”が保持するデータ項目（id, name）をＳ１にて入力する。
【００３６】
図１０は、本発明の実施形態におけるシステム間インタフェース設計装置により処理する、管理対象の種別間の関係性の一例を示す図である。この図１０は、図７で示した例の管理対象の種別間の関係性を表形式で表したものである。  
本例では、リソース設計部１１は、“Network”、“Hardware”、“Switch”、“Router”、“PhysicalPort”でなる、各管理対象の種別が持つ、他種別との関係性をＳ１にて入力する。
【００３７】
ここでは、“集約”、“コンポジション”、“汎化”については、集約する／コンポジションする／汎化する関係性を、それぞれ集約（先）／コンポジション（先）／汎化（先）と記載する。また、図１０に示した表の、ある行の「管理対象の種別」に集約される／コンポジションされる／汎化される関係性を、それぞれ集約（元）／コンポジション（元）／汎化（元）と記載した。例えば、図１０に示した表における管理対象の種別“Network”に対して、関係性「集約（元）」とともに、表の同じ行で関連付けられる対象“Switch”、“Router”は、同じ行で関連付けられる管理対象の種別“Network”の集約元である。
【００３８】
図１１は、本発明の実施形態におけるシステム間インタフェース設計装置により処理する、共通URIの一例を示す図である。  
システム間インタフェースの設計者は、全てのリソースに共通的に付与したいURIを共通URIとして本発明の実施形態におけるシステム間インタフェース設計装置１０に入力する。この共通URIには、オペレーションシステムのホスト名やインタフェースのバージョン等を含むことができる。  
本例では、リソース設計部１１は、“operationSystem”がオペレーションシステムのホスト名を表し、“v1.0”がインタフェースのバージョン「1.0」を表すものとして、“/operationSystem/v1.0”が共通URIとして入力する。
【００３９】
図１２は、本発明の実施形態におけるシステム間インタフェース設計装置による、管理対象の種別間の関係性の処理の具体例を示すフローチャートである。  
本例では、リソース設計部１１が、全ての管理対象の種別の持つ、他種別への全ての関係性に対して、関係性毎に予め定めた処理を行う（Ｓ１１Ａ）ときで、管理対象の複数の種別間の関係性が“関連”“集約（集約（元）、集約（先））”“コンポジション（コンポジション（元）、コンポジション（先））”のいずれかであった場合は、リソース設計部１１は、それぞれの種別に対応するリソースを相互にリンクするために、ある管理対象の種別のリソースデータ項目に、対象種別（他種別）の管理対象のURIが記載されるリスト（以下、対象種別のリストと称することがある）を追加する（Ｓ１１Ｂ１）。  
また、現在の処理対象の管理対象の種別（例えば“Switch”）に対する、ある他の管理対象の種別（例えば“Hardware”）の関係性が“汎化（先）”であった場合（例えば“Switch”の汎化先が“Hardware”である場合）は、リソース設計部１１は、対象の種別（“Hardware”）の属性を継承するために、上記の現在の処理対象の管理対象の種別のリソースデータ項目に対し、対象の種別（“Hardware”）が保持するデータ項目を追加し（Ｓ１１Ｂ２）、上記の関係性が“汎化（元）”であった場合（例えば“Hardware”の汎化元が“Switch”である場合）は、リソース設計部１１は、現在の処理対象の管理対象の種別のリソースデータ項目に対して処理なしとする（Ｓ１１Ｂ３）。  
以上の処理によって、管理対象の種別間の関係性がリソースデータ項目に反映される。
【００４０】
図１３は、本発明の実施形態におけるシステム間インタフェース設計装置のリソースURI保持部が保持する情報の一例を示す図である。図１４は、本発明の実施形態におけるシステム間インタフェース設計装置のリソースデータ項目保持部が保持する情報の一例を示す図である。  
これらの図１３及び図１４は、入力データが図８〜１１に示したデータである場合で、図２、図３、図４、図６、図１２のフローチャートのようにリソース設計部１１を動作させた場合における、リソースURIの設計結果（図１３）およびリソースデータ項目の設計結果（図１４）である。
【００４１】
本実施形態では、リソース設計部１１は、管理対象の種別の処理（図３）で設定されたリソースURI（“/管理対象の種別/{id}”）に対して、共通URIの処理（図６）で共通URI（“/operationSystem/v1.0”）を挿入することで、最終的なリソースURIを設計する。このため、図１３に示すように、リソースURI保持部１２には、管理対象の種別毎に“/operationSystem/v1.0/管理対象の種別/{id}”が格納される。
【００４２】
本実施形態では、管理対象の種別が保持するデータ項目の処理（図４）と、管理対象の種別間の関係性の処理（図１２）とにより、リソースデータ項目が設計される。  
したがって、図１４に示すように、リソース設計部１１は、種別“Network”のリソースデータ項目には、当該種別が保持するデータ項目（id, name, operator）（図９（ａ）参照）に、（１）集約（元）の種別“Switch”のリストと、（２）同じく集約（元）の種別“Router”のリストとを追加する。  
種別“Hardware”のリソースデータ項目としては、当該種別が保持するデータ項目（id, name, size, weight）（図９（ｂ）参照）のみが記載され、この項目に対する追加はなされない。  
種別“Switch”のリソースデータ項目には、当該種別が保持するデータ項目（switchType）（図９（ｃ）参照）に対し、（１）汎化（先）の種別“Hardware”が保持するデータ項目（id, name, size, weight）（図９（ｂ）参照）と、（２）集約（先）の種別“Network”のリストと、（３）参照関係（関連）の種別“Router”のリストと、（４）コンポジション（元）の種別“PhysicalPort”のリストとが追加される。  
種別“Router”のリソースデータ項目には、当該種別が保持するデータ項目（routerType）（図９（ｄ）参照）に、（１）汎化（先）の種別“Hardware”が保持するデータ項目（id, name, size, weight）（図９（ｂ）参照）と、（２）集約（先）の種別“Network”のリストと、（３）参照関係（関連）の種別“Switch”のリストと、（４）コンポジション（元）の種別“PhysicalPort”のリストとが追加される。  
種別“PhysicalPort”のリソースデータ項目には、当該種別が保持するデータ項目（id, name）（図９（ｅ）参照）に、（１）コンポジション（先）の種別“Switch”と、（２）同じくコンポジション（先）の種別“Router”のリストとが追加される。  
なお、各種別のリストについて、図１４では、“管理対象の種別（list）”の形式で記載した。
【００４３】
次に、本発明の実施形態における管理対象の種別間の関係性の処理の変形例について説明する。  
図１５は、本発明の実施形態におけるシステム間インタフェース設計装置による、関係性の処理の変形例を示すフローチャートである。  
この図１５は、図１２とは異なる、管理対象の種別間の関係性の処理の具体例を示すフローチャートである。  
本例では、リソース設計部１１が、全ての管理対象の種別の持つ、他種別への全ての関係性に対して、関係性毎に予め定めた処理を行う（Ｓ２１Ａ）ときで、管理対象の種別間の関係性が“関連”、“集約（集約（元）、集約（先））”のいずれかであった場合は、図１２に示した例と同様に、リソース設計部１１は、それぞれの種別に対応するリソースを相互にリンクするために、ある管理対象の種別のリソースデータ項目に、対象種別（他種別）の管理対象のURIが記載されるリストを追加する（Ｓ２１Ｂ１）。  
また、現在の処理対象の管理対象の種別（例えば“PhysicalPort”）に対する、ある他の管理対象の種別（例えば“Switch”）の関係性が“コンポジション（先）”であった場合は、リソース設計部１１は、URIの階層構造によって、それぞれの種別に対応するリソースを相互にリンクするために、現在の処理対象の管理対象の種別に対応するリソースURIに“対象種別のリソースURI/管理対象の種別/{id}”を設定し、図３のフローチャートで設定していたリソースURI（“/管理対象の種別/{id}”）を削除する（Ｓ２１Ｂ２）。この、対象種別のリソースURIは、上記のコンポジション先となる他種別に対応するリソースURIである。例えば、“PhysicalPort”のコンポジション先の１つである他の種別が“Switch”である場合は、Ｓ２１Ｂ２では“対象種別のリソースURI/管理対象の種別/{id}”は、“Switch/ {id}/PhysicalPort/ {id}”が設定される。“PhysicalPort”のコンポジション先が他にもある場合には、このコンポジション先についても同様に設定される。
【００４４】
また、管理対象の種別間の関係性が“コンポジション（元）”であった場合は、リソース設計部１１は、関係性の処理に関しては処理なしとする（Ｓ２１Ｂ４）。  
また、現在の処理対象の管理対象の種別（例えば“Switch”）に対する、ある他の管理対象の種別（例えば“Hardware”）の関係性が“汎化（先）”であった場合は、図１２に示した例と同様に、リソース設計部１１は、対象の種別（他種別）の属性を継承するために、上記の現在の処理対象の管理対象の種別のリソースデータ項目に、対象種別（他種別）が保持するデータ項目を追加する（Ｓ２１Ｂ３）。上記の関係性が“汎化（元）”であった場合は、図１２に示した例と同様に、リソース設計部１１は、現在の処理対象の管理対象の種別のリソースデータ項目に対して処理なしとする（Ｓ２１Ｂ４）。  
図１２に示した例と異なり、図１５に示した例は、コンポジション（先）の関係性をリソースデータ項目のリストではなく、リソースURIの階層構造で表現する例である。
【００４５】
図１６は、本発明の実施形態におけるシステム間インタフェース設計装置のリソースURI保持部が保持する情報の一例を示す図である。図１７は、本発明の実施形態におけるシステム間インタフェース設計装置のリソースデータ項目保持部が保持する情報の一例を示す図である。これら図１６及び図１７は、図８〜１１を入力データとし、図２、図３、図４、図６、図１５のフローチャートのようにリソース設計部１１を動作させた場合におけるリソースURIとリソースデータ項目の設計結果である。
【００４６】
図１６に示すように、関係性の処理の変形例は、“Network”、“Hardware”、“Switch”、“Router”については、管理対象の種別の処理（図３）で設定されたリソースURI（“/管理対象の種別/{id}”）に対して、共通URIの処理（図６）で共通URI（“/operationSystem/v1.0”）が挿入される。このため、リソースURI保持部１２には管理対象の種別毎に“/operationSystem/v1.0/管理対象の種別/{id}”が格納される。  
一方、図１０に示すように、“PhysicalPort”は、“Switch”と“Router”にコンポジション（先）の関係性を持つため、リソースURI保持部１２には、“PhysicalPort”に関する設計対象のリソースURIとして、図１５に示すＳ２１Ｂ２で設定したリソースURI“対象種別のリソースURI/管理対象の種別/{id}”の前段に共通URIを挿入したリソースURI
（１）（/operationSystem/v1.0/Switch/{id}/PhysicalPort/{id}）および
（２）（/operationSystem/v1.0/Router/{id}/PhysicalPort/{id}）
が図１６に示すように格納される。
【００４７】
図１７に示すように、関係性の処理の変形例では、管理対象の種別が保持するデータ項目の処理（図４）と管理対象の種別間の関係性の処理（図１５）とでリソースデータ項目が設計される。  
したがって、種別“Network”のリソースデータ項目では、図１４に示した例と同様に、当該種別が保持するデータ項目に、（１）集約（元）の種別“Switch”のリストと、（２）同じく集約（元）の種別“Router”のリストとが追加される。  
種別“Hardware”のリソースデータ項目では、図１４に示した例と同様に、当該種別が保持するデータ項目（図９（ｂ）参照）に対する追加はなされない。  
種別“Switch”のリソースデータ項目では、当該種別が保持するデータ項目に、（１）汎化（先）の種別“Hardware”が保持するデータ項目（図９（ｂ）参照）と、（２）集約（先）の種別“Network”のリストと、（３）参照関係（関連）の種別“Router”のリストとが追加される。  
種別“Router”のリソースデータ項目では、当該種別が保持するデータ項目に、（１）汎化（先）の種別“Hardware”が保持するデータ項目（図９（ｂ）参照）と、（２）集約（先）の種別“Network”のリストと、（３）参照関係（関連）の種別“Switch”のリストとが追加される。  
種別“PhysicalPort”のリソースデータ項目では、当該種別が保持するデータ項目に対する追加はなされない。
【００４８】
この、関係性の処理の変形例では、コンポジション（コンポジション（元）、コンポジション（先））の関係性に対する処理内容を変更したので、図１４に示した例と異なり、“Switch”や“Router”のリソースデータ項目にコンポジション元である“PhysicalPort”のリストの追加（図１４）はなされない。また、“PhysicalPort”のリソースデータ項目へのコンポジション先である“Switch”のリストや“Router”のリストの追加（図１４）はなされない。
【００４９】
以上のように、本発明の実施形態におけるシステム間インタフェース設計装置によれば、オペレーションシステムの管理対象の種別、当該管理対象の種別が保持するデータ項目、当該管理対象の種別間の関係性、全リソースに共通的に付与されるURIを入力データとして、REST APIにおけるリソースのURIとデータ項目とを自動的に設計できるので、インタフェース設計のスキルレス化と設計期間の短縮を実現することができる。
【００５０】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【００５１】
また、各実施形態に記載した手法は、計算機（コンピュータ）に実行させることができるプログラム（ソフトウエア手段）として、例えば磁気ディスク（フロッピー（登録商標）ディスク、ハードディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ、ＭＯ等）、半導体メモリ（ＲＯＭ、ＲＡＭ、フラッシュメモリ等）等の記録媒体に格納し、また通信媒体により伝送して頒布することもできる。なお、媒体側に格納されるプログラムには、計算機に実行させるソフトウエア手段（実行プログラムのみならずテーブルやデータ構造も含む）を計算機内に構成させる設定プログラムをも含む。本装置を実現する計算機は、記録媒体に記録されたプログラムを読み込み、また場合により設定プログラムによりソフトウエア手段を構築し、このソフトウエア手段によって動作が制御されることにより上述した処理を実行する。なお、本明細書でいう記録媒体は、頒布用に限らず、計算機内部あるいはネットワークを介して接続される機器に設けられた磁気ディスクや半導体メモリ等の記憶媒体を含むものである。
【符号の説明】
【００５２】
１０…システム間インタフェース設計装置、１１…リソース設計部、１２…リソースURI保持部、１３…リソースデータ項目保持部。
【図１】
0006454654.tif 000002
【図２】
0006454654.tif 000003
【図３】
0006454654.tif 000004
【図４】
0006454654.tif 000005
【図５】
0006454654.tif 000006
【図６】
0006454654.tif 000007
【図７】
0006454654.tif 000008
【図８】
0006454654.tif 000009
【図９】
0006454654.tif 000010
【図１０】
0006454654.tif 000011
【図１１】
0006454654.tif 000012
【図１２】
0006454654.tif 000013
【図１３】
0006454654.tif 000014
【図１４】
0006454654.tif 000015
【図１５】
0006454654.tif 000016
【図１６】
0006454654.tif 000017
【図１７】
0006454654.tif 000018