JP6599313B2 - ネイティブモバイルアプリケーションコードのコンピュータ支援開発 - Google Patents

Description

分野
本開示は、コンピュータ支援ソフトウェアアプリケーション開発の分野に関し、より特定的には、アプリケーションオブジェクトモデルに基づいたネイティブモバイルアプリケーションの自動的合成のための技術に関する。

背景
モバイルデバイスは至る所に存在し、ユーザはデスクトップアプリケーションを使用するのと同じまたは同様の態様で自身のモバイルデバイスを使用することを要求している。モバイルアプリケーションのより多くかつより速い展開を求める要求は重大であるが、モバイルデバイス上で実行されるネイティブアプリケーションを合成する容易または標準的な方法は出現していない。レガシー技術は、モバイルデバイスのブラウザにおいて実行されるアプリケーションプラグインを作成することを含む。しかしながら、そのようなレガシーアプローチは、デバイスに対してネイティブで実行される（たとえばブラウザに依存しない）モバイルアプリケーションを作り出すことはできない。モバイルデバイスがダウンロード可能なアプリケーションまたはアプレットをサポートする他のレガシーの場合、および、そのようなモバイルアプリケーションがブラウザに利用可能なリソースを超えてモバイルデバイスシステムリソースの使用を含む他のレガシーの場合においてさえ、ネイティブアプリケーションのハンドコーディング、または、各モバイルデバイスおよび／もしくは各オペレーティングシステムに特有のアプリケーションもしくはプラグインの開発は煩わしすぎる。異種混合モバイルプラットフォーム上で実行されることを目標としているが、それでもデスクトップアプリケーションが動作する態様と同様または同一である態様でバックエンド（たとえば、サーバベースの）アプリケーションとインターフェイス接続するアプリケーションの迅速な開発および展開の問題に対処するための技術が必要である。

前述のレガシーアプローチのいずれも、アプリケーションオブジェクトモデルに基づいたネイティブモバイルアプリケーションの自動的な合成のための本願明細書において開示される技術の能力を達成しない。したがって、改良の必要性がある。

概要
本開示は、レガシーアプローチに関する前述の問題に対処するのに適した向上された方法、システムおよびコンピュータプログラムプロダクトを提供する。より具体的には、本開示は、アプリケーションオブジェクトモデルに基づいたネイティブモバイルアプリケーションの自動的な合成のための方法、システム、およびコンピュータプログラムプロダクトにおいて使用される技術の詳細な説明を提供する。特許請求される実施形態は、異種混合のモバイルプラットフォーム上で実行されることを目標とするアプリケーションの迅速な開発および展開の問題に対応する。より具体的には、いくつかの請求項は、所与のオブジェクトモデルに準拠するようネイティブコードの集合を合成するためのアプローチに向けられており、これらの請求項は、異種混合のモバイルプラットフォーム上で実行されることを目標とするアプリケーションの迅速な開発および展開の問題に対処するための技術分野を進歩させるとともに、周辺技術分野を進歩させる。いくつかの請求項は、開示された環境における複数のシステムの機能を向上させる。

シンセサイザは、モバイルデバイス識別子と、アプリケーション識別子、オブジェクトモデルおよびフォーム識別子のような付加的な情報とを受け取り、次いで識別されたタイプのモバイルデバイス上でどのフォームを実現するべきかを決定するよう付加的な情報を分析すると開始する。さらなる合成処理は、モバイルデバイス上で実現するべきファンクションのセットを決定するためにフォームを分析することを含む。ファンクションの決定されたセットを使用して、ネイティブアプリケーションコードモジュールはリポジトリから抽出される。抽出されたネイティブアプリケーションコードモジュールは、ファンクションのセット（たとえば作成、読出、更新、削除）に対応する。コードモジュールは、モバイルデバイスに対して展開され得るネイティブモバイルアプリケーションを生成するためにアセンブルされる。サーバ機能（たとえばミドルウェア）が、バックエンドアプリケーションのフォーム処理をエミュレートするようにモバイルデバイスからのメッセージをインターセプトする。フォームを使用する任意のバックエンドアプリケーションは、ネイティブモバイルアプリケーションによってアクセスされ得る。

いくつかの実施形態は、モバイルデバイス識別子と、アプリケーション識別子、オブジェクトモデルおよびフォーム識別子のうちの少なくとも１つを含む情報とを受け取ることと、モバイルデバイス上で実現するべき少なくとも１つのフォームを決定するよう情報を分析することと、モバイルデバイス上で実現するべきファンクションのセットを決定するようフォームを分析することと、ファンクションのセットの少なくとも一部分に対応する複数の選択されたネイティブアプリケーションコードモジュールをネイティブアプリケーションコードモジュールのリポジトリから抽出することと、フォームの少なくとも一部分と、選択されたネイティブアプリケーションコードモジュールのうちの少なくともいくつかとを含むモバイルアプリケーションをアセンブルすることとを実現する。

１つの局面において、オブジェクトモデルは、フィールド、ファンクションおよびメッセージのうちの少なくとも１つを含む。別の局面において、選択されたネイティブアプリケーションコードモジュールは、作成オペレーション、置換オペレーション、更新オペレーションおよび削除オペレーションのうちの少なくとも１つを開始するよう機能する。

いくつかの実施形態は、モバイルデバイス識別子に対応するモバイルデバイス上にモバイルアプリケーションを展開することをさらに含み、また、いくつかの実施形態はＪＳＯＮメッセージからＪａｖａ（登録商標）クラスを生成することをさらに含む。

いくつかの実施形態において、選択されたネイティブアプリケーションコードモジュールのうちの少なくとも１つは、要求メッセージを形成することを実現し、またいくつかの実施形態において要求メッセージは、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ：simple object access protocol）要求を含み、また、いくつかの実施形態において、要求メッセージは、リプリゼンテーショナルステイトトランスファ（ＲＥＳＴ：representational state transfer abstraction）抽象化要求を含み、さらに他の実施形態において、要求メッセージはパスワードおよび／または画像キャプチャファイルを含む。

既存のバックエンドアプリケーションの特定から、特定されたアプリケーションのデータモデルは既知であり得、また、フォームにおいて使用されるフィールドが既知であり得る。シンセサイザモジュールは、ユーザから特定を受け取り、ネイティブモバイルアプリケーションコードモジュールの集合を合成する。シンセサイザモジュールは、特定を分析するためのパーサーモジュールと、クエリージェネレータとを含み得、当該クエリージェネレータは、フレームワーク規格、サポートされたインターフェイス、およびコンポーネント定義などを含むフレームワーク定義にアクセスし得、および／または、ネイティブアプリケーションコードモジュールのリポジトリと、バックエンドアプリケーションおよび／またはメッセージによって使用されるフォームおよびフィールドのリポジトリとにアクセスし得る。シンセサイザモジュールはさらに、２つ以上のネイティブアプリケーションコードモジュールのアセンブリを促進するコード統合モジュールを含み得る。

いくつかの実施形態において、（たとえば特定モジュールからの）特定は、シンセサイザモジュールが（たとえば、コンフィギュラブルクラスジェネレータを使用して）それからＪａｖａクラスを生成すべきメッセージを抽出するのに十分である。この技術はさらに以下に論じられる。特定モジュールは、データモデルが既知であり得るバックエンドアプリケーションを特定するようユーザを支援するように機能する。例示的な場合において、特定されたアプリケーションについてのフォームのセットは、（たとえば規約に基づいて）分かり得るか、または、明示的に特定され得る。フォームはそれ自体、マークアップ言語（たとえばＨＴＭＬ）でコード化され得る。フォームはフィールドを使用し、データモデルにおいて使用されるフィールドのうちのいずれかが抽出され得、抽出されたフィールドは、フレームワークオペレーションのライブラリから選択される対応するオペレーション（たとえば、作成オペレーション、読出オペレーション、更新オペレーション、削除オペレーション）にマッピングされ得る。フレームワークオペレーションのライブラリは、モバイルデバイスのためのネイティブコードを含み得、特定のモバイルデバイスまたはオペレーティングシステムに特有であり得る。モバイルデバイスについてのそのようなネイティブコードは、パラメータ化され得るか、および／または、予め知られた態様で相互作用するように定義され得る。

ひとたびフレームワークオペレーションが選択およびパラメータ化されれば、選択されたフレームワークオペレーション同士の間でのリレーションシップ（たとえばコール、コールバック、パス）を提供するようコードが合成される。付加的なネイティブコードが、当該コードがモバイルデバイスにロードされテストされ得るようにモバイルデバイスアプリケーションを生成するよう加えられ得る。モバイルデバイスアプリケーションは、さまざまな条件下およびさまざまなセッティングにおいてテストされ得、テスト結果は、別のイテレーションを通じて進捗に影響を与え得、合成されたアプリケーションに組み込まれるように付加的なファンクションを追加する。

合成のいくつかの局面および結果得られるモバイルデバイスアプリケーションのいくつかの局面は、フレームワークの特性およびフレームワークとの相互作用に部分的に依存する。例示的な特性および相互作用のセットは、以下のように論じられる。

前述のフレームワークは、バックエンドフレームワーク（たとえばモバイルサービスフレームワーク）の形態を取り得、当該バックエンドフレームワークは、サービスプロキシ、Ｊａｖａアプリケーションサーバ（ＪＡＳ：Java Application Server）、および任意数または任意のグループのアプリケーションから形成される。これらのアプリケーションは、デスクトップ環境にサーブするバックエンドアプリケーションと実質的に同じである。たとえば、多くのバックエンドアプリケーションは、（たとえば、コンフィギュレーションデータを使用して）コンフィギュラブルであり、作成、読出、更新、および削除といった良好に定義されたフォームオペレーションのセット（たとえばオペレーションを参照）をサポートするフォーム（たとえばフォーム）を介してユーザと相互作用する。オペレーションのうちのいずれか、いくつかまたはすべてがデータベースエンジンにアクセスするよう機能する。

モバイルデバイスは、モバイルデバイスアプリケーションの任意の合成されたインスタンスにアクセスするレイヤーとして構成されるネイティブモバイルデバイスユーザインターフェイス（ＵＩ）を含む。モバイルデバイスアプリケーションは、プレゼンテーションレイヤーおよびデータ制御レイヤーから構成される。プレゼンテーションレイヤーおよびデータ制御レイヤー内のモジュール間の相互作用は、非同期通信を促進するハンドシェイク交換、ならびに／または、モバイルデバイスおよび／もしくはそのオペレーティングシステムのネイティブな局面に従って定義される共通してアクセス可能なデータ構造を使用するデータの交換のような良好に定義されたルールに従う。

例示的な場合において、モバイルデバイスは、無線ネットワークを介してアプリケーションシステムのネットワークインターフェイスに対して直接的に通信する。他の場合において、モバイルデバイスは、無線ネットワークを介してミドルウェアと直接的に通信する。

モバイルアプリケーション相互作用は、ミドルウェアコンポーネント（たとえばミドルウェア）を含む。ミドルウェアは、モバイルデバイスへの通信およびモバイルデバイスからの通信を促進するよう機能するオペレーションユニットを含み得る。たとえば、ミドルウェアコンポーネントはウェブサーバを実現し得、そのようなウェブサーバは、モバイルデバイスに対して、バックエンドとの直接的なインターフェイスを必要としないさまざまなサービスを実行し得る。厳密に１つのそのような例として、ミドルウェアコンポーネントはサービスプロセッサの連なり（たとえばフォームサービス要求プロセッサ、トークンサービス要求プロセッサ、メディアオブジェクト要求プロセッサなど）を含み得る。トークンサービス要求プロセッサは、パスワード、支払い、または、暗号化されたデータもしくは暗号されていないデータの任意のフォームを指すトークンを処理し得る。メディアオブジェクト要求プロセッサは、メディアオブジェクトの転送およびフォーマットを促進する。たとえば、メディアオブジェクトプロセッサは、バックエンドアプリケーションに大きなメディアファイル（たとえば高解像度画像キャプチャ）を転送するよう、モバイルデバイスに対する複数回の非同期アクセスまたは要求を行ない得る。

ミドルウェアコンポーネントによって提供されるサービスは、これまでに論じられたようにモバイルデバイスのみへのサービスの提供に限定されない。いくつかの場合には、ミドルウェアコンポーネントは任意の外部システムにサービスを提供し得る。

この環境において、ミドルウェアコンポーネントは、モバイルデバイスおよびアプリケーションシステムへのメッセージならびにモバイルデバイスおよびアプリケーションシステムからのメッセージを処理する。例示的な実施形態において、メッセージは予め定義されたプロトコルに従う。いくつかの場合において、メッセージは、たとえばＪａｖａＳｃｒｉｐｔ（登録商標）オブジェクトノーテーション（ＪＳＯＮ：JavaScript Object Notation）に従って、メッセージのペイロードにおいて予め定義されたオブジェクトまたはその部分を含む場合がある予め定義されたメッセージ仕様に適合するメッセージへとフォーマットされる。

モバイルデバイスアプリケーションメッセージ交換メカニズムは、要求および応答を含むＪＳＯＮメッセージ交換を含む。コードの開発の取り組みおよび合成は、ある規約に従う既存のアプリケーションのオブジェクトモデルに基づき行なわれ得る。たとえば、１つの規約は、所望のモバイルアプリケーションのデータモデル表現へのアクセスを必要とする。そのようなアクセスが与えられると、ネイティブモバイルアプリケーションを実現するためにビジネスモデルタイプロジックをコード化する必要はほとんどなくなるか、またはその必要はなくなる。そのようなモバイルアプリケーションは、所与のデータモデルに対して作成オペレーション、読出オペレーション、更新オペレーション、および削除オペレーション（ＣＲＵＤ）を行うよう、ネイティブコードを用いて構成され得る。デベロッパによって提供される場合がある特定および／または命令を有するシンセサイザモジュールは、（たとえばフォーム要求プロセッサによってＪａｖａオブジェクトに返されるＪＳＯＮメッセージをデシリアライズ（deserialize）する）Ｊａｖａクラスと、オブジェクトをユーザインターフェイスの特定の局面（たとえばフォームフィールド）に結合するように構成されるデータ結合モジュール（たとえばデータ制御モジュール）と、（たとえばサーバ環境における）選択されたアプリケーションを実行または開始するようサービスプロキシに要求するＪａｖａクラス（たとえば示されたＪａｖａデータ制御クラス）とを合成または作成し得る。

Ｊａｖａオブジェクトは、データ結合モジュールを介してＵＩに結合される。シンセサイザモジュールは、（たとえばプレゼンテーションレイヤーにおいて実現され得るような）ユーザインターフェイスコンポーネントと、モバイルアプリケーションによって実現されるページ間でナビゲートするナビゲーションメカニズムといったような付加的なコンポーネントをアセンブルするようパーティショニングを生成する。

合成プロセスは、モバイルアプリケーションコードの生成をガイドするために合成能力を使用するモバイルアプリケーションデベロッパによるイテレーションからなる。合成能力を使用することにより、デベロッパは、プラットフォームから独立したモバイルデバイスアプリケーションを作成することが可能になる。厳密に一例として、モバイルデバイスはモバイルデバイス識別子（たとえばｉＯＳ、ＡｎｄｒｏｉｄまたはＷｉｎｄｏｗｓモバイルなど）によって識別され得、ネイティブモバイルデバイスコードは、特定されたデバイスについて、（たとえば、モバイルデバイス識別子に基づいて）抽出および／またはアセンブルおよび／または生成され得る。

モバイルサービスフレームワークメッセージ交換メカニズムは、交換されたメッセージがモバイルサービスフレームワークによって生成および／または消費されるＪＳＯＮ交換を含む。示されるように、モバイルサービスフレームワークは、デベロッパが迅速にネイティブモバイルアプリケーションを開発するためのビルディングブロックとして使用され得るフレームワークを一緒に形成する複数の予めパッケージ化された技術の組合せを含む。サービスプロキシはメッセージステアリングおよびフロー制御のために機能し、抽象化レイヤー（たとえばファンクションのあるセットのみを公開する）として機能する。サービスプロキシはいくつかのパーティションへ分割され得、各パーティションはあるタイプの要求を処理するために専用である。厳密に例として、示されるサービスプロキシは、フォームサービス要求プロセッサと、トークンサービス要求プロセッサと、メディアオブジェクト要求プロセッサとを含む。そのような要求プロセッサは、サービスとしてアプリケーション層機能の実行を促進する。第２に、上記例は、Ｊａｖａアプリケーションサーバ（ＪＡＳ：Java Application Server）を含む。示されるように、ＪＡＳは、要求および応答のプロトコルを介してサービスプロキシからの要求を扱うよう修正される。第３に、当該例は１つ以上のバックエンドアプリケーションを含む。

例示的な開発環境において、モバイルサービスフレームワークの構成は、バイナリコードフォーマット（たとえば、．ｊａｒファイル）で再使用可能な予めパッケージ化された機能の利用可能性によって促進され、たとえば、ログインフォームが．ｊａｒファイルで提供され得る。例示的な開発環境はさらに、所与のＪＳＯＮメッセージに特有のＪａｖａクラスを作成するコンフィギュラブルクラスジェネレータの１つ以上のインスタンスを含み得る。これらのクラスはたとえば、Ｊａｖａオブジェクトへのモバイルアプリケーションの要求に基づいて、サービスプロキシによって返されるＪＳＯＮメッセージをデシリアライズするよう使用される。

モバイルサービスフレームワークおよびサービスプロキシによって提供されるサービスは、これまでに論じられたようにモバイルデバイスのみへサービスを提供することに限定されない。いくつかの場合において、モバイルサービスフレームワークおよびサービスプロキシは任意の外部システムにサービスを提供し得る。

ユーザは、エンタープライズアプリケーションの機能へのアクセスをいつでもおよびどこからでも（たとえばネイティブ環境外から）から求める。この状況は、時に非常に複雑なビジネスロジックを有する良好に開発されたビジネスアプリケーションを外部システムにて利用可能になるよう提供することについてのユーザの要求と解釈される。そのような外部システムは、前述のモバイルデバイスのいずれかとして具現化され得るか、または、外部システムが、モバイルデバイスであるかまたはモバイルデバイスでない場合がある付随的なプロセッサであり得る。外部システムに全アプリケーションを移すことはコスト効率（または実際的）でなく、また、デスクトップから外部システムに単にユーザインターフェイスを移すレガシーな試みも不十分である。後者のアプローチは少なくとも、デプロイヤ（deployer）がしばしばエンタープライズアプリケーションのファンクションのあるサブセットのみが外部システムで利用可能であることを（たとえばセキュリティおよび／または性能上の理由で）望むという点で失敗している。

１つ以上の外部システムがネイティブ（非外部）のシステムと相互作用する必要がある環境において、インターフェイスはしばしば、データを作成および消費するよう特定のインターフェイスを必要とする異なる規格を使用して開発されている。外部インターフェイスに、異なる規格を実現させるおよび／または複数の内部インターフェイスを実現させる、ことを可能にする抽象化レイヤーを、ネイティブアプリケーションと外部システムとの間に作成する必要性がある。この抽象化レイヤーは、ネイティブシステムがアップグレード（たとえばコード変更）をする場合またはインターフェイス接続技術のうちのいずれかが変化する場合に、外部システムへの影響を低減する。

ミドルウェアは、サービスプロキシのインスタンスを含む。サービスプロキシは、アプリケーションに対して抽象化レイヤーを実現しており、バックエンドアプリケーションのデータモデルに従って、変更、読出、更新、および削除オペレーションのうちのいずれかのフォームを実行するように構成される。

示されるように、ソリューションは、ＪＡＳサーバへのサーブレットベースのコールを用いて、フォームサービス要求（フォームサービス要求プロセッサを参照）と、トークンサービス要求（トークンサービス要求プロセッサを参照）と、メディアオブジェクトサービス要求（メディアオブジェクト要求プロセッサを参照）とをサポートする。サービスプロキシは拡張可能であり、そのようなニーズが発生する際に継続していて進行中の開発および追加されるべき機能をサポートする。

付加的なパーティショニングは妥当である。たとえば、サービスプロキシは、外部システムからデータ（たとえばネイティブアプリケーションのフォームフィールドに対応するデータ）を受け取り得、データがネイティブに受け取られた（たとえばネイティブアプリケーションのフォームフィールドに対応するデータを受け取った）かのようにネイティブシステム上でそのデータを処理する。そのようなオペレーションは、外部システムからのフォーム指向のオペレーションを実行するために、本願明細書において開示されたフォームサービスの実施形態を使用して実現され得る。

前述の議論で言及されたように、サービスプロキシは多くのこれまで未知であるビジネスサービス要求を消費するよう拡張または増強され得る。そのような増強は、シンプルオブジェクトアクセスプロトコル（Simple Object Access Protocol）すなわちＳＯＡＰ（たとえばＳＯＡＰ要求を参照）のすべてもしくは一部のインプリメンテーションを含み得、および／または、そのような増強は、リプリゼンテーショナルステイトトランスファ（Representational State Transfer）の抽象化すなわちＲＥＳＴ（ＲＥＳＴ要求を参照）または将来のプロトコルのすべてもしくは一部のインプリメンテーションを含み得、これにより、外部システムがそれらのプロトコルのうちのいずれか（または任意の組合せ）を使用してサービスプロキシとインターフェイス接続し得る。

サービスプロキシは、示されるアプリケーションと他の現在および潜在的な外部システムとの間の抽象化レイヤーとして機能することに加えて、セッション管理、キャッシング、バッチ要求のサポートおよびセキュリティ向上を提供するよう有効化され得る。抽象化レイヤーによって提供されるファンクションの処理のいくつかの局面は、バックエンドシステムによる処理を伴い得る。たとえば、サーブレットコールは、Ｊａｖａサーバにフォームサービス要求を開始させ得る。または、たとえば、ＳＯＡＰコールは、拡張可能ロジックにおける処理を開始し得る。

前述のように、特定されたアプリケーションについてのフォームのセットは（たとえば規約に基づいて）既知であり得る。さらに、フォームが既知である場合、フィールドは既知であり得る。フィールドのセットが与えられると、対応するオペレーションのセットが既知であり得、また、フィールドのセットが与えられると、バックエンドアプリケーションにフィールドデータを搬送するメッセージのセットおよびバックエンドアプリケーションからフィールドデータを搬送するメッセージのセットも既知であり得る。多くの場合において、モバイルアプリケーションによって扱われる必要があるのはいくつかのフィールドのみである（たとえばバックエンドアプリケーションによってサポートされる必要があるのはフィールドおよび／または対応するオペレーションのサブセットのみ）。

示されるように、オブジェクトモデルヒエラルキーは、アプリケーション（たとえば、アプリケーションセットを参照）の１つ以上のインスタンスを含むよう組織化され得、当該アプリケーションは、複数のファンクション（ファンクションセットを参照）を包含しており、当該ファンクションはフィールド（フィールドセットを参照）を通じてユーザと相互作用しており、フィールドは、オペレーション（オペレーションセットを参照）に対して一対一または一対多のリレーションシップを有し得る。任意のアプリケーションまたはファンクションまたはフィールドは、メッセージを発し得る（メッセージを参照）。他のヒエラルキーが可能であり、また、いくつかの組織は厳密に階層的ではない。

（たとえばオブジェクトモデルから得られ得るような）マッピングリレーションシップは、フォームと、オペレーションの任意のインスタンスおよび／またはフォームメタデータとの間の任意数のリレーションシップ４０４を定義し得る。フォームメタデータは任意の公知の技術を使用（たとえばＸＭＬを使用、ＢＮＦを使用など）してコード化され得る。厳密に例示的な例として、フォームメタデータは、それぞれのフォームコンポーネント（たとえばファンクション、オペレーション、フィールド、グリッド、ボタンなど）に対応するＸＭＬ要素から構成され得る。フォームメタデータは、フォームおよび／またはそのコンポーネントの構造および任意の他の局面を記述し得る。

示されるように、リレーションシップはＸＭＬ要素にフォームをマッピングする。オペレーションは、フィールドの任意数の関連付けられるインスタンスを有し得る。リレーションシップはＸＭＬ要素にオペレーションをマッピングする。ＸＭＬ要素は、任意数のさまざまな属性（たとえばタイプなど）から構成され得る。リレーションシップは、ＸＭＬ要素に、フィールドボックスに与えられるフィールドをマッピングし得る。ＸＭＬ要素は、任意数のさまざまな属性（たとえばｉｄ、ラベル、データタイプなど）を含み得る。リレーションシップは、ＸＭＬ属性（たとえばラベルなど）にフィールドラベル（たとえば都市など）をマッピングし得る。リレーションシップは、示されたＸＭＬフィールド要素を使用して、ＸＭＬ属性（たとえばデータタイプなど）にフィールド値をマッピングし得る。

他の実施形態は、ＸＭＬフォーマットではなくＪＳＯＮフォーマットで直接的にマップを作成し得る。いくつかの場合において、リレーションシップは、オブジェクトモデル、データ構造またはハードコードされたマップを用いる、オペレーションへのマップ／オペレーションからのマップを含む。ランタイムプロセスは、（たとえばフォーム識別子または推論を介して）実行されているフォームを識別し、識別されたフォームにおいて使用されるコンポーネント（たとえば日付フィールド、ドロップダウン、グリッド行など）に基づいて、そのフォームのＪＳＯＮ表現を作り出す。

シンセサイザモジュールは、バックエンドアプリケーションの識別を与えられる。アプリケーションは、オブジェクトモデルによって決定され得るフォームのセットを使用する。前述のように、モバイルアプリケーションによって扱われる必要があるのは、いくつかのフィールドのみである。フィールドは、フィールド名によって明示的に特定され得るか、または、ファンクションが抽出されるアプリケーションの特定によって暗示的に表現され得るか、または、ファンクションのセットの特定によって暗示的に特定され得る。いくつかの場合において、選択されたファンクションの選択および／または定義は、使用されるべきフィールドを（たとえば暗示的に）特定するよう機能する。必要とされるフィールドおよび／またはファンクションが既知の場合、対応するメッセージのセットは既知であり得る。ここで、モバイルデバイスアプリケーションの構造は既知であり、コードは、ネイティブモバイルアプリケーションコードモジュールのリポジトリにマッピングされ得るとともに、ネイティブモバイルアプリケーションコードモジュールのリポジトリから選択される。そのようなネイティブモバイルアプリケーションコードモジュールは、前述の技術を使用してアセンブルされ得、モバイルアプリケーションコードモジュールコードと、生成されたコード（たとえば、クラスジェネレータから発せられたコード）および／または任意の他のコード（たとえば合成されたコード）とは、モバイルターミナル上で実行され得、テストが行なわれ得る。

１つのフローは、シンセサイザのユーザがＵＩレイアウトを定義し、制御をデータコントローラに結合し、ページナビゲーションを定義すると開始する。別のフローは、シンセサイザのユーザが、データ制御クラスに基づいてデータ制御を自動生成すると始まり、その後、データ制御は自動的にデータ制御クラスと同期したままとなる。さらに別のフローは、シンセサイザのユーザが、アプリケーションがビジネスロジックを実行する必要がある属性および機能を使用するためのインターフェイス接続ルールをコーディングすると始まる。インターフェイス接続ルールは、属性を格納し、かつ、対応するバックエンドアプリケーションをサービスプロキシを介して呼び出すために機能し、モバイルアプリケーションについて必要なビジネスロジックを実行する。

いくつかの場合において、シンセサイザのユーザのワークフローは、カスタマイズされたニーズに合致するようモバイルアプリケーションによって使用されている基礎をなすバックエンドアプリケーションを修正することを含む。

結果得られる生成されたモバイルアプリケーションは、たとえば、「顧客（customer）の「Ｃ」のサーチタイプによってアドレス帳をサーチする」ようユースケース（use case）が与えられるある範囲の使用モデルをサポートする。初期オペレーションは、ユーザアクション（たとえば、ユーザがＵＩテキストボックスに「Ｃ」を入力）に応答し得る。次のオペレーションは、デベロッパがデータ制御とＵＩのテキスト制御との間にセットした結合に基づいてデータ制御を通じてデータが渡されるシステム応答を含み得る。システム応答はさらに、データ制御モジュールがそのサーチ属性をセットするためにデータ制御オブジェクトのセッターを呼び出すオペレーションを含み得る。そのような応答は、データ制御とデータ制御クラスとの間のシステムが生成した結合に基づき得る。

別の状況において、生成されたモバイルアプリケーションは、ユーザがサーチボタンをクリックするユーザアクションの際に開始する使用モデルをサポートし、システムは、デベロッパが確立した結合に基づきデータ制御クラスのサーチメソッドを自動的に実行することによって応答する。たとえば、データ制御クラスは、パラメータ（サーチタイプ、トークン、呼び出しのためのＥｌフォームなど）をＪＳＯＮメッセージへロードし得、その後、ＪＳＯＮメッセージをシリアライズ（serialize）し、サービスプロキシに要求を行う。サービスプロキシは要求を監視するとともにＪＡＳサーバへ転送し、その後、ＪＡＳサーバはアプリケーションを実行または呼び出す。

別のフローは、それを用いて実行するよう与えられたパラメータに基づいてフォームおよびそのデータのＪＳＯＮデータ表現を作成し、その後、当該データをサービスプロキシに返す。サービスプロキシは、データをモバイルアプリケーションに戻し、その際、モバイルアプリケーションは、サポートする予め生成されたＪａｖａオブジェクトへとデータをデシリアライズする。サポートするＪＳＯＮ Ｊａｖａオブジェクトは、データ制御クラスを介してデータ制御に結合され、これにより、データコントローラが結合に基づいてＵＩ制御にデータを渡すことが可能になることを促進する。

本開示の局面、目的および利点のさらなる詳細は、以下に記載されるとともに、詳細な説明、図面および請求の範囲において記載される。上記の背景の概説および以下の詳細な説明の両方は例示および説明であり、請求の範囲に関して限定するようには意図されない。

以下に記載された図は例示目的のみである。図面は本開示の範囲を限定するようには意図されない。

いくつかの実施形態に従った、アプリケーションオブジェクトモデルに基づくネイティブモバイルアプリケーションの自動的な合成のための環境を例示する図である。 いくつかの実施形態に従った、バックエンドアプリケーションシステムとのモバイルアプリケーション相互作用の例を示す図である。 いくつかの実施形態に従った、ミドルウェアおよびバックエンド応用システムとのモバイルアプリケーション相互作用の例を示す図である。 いくつかの実施形態に従った、モバイルデバイスアプリケーションメッセージ交換メカニズムの例を示す図である。 いくつかの実施形態に従った、自動的に合成されたネイティブモバイルアプリケーションと相互作用するように構成されるモバイルサービスフレームワークメッセージ交換メカニズムの例を示す図である。 いくつかの実施形態に従った、自動的に合成されたネイティブモバイルアプリケーションと相互作用するように構成されるミドルウェアコンポーネント内に実現されたサービスプロキシを含む多層環境を示す図である。 いくつかの実施形態に従った、サービスプロキシのパーティショニングを示す図である。 一実施形態に従った、ネイティブモバイルアプリケーションの自動的な合成のための合成ツールを使用する際にオブジェクトモデルを特定するためのサンプルヒエラルキーを示す図である。 一実施形態に従った、ネイティブモバイルアプリケーションの自動的な合成のための合成ツールによって使用されるオブジェクトモデルから得られるフォームおよびメッセージを示す図である。 いくつかの実施形態に従った、アプリケーションオブジェクトモデルに基づいたネイティブモバイルアプリケーションの自動的な合成につながる動作フローを示す図である。 一実施形態に従った、アプリケーションオブジェクトモデルに基づいたネイティブモバイルアプリケーションの自動的な合成のためのシステムのブロック図である。 本開示の実施形態を実現するのに好適であり、および／または、本願明細書において記載される環境における使用のために好適であるコンポーネントの例示的なアーキテクチャを示す図である。

詳細な説明
本開示のいくつかの実施形態は異種混合のモバイルプラットフォーム上で実行することを目標としたアプリケーションの迅速な開発および展開の問題に対処し、また、いくつかの実施形態は、所与のオブジェクトモデルに準拠するようネイティブコードの集合を合成するためのアプローチに関する。より特定的には、アプリケーションオブジェクトモデルに基づいたネイティブモバイルアプリケーションの自動的な合成のための例示的な環境、方法およびシステムが本願明細書および添付の図面において開示される。

概略
本願明細書において開示される合成システムは、予めパッケージ化されたコードモジュール（たとえばフォームおよびファンクション指向コードモジュール）の選択されたセットのみを用いて特定ベースの合成を実行する。結果得られるモバイルデバイスアプリケーションは、アプリケーションのファンクションまたはオペレーション（たとえばフォームデータの送信および受信）のある予め知られているセットの使用を促進するサービスに部分的に依存する。いくつかの状況において、本願明細書において開示される合成システムは、予めパッケージ化されたファンクションの選択されたセット（たとえばフォーム指向ファンクション）を決定するよう、フォームを使用して特定ベースの合成を実行する。前述のサービスは、フォームデータを送信および／もしくは受信するオペレーション、ならびに／または、フォームフィールドおよび／もしくはデータベースフィールドを作成、読出、更新、もしくは削除する動作といったオペレーションのある既知のセットを実現する。

ソフトウェアを開発する際に、デザイナーにモジュールまたはライブラリを提供することは、抽象化のレベルを上昇させる。確かに、予めパッケージ化されたモジュールまたはライブラリのみを使用するといった制限にデザイナーが従う場合にはしばしば、稼働するソフトウェアがはるかに速く開発される。抽象化の付加的な局面を考慮すると、あるファンクション、オペレーションまたはモジュール（たとえば予め構築されたファンクションおよび／または予めテストされたオペレーション）のみを使用するようデザイナーが自己訓練されている場合、エラーまたは不適合性についての可能性は大幅に低減される。人間のデザイナーだけでなくコンピュータ支援プログラム（たとえば合成ツール）も、特定に基づいておよび／またはルールまたは制限のセットに従ってコードを合成および／またはアセンブルする際の可能性がより少ないことの恩恵を利用することができる。

定義
この記載において使用される用語のうちのいくつかは、容易な参照のために以下に定義される。提示された用語およびそれらのそれぞれの定義はこれらの定義に厳密に制限されない。すなわち、ある用語は、この開示における当該用語の使用によってさらに定義され得る。

「例示的」という用語は、例、実例、または例示として機能することを意味するように本願明細書において使用される。「例示的な」ものとして本願明細書において記載される任意の局面または設計は、他の局面または設計に対して好ましいまたは有利であるとは必ずしも解釈されるべきでない。むしろ、例示的という単語の使用は、具体的な態様で概念を提示するように意図される。

この出願および添付の請求の範囲において使用されるように、「または」という用語は、排他的な「または」ではなく、包含的な「または」を意味するように意図される。すなわち、別の態様で特定されなければ、または、文脈から明らかでなければ、「ＸはＡまたはＢを使用する」は、自然な包含的な順列のいずれかを意味するように意図される。すなわち、ＸがＡを使用する場合、ＸがＢを使用する場合、または、ＸがＡおよびＢの両方を使用する場合には、前述の場合のうちのいずれかのもとで「ＸがＡまたはＢを使用する」が満たされる。

この出願および添付の請求の範囲において使用されるような「ある（ａ；ａｎ）」という冠詞は、別の態様で特定されていなければ、または、文脈から単数形に向けられることが明らかでなければ、「１つ以上」を意味するよう一般に解釈されるべきである。

ここで、ある実施形態が詳細に参照される。開示された実施形態は、請求の範囲を限定するようには意図されない。

例示的な実施形態の記載
図１Ａは、アプリケーションオブジェクトモデルに基づいたネイティブモバイルアプリケーションの自動的な合成のための環境１Ａ００を例示する。オプションとして、環境１Ａ００の１つ以上のインスタンスまたはその任意の局面は、本願明細書に記載される実施形態のアーキテクチャおよび機能の文脈において実現され得る。さらに、環境１Ａ００またはその任意の局面は、任意の所望の環境において実現され得る。

示されるように、ユーザ１０５は、存在する「バックエンド」アプリケーションを特定するよう、この環境において相互作用する（たとえば、特定モジュール１２０を参照）。存在するバックエンドアプリケーションの特定から、特定されたアプリケーションのデータモデルが分かり得、さらに、フォームにおいて使用されるフィールドが分かり得る。シンセサイザモジュール１１０はユーザから特定を受け取り、ネイティブモバイルアプリケーションコードモジュールの集合を合成する。シンセサイザモジュールは、特定を分析するためのパーサーモジュール１３２と、クエリージェネレータ１３３とを含み得る。クエリージェネレータ１３３は、フレームワーク規格、サポートされたインターフェイス、およびコンポーネント定義などを含むフレームワーク定義にアクセスし得るか、ならびに／または、ネイティブアプリケーションコードモジュール１５０のリポジトリと、バックエンドアプリケーションおよび／もしくはメッセージによって使用されるフォームおよびフィールドのリポジトリとにアクセスし得る。シンセサイザモジュールはさらに、２つ以上のネイティブアプリケーションコードモジュールのアセンブリを容易にするよう、コード統合モジュール１３４を含み得る。

いくつかの場合において、（たとえば特定モジュール１２０からの）特定は、シンセサイザモジュールが（たとえばコンフィギュラブルクラスジェネレータ１３５を使用して）Ｊａｖａクラスを生成するメッセージを抽出するのに十分である。この技術がさらに以下で論じられる。特定モジュール１２０は、データモデルがそこから分かり得るバックエンドアプリケーションを特定するようユーザを支援するように機能する。例示的な場合において、特定されたアプリケーションについてのフォームのセットは、（たとえば規約に基づいて）分かり得るか、または、明示的に特定され得る。フォームはそれ自体、マークアップ言語（たとえばＨＴＭＬ）でコード化され得る。フォームはフィールドを使用し、データモデルにおいて使用されるフィールドのうちのいずれかが抽出され得、抽出されたフィールドは、フレームワークオペレーションのライブラリから選択される対応するオペレーション（たとえば、作成オペレーション、読出オペレーション、更新オペレーション、削除オペレーション）にマッピングされ得る。フレームワークオペレーションのライブラリは、モバイルデバイスのためのネイティブコードを含み得、特定のモバイルデバイスまたはオペレーティングシステムに特有であり得る。モバイルデバイスについてのそのようなネイティブコードは、パラメータ化され得るか、および／または、予め知られた態様で相互作用するように定義され得る。

ひとたびフレームワークオペレーションが選択およびパラメータ化されれば、選択されたフレームワークオペレーション同士の間でのリレーションシップ（たとえばコール、コールバック、パス）を提供するようコードが合成される。付加的なネイティブコードがモバイルデバイスアプリケーションを生成するよう加えられ得、当該コードはモバイルデバイスにロードされテストされ得る。モバイルデバイスアプリケーションは、さまざまな条件下およびさまざまなセッティングにおいてテストされ得、テスト結果は、別のイテレーションを通じて進捗に影響を与え得、合成されたアプリケーションに組み込まれるように付加的なファンクションを追加する。

合成のいくつかの局面および結果得られるモバイルデバイスアプリケーションのいくつかの局面は、フレームワーク１３０の特性およびフレームワーク１３０との相互作用に部分的に依存する。例示的な特性および相互作用のセットは、以下のように論じられる。

図１Ｂ１は、合成されたネイティブモバイルアプリケーションと相互作用するように構成されるバックエンドアプリケーションシステムとのモバイルアプリケーション相互作用１Ｂ１００の例を示す。オプションとして、モバイルアプリケーション相互作用１Ｂ１００またはその任意の局面の１つ以上のインスタンスは、本願明細書に記載される実施形態のアーキテクチャおよび機能の文脈において実現され得る。さらに、モバイルアプリケーション相互作用１Ｂ１００またはその任意の局面は、任意の所望の環境において実現され得る。

前述のフレームワークは、バックエンドフレームワーク（たとえばモバイルサービスフレームワーク１１４）の形態を取り得、バックエンドフレームワークは、サービスプロキシ、Ｊａｖａアプリケーションサーバ（ＪＡＳ：Java Application Server）および任意数または任意のグループのアプリケーション（たとえばアプリケーション１０１_１、アプリケーション１０１_２など）から形成される。これらのアプリケーションは、デスクトップ環境にサーブするバックエンドアプリケーションと実質的に同じである。たとえば、多くのバックエンドアプリケーションは、（たとえばコンフィギュレーションデータ１２２を使用して）コンフィギュラブルであり、作成、読出、更新、および削除といった良好に定義されたフォームオペレーションのセットをサポートする（たとえば、オペレーション１１８を参照）フォーム（たとえばフォーム１１６）を介してユーザと相互作用する。オペレーション１１８のうちのいずれか、いくつかまたはすべてがデータベースエンジン１２６にアクセスするよう機能する。

モバイルデバイス１０２は、モバイルデバイスアプリケーション１０６の任意の合成されたインスタンスにアクセスするレイヤーとして構成されるネイティブモバイルデバイスユーザインターフェイス（ＵＩ）１０４を含む。モバイルデバイスアプリケーション１０６は、プレゼンテーションレイヤーおよびデータ制御レイヤーから構成される。プレゼンテーションレイヤーおよびデータ制御レイヤー内のモジュール間の相互作用は、非同期通信を促進するハンドシェイク交換、ならびに／または、モバイルデバイスおよび／もしくはそのオペレーティングシステムのネイティブな局面に従って定義される共通してアクセス可能なデータ構造を使用するデータの交換のような良好に定義されたルールに従う。

例示的な場合において、モバイルデバイス１０２は、無線ネットワーク１０９を介してアプリケーションシステムのネットワークインターフェイスと直接的に（たとえばネットワークインターフェイス１１１_１およびネットワークインターフェイス１１１_２を使用して）通信する。他の場合において、モバイルデバイス１０２は、無線ネットワーク１０９を介してミドルウェアと直接的に通信する。そのようなパーティショニングは図１Ｂ２に関係すると例示および記載される。

図１Ｂ２は、合成されたネイティブモバイルアプリケーションと相互作用するように構成されるバックエンドアプリケーションシステムとのモバイルアプリケーション相互作用１Ｂ２００の例を示す。オプションとして、モバイルアプリケーション相互作用１Ｂ２００またはその任意の局面の１つ以上のインスタンスは、本願明細書に記載される実施形態のアーキテクチャおよび機能の文脈において実現され得る。さらに、モバイルアプリケーション相互作用１Ｂ２００またはその任意の局面は、所望の環境において実現され得る。

示されるモバイルアプリケーション相互作用１Ｂ２００は、ミドルウェアコンポーネント（たとえばミドルウェア１０８）を含む。ミドルウェアは、モバイルデバイスへの通信およびモバイルデバイスからの通信を促進するよう機能するオペレーションユニットを含み得る。たとえば、ミドルウェアコンポーネントはウェブサーバを実現し得、そのようなウェブサーバは、モバイルデバイスに対して、バックエンドとの直接的なインターフェイス接続を必要としないさまざまなサービスを実行し得る。厳密に１つのそのような例として、ミドルウェアコンポーネントはサービスプロセッサの連なり（たとえばフォームサービス要求プロセッサ、トークンサービス要求プロセッサ、メディアオブジェクト要求プロセッサなど）を含み得る。トークンサービス要求プロセッサは、パスワード、支払い、または、暗号化されたデータもしくは暗号されていないデータの任意のフォームを指すトークンを処理し得る。メディアオブジェクト要求プロセッサは、メディアオブジェクトの転送およびフォーマットを容易にする。たとえば、メディアオブジェクトプロセッサは、バックエンドアプリケーションに大きなメディアファイル（たとえば高解像度画像キャプチャ）を転送するよう、モバイルデバイスに対する複数回の非同期アクセスまたは要求を行ない得る。

ミドルウェアコンポーネントによって提供されるサービスは、これまでに論じられたようにモバイルデバイスのみへのサービスの提供に限定されない。いくつかの場合、ミドルウェアコンポーネントは任意の外部システムにサービスを提供し得る。外部システムを伴うそのような例は、図２Ｃに関係するとして例示および議論される。

この環境において、ミドルウェアコンポーネントは、モバイルデバイスおよびアプリケーションシステムへのメッセージならびにモバイルデバイスおよびアプリケーションシステムからのメッセージを処理する。例示的な実施形態において、メッセージは予め定義されたプロトコルに従う。いくつかの場合において、メッセージは、たとえばＪａｖａＳｃｒｉｐｔオブジェクトノーテーション（ＪＳＯＮ：JavaScript Object Notation）に従って、メッセージのペイロードにおいて予め定義されたオブジェクトまたはその部分を含む場合がある予め定義されたメッセージ仕様に適合するメッセージへとフォーマットされる。交換メカニズムは以下の図２Ａにおいて示されるとともに記載される。図２Ａの特定の例は、ＪＳＯＮメッセージを指すが、他のメッセージングプロトコル、フォーマットまたはノーテ―ションが可能である。

図２Ａは、モバイルデバイスアプリケーションメッセージ交換メカニズム２Ａ００の例を示す。オプションとして、モバイルデバイスアプリケーションメッセージ交換メカニズム２Ａ００またはその任意の局面の１つ以上のインスタンスは、本願明細書に記載される実施形態のアーキテクチャおよび機能の文脈において実現され得る。さらに、モバイルデバイスアプリケーションメッセージ交換メカニズム２Ａ００またはその任意の局面は、任意の所望の環境において実現され得る。

図２Ａにおいて示されるように、モバイルデバイスアプリケーションメッセージ交換メカニズムは、要求および応答（たとえば要求２０９、応答２１１など）を含むＪＳＯＮメッセージ交換を含む。コードの開発の取り組みおよび合成は、ある規約に従う既存のアプリケーションのオブジェクトモデルに基づき行なわれ得る。たとえば、１つの規約は、所望のモバイルアプリケーションのデータモデル表現へのアクセスを必要とする。そのようなアクセスが与えられると、ネイティブモバイルアプリケーションを実現するためにビジネスモデルタイプロジックをコード化する必要はほとんどなくなるか、または、その必要はなくなる。そのようなモバイルアプリケーションは、所与のデータモデルに対して作成オペレーション、読出オペレーション、更新オペレーション、および削除オペレーション（ＣＲＵＤ）を行うよう、ネイティブコードを用いて構成され得る。デベロッパによって提供される場合がある特定および／または命令を有するシンセサイザモジュールは、（たとえばフォーム要求プロセッサによってＪａｖａオブジェクトに返されるＪＳＯＮメッセージをデシリアライズする）Ｊａｖａクラスと、オブジェクトをユーザインターフェイスの特定の局面（たとえばフォームフィールド）に結合するように構成されるデータ結合モジュール（たとえばデータ制御モジュール２４４）と、（たとえばサーバ環境における）選択されたアプリケーションを実行または開始するようサービスプロキシに要求するＪａｖａクラス（たとえば示されたＪａｖａデータ制御クラス２４２）とを合成または作成し得る。

本願のいくつかの実施形態におけるある局面は、「ＪＳＯＮメッセージからのルールベースの自動クラス生成（RULE-BASED AUTOMATIC CLASS GENERATION FROM A JSON MESSAGE）」（代理人管理番号ＯＲＡ１４０３６０−ＵＳ−ＮＰ）という名称を有する、２０１４年２月１２日に出願された米国特許出願第１４／１７９，５４８号に開示される資料に関する。

Ｊａｖａオブジェクトは、データ結合モジュールを介してＵＩに結合される。シンセサイザモジュールは、（たとえばプレゼンテーションレイヤー２４６において実現され得るような）ユーザインターフェイスコンポーネントと、モバイルアプリケーションによって実現されるページ間でナビゲートするナビゲーションメカニズムといったような付加的なコンポーネントをアセンブルするようパーティショニングを生成する。

合成プロセスは、モバイルアプリケーションコードの生成をガイドするために合成能力を使用するモバイルアプリケーションデベロッパによるイテレーションからなる。合成能力を使用することにより、デベロッパは、プラットフォームから独立したモバイルデバイスアプリケーションを作成することが可能になる。厳密に一例として、モバイルデバイスはモバイルデバイス識別子（たとえばｉＯＳ、ＡｎｄｒｏｉｄまたはＷｉｎｄｏｗｓモバイルなど）によって識別され得、ネイティブモバイルデバイスコードは、特定されたデバイスについて、（たとえば、モバイルデバイス識別子に基づいて）抽出および／またはアセンブルおよび／または生成され得る。

図２Ｂは、自動的に合成されるネイティブモバイルアプリケーションと相互作用するように構成されるモバイルサービスフレームワークメッセージ交換メカニズム２Ｂ００の例を示す。オプションとして、モバイルサービスフレームワークメッセージ交換メカニズム２Ｂ００またはその任意の局面の１つ以上のインスタンスは、本願明細書に記載される実施形態のアーキテクチャおよび機能の文脈において実現され得る。さらに、モバイルサービスフレームワークメッセージ交換メカニズム２Ｂ００またはその任意の局面は、任意の所望の環境において実現され得る。

図２Ｂにおいて示されるように、モバイルサービスフレームワークメッセージ交換メカニズムは、交換されたメッセージがモバイルサービスフレームワーク１１４によって生成および／または消費されるＪＳＯＮ交換を含む。示されるように、モバイルサービスフレームワーク１１４は、デベロッパが迅速にネイティブモバイルアプリケーションを開発するためのビルディングブロックとして使用され得るフレームワークを一緒に形成する複数の予めパッケージ化された技術の組合せを含む。図２Ｂの例において、モバイルサービスフレームワークはいくつかのコンポーネントを含む。まず、サービスプロキシ２１０はメッセージステアリングおよびフロー制御のために機能し、抽象化レイヤー（たとえばファンクションのあるセットのみを公開する）として機能する。サービスプロキシはいくつかのパーティションへ分割され得、各パーティションはあるタイプの要求を処理するために専用である。厳密に例として、示されるサービスプロキシ２１０は、フォームサービス要求プロセッサ１２１と、トークンサービス要求プロセッサ２１４と、メディアオブジェクト要求プロセッサ２１６とを含む。そのような要求プロセッサは、サービスとしてアプリケーション層機能の実行を促進する。第２に、上記例は、Ｊａｖａアプリケーションサーバ（ＪＡＳ：Java Application Server）を含む。示されるように、ＪＡＳ２１８は、要求２０４および応答２０６のプロトコルを介してサービスプロキシ２１０からの要求を扱うよう修正される。第３に、上記例は、１つ以上のバックエンドアプリケーション（たとえばアプリケーション１０１_１、アプリケーション１０１_Ｎ））を含む。

例示的な開発環境において、モバイルサービスフレームワーク１１４の構成は、バイナリコードフォーマット（たとえば、．ｊａｒファイル）で再使用可能な予めパッケージ化された機能の利用可能性によって促進され、たとえば、ログインフォームが．ｊａｒファイルで提供され得る。例示的な開発環境はさらに、所与のＪＳＯＮメッセージに特有のＪａｖａクラスを作成するコンフィギュラブルクラスジェネレータ１３５の１つ以上のインスタンスを含み得る。これらのクラスはたとえば、Ｊａｖａオブジェクトへのモバイルアプリケーションの要求に基づいて、サービスプロキシによって返されるＪＳＯＮメッセージをデシリアライズするよう使用される。

モバイルサービスフレームワーク１１４およびサービスプロキシ２１０によって提供されるサービスは、これまでに論じられたようにモバイルデバイスのみへのサービスの提供に限定されない。いくつかの場合において、モバイルサービスフレームワークおよびサービスプロキシは任意の外部システムにサービスを提供し得る。外部システムを伴うそのような例は、図２Ｃに関係するものであると例示および議論される。

図２Ｃは、自動的に合成されたネイティブモバイルアプリケーションと相互作用するように構成されるミドルウェアコンポーネント内で実現されるサービスプロキシを含む多層環境２Ｃ００を示す。オプションとして、多層環境２Ｃ００またはその任意の局面の１つ以上のインスタンスは、本願明細書に記載される実施形態のアーキテクチャおよび機能の文脈において実現され得る。さらに、多層環境２Ｃ００またはその任意の局面は任意の所望の環境において実現され得る。

ユーザは、エンタープライズアプリケーションの機能へのアクセスをいつでもおよびどこからでも（たとえばネイティブ環境外から）から求める。この状況は、時に非常に複雑なビジネスロジックを有する良好に開発されたビジネスアプリケーションを外部システム２０２にて利用可能になるよう提供することについてのユーザの要求と解釈される。そのような外部システム２０２は、前述のモバイルデバイスのいずれかとして具現化され得るか、または、外部システムが、モバイルデバイスであるかまたはモバイルデバイスでない場合がある付随的なプロセッサであり得る。外部システムに全アプリケーションを移すことはコスト効率（または実際的）でなく、また、デスクトップから外部システムに単にユーザインターフェイスを移すレガシーな試みも不十分である。後者のアプローチは少なくとも、デプロイヤ（deployer）がしばしばエンタープライズアプリケーションのファンクションのあるサブセットのみが外部システムで利用可能であることを（たとえばセキュリティおよび／または性能上の理由で）望むという点で失敗している。

１つ以上の外部システム２０２がネイティブ（非外部）のシステムと相互作用する必要がある環境において、インターフェイスはしばしば、データを作成および消費するよう特定のインターフェイスを必要とする異なる規格を使用して開発されている。外部インターフェイスに、異なる規格を実現させるおよび／または複数の内部インターフェイスを実現させる、ことを可能にする抽象化レイヤーを、ネイティブアプリケーションと外部システムとの間に作成する必要性がある。この抽象化レイヤーは、ネイティブシステムがアップグレード（たとえばコード変更）をする場合またはインターフェイス接続技術のうちのいずれかが変化する場合に、外部システムへの影響を低減する。

ミドルウェア１０８は、サービスプロキシ２１０のインスタンスを含む。サービスプロキシは、アプリケーションに対して抽象化レイヤーを実現しており、バックエンドアプリケーションのデータモデルに従って、変更、読出、更新、および削除オペレーションのうちのいずれかのフォームを実行するように構成される。

示されるように、ソリューションは、ＪＡＳサーバへのサーブレットベースのコール（たとえば２０４および２０６）を用いて、フォームサービス要求（フォームサービス要求プロセッサ２１２を参照）と、トークンサービス要求（トークンサービス要求プロセッサ２１４を参照）と、メディアオブジェクトサービス要求（メディアオブジェクト要求プロセッサ２１６を参照）とをサポートする。サービスプロキシは拡張可能であり、そのようなニーズが発生する際に継続していて進行中の開発および追加されるべき機能をサポートする。

付加的なパーティショニングは妥当である。たとえば、サービスプロキシは、外部システム２０２（たとえば外部システム２０２_１、外部システム２０２_２など）からデータ（たとえばネイティブアプリケーションのフォームフィールドに対応するデータ）を受け取り得、データがネイティブに受け取られた（たとえばネイティブアプリケーションのフォームフィールドに対応するデータを受け取った）かのようにネイティブシステム上でそのデータを処理する。そのようなオペレーションは、外部システムからフォーム指向オペレーションを実行するために、本願明細書において開示されたフォームサービスの実施形態を使用して実現され得、そのようなパーティショニングは以下の図３に提示される。

図３は、サービスプロキシのパーティショニング３００を示す。オプションとして、パーティショニング３００またはその任意の局面の１つ以上のインスタンスは、本願明細書に記載される実施形態のアーキテクチャおよび機能の文脈において実現され得る。さらに、パーティショニング３００またはその任意の局面は、所望の環境において実現され得る。

前述の議論で言及されたように、サービスプロキシは多くのこれまで未知であるビジネスサービス要求を消費するよう拡張または増強され得る。そのような増強は、シンプルオブジェクトアクセスプロトコル（Simple Object Access Protocol）すなわちＳＯＡＰ（たとえばＳＯＡＰ要求３０８を参照）のすべてもしくは一部のインプリメンテーションを含み得、および／または、そのような増強は、リプリゼンテーショナルステイトトランスファ（Representational State Transfer）抽象化すなわちＲＥＳＴ（ＲＥＳＴ要求３１０を参照）または将来のプロトコル３１２のすべてもしくは一部のインプリメンテーションを含み得、これにより、外部システムがそれらのプロトコルのうちのいずれか（または任意の組合せ）を使用してサービスプロキシとインターフェイス接続し得る。

サービスプロキシは、示されるアプリケーションと他の現在および潜在的な外部システムとの間の抽象化レイヤーとして機能することに加えて、セッション管理、キャッシング、バッチ要求のサポートおよびセキュリティ向上を提供するよう有効化され得る。抽象化レイヤー３０２によって提供されるファンクションの処理のいくつかの局面は、バックエンドシステムによる処理を伴い得る。たとえば、サーブレットコール３１４は、Ｊａｖａサーバにフォームサービス要求を開始させ得る（オペレーション３２０を参照）。または、たとえば、ＳＯＡＰコール３１６は、拡張可能ロジックにおける処理を開始し得る（オペレーション３２４_１およびオペレーション３２４_２を参照）。

図４Ａは、ネイティブモバイルアプリケーションの自動的な合成のための合成ツールを使用する際にオブジェクトモデルを特定するためのサンプルヒエラルキー４Ａ００を示す。オプションとして、ヒエラルキー４Ａ００またはその任意の局面の１つ以上のインスタンスは、本願明細書に記載される実施形態のアーキテクチャおよび機能の文脈において実現され得る。さらに、ヒエラルキー４Ａ００またはその任意の局面は、任意の所望の環境において実現され得る。

前述のように、特定されたアプリケーションについてのフォームのセットは（たとえば規約に基づいて）既知であり得る。さらに、フォームが既知である場合、フィールドは既知であり得る。フィールドのセットが与えられると、対応するオペレーションのセットが既知であり得、また、フィールドのセットが与えられると、バックエンドアプリケーションにフィールドデータを搬送するメッセージのセットおよびバックエンドアプリケーションからフィールドデータを搬送するメッセージのセットも既知であり得る。多くの場合において、モバイルアプリケーションによって扱われる必要があるのはいくつかのフィールドのみである（たとえばバックエンドアプリケーションによってサポートされる必要があるのはフィールドおよび／または対応するオペレーションのサブセットのみ）。

示されるように、オブジェクトモデルヒエラルキーは、アプリケーション（たとえば、アプリケーションセット４２０を参照）の１つ以上のインスタンスを含むよう組織化され得、当該アプリケーションは、複数のファンクション（ファンクションセット４３０を参照）を包含しており、当該ファンクションはフィールド（フィールドセット４４０を参照）を通じてユーザと相互作用しており、フィールドは、オペレーション（オペレーションセット４４５を参照）に対して一対一または一対多のリレーションシップを有し得る。任意のアプリケーションまたはファンクションまたはフィールドは、メッセージを発し得る（メッセージ４５０を参照）。他のヒエラルキーが可能であり、また、いくつかの組織は厳密に階層的ではない。

図４Ｂは、一実施形態に従った、ネイティブモバイルアプリケーションの自動的な合成のための合成ツールによって使用されるオブジェクトモデルから得られるフォームおよびメッセージを示す。フォームおよびメッセージは、フォームと、フォームフィールドと、フォームメタデータ４０２との間のマッピングリレーションシップを示す。示されたマッピングリレーションシップまたはその任意の局面は、任意の所望の環境において実現され得る。

（たとえばオブジェクトモデルから得られ得るような）マッピングリレーションシップ４Ｂ００は、フォームと、オペレーションの任意のインスタンスおよび／またはフォームメタデータ４０４_１〜４０４_５との間の任意数のリレーションシップ４０４を定義し得る。フォームメタデータは任意の公知の技術を使用（たとえばＸＭＬを使用、ＢＮＦを使用など）してコード化され得る。厳密に例示的な例として、フォームメタデータ４０４_１〜４０４_５は、それぞれのフォームコンポーネント（たとえばファンクション、オペレーション、フィールド、グリッド、ボタンなど）に対応するＸＭＬ要素から構成され得る。フォームメタデータは、フォームおよび／またはそのコンポーネントの構造および任意の他の局面を記述し得る。

示されるように、リレーションシップ４０４_１はＸＭＬ要素４１４_１にフォームをマッピングする。オペレーション４０６は、フィールドの任意数の関連付けられるインスタンスを有し得る。リレーションシップ４０４_３は、ＸＭＬ要素４１４_２にオペレーション４０６をマッピングする。ＸＭＬ要素４１４_２は、任意数のさまざまな属性（たとえばタイプなど）から構成され得る。リレーションシップ４０４_２は、ＸＭＬ要素４１４_３に、フィールドボックス４０８に与えられるフィールドをマッピングし得る。ＸＭＬ要素４１４_３は、任意数のさまざまな属性（たとえばｉｄ、ラベル、データタイプなど）を含み得る。リレーションシップ４０５_４は、ＸＭＬ属性４１６_１（たとえばラベルなど）にフィールドラベル４１０（たとえば都市など）をマッピングし得る。リレーションシップ４０４_４は、示されたＸＭＬフィールド要素４１４_４を使用して、ＸＭＬ属性４１６_２（たとえばデータタイプなど）にフィールド値４１２をマッピングし得る。

上記は単に１つの実現例であり、他の実施形態は、ＸＭＬフォーマットではなくＪＳＯＮフォーマットで直接的にマップを作成し得る。いくつかの場合において、リレーションシップ４０４は、オブジェクトモデル、データ構造またはハードコードされたマップを用いる、オペレーション４０６へのマップ／オペレーション４０６からのマップを含む。ランタイムプロセスは、（たとえばフォーム識別子または推論を介して）実行されているフォームを識別し、識別されたフォームにおいて使用されるコンポーネント（たとえば日付フィールド、ドロップダウン、グリッド行など）に基づいて、そのフォームのＪＳＯＮ表現を作り出す。

ＪＳＯＮ表現の使用についての一般的なアプローチに関するさらなる詳細は、「ＪＳＯＮメッセージからのルールベースの自動クラス生成（RULE-BASED AUTOMATIC CLASS GENERATION FROM A JSON MESSAGE）」という名称を有する米国出願第１４／１７９，５４８号（代理人管理番号ＯＲＡ１４０３６０−ＵＳ−ＮＰ）に記載されている。

図５は動作フロー５００を示しており、動作フロー５００は、アプリケーションオブジェクトモデルに基づいたネイティブモバイルアプリケーションの自動的な合成につながる。オプションとして、動作フロー５００またはその任意の局面の１つ以上のインスタンスは、本願明細書に記載される実施形態のアーキテクチャおよび機能の文脈において実現され得る。さらに、動作フロー５００またはその任意の局面は、所望の環境において実現され得る。

図５のフローにおいて、シンセサイザモジュール１１０は、バックエンドアプリケーションの識別性を与えられる（オペレーション５２０を参照）。アプリケーションは、オブジェクトモデルによって決定され得るフォームのセットを使用する（オペレーション５３０を参照）。前述のように、モバイルアプリケーションによって扱われる必要があるのは、いくつかのフィールドのみである。フィールドは、フィールド名によって明示的に特定され得るか、または、ファンクションが抽出されるアプリケーションの特定によって暗示的に表現され得るか、または、ファンクションのセットの特定によって暗示的に特定され得る（オペレーション５４０を参照）。いくつかの場合において、選択されたファンクションの選択および／または定義は、使用されるべきフィールドを（たとえば暗示的に）特定するよう機能する（オペレーション５５０を参照）。必要とされるフィールドおよび／またはファンクションが既知の場合、対応するメッセージのセットは既知であり得る。ここで、モバイルデバイスアプリケーションの構造は既知であり、コードは、ネイティブモバイルアプリケーションコードモジュールのリポジトリにマッピングされ得るとともに、ネイティブモバイルアプリケーションコードモジュールのリポジトリから選択される（オペレーション５６０を参照）。そのようなネイティブモバイルアプリケーションコードモジュールは、前述の技術を使用してアセンブルされ得（オペレーション５７０を参照）、モバイルアプリケーションコードモジュールコードと、生成されたコード（たとえば、クラスジェネレータから発せられたコード）および／または任意の他のコード（たとえば合成されたコード）とは、モバイルターミナル上で実行され得（たとえば、オペレーション５８０を参照）、テストが行なわれ得る（オペレーション５７０を参照）。

他のフローが可能である。たとえば、１つのフローは、シンセサイザのユーザがＵＩレイアウトを定義し、制御をデータコントローラに結合し、ページナビゲーションを定義すると開始する。別のフローは、シンセサイザのユーザが、データ制御クラスに基づいてデータ制御を自動生成すると始まり、その後、データ制御は自動的にデータ制御クラスと同期したままとなる。さらに別のフローは、アプリケーションがビジネスロジックを実行する必要がある属性および機能を使用するためのインターフェイス接続ルールをシンセサイザのユーザがコーディングすると始まる。インターフェイス接続ルールは、属性を格納し、かつ、対応するバックエンドアプリケーションをサービスプロキシを介して呼び出すために機能し、モバイルアプリケーションについて必要なビジネスロジックを実行する。

いくつかの場合において、シンセサイザのユーザのワークフローは、カスタマイズされたニーズに合致するようモバイルアプリケーションによって使用されている基礎をなすバックエンドアプリケーションを修正することを含む。

結果得られる生成されたモバイルアプリケーションは、たとえば、「顧客（customer）の「Ｃ」のサーチタイプによってアドレス帳をサーチする」ようユースケース（use case）が与えられるある範囲の使用モデルをサポートする。初期オペレーションは、ユーザアクション（たとえば、ユーザがＵＩテキストボックスに「Ｃ」を入力）に応答し得る。次のオペレーションは、デベロッパがデータ制御とＵＩのテキスト制御との間にセットした結合に基づいてデータ制御を通じてデータが渡されるシステム応答を含み得る。システム応答はさらに、データ制御モジュールがそのサーチ属性をセットするためにデータ制御オブジェクトのセッターを呼び出すオペレーションを含み得る。そのような応答は、データ制御とデータ制御クラスとの間のシステムが生成した結合に基づき得る。

別の状況において、生成されたモバイルアプリケーションは、ユーザがサーチボタンをクリックするユーザアクションの際に開始する使用モデルをサポートし、システムは、デベロッパが確立した結合に基づきデータ制御クラスのサーチメソッドを自動的に実行することによって応答する。たとえば、データ制御クラスは、パラメータ（サーチタイプ、トークン、呼び出しのためのＥｌフォームなど）をＪＳＯＮメッセージへロードし得、その後、ＪＳＯＮメッセージをシリアライズし、サービスプロキシに要求を行う。サービスプロキシは要求を監視するとともにＪＡＳサーバへ転送し、その後、ＪＡＳサーバはアプリケーションを実行または呼び出す。

別のフローは、それを用いて実行するよう与えられたパラメータに基づいてフォームおよびそのデータのＪＳＯＮデータ表現を作成し、その後、当該データをサービスプロキシに返す。サービスプロキシは、データをモバイルアプリケーションに戻し、その際、モバイルアプリケーションは、サポートする予め生成されたＪａｖａオブジェクトへとデータをデシリアライズする。サポートするＪＳＯＮ Ｊａｖａオブジェクトは、データ制御クラスを介してデータ制御に結合され、これにより、データコントローラが結合に基づいてＵＩ制御にデータを渡すことが可能になることを促進する。

開示の付加的な実施形態
付加的な実用適用例
図６は、いくつかの実施形態に従った、アプリケーションオブジェクトモデルに基づいたネイティブモバイルアプリケーションの自動的な合成のためのシステムのブロック図である。システム６００またはシステム６００における任意のオペレーションは任意の所望の環境において行なわれ得る。システム６００は、少なくとも１つのプロセッサおよび少なくとも１つのメモリを含んでおり、メモリは、システムのオペレーションに対応するプログラム命令を格納するよう機能する。示されるように、オペレーションは、モジュールによってアクセス可能なプログラム命令を使用して全体的または部分的に実現され得る。モジュールは通信パス６０５に接続され、任意のオペレーションは、通信パス６０５にわたって他のオペレーションと通信し得る。システムのモジュールは、個々にまたは組合せて、システム６００内でメソッドオペレーションを実行し得る。システム６００内で実行された任意のオペレーションは、請求の範囲において特定され得るのではなければ、任意の順番で行なわれ得る。図６の実施形態は、システム６００として示されるコンピュータシステムの部分を実現しており、システム６００は、プログラムコード指示のセットを実行するコンピュータプロセッサ（モジュール６１０を参照）と、プログラムコード指示を保持するようメモリにアクセスするためのモジュールとを含み、当該モジュールは、モバイルデバイス識別子と、アプリケーション識別子、オブジェクトモデルおよびフォーム識別子のうちの少なくとも１つを含むリストとを特定モジュールから受け取る（モジュール６２０を参照）ことと、モバイルデバイス上で実現するべき少なくとも１つのフォームを決定するために情報を分析し、かつ、モバイルデバイス上で実現するべきファンクションのセットを決定するためにフォームを分析する（モジュール６３０を参照）ことと、ファンクションのセットの少なくとも一部分に対応する少なくとも１つの選択されたネイティブアプリケーションコードモジュールをネイティブアプリケーションコードモジュールのリポジトリから抽出する（モジュール６４０を参照）ことと、特定に少なくとも部分的に基づいて、少なくとも選択されたネイティブアプリケーションコードモジュールを含むモバイルアプリケーションをアセンブルする（モジュール６５０を参照）こととを実行する。

システムアーキテクチャの概略
付加的なシステムアーキテクチャの例
図７は、本開示の実施形態を実現するのに好適なコンピュータシステム７００のインスタンスのブロック図を示す。コンピュータシステム７００は、サブシステムとデバイスとの間を相互接続する、情報を通信するためのバス７０６または他の通信メカニズムを含んでおり、当該デバイスの例としては、プロセッサ７０７と、システムメモリ（たとえばメインメモリ７０８またはランダムアクセスメモリＲＡＭのエリア）と、スタティックストレージデバイス（たとえばＲＯＭ７０９）と、ストレージデバイス７１０（たとえば磁気または光学）と、データインターフェイス７３３と、通信インターフェイス７１４（たとえばモデムまたはイーサネット（登録商標）カード）と、ディスプレイ７１１（たとえばＣＲＴまたはＬＣＤ）と、入力デバイス７１２（たとえばキーボード、カーソル制御）と、外部データリポジトリ７３１とがある。

本開示の一実施形態に従うと、コンピュータシステム７００は、システムメモリに含まれる１つ以上の指示の１つ以上のシーケンスをプロセッサ７０７が実行することにより、特定のオペレーションを実行する。そのような指示は、スタティックストレージデバイスまたはディスクドライブといった別のコンピュータ読取可能／使用可能媒体からシステムメモリに読み出され得る。代替的な実施形態において、本開示を実現するソフトウェア命令の代わりにおよび当該ソフトウェア命令と組合せて、ハードワイヤード回路が使用されてもよい。したがって、本開示の実施形態は、ハードウェア回路および／またはソフトウェアの任意の特定の組合せに限定されない。一実施形態において、「ロジック」という用語は、開示のすべてまたは部分を実現するために使用されるソフトウェアまたはハードウェアの任意の組合せを意味する。

本願明細書において使用されるような「コンピュータ読取可能媒体」または「コンピュータ使用可能媒体」という用語は、実行のためにプロセッサ７０７に指示を提供することを担う任意の媒体を指す。そのような媒体は、多くの形態を取り得、当該形態は不揮発性媒体および揮発性媒体を含むがこれらに限定されない。不揮発性媒体はたとえば、ディスクドライブまたはテープドライブのような光学または磁気ディスクを含む。揮発性媒体は、ＲＡＭメモリのようなダイナミックメモリを含む。

コンピュータ読取可能媒体の一般的な形態はたとえば、フロッピーディスク（登録商標）、フレキシブルディスク、ハードディスク、磁気テープもしくは任意の他の磁気媒体か、ＣＤ−ＲＯＭもしくは任意の他の光学媒体か、穴のパターンを有するパンチカード、紙テープもしくは任意の他の物理的な媒体か、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭもしくは任意の他のメモリチップもしくはカートリッジか、または、コンピュータがデータを読み出すことができる任意の他の一時的でない媒体を含む。

本開示の実施形態において、本開示を実施する指示のシーケンスの実行は、コンピュータシステム７００の単一のインスタンスによって実行される。本開示のある実施形態に従うと、通信リンク７１５（たとえばＬＡＮ、ＰＴＳＮまたは無線ネットワーク）によって結合されるコンピュータシステム７００の２つ以上のインスタンスは、互いに協働して本開示を実施するために必要とされる指示のシーケンスを実行し得る。

コンピュータシステム７００は、メッセージと、データと、プログラム（たとえばアプリケーションコード）を含む指示とを、通信リンク７１５および通信インターフェイス７１４を通じて送信および受信し得る。受け取られたプログラムコードは、受信された際にプロセッサ７０７によって実行され得るか、および／または、その後の実行のためにストレージデバイス７１０または任意の他の不揮発性ストレージに格納される。コンピュータシステム７００は、外部データリポジトリ７３１上のデータベース７３２にデータインターフェイス７３３を通じて通信し得る。データベース７３２におけるデータ項目は、プライマリキー（たとえばリレーショナルデータベースのプライマリキー）を使用してアクセスされ得る。本願明細書において使用されるようなモジュールは、システムメモリの任意の部分と、プロセッサ７０７として具現化されたハードワイヤード回路を含むハードワイヤード回路の任意の範囲との任意の混合を使用して実現され得る。

前述の明細書において、本開示はその特定の実施形態を参照して記載されている。しかしながら、本開示のより広い精神および範囲から逸脱することがなければ、さまざまな修正および変更が行なわれてもよいということが明白であろう。たとえば、上記のプロセスフローは、プロセスアクションの特定の順序を参照して記載されている。しかしながら、記載されたプロセスアクションの多くの順序は、開示の範囲または動作に影響を与えることがなければ変更されてもよい。したがって、明細書および図面は、限定的な態様ではなく例示的な態様であるとみなされるべきである。

Claims (14)

1. フィールドのセットを有する既存のフォームを少なくとも介してユーザと遣り取りする既存のアプリケーションを識別することと、
   新しいフォームとしてモバイルデバイス上で前記既存のフォームの少なくとも一部分を実現するように適合されるモバイルアプリケーションを生成することとを含み、前記モバイルアプリケーションは、前記既存のフォームの前記フィールドのセットのすべてまたはサブセットを扱うように適合されており、
   モバイルデバイスタイプ識別子と、アプリケーション識別子またはフォーム識別子のうちの少なくとも１つを含む情報とを受け取ることと、
   前記アプリケーション識別子または前記フォーム識別子のうちの少なくとも１つを分析して、前記モバイルデバイス上で実現するべき前記既存のフォームを決定することと、
   前記既存のフォームを分析して、前記モバイルデバイス上で実現するべきファンクションのセットを決定することとを含み、前記ファンクションのセットは、既存のアプリケーションシステムが実行する１つ以上のオペレーションに対応するものであり、前記既存のアプリケーションシステムは、前記既存のアプリケーションを含み、
   ネイティブアプリケーションコードモジュールのリポジトリから、前記ファンクションのセットの少なくとも一部分に対応する複数の選択されたネイティブアプリケーションコードモジュールを抽出することを含み、前記複数の選択されたネイティブアプリケーションコードモジュールは、前記モバイルデバイス上でブラウザに依拠することなく実行可能であり、
   前記モバイルアプリケーションを生成するために、少なくとも前記既存のフォームと、前記複数の選択されたネイティブアプリケーションコードモジュールのうちの少なくともいくつかとをアセンブルすることを含む、方法。
2. 前記複数の選択されたネイティブアプリケーションコードモジュールは、作成オペレーション、置換オペレーション、更新オペレーションおよび削除オペレーションのうちの少なくとも１つを開始するよう機能する、請求項１に記載の方法。
3. 前記モバイルデバイスタイプ識別子に対応するモバイルデバイス上に前記モバイルアプリケーションを展開することをさらに含む、請求項１に記載の方法。
4. 前記モバイルアプリケーションは、ＪＳＯＮメッセージをＪａｖａオブジェクトにデシリアライズするためのＪａｖａクラスをさらに含む、請求項１に記載の方法。
5. 前記複数の選択されたネイティブアプリケーションコードモジュールの少なくとも１つは、要求メッセージを形成することを実現する、請求項１に記載の方法。
6. 前記要求メッセージは、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ：simple object access protocol）要求またはリプリゼンテーショナルステイトトランスファ抽象化（ＲＥＳＴ：Representational State Transfer）要求を含む、請求項５に記載の方法。
7. 前記要求メッセージはパスワードまたは画像キャプチャファイルを含む、請求項５に記載の方法。
8. 前記モバイルデバイスタイプ識別子に対応する前記モバイルデバイス上に前記モバイルアプリケーションを展開することをさらに含み、
   前記複数の選択されたネイティブアプリケーションコードモジュールの少なくとも１つが、作成オペレーション、置換オペレーション、更新オペレーションおよび削除オペレーションのうちの少なくとも１つを開始するよう機能しており、
   前記複数の選択されたネイティブアプリケーションコードモジュールの少なくとも１つは、要求メッセージを形成することを実現し、前記要求メッセージは、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ：simple object access protocol）要求、リプリゼンテーショナルステイトトランスファ抽象化（ＲＥＳＴ：Representational State Transfer）要求、パスワード、または、画像キャプチャファイルのうちの少なくとも１つを含む、請求項１に記載の方法。
9. 前記既存のアプリケーションは、デスクトップ環境として機能するバックエンドアプリケーションと実質的に同じである、請求項１〜８のいずれか１項に記載の方法。
10. 前記既存のアプリケーションシステムは、ファンクションのあるセットのみを公開することにより抽象化レイヤーとして機能するサービスプロキシをさらに含む、請求項１〜９のいずれか１項に記載の方法。
11. プロセスを実行するよう指示のシーケンスを格納するコンピュータ読取可能媒体において具現化されたコンピュータプログラムプロダクトとして実現される、請求項１〜１０のいずれか１項に記載の方法。
12. フィールドのセットを有する既存のフォームを少なくとも介してユーザと遣り取りする既存のアプリケーションを識別する特定モジュールと、
    新しいフォームとしてモバイルデバイス上で前記既存のフォームの少なくとも一部分を実現するように適合されるモバイルアプリケーションを生成するアプリケーションシステムとを備え、前記モバイルアプリケーションは、前記既存のフォームの前記フィールドのセットのすべてまたはサブセットを扱うように適合されており、
    モバイルデバイスタイプ識別子と、アプリケーション識別子またはフォーム識別子のうちの少なくとも１つを含む情報とを受け取るシンセサイザモジュールと、
    パーサーモジュールとを備え、前記パーサーモジュールは、
    前記アプリケーション識別子または前記フォーム識別子のうちの少なくとも１つを分析して、前記モバイルデバイス上で実現するべき前記既存のフォームを決定し、かつ、前記既存のフォームを分析して、前記モバイルデバイス上で実現すべきファンクションのセットを決定しており、前記ファンクションのセットは、既存のアプリケーションシステムが実行する１つ以上のオペレーションに対応するものであり、前記既存のアプリケーションシステムは、前記既存のアプリケーションを含み、
    ネイティブアプリケーションコードモジュールのリポジトリから、前記ファンクションのセットの少なくとも一部分に対応する複数の選択されたネイティブアプリケーションコードモジュールを抽出するクエリージェネレータを備え、前記複数の選択されたネイティブアプリケーションコードモジュールは、前記モバイルデバイス上でブラウザに依拠することなく実行可能であり、
    前記モバイルアプリケーションを生成するために、少なくとも前記既存のフォームと、前記複数の選択されたネイティブアプリケーションコードモジュールのうちの少なくともいくつかとをアセンブルするコード統合モジュールとを含む、システム。
13. 選択された前記ネイティブアプリケーションコードモジュールは、作成オペレーション、置換オペレーション、更新オペレーションおよび削除オペレーションのうちの少なくとも１つを開始するよう機能する、請求項１２に記載のシステム。
14. 前記モバイルデバイスタイプ識別子に対応するモバイルデバイス上に前記モバイルアプリケーションを展開することをさらに含む、請求項１２に記載のシステム。

Images