特許 7011752 ナビゲーションスキーマの分析および生成のシステムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-01-18

(45)【発行日】2022-01-27

(54)【発明の名称】ナビゲーションスキーマの分析および生成のシステムおよび方法

(51)【国際特許分類】

   G06F 8/38 20180101AFI20220119BHJP

【ＦＩ】

G06F8/38

【請求項の数】 8

(21)【出願番号】P 2021508313

(86)(22)【出願日】2019-08-26

(65)【公表番号】

(43)【公表日】2021-12-16

(86)【国際出願番号】 US2019048150

(87)【国際公開番号】W WO2020046818

(87)【国際公開日】2020-03-05

【審査請求日】2021-04-26

(31)【優先権主張番号】16/118,004

(32)【優先日】2018-08-30

(33)【優先権主張国・地域又は機関】US

【早期審査対象出願】

(73)【特許権者】

【識別番号】518279875

【氏名又は名称】イングラム マイクロ インコーポレーテッド

(74)【代理人】

【識別番号】100138760

【弁理士】

【氏名又は名称】森 智香子

(72)【発明者】

【氏名】ロスティスラフ，コリヤキン

【審査官】松崎 孝大

(56)【参考文献】

【文献】特開２０１１－１８０７６２（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１８／０２０３５７１（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１５／００２６３４９（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ８／３８

(57)【特許請求の範囲】

【請求項1】

階層ナビゲーションスキーマを平面スキーマに変換する変換要求を受信することと、
変換要求を受信することに応答して、ナビゲーションスキーマを受信することと、
複数のナビゲーション要素を初期化することであって、前記ナビゲーション要素の前記各々は、可変コンテキストを自身に関連付けることと、
前記複数のナビゲーション要素の各々のための前記可変コンテキストの前記各々をマップに保存することと、
前記複数のナビゲーション要素の前記各々を平面ナビゲーションスキーマに移動させることと、
前記複数のナビゲーション要素の前記各々をルートプレースホルダに統合することとを含む、
ナビゲーションスキーマの分析のための方法。

【請求項2】

前記複数のナビゲーション要素の前記各々の前記可変コンテキストを前記平面ナビゲーションスキーマ内に入れる前記ステップをさらに含む、請求項１に記載の方法。

【請求項3】

前記マップが空であるかをチェックする前記ステップをさらに含む、請求項１に記載の方法。

【請求項4】

空のナビゲーションスキーマを作成することと、
プラットフォームプレースホルダの利用可能なリストを示すことと、
スキーマテンプレートを前記空のナビゲーションスキーマに挿入して、生成されたスキーマを作成することと、
前記生成されたスキーマを分析することとをさらに含む、請求項１に記載の方法。

【請求項5】

前記生成されたスキーマを作成することは、
少なくとも１つのレベルメニューを挿入することと、
前記少なくとも１つのレベルメニューに対応する少なくとも１つのビューまたはウィザードを挿入することと、
前記可変コンテキストの前記各々に関して、ラベルを要求して変数を構築することとをさらに含む、請求項４に記載の方法。

【請求項6】

前記生成されたスキーマに少なくとも部分的に基づいてコネクタパッケージをサービスデータベースに対して公開する前記ステップをさらに含む、請求項５に記載の方法。

【請求項7】

階層ナビゲーションスキーマを平面スキーマに変換する変換要求を受信することと、
ナビゲーションスキーマアナライザにおいて、ナビゲーションオブジェクトモデルを用いて空のナビゲーションスキーマを作成することと、
対応するスキーマテンプレートをテンプレートライブラリから読み出して、前記対応するスキーマテンプレートを前記空のナビゲーションスキーマに挿入することと、
前記ナビゲーションスキーマアナライザにおいて、メニューレベル、ビュー、ウィザードおよびラベルからなるグループから選択された少なくとも１つのナビゲーション要素を含む生成されたスキーマを生成することと、
前記ナビゲーションスキーマアナライザにおいて、前記生成されたスキーマを分析することと、
前記ナビゲーションスキーマアナライザにおいて、前記生成されたスキーマに少なくとも部分的に基づいてコネクタパッケージを完成させることと、前記コネクタパッケージを公開することとを含む、
ナビゲーションスキーマの生成の方法。

【請求項8】

前記少なくとも１つのナビゲーションは、選択された前記各少なくとも１つのナビゲーション要素のための少なくとも１つの変数をさらに含む、請求項７に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本願は、２０１８年８月３０日に出願された米国特許出願第１６／１１８，００４号の優先権の利益を主張する国際特許出願であり、その本文および図面はその全体が参照として本明細書に組み込まれる。

【0002】

本発明は、ユーザインタフェース（ＵＩ）のためのシステムおよび方法に、より詳細には、クラウドアプリケーションのＵＩを統合するためのナビゲーションスキーマの分析および生成のシステムおよび方法に関する。

【背景技術】

【0003】

クラウドサービスブローカ（ＣＳＢ）は、独立系ソフトウェアベンダー（ＩＳＶ）がＣＳＢプラットフォームを通じてクラウドサービスを配信して、異なるクラウドアプリケーションが標準化されたＲＥＳＴｆｕｌアプリケーションプログラミングインタフェース（ＡＰＩ）を通じて協働できるようにするための方法を提供する。ＩＳＶが自身のアプリケーションをＣＳＢプラットフォームと統合するために、各クラウドアプリケーションに関してコネクタパッケージを作成しなければならない。

【0004】

コネクタパッケージは通常、アーカイブファイルの形態を有し、このアーカイブファイルはメタデータ、制御方法の記述およびコンテンツファイルを一般的に含み、これらは、アプリケーションリソース、サービス、ユーザインタフェース構成要素を宣言して定義するために使用可能であるとともに、クラウドアプリケーションに適用可能なリソースを管理するために必要な制御方法の論理を使用する。コネクタパッケージは、ＩＳＶのアプリケーションリソースを定義するために使用される宣言型ファイルと、「コネクタフロントエンド」、すなわち、ＣＳＢの顧客がＣＳＢインタフェース内にみるウェブインタフェースとからなることが理解されるであろう。このウェブインタフェースは、ウィジェット、事前定義されたページ構造、ナビゲーション方法および画面挿入機構を含み得る特殊なフレームワークを使用してコネクタパッケージデベロッパによって開発される。一般的なコネクタフロントエンドは、事前定義されたビューに挿入された画面、ウィジェットをレンダリングするためのカスタム論理およびカスタムナビゲーション構造からなる。ウィジェットは、対応するクラウドアプリケーションの顧客にとって価値があるとコネクタデベロッパがみなす情報を表示し得る。例として、使用量報告、サブスクリプションおよびサービス情報、および命令が、特定のクラウドアプリケーションのユーザに適用可能な情報となり得る。

【0005】

統合導入プロセス中に、コネクタパッケージのインスタンスをアクティブ化するために、コネクタパッケージがコネクタアプリケーションに変換される。この統合方法は、共通の制御スタイルおよびコレクションを有する単一のウェブパネルを通じて、いくつかのクラウドアプリケーションの管理を可能にする。同時に、統合されたＵＩの機能は、クラウドアプリケーションのための幅広いクライアントビジネスロジックのセットを十分に実装するように開発される。この統合方法は、ＵＩナビゲーションとして知られる。言い換えれば、ＣＳＢプラットフォームは、自身のプラットフォームＵＩを統合アプリケーションのＵＩと統合して、ＣＳＢプラットフォームのクライアントにいくつかの方法で提示することができる。

【0006】

例として、図１Ａおよび図１Ｂは、ＣＳＢプラットフォームの顧客パネル（ＣＰ）のスクリーンショットである。両方のスクリーンショットには、「ホーム」「ユーザ」「ドメイン」および「アカウント」というアイテムを含むメインナビゲーションメニュー（ルートナビゲーションアイテム）が存在する。これらのすべての要素は、コネクタアプリケーションによって所有されて、ＣＳＢ制御パネル内に統合される。各統合されたアイテムは、ボタン、タイル、アイコン、および様々な他の制御を含む。制御の一部は、必要に応じて別のビューへの遷移を実行することができる。ビューは、例えば、有用な情報の表示、任意のユーザの設定、リソースの変更、または別のビューへのナビゲートなど、ユーザとの相互作用が可能な画面である。

【0007】

このような従来の実施形態においては、ＵＩナビゲーションは、ビューのツリーであり、ナビゲーションツリーが階層を形成する。このような実施形態においては、最上位レベルのメニューアイテムは、ルート要素と呼ばれる。ツリーのノードとしての各要素は、いくつかの葉（子要素）を有することができる。この階層は、以下の３つの目的を有する：（１）２つの最高位レベルの要素は、顧客のパネル内のメニューを形成する。（２）ツリーの最上位要素から任意の子孫へのパスが、可能なユーザのナビゲーションパスを形成する。（３）ツリーの最上位要素から任意の子孫へのパスが、コンテキスト（後述する）を形成する。この従来の階層の実施形態を、図１Ｃに示す。

【0008】

従来のＣＳＢプラットフォーム実装においては、ナビゲーション要求は、ユーザのブラウザからＣＳＢプラットフォームバックエンドに対して開始されて、ＣＳＢプラットフォームバックエンドが、要求をナビゲーションエンジンに、ＣＳＢコントローラに、ＵＩフレームワークに、およびＡＰＰクライアントモジュールに送信する。構成要素の各々は、図１Ｄに示すように、ＵＩ応答においてある役割を果たす。

【0009】

上述のように、従来の方法は、適正なナビゲーションＵＩを調整するためにかなりの量のアップフロント作業を、ただし、実行中には稼働するためのかなりのコンピューティングリソースも必要とする。くわえて、実行中に、ナビゲーションエンジンがナビゲーションを行うために、数多くのリソースにアクセスする必要があることを所与とすると、低速の応答時間の可能性が増す。

【0010】

したがって、ナビゲーションスキーマの分析および生成の改善されたシステムおよび方法に対する必要性が存在する。

【発明の概要】

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

【0011】

本開示は、ナビゲーションスキーマの分析のための方法に関し、変換要求をチェックすることと、ナビゲーションスキーマをチェックすることと、複数のナビゲーション要素を初期化することであって、ナビゲーション要素の各々は、可変コンテキストを自身に関連付けることと、複数のナビゲーション要素の各々のための可変コンテキストの各々をマップに保存することと、複数のナビゲーション要素の各々を平面ナビゲーションスキーマに移動させることと、複数のナビゲーション要素の各々をルートプレースホルダに統合することとを含む。

【0012】

本開示の少なくとも１つの実施形態においては、方法は、複数のナビゲーション要素の各々の可変コンテキストを平面ナビゲーションスキーマ内に入れるステップと、マップが空であるかをチェックするステップとをさらに含む。

【0013】

本開示の少なくとも１つの実施形態においては、ナビゲーションスキーマの生成の方法が提供され、方法は、ナビゲーションスキーマアナライザにおいて、ナビゲーションオブジェクトモデルを用いて空のナビゲーションスキーマを作成することと、対応するスキーマテンプレートをテンプレートライブラリから読み出して、対応するスキーマテンプレートを空のナビゲーションスキーマに挿入することと、ナビゲーションスキーマアナライザにおいて、メニューレベル、ビュー、ウィザードおよびラベルからなるグループから選択された少なくとも１つのナビゲーション要素を含む生成されたスキーマを生成することと、ナビゲーションスキーマアナライザにおいて、生成されたスキーマを分析することと、ナビゲーションスキーマアナライザにおいて、生成されたスキーマに少なくとも部分的に基づいてコネクタパッケージを完成させることと、コネクタパッケージを公開することとを含む。

【0014】

本開示の少なくとも１つの実施形態においては、ナビゲーションスキーマの分析および生成のためのシステムが提供され、マーケットプレイスコンピューティングデバイスに動作可能に接続されたデベロッパコンピューティングデバイスを含み、デベロッパコンピューティングデバイスは、リソースタイプマネージャに動作可能に接続されたナビゲーションスキーマアナライザをさらに備え、デベロッパコンピューティングデバイスは、ナビゲーションスキーマアナライザに動作可能に接続されたデベロッパポータルユーザインタフェース（ＵＩ）をさらに備える。

【図面の簡単な説明】

【0015】

実施形態ならびに本明細書に含まれる他の特徴、利点および開示、ならびに、それらを達成する方法は、本開示の様々な例示的実施形態の以下の説明および添付図面を参照することにより明らかになるとともに、本開示は、よりよく理解されるであろう。

【0016】

【図1A】グラフィカルユーザインタフェースを介した、クラウドサービスブローカの顧客の制御パネルを示す図である。

【0017】

【図1B】グラフィカルユーザインタフェースを介した、クラウドサービスブローカの顧客の制御パネルを示す図である。

【0018】

【図1C】ユーザインタフェースのナビゲーション応答の動的なツリーのビューを示す図である。

【0019】

【図1D】ブラウザからＣＳＢバックエンドへのナビゲーション応答のシーケンスフローを示す図である。

【0020】

【図2】本開示の少なくとも１つの実施形態による、ナビゲーションスキーマの分析および生成のためのシステムを示す図である。

【0021】

【図3】本開示の少なくとも１つの実施形態による、ナビゲーションスキーマの分析および生成のための方法を示す図である。

【0022】

【図4】本開示の少なくとも１つの実施形態による、ナビゲーションスキーマの分析および生成のための方法を示す図である。

【0023】

【図5A】本開示の少なくとも１つの実施形態による、ナビゲーションスキーマの分析および生成のための方法を示す図である。

【0024】

【図5B】本開示の少なくとも１つの実施形態による、ナビゲーションスキーマの分析および生成のための方法を示す図である。

【0025】

【図5C】本開示の少なくとも１つの実施形態による、ナビゲーションスキーマの分析および生成のための方法を示す図である。

【発明を実施するための形態】

【0026】

本開示の原理の理解を促進するために、図面に示される実施形態を参照しつつ、特定の言語を用いて記述する。それにもかかわらず、これにより本開示の範囲を限定する意図ではないことが理解されるであろう。

【0027】

本詳細説明は、コンピュータまたはコンピュータのネットワーク上で実行されるプログラム、データ構造またはプロシージャに関して提示される。システムによって実装されるソフトウェアプログラムは、任意のプログラミング言語、すなわち、インタープリタ型、コンパイル型、またはその他で記述され得る。これらの言語は、Ｘｃｏｄｅ、ｉＯＳ、ｃｏｃｏａ、ｃｏｃｏａ ｔｏｕｃｈ、ＭａｃＲｕｂｙ、ＰＨＰ、ＡＳＰ．ｎｅｔ、ＨＴＭＬ、ＨＴＭＬ５、Ｒｕｂｙ、Ｐｅｒｌ、Ｊａｖａ、Ｐｙｔｈｏｎ、Ｃ＋＋、Ｃ＃、ＪａｖａＳｃｒｉｐｔ、および／またはＧｏプログラミング言語を含み得るが、これらに限定されない。当業者であれば、代わりにまたは上記と組み合わせて他の言語が使用され得ること、および例えば、Ｒｕｂｙ ｏｎ Ｒａｉｌｓ、Ｓｙｓｔｅｍ．ｊｓ、Ｚｅｎｄ、Ｓｙｍｆｏｎｙ、Ｒｅｖｅｌ、Ｄｊａｎｇｏ、Ｓｔｒｕｔｓ、Ｓｐｒｉｎｇ、Ｐｌａｙ、Ｊｏ、Ｔｗｉｔｔｅｒ Ｂｏｏｔｓｔｒａｐおよびその他などの、ウェブおよび／またはモバイルアプリケーションフレームワークも使用され得ることが理解されるであろうことを、当然ながら理解すべきである。本明細書に開示するシステムおよび方法は、例えばインターネットなどのコンピュータネットワーク上で利用可能なソフトウェアアズアサービスにおいて具現化され得ることをさらに理解すべきである。さらに、本開示は、ウェブサービス、アプリケーションプログラミングインタフェースおよび／または１つ以上のアプリケーションプログラミングインタフェースまたはそれ以外を通じたサービス指向のアーキテクチャを可能にし得る。

【0028】

定義（ＤＥＦＩＮＩＴＩＯＮ）：技術または科学用語を含む、本明細書で使用するすべての用語は、当業者によって一般的に理解される同じ意味を有し得る。概して、辞書で定義される用語は、関連技術の文脈上の意味と同じ意味を有するとみなされるべきであり、本明細書に明確に定義されない限り、例外的にまたは極度に正式な意味を有するものとして理解されるべきではない。いずれの場合であっても、本明細書で定義される用語でさえも、本開示の実施形態を除外するものと解釈することはできない。

【0029】

クラウドサービスブローカプラットフォーム：いくつかのＩＳＶとの関係を有するプラットフォームで、コネクタパッケージを利用して、プラットフォームの顧客間に自身のサービスを販売するための方法を提供する。

【0030】

コネクタパッケージ：ベンダーエンティティおよびＡＰＩの用語をＣＳＢプラットフォームの用語に変換するように意図されたソフトウェアユニットおよび、クラス、プロシージャおよび関数のセット。

【0031】

コネクタアプリケーション：ＣＳＢプラットフォーム上にインストールされたコネクタパッケージのアクティブインスタンス。

【0032】

ビュー：単一のＵＩ画面を提示するコネクタのフロントエンドの論理要素。タイル、ボタン、コンボボックスなどのようなＵＩ制御を含む。

【0033】

ＣＳＢ顧客パネル：ＣＳＢプラットフォームおよびメニューレベルに分割されたコネクタアプリケーションビューの階層構造セット。

【0034】

ＣＳＢプラットフォームバックエンド：統合することを意図されたクラス、プロシージャおよび関数のセット。

【0035】

ＵＩフレームワーク：コネクタアプリケーションインタフェースコードからＣＳＢプラットフォーム内部をカプセル化する、ＣＳＢプラットフォームのクラス、プロシージャおよび関数のセット。

【0036】

コネクタフロントエンド：コネクタデベロッパによって提供されるウェブインタフェースで、ＣＳＢプラットフォームによってＩＳＶエンティティを動作させる。

【0037】

ナビゲーションスキーマ（ナビゲーションツリー）：コネクタアプリケーションの利用可能なビュー、それらの階層およびコンテキスト、それらのビュー間の遷移のルールの持続的またはメモリ内表現。

【0038】

ナビゲーション要求：特定のビューをターゲットとする遷移要求。

【0039】

ナビゲーション応答：特定のビュー、可視性、コンテキストおよびメニューアイテムの可用性についての情報を含む応答。

【0040】

ナビゲーションプレースホルダ：別のツリーの代替を意図するナビゲーションツリーの要素である、統合ポイント。

【0041】

リソースタイプ：共通または個別の継承チェーンへのリソースインスタンスの所属を指定する抽象概念。くわえて、リソースタイプは、属性および特性セットを定義する。

【0042】

リソース：インスタンス化されたリソースタイプ。そのタイプのすべてのインスタンスと共有される属性および特性を含むが、独立した値を有する。

【0043】

タイプ階層：タイプ間の順序関係。リソースは、オブジェクト指向のプログラミングで機能するときに、共通タイプまたは継承タイプまたは独立タイプを有することができる。

【0044】

ナビゲーション変数：ナビゲーションスキーマおよびナビゲーションツリー内のノードであり、ビューのコンテキストおよび可視性条件を定義する。すべての変数が、変数フィルタによって定義されるいくつかのリソースセットに対応する。

【0045】

コンテキスト：特定のナビゲーションサブツリーを表示するために必要に応じてコネクタデベロッパによって宣言されるリソースセット。

【0046】

変数範囲：変数フィルタを満たすリソースセットであるコンテキストへの単一変数の寄与。

【0047】

変数解決：変数範囲に含まれるリソースを読み出すプロセス。

【0048】

図２は、クラウドアプリケーションのＵＩを統合するためのナビゲーションスキーマの分析および生成のためのシステムの概略図であり、概して２００に示す。システムは、デベロッパポータルコンピューティングデバイス２０２、デベロッパポータルＵＩ２０４、入力プロセッサ２０６、ナビゲーションスキーマアナライザ２０８、リソースタイプマネージャ２１０、ナビゲーションオブジェクトモデル２１２、テンプレートライブラリ２１４、リソースタイプ記憶２１６、スキーマ記憶２１８、マーケットプレイスコンピューティングデバイス２２０およびコネクタハブ２２２を含む。明確にするために、図２には各構成要素タイプのただ１つのみを示す。しかしながら、システム２００は、システム２００に示されたデベロッパポータルコンピューティングデバイス２０２およびマーケットプレイスコンピューティングデバイス２２０を含む、構成要素の任意の２つ以上を有し得ることは、本開示の範囲内であり、当業者であれば理解されるであろう。

【0049】

本開示の少なくとも１つの実施形態においては、デベロッパポータルＵＩ２０４は、ユーザがコネクタパッケージをアップロードして、修正されたパッケージをダウンロードして、ナビゲーションスキーマを作成、編集、および分析するための制御を提供するように構成される。

【0050】

本開示の少なくとも１つの実施形態においては、入力プロセッサ２０６は、以下でさらに開示するように、コネクタパッケージをアンパックして、リソースタイプマネージャ２１０からリソースタイプを読み出すように構成される。入力プロセッサ２０６は、以下でさらに開示するように、リソースタイプを処理してロードして、ナビゲーションオブジェクトモデル２１２からナビゲーションスキーマを読み出すようにさらに構成される。

【0051】

本開示の少なくとも１つの実施形態においては、ナビゲーションスキーマアナライザ２０８は、例えば、ナビゲーションスキーマの生成、および既存のナビゲーションスキーマを平面にするなど、ユーザによって要求されるすべての動作を実行するように構成される。本開示の少なくとも１つの実施形態においては、ナビゲーションスキーマアナライザ２０８は、当業者には周知のように、構成されたリソースタイプマネージャ２１０、ナビゲーションオブジェクトモデル２１２、およびテンプレートライブラリ２１４に動作可能に接続される。ナビゲーションスキーマアナライザ２０８の出力は、いくつかの非限定的な例を挙げると、（以下でさらに開示するように）警告またはエラーのリスト、修正されたナビゲーションスキーマ、作成されたナビゲーションスキーマ、またはダウンロードするための修正されたコネクタパッケージを含み得ることが理解されるであろう。

【0052】

本開示の少なくとも１つの実施形態においては、リソースタイプマネージャ２１０は、コネクタのリソースタイプおよびこれらの階層を維持して分析するように構成される。これは、交差タイプの継承チェーンまたは範囲が広すぎる広い変数宣言を検出するために必要であることが理解されるであろう。本開示の少なくとも１つの実施形態においては、リソースタイプマネージャ２１０の共通インタフェースは、いくつかの非限定的な例を挙げると、すべてのリソースタイプのリストを取得して、タイプＡがタイプＢを継承するかをチェックして、タイプＡおよびＢの共通の親タイプを取得して、タイプＡの継承チェーンの長さを取得するための能力を提供する。ナビゲーションスキーマ生成モードにおいては、リソースタイプマネージャ２１０は、プラットフォームリソースタイプのリストをユーザに示すようにさらに構成される。

【0053】

本開示の少なくとも１つの実施形態においては、ナビゲーションオブジェクトモデル２１２は、下位レベルのＸＭＬ表現をカプセル化して、ツリーを操作して探索するために上位レベル方法を公表する。ナビゲーションオブジェクトモデルは、オブジェクトおよびオブジェクト間のリンクに関するナビゲーションスキーマの内部表現をさらに含む。この表現は、特殊な用語で記述されるので、処理がより簡単である。この表現は、ＸＭＬよりも高速であり、それは、ＸＭＬ解析はただ１度しか行われないからである。本開示の少なくとも１つの実施形態においては、ナビゲーションスキーマアナライザ２０８は、妥当性、冗長階層レベル、ループ、繰り返し要素、異なる階層レベル上に同じフィルタで配置された冗長変数、過度に広いかまたは過度に狭い限度を有する不正確なまたは冗長のフィルタに関してスキーマをチェックするためにナビゲーションオブジェクトモデル２１２を使用できるように構成される。ナビゲーションスキーマ生成モードにおいては、ナビゲーションスキーマアナライザ２０８は、ナビゲーションオブジェクトモデル２１２およびスキーマ記憶２１８を用いて、ナビゲーション要素のテンプレートをユーザに提案して、要求に応じて、生成されたナビゲーションスキーマ内にそれらをペーストする。

【0054】

ここで図３を参照すると、階層ＵＩナビゲーションスキーマを平面スキーマに一意に変換するための方法が示され、概して３００に示す。本開示の少なくとも１つの実施形態においては、方法３００は、ステップ３０２において、変換要求をチェックすることと、ステップ３０４において、ナビゲーションスキーマをチェックすることと、ステップ３０６において、ナビゲーション要素を初期化することと、ステップ３０８において、可変コンテキストを保存することと、ステップ３１０において、マップをチェックすることと、ステップ３１２において、ナビゲーション要素を移動させることと、ステップ３１４において、要素を統合することと、ステップ３１６において、可変コンテキストを入れることとを含む。

【0055】

本開示の少なくとも１つの実施形態においては、シナリオは、既存のコネクタパッケージをデベロッパポータルＵＩ２０４を介してアップロードすることから始まり、ステップ３０２において、変換要求が受信されたかを確認するためにチェックする。本開示の少なくとも１つの実施形態においては、入力プロセッサ２０６は、コネクタパッケージをアンパックして、リソースタイプマネージャ２１０からリソースタイプおよび要求を読み出して、これらを処理してロードする。

【0056】

本開示の少なくとも１つの実施形態においては、ナビゲーションスキーマアナライザ２０８およびナビゲーションオブジェクトモデル２１２は、ナビゲーションスキーマツリーが存在するかをチェックするように構成される。次に方法３００は、ステップ３０６に進み、ナビゲーションスキーマアナライザ２０８およびナビゲーションオブジェクトモデル２１２は、ナビゲーション要素をこれらの可変コンテキストで初期化する。次に方法３００は、ステップ３０８に進み、ナビゲーションスキーマアナライザ２０８は、各ナビゲーション要素のための可変コンテキストをマップに保存するように構成される。

【0057】

本開示の少なくとも１つの実施形態においては、次に方法３００は、ステップ３１０に進み、ナビゲーションスキーマアナライザ２０８は、マップが空であるかをチェックするように構成される。マップが空であれば、方法３００は、ステップ３１２に進み、ナビゲーションスキーマアナライザ２０８およびナビゲーションオブジェクトモデル２１２は、ナビゲーション要素をツリーから平面ナビゲーションスキーマに移動させる。本開示の少なくとも１つの実施形態においては、ナビゲーションスキーマアナライザ２０８およびナビゲーションオブジェクトモデル２１２は、ステップ３１４において、この要素をプレースホルダに統合するようにさらに構成される。次に方法３００は、ステップ３１６に進み、ナビゲーションスキーマアナライザ２０８およびナビゲーションオブジェクトモデル２１２は、その要素の上にある可変コンテキストを平面ナビゲーションスキーマ内に入れるように構成される。

【0058】

例として、マルチコンテキストビューは、以下のようにコード化され得る：

【0059】

上記のマルチコンテキストビューの例においては、コンテキストがいくつかの変数を含む。ここでのアプリケーション名は、サービス「ＶＰＳ」による「ＶＰＳ」である。ＶＰＳサービスは、バックアップを有し得るが、バックアップは、バックアップサーバ上に記憶される。すべてのバックアップサーバは、異なるＶＰＳからのバックアップを記憶することができる。上記の例を続けると、ＩＤ「ＶＰＳ」を有するビューは、ＶＰＳサーバに関連するバックアップサーバへのリンクを含むＶＰＳサーバのダッシュボードである。ここでの「ＶＰＳ」ビューのためのコンテキストは、ＶＰＳ変数のみである。バックアップサーバビューのコンテキストは、「ＶＰＳ」変数および「バックアップサーバ」変数である。くわえて、第３レベルの階層、すなわち変数「バックアップリスト」が存在する。ユーザは、この特定のＶＰＳのバックアップサーバのビューからバックアップのリストまでナビゲートすることができる。第３レベルのコンテキストは、ＶＰＳ、バックアップサーバおよびバックアップリストの融合である。ここでのバックアップリストは、特定のＶＰＳのバックアップサーバ上に記憶されたバックアップのリストとして提示されるべきである。上記の例においては、ＵＩナビゲーションが、３つのコンテキストを解決して、必要な可視性計算を実行すべきである。

【0060】

上記の例を続けると、上記のＵＩナビゲーションスキーマは、（方法２００を介して）平面スキーマに一意に変換することができ、以下に示す通りである：

【0061】

上記の変換された平面スキーマに示されるように、変換の方法２００により、階層を用いることなく、コネクタアプリケーションのナビゲーションスキーマの開発が可能になる。特定の変数の上にあるすべてのレベルのコンテキストを追跡する必要はないことが理解されるであろう。

【0062】

上記の例を続けると、上記の変換された平面スキーマは、各ビューが今や正確に必要な数の変数を含むことを示す。示されるように、ビュー「バックアップリスト」は、３つの変数を明示的に宣言して、３つのコンテキストアイテムを提供しなければ、各々に飛ぶことは不可能である。コンテキスト変数解決は、この場合は非常に簡単であることが理解されるであろう。各コンテキストは平面であり、要素を参照する変数を解決するために必要な情報を収集するために、コンテキスト要素に対する反復が存在しない。ユーザインタフェースにおいて、バックアップリスト内に移動するステップは、ここでは以下のように提示することになる：（１）パネルを開いて、ＶＰＳページのルートメニューアイテムをクリックする、（２）ＶＰＳのバックアップサーバをクリックして、ダブルコンテキストを設定することでｇｏｔｏＶｉｅｗ（ビューに進む）が行われる。ここではナビゲーションルートに向かう上への通過は必要なく、ターゲットビューが可視ルート内に統合されることが理解されるであろう。ターゲットビューの下に配置された変数のみが計算されることになる。（３）リストから何らかのバックアップサーバをクリックする。ここでトリプルコンテキストを設定することでｇｏｔｏＶｉｅｗ（ビューに進む）が行われる。繰り返すが、ツリーを通じた上および下への通過は実行されない。正確なコンテキストからの３つの変数のみが評価される。

【0063】

この変換されたケースでは、コンテキスト変数解決は非常に簡単であることがさらに理解されるであろう。

【0064】

ここで図４を参照すると、本開示の少なくとも１つの実施形態によるナビゲーションスキーマ自動生成のための方法４００が示される。方法４００は、ステップ４０２において、ナビゲーションスキーマ生成要求が受信されたかをチェックすることと、ステップ４０４において、空のナビゲーションスキーマを作成することと、ステップ４０６において、プラットフォームプレースホルダの利用可能なリストを示すことと、ステップ４０８において、選択されたプレースホルダを含む応答が受信されたかをチェックすることと、ステップ４１０において、対応するスキーマテンプレートを取得して、これらをナビゲーションスキーマに挿入することと、ステップ４１２において、第１および第２レベルのメニューアイテムを挿入することと、ステップ４１４において、ラベルを要求することと、ステップ４１６において、変数を構築することと、ステップ４１８において、生成されたスキーマを分析することと、ステップ４２０において、コネクタパッケージを完成させることと、ステップ４２２において、コネクタパッケージを利用可能なサービスデータベース内で公開することとを含む。

【0065】

本開示の少なくとも１つの実施形態においては、入力プロセッサ２０６は、ステップ４０２において、ナビゲーションスキーマ生成要求が受信されたかをチェックするように構成される。次に方法４００は、ステップ４０４に進み、ナビゲーションスキーマアナライザ２０８およびナビゲーションオブジェクトモデル２１２は、空のナビゲーションスキーマを作成するように構成される。次に方法は、ステップ４０６に進み、ナビゲーションスキーマアナライザ２０８は、プラットフォームプレースホルダを作成して、デベロッパポータルＵＩ２０４を介して表示されるように構成される。

【0066】

本開示の少なくとも１つの実施形態においては、次に方法４００は、ステップ４０８に進み、デベロッパポータルＵＩ２０４は、選択されたプレースホルダを含む応答を受信して、受信されたかをチェックするように構成される。受信されれば、方法４００は、ステップ４１０に進む。受信されなければ、方法４００は、ステップ４０２に戻る。

【0067】

本開示の少なくとも１つの実施形態においては、ナビゲーションスキーマアナライザ２０８は、ステップ４１０において、対応するスキーマテンプレートをテンプレートライブラリ２１４から取得して、これらをナビゲーションスキーマに挿入するように構成される。

【0068】

次に方法４００は、ステップ４１２に進み、ナビゲーションスキーマアナライザ２０８は、デベロッパポータルＵＩ２０４を介して変更を示してラベルを要求するために、ナビゲーションオブジェクトモデル２１２を用いることでレベルメニューを挿入する。

【0069】

次に方法４００は、ステップ４１４に進み、ナビゲーションスキーマアナライザ２０８は、デベロッパポータルＵＩ２０４を介して変更を示してラベルを要求するために、ナビゲーションオブジェクトモデル２１２を用いてビューを挿入する。次に方法４００は、ステップ４１６に進み、ナビゲーションスキーマアナライザ２０８は、可変コンテキスト（ラベルを要求して、リソースタイプを提案して、フィルタを要求して、変数のスカラーまたは大量クラスを選択するように提案する）の各々に関して、変数を構築する。次に方法は、ステップ４１８に進み、ナビゲーションスキーマアナライザ２０８は、リソースタイプマネージャ２１０を用いてツリーおよびスキーマをバイパスして分析するために、ナビゲーションオブジェクトモデル２１２を使用するように構成される。

【0070】

次に方法４００は、ステップ４２０に進み、ナビゲーションスキーマアナライザ２０８は、コネクタパッケージを完成させて、次にステップ４２２において、コネクタハブ２２２を介してコネクタパッケージを公開する。

【0071】

ここで図５Ａ、５Ｂおよび５Ｃを参照すると、本開示の少なくとも１つの実施形態によるナビゲーションスキーマ分析のための方法５００が示される。方法５００は、ステップ５０２において、標準ＸＭＬバリデータでナビゲーションスキーマのＸＭＬファイルの妥当性確認を行うことを含む。ステップ５０４において、これは下位レベルチェックであり、存在しないタグ、誤った属性名、および同様のものを有するファイルをフィルタリングすることになることが理解されるであろう。ＸＭＬが有効でない場合、ステップ５０６において、妥当性確認エラーが出力されて、方法５００は終了する。

【0072】

それ以外の場合、次に方法５００は、ステップ５０８に進み、方法は、ＸＭＬファイルのナビゲーションオブジェクトモデルへの変換を開始する。後続のすべてのステップは、本明細書にさらに開示するように、オブジェクトモデルを呼び出して実行されることになる。本開示の少なくとも１つの実施形態においては、方法５００は、ステップ５０８において、スキーマをオブジェクトモデルにロードして、ステップ５１０において、スキーマ内の変数のリストをロードする。本開示の少なくとも１つの実施形態においては、リソースタイプマネージャ２１０は、例えば、ＡＰＳタイプなどの既存のプラットフォームタイプを確実に含むように、すべての変数の「ｔｙｐｅ－ｉｄ」属性をチェックするために初期化される。

【0073】

次に方法５００は、ステップ５１２に進み、すべての変数が処理されたかをチェックする。本開示の少なくとも１つの実施形態においては、処理を必要とする変数が存在する場合、方法はステップ５１４に進み、スキーマ内のすべての変数に関して、変数が十分な特異性を持たない汎用タイプであるかを確認するためにチェックが行われる（すなわち、変数が汎用的すぎると、これにより変数の「ｔｙｐｅ－ｉｄ」属性も過度に汎用的なタイプであり、これは、このタイプが「ａｐｓリソース」または「カウンタ」または「ユーザ」のような多くの他のタイプの子孫であることを意味する）。ステップ５１６において、方法５００は、リソースタイプマネージャ２１０から階層タイプを取得する。

【0074】

スキーマ内のすべての変数に関して、変数範囲のサイズ（変数の下のビューの数）もチェックされる。範囲が広すぎる（変数の配置が高すぎる）場合は、（ステップ５２０において）警告メッセージが出力される。同様に、すべての重複変数に関して、警告が出力される。すべてのビューに関して、ビューの配置が深すぎる（ツリーの妥当でない深さ）場合は、警告が出力される。すべてのビューに関して、ビューのコンテキストのサイズがチェックされて、コンテキストが大きすぎる場合は、警告が出力される（複雑なコンテキストの警告）。すべてのビューに関して、ビューのコンテキストからのすべての変数のバイパスがチェックされる。変数のペアの「ｔｙｐｅ－ｉｄ」属性が、直接的な継承関係にある（ある１つのタイプが別のタイプの親である）ような任意の変数ペアが存在する場合は、警告が出力されることがさらに理解されるであろう。

【0075】

次に方法５００は、ステップ５２２に進み、ツリーの枝が読み出される。ステップ５２４において、すべての枝が処理されたかを確認するためにチェックが行われる。処理されていれば、方法はステップ５３６に進み、処理されていなければ、方法はステップ５２６に進む。

【0076】

本開示の少なくとも１つの実施形態においては、ステップ５２６において、枝内のすべての変数ペアが読み出される。ステップ５２８において、確実にすべてのペアが処理されるようにチェックが行われる。次に方法５００は、ステップ５３２に進み、直接的な継承が存在するかを確認するためにチェックが行われる。

【0077】

本開示の少なくとも１つの実施形態においては、次に方法５００は、ステップ５３６に進み、すべてのツリー要素がロードされて、ステップ５３８において、すべての要素が処理されたかを確認するためにチェックされる。何らかの警告があれば、ステップ５４２でそれらが出力される。ステップ５４４において、要素が、複数の埋め込みを伴うプレースホルダであるかを確認するためにチェックが行われ、プレースホルダである場合は、方法はステップ５４６に進み、何らかの警告が出力される。

【0078】

ツリー内のすべてのプレースホルダに関して、プレースホルダがいくつかの統合ポイント内に統合される場合は、警告が出力されることが理解されるであろう。通常は、これにより、１つの枝がいくつかのノードに結合されたツリーとなり、場合によってはツリーをグラフに変換させることがさらに理解されるであろう。

【0079】

本開示は、様々な実施形態を有するものとして説明してきたが、本開示によるこれらの実施形態は、本開示の範囲および精神内でさらに修正可能である。したがって、本願は、一般原則を用いて本開示の任意の変形、使用または適応を包含することが意図される。例えば、本明細書に開示される任意の方法は、これらのステップを実行する１つの考えられる順序を表す。実践者は、開示する方法のうちの１つ以上の複数のステップを結合可能であり得ること、または同じ結果を得るために、ステップの異なる順序が採用され得ることを、特定の実装で決定し得る。このような各実装は、本明細書および添付の特許請求の範囲に開示されるような本開示の範囲内に含まれる。さらに、本願は、本開示が関係する技術分野における既知の実践または慣行に含まれるような、本開示からのこのような逸脱を包含することが意図される。

【図1A】

【図1B】

【図1C】

【図1D】

【図2】

【図3】

【図4A】

【図4B】

【図5A】

【図5B】

【図5C】

【図5D】