JP2023553535A - ユーザインタフェースアプリケーションを開発するためのシステム及び方法 - Google Patents

Abstract

ユーザインタフェースアプリケーションを設計するためのコンピュータ実装方法は、視覚的フロー言語及びモデルビューフローアーキテクチャを用いる。視覚的フロー言語はコンポーネントを含み得るのであり、コンポーネントはブロック及びノードを含む。コールストリーム及びデータフローは、ユーザによって定義され得る。アプリケーションフロー論理グラフが生成される。アプリケーションフロー論理グラフは、ユーザインタフェースアプリケーションを生成するために用いられ得る。

Description

本開示は、エンタープライズアプリケーション用のユーザインタフェースを構築することに一般的に関連する。より具体的には、本発明は、ユーザインタフェースアプリケーションを設計及び実装するためのアーキテクチャ及び視覚的フロー言語に向けられている。

企業のデータ、ユーザインタフェース（ＵＩ）、及びインテグレーションを用いてセキュア且つスケール可能なフロントエンドアプリを構築するために、エンタープライズアプリケーション用のＵＩ設計に関してはコーディングについての知識が従来的には必要とされていた。モデルビューコントローラ（ＭＶＣ、model-view-controller）、モデルビュープレゼンタ（ＭＶＰ、model-view-presenter）及びモデルビュービューモデル（ＭＶＭＭ、model view viewModel）等の従来型ツールは、重大な制約を伴っている。

本開示の実施形態は、上述の課題を前提にして開発された。

本開示は、ユーザインタフェースアプリケーションを設計及び展開するためのシステム及び方法に関する。１つの実施形態では、視覚的フロー言語を用いてアプリケーションを設計するための設計スタジオが提供される。視覚的フロー言語には複数の異なるコンポーネントタイプが含まれ、各コンポーネントは少なくとも１つのブロックを有するのであり、ブロックは少なくとも１つのノードを含む。ユーザは、ノード間でコールストリーム接続及びデータマッピングを形成できる。各コンポーネントは、自己の対応するモデルをカプセル化できる。ユーザ選択に基づいてアプリケーション論理フローグラフを生成して、ユーザインタフェースアプリケーションを定義できる。

もっとも、列挙された特徴及び利点は全てを網羅しておらず、多くの追加の特徴及び利点が想定され、本開示の範囲に包括されることに留意されたい。さらに、本開示で使用される文言は、主として可読性および教示目的のために選定されたものであり、本明細書に開示される主題の範囲を限定するためのものではないことに留意されたい。

同様の参照符合が同様の要素を指すために用いられる添付の図面中の図において、本開示は限定のためではなく例を伴って例示される。

実施形態による、ユーザインタフェースアプリケーションを開発するためのシステムについて示すブロック図である。 実施形態による、ＵＩ設計スタジオ内の機能の例について示すブロック図である。 実施形態による、ユーザアプリケーションアーキテクチャ層について示すブロック図である。 実施形態による、ドッカーイメージを用いる展開戦略の例について示す図である。 実施形態による、サーバを基盤とする実装例について示す図である。 実施形態による、モデルビューフロー（ＭＶＦ、Model View Flow）アーキテクチャについて示すブロック図である。 実施形態による、アプリケーション論理グラフについて示す図である。 実施形態による、コンポーネントタイプの例について示す図である。 図５Ａ及び図５Ｂは、実施形態による、ブロック及びノードを伴うコンポーネントの例について示す図である。 実施形態による、ブロックタイプの例について示す図である。 実施形態による、ノードタイプの視覚化の例について示す図である。 実施形態による、フローの例及びコンポーネント間のフローを強調する例について示す図である。 実施形態による、コンポーネント間のフローの例について示す図である。 図９Ａ及び図９Ｂは、実施形態による、姉妹インタフェース構築について示す図である。 図１０Ａ及び図１０Ｂは、実施形態による、親インタフェース構築について示す図である。 図１１Ａは、実施形態による、ＵＩフロー設計スタジオの主要セクションの例について示す図である。図１１Ｂは、実施形態による、ＵＩ、フローパネル内のＵＩフロー、カタログパネル、及びインスペクタパネルについてのプレビューを示す例についての図である。図１１Ｃは、ＵＩフロー設計の例について示す図である。図１１Ｄは、カタログパネルの例について示す図である。図１１Ｅは、インスペクタパネルの例について示す図である。 実施形態による、カスタムコードコンポーネントの生成について示す図である。 実施形態による方法についての流れ図である。 実施形態による方法についての流れ図である。 実施形態による別の例示的方法についての流れ図である。

アーキテクチャの概要
ソフトウェアをコードすることを要さずにしてユーザインタフェースアプリケーションを設計するシステム及び方法が開示される。これにはモデルビューフロー（ＭＶＦ、Model View Flow）アーキテクチャを含み、これにはソフトウェアアプリケーションを開発するための視覚的フロー言語（ＶＦＬ（Visual Flow Language）又はFlowlang）が含まれる。FlowlangとはＭＶＦ上に構築された視覚的言語（ビジュアル言語）であり、コードのない態様でアプリケーション構築者（ユーザ）がアプリケーションを構築することを可能とするものである。ＭＶＦアーキテクチャを伴ってアプリケーションを構築することに関して、視覚的言語の使用は絶対的要件とはされない。伝統的（テキストコード的）な態様でアプリケーションを構築することも可能である。もっとも、Flowlangによればアプリケーション構築は容易となる。

ＭＶＦは、アプリケーション論理及びアプリケーション状態をＵＩストリームを通じてモデリングするのであり、該ＵＩストリームはコンポーネントからのイベントを起源とし（originate）、１つ以上の他のコンポーネントのメソッドをコールすることによって完了する（complete）。ＭＶＦでは、メソッドパラメータは、他のステートフルコンポーネントへのデータマッピングを介して取得される。ＭＶＦの特徴としては、データマッピングが複雑なアプリケーションフローを支援するということが挙げられる。これによって利点がもたらされるのであり、例えば、ソフトウェア設計パターンがチューリング完全となることが許容され、また、論理の完全な非線形実行が許容されるのであってこれは現代的なプログラミング言語のようである。ＭＶＦアプリケーションは視覚的に作成されることができるも、より一般的にはコードにてテキスト的に作成されることもできる。

図１Ａの例を参照するに、ＵＩ設計スタジオ１０２は、ユーザインタフェースアプリケーションの設計のための視覚的フロー言語（Flowlang）を支援する。ＵＩ設計スタジオ１０２は、例えば、コンピューティング装置又はサーバ上にて実装されていることができる。展開サポートアーキテクチャ２０２を色々な態様で実装して、ＵＩ設計スタジオ１０２の出力を用いて、ＵＩ設計の展開をサポートできる。展開サポートアーキテクチャ２０２は、アプリ定義及びアプリアセット等のＵＩアーチファクトを含み得る。それには、ＵＩ設計の展開を支援するためのＵＩサーバが含まれ得る。ユーザアプリケーション層３０２は、ブラウザ内にフロントエンドＵＩアプリを有しているものとして示されている。

１つの実施形態には、視覚的フロー言語を用いるアプリケーションフローグラフ設計段階がある。１つの実施形態では、設計段階（design phase）において、ユーザは、カタログからコンポーネントを選択でき、コンポーネントを所望位置へとドラッグアンドドロップでき、また、例えばコールストリーム接続若しくはデータマッピング接続等を用いてコンポーネントのノード間で接続を形成できる。コンポーネントの特徴又は特性を構成／カスタマイズするためのステップを行い得る。構築段階（build phase）では、アプリケーション定義ファイルを生成でき、ＵＩアプリケーションを構築するために用いられ得る。もっとも、エンドユーザからすれば、コードを書かずに視覚的フロー言語を用いてＵＩアプリケーションを設計することができる。アプリケーションフローグラフを自動的に動かすことと(walk)、論理グラフを生成することと、最終ＵＩアプリケーションを構築するための他のステップを実行することと、のための他のソフトウェア（例えば、フローエンジン）がＭＶＦアーキテクチャに含まれている。

図１Ｂは、ＵＩ設計スタジオ１０２の例について例示している。ビューモデルを生成するために統合設計環境（ＩＤＥ）内にてパネルが支援され得る。パネルには、テーマパネル、ツリーパネル、ビューパネル、フローパネル、インスペクタパネル、及びコンポーネントカタログパネルが含まれ得る。Flowlangは、統合開発環境（ＩＤＥ）の上に築かれたオーサリングツール（編集支援ツール）である。ＵＩ設計スタジオアプリケーションは、一部の実装形態では、ビジュアルスタジオ（ＶＳ）コードプラグインモジュールを含み得る。

コンポーネントパネルは、様々な異なるコンポーネントタイプからコンポーネントを選択することに関してユーザを支援する。例えば、ドラッグアンドドロップ機能は、コンポーネントを選択することと、アプリケーションフローパネル上の所望位置へとドラッグすることとを支援されることができる。アプリケーションツリーが設計過程（design process）で構築（built up）される際に、ＵＩツリーパネルは現在のコンポーネントについてのリスト及び他の属性等の事柄を要約し得る。スタイル及びテーマを構成するためのパネルを提供することができる。例えば、ＵＩの視覚的外観への様々な調整を支援でき、加えて特定のエンド顧客に固有のスタイル（企業に固有な色彩スキーム等）をも支援できる。アプリケーションフローパネルを含めて視覚的フロー言語を用いてのアプリケーションフローグラフの設計をなし得る。ＵＩアプリのプレビューの表示を許可するＵＩプレビューパネルが含まれ得る。

アプリフロー論理は、コンポーネント間で視覚的に構成され得る。これによって、アプリ開発者は真に一意的でカスタマイズされたコンポーネント及びアプリケーションを作成でき、その一方で標準的なコンポーネントを用いて単に迅速にアプリを作成したいだけのアプリ開発者も支援できる。また、これによって、他の職域の者（例えば、プロダクトマネージャ、デザイナ、及び品質保証（ＱＡ）等）が、コードの書き方を知らずともアプリケーションフローについて理解、変更、及び構築をすることを可能とする。

一部の実装例では、視覚的フロー言語を用いて生成されたアプリケーションフローグラフは、アプリケーション定義ファイル（或いは同様の情報）を生成するために用いられて、クラウド又はエンタープライズ実装等の展開サポートアーキテクチャがＵＩアプリのブラウザ内への展開を支援できる。例えば、ＵＩアプリケーションをフローパネル内にて視覚的に設計することは、アプリケーションをコンパイルするため並びにクライアント（即ち、ブラウザ又はモバイルアプリ）内にてアプリケーション論理を実行するために用いられるアプリケーション論理グラフを生成するために用いられ得る。アプリケーション論理グラフを記述するファイルは、例えば、展開サポート層へと渡されたり、或いはアプリケーション定義ファイルを生成するために用いられたりできる。

図１Ｃは、ユーザアプリケーション層３０２の例について示す。ビューモデルは、フローエンジン、アプリ状態モジュール、アプリ構築モデル、及びレイアウトエンジンをサポートする。もっとも、実装詳細事項に応じての実装例もあり得る。

最終ＵＩアプリの展開は、クラウド経由等の様々な態様で実装され得る。ＵＩフローのクラウドを基盤とする実装には、例えば商用クラウドサービス（例えば、Amazon Web Services （登録商標）(AWS)）を用いることを含むことができ、また、関係データベースサービス（ＲＤＳ）、live EB Web server（登録商標）、.com EB Web server（登録商標）、及びApp Compiler EB worker（登録商標）等のクラウド支援機能も含まれ得る。１つの実装例では、S3 cloud storage（登録商標）がアプリケーション定義（App Def）及びアプリケーション静的アセット（App Static Assets）を格納することができる。

図１Ｄは、展開戦略についての別の例について示す。展開サポート層は、エンタープライズネットワークを介して又はクラウド内にて実装され得る。一部の実装例では、ドッカーイメージを用い得るのであり、ドッカー(docker)とはアプリケーションについてコンテナを作成するためのオープンなプラットフォームである。

図１Ｅは、実装例のいくつかの態様が、サーバの非一時的メモリ内に格納されたコンピュータプログラム命令としてどのように実装され得るかについて示す。換言するに、原理的には、企業体はＭＶＦ及びFlowlangを、サーバを基盤とするシステムにて実装できる。

ＭＶＦ高水準記述
図２は、フローエンジン２０５とコンポーネントの例について示しており、コンポーネントには、データコンポーネント２１０、ＵＩコンポーネント２１８、フローについて指図する論理コンポーネント（図２では不図示）、データについて変換をなす変換コンポーネント（図２では不図示）等の様々なタイプが含まれ得る。ＭＶＦアーキテクチャでは、各コンポーネントは自己のモデルをカプセル化している。例えば、データコンポーネント２１０は自己のモデル２１２をカプセル化しており、また、ＵＩコンポーネント２１８は自己のモデル２１４をカプセル化している。

ＵＩコンポーネントは、ユーザ生成イベント（例えば、ボタンのクリック、入力変更等）及びモデルイベント（例えば、ボタンの種別変更等）を送出する。データコンポーネントは、モデル変更イベント（例えば、要求―応答の戻り、ウェブソケット(WebSocket)のプッシュ通知等）を送出する。

ＵＩコンポーネントはアプリケーションのＵＩツリーを構成するのであり、また、これらは視覚的である。ＵＩコンポーネントはメソッドを有するのであり、イベントを発動させることができる。ＵＩコンポーネントは、状態情報を格納することもできる。

論理コンポーネントは、ＵＩと他のコンポーネントとの間の「接着剤」である。これらは入力を取ってそれらを出力に変換する。またこれらはコールストリームを取ってストリームを分割する、又はストリームのルーティングのための論理を組み込む（論理スイッチ等に似ている）。

１つの実装例では、フローエンジンはこれらのイベントについて監視するのであり、論理コンポーネントを通って論理グラフを辿るのであり、また、他のＵＩコンポーネント又はデータコンポーネントに対してアクションをコールする。

１つの実装例では、ＭＶＦはアプリケーション論理層全体を有向グラフとしてモデリングするのであり、また、コンポーネントは自己がカプセル化する自己の各々のモデルについて担当する。アプリケーションソフトウェアについて述べるに、フロー構造は、アプリケーションがどのように機能するかを制御するためにアプリケーション論理グラフを辿るフローエンジンとして、実装される。

図３は、一般的なアプリケーション論理グラフについて示す。アプリケーション論理は、２種類の異なるエッジ（即ち、コール線及びデータ線）を有する有向グラフとして表される。システム内にてイベントが検出された場合、新たなストリームが開始されるのであり、また、フローエンジンはイベントの始点となったコンポーネントを起点に論理グラフを辿り始める。図３では、コール線は破線として示されており、また、データマッピング線は実線で示されている。

図４は、ＭＶＦアプリケーションの４つのコンポーネントタイプについて示す：即ち、ＵＩコンポーネントタイプ、データコンポーネントタイプ、論理コンポーネントタイプ、及び変換コンポーネントタイプ。全てのコールストリームは、ＵＩコンポーネント又はデータコンポーネントで始まり、また、ＵＩコンポーネント又はデータコンポーネントのアクションで終わる。論理コンポーネントは、フローに指図するために用いられる。論理コンポーネントは、ＵＩコンポーネントを「接着」するために用いられる。論理コンポーネントには、変換、ブランチ、及びデバッグする（プログラムミスを除去する）ことが含まれる。変換コンポーネントは、入力パラメータについて要求されるデータを他の変換コンポーネントへと、又は、入力パラメータをＵＩコンポーネント若しくはデータコンポーネントについてのアクションへと、変換するために用いられる。個別のコンポーネントは、１つ以上のデータマッピングを入力として、並びに、１つ以上のコールストリームを出力として、有し得ることに留意されたい。

コンポーネントには、統合コンポーネントも含まれ得る。ＵＩコンポーネントは、アプリケーションの視覚的態様を構成する。統合コンポーネントは、他のサービス（例えば、Stripe（登録商標）、Twilio（登録商標）、Salesforce（登録商標）、AWS（登録商標）等）からのデータにアクセスするrest又はベンダー固有のコンポーネントを含み得る。統合コンポーネントは、アプリ外のシステムに接続するために用いられる。例としては、Restfulコンポーネント、Salesforce（登録商標）若しくはAWS（登録商標）を表す第三者製統合コンポーネント、又はウェブソケットコンポーネントが挙げられる。１つの実装例では、統合コンポーネントはメソッドを有しており、イベントを発動させることができる。これらは状態を保持はしない

１つの実装例では、ＵＩコンポーネントは、任意の個数の他のコンポーネントタイプ又は基本（プリミティブ）コンポーネントを含み得る。基本コンポーネントは、他のＵＩコンポーネントを含むことができないＵＩコンポーネントである（例えば、テキスト、テキスト入力、又はアイコン）。特定のブロックタイプについては、ノードが構成可能とされ得る。データアダプタは、オブジェクト及びアレイを構築及び抽出する変換ブロックを組み合わせることによって視覚的に作成される。

コンポーネント、コンポーネント内のブロック、及びブロック内のノードについて階層をもたらし得る。コンポーネントの例としては、ＵＩコンポーネント、データコンポーネント、論理コンポーネント、及び変換コンポーネントが含まれる。

図５Ａは２つのコンポーネントの初期選択を示し、図５Ｂは２つのコンポーネントのノード間の接続を形成する様相を示す。図５Ａ及び５Ｂに示されるように、コンポーネントは設計スタジオにて選択され得る。個別のコンポーネントは、１つ以上のブロックを有し得る。一部の例では、ブロックは構成可能である。一部の実装例では、マウス操作（例えば、ドラッグ、ドロップ、マウスクリック／マウスアップ等）は、コンポーネントを移動させるために、コンポーネントを挿入するために、コンポーネントを構成するために、及びコンポーネント間のコールストリーム又はデータマッピング接続を形成するために用いられ得る。即ち、個別のコンポーネントは１つ以上のブロックを含み得るのであり、ブロックはノードを有するのであってこれらはコールストリーム又はデータマッピングによって他のノードと結合されている。個別のコンポーネントは、コンポーネントのタイプに応じて自己の構成に関しての選択肢をもたらし得る。

図６は、ブロックタイプについてのいくつかの例を示しており、これらはアクションブロック、非同期（async）コールバックを伴うアクションブロック、ゲッターブロック、入力パラメータを要するゲッターブロック、及びプレイバックを伴うイベントブロックに対応する。

図７は、ノードタイプ視覚的取り扱いの例を示しており、これらは非接続コール入力ノード、非接続データ入力ノード、接続コール入力ノード、接続データ入力ノード、非接続コール出力ノード、非接続コール出力ノード、及び接続データ出力ノードを表す。

１つの実装例では、コンポーネントの実行時作成は２つの主たる態様で管理されている。第１に、クラス／インスタンスによる管理が挙げられる。コンポーネントは、インスタンス又はクラスのどちらかに転換されることができる。コンポーネントがクラスモードにある場合、コンストラクタアクションが利用可能であり、また、コールストリームをアクションに接続してクラスのインスタンスを作成できる。コンポーネントがコレクションモード（collections mode）にある場合、ユーザはコレクションコンポーネント（collection components）を用いることができるのであってこれらはコンポーネントのコレクション（collections of components）を管理するためのメソッドを有している。クラス／インスタンスの使用は、実行時コンポーネント作成に関して優秀な助けとなる。アプリ開発者は、実行時にユーザ挙動に基づいて１つ以上のコンポーネントを動的にインスタンス化するための手法を必要としている。例を挙げるに、ＵＩコンポーネントをクラスとして設定でき、クラスの「constructor()」メソッドをコールすることによって実行時にインスタンスを作成するために用いることができる。これによって、アプリ開発者がエディタ内にてコンポーネントをインスタンスとして構成し、そしてそれをクラスにトグル処理してコンポーネントが実行時にインスタンス化できるようにすることが可能となる。

１つの実装例では、アプリケーションがプレビューパネル内又は飛び出した(popped-out)ウィンドウ内のいずれかにて実行される場合、フローパネル視覚言語（flow panel visual language）は実行されているフローを強調してどの論理が実行されているかをユーザが見られるようにしている。また、ユーザは、各コンポーネントについてのデータ値を、有効値(live value)インスペクタを介して監視できる。

図８Ａは、コンポーネントの例について示すのであり、フローパネル言語（flow panel language）は実行されているフローを強調している。この例では、複数のＵＩコンポーネントと、複数の論理コンポーネントと、複数のデータコンポーネントとがある。図８Ａにおけるいくつかのフローについて検討を以下示す。

１．ユーザは「ボタン」コンポーネントをクリックしてデータを保存する。コールストリームが作成される；

２．コールストリームは「If Else」コンポーネントをコールする。このコンポーネントは、入力として条件を必要とする。コンポーネントは、「チェックボックス(Checkbox)」コンポーネント上の「isChecked」データアクセサ（data accessor）から真／偽値を取得する；

３．この例では、「チェックボックス」コンポーネントがチェックされて、条件が真であるコールストリームが実行され、「要求(Request)」コンポーネントがコールされてデータの保存がなされる；

４．「要求」コンポーネントは、パラメータとして値が保存されることを必要とする。パラメータの値は、「切り捨て(Truncate)」コンポーネントによって提供される；

５．切り捨て（truncate）コンポーネントは、入力を受け付けて、値に対して切り捨てを行う。入力パラメータは「str」であり、これはテキスト入力コンポーネントの値から取得される。

図８Ｂは、視覚的に提示されるフローについての単純な例について示す。この例では、４つのＵＩコンポーネント及び１つの論理コンポーネントがある。この例でのフローについての説明を次に提供する。コンポーネントＡにてイベントが発生し、これが論理コンポーネントＣの入力ノードによって受信される。この例では、論理コンポーネントＣは分割器（スプリッタ）であり、ＵＩストリームを２つのストリーム（ＵＩコールストリーム２及びＵＩコールストリーム４）に分割する。第１のＵＩコールストリーム２（UI call stream 2）はＵＩコンポーネントＤ内へと流入する。この例では、ＵＩストリーム２（UI stream 2）は、ＵＩコンポーネントＢからデータマッピング３を介して取得される値を伴うパラメータを必要とする。この例では、論理コンポーネントＣの分割器はコール実行を再開するのであり、また、ＵＩコールストリーム４（UI call stream 4）がＵＩコンポーネントＥ内へと流入する。この例では、コールストリーム４（call stream 4）からのメソッドコールは、コンポーネントＢの状態からのデータマッピングによって取得される値を伴うパラメータを必要とする。

理論上では、この例示的フローはコードをもってテキスト的に表現できよう。もっとも、単純な例であったとしても簡単に多数の関係を伴う複数行のコードがもたらされてしまうのであり、プログラマがこれについて正確にコーディング及びデバッグを行わなければならない。その結果、ＵＩを迅速且つ容易に設計及びデバッグすることが困難となる。

Flowlangでフローを作成する例示的方法について以下説明する。フローを作成する方法は、第１に、特定のコンポーネントから新たなフローを発動させることとなるイベントを識別することを含み得る。第２に、イベントノードから論理コンポーネントのコールノードへの（左から右への）接続を作成できるのであり、ＵＩ又はデータコンポーネントに行きあたるまで反復される。これらが下流接続である。第３に、ＵＩ又はデータコンポーネントが入力パラメータを必要とする場合、ユーザは入力パラメータを変換コンポーネントに（右から左へと）接続して、ＵＩコンポーネント又はデータコンポーネントに接続するまで反復される。これらが上流接続である。

１つの例では、インタフェース作成は、異なる方法で支援され得る。ユーザは、コールを発動する又は入れ子(nested)コンポーネント内のコンポーネントへパラメータ用の値を送る方法を必要としている。一部の例では、ユーザは１つ以上のノードを境界ボックス外へと単にドラッグして、コール及びデータマッピングノードを収容側コンポーネントへ露出させる１つ以上のインタフェースを作成する。入力又は出力インタフェースの作成は、ユーザが入力ノードをドラッグするか（入力インタフェースを作成する場合）、或いは、ユーザが出力ノードをドラッグするか（出力インタフェースを作成する場合）による。既存のインタフェースの削除は可能である。既存のインタフェースの再度の並べ替えは可能である。一部の例では、ユーザは複数のインタフェースを作成できるのであり、宛先コンポーネント（destination component）を指定することによってこれをなせるのであり、これによってソース及び対象コンポーネント（target components）の間のインタフェースを作成することとなる。各レベルでは、１つのノードに対して１つのインタフェースのみが存在する。

図９Ａ及び９Ｂは、姉妹インタフェースの構築について示す。図９Ａは、エッジをコンポーネントＡからコンポーネントＢへとドラッグすることを示す。図９Ｂは、コンポーネントＢ上でインタフェースを作成するためのマウスアップについて示す。換言するに、単純なマウス操作を用いて姉妹インタフェースを作成できる。

図１０Ａ及び１０Ｂは、親インタフェースの構築について示す。図１０Ａでは、ユーザは親コンポーネント境界の外へとエッジをドラッグする。図１０Ｂでは、親コンポーネント上にインタフェースを形成するためにマウスアップが用いられる。

図１１Ａは、UIflowスタジオの例について示す。これには、ヘッダ＆ナビゲーション部分、プレビューパネル、フローパネル、インスペクタパネル、コンポーネントカタログ＆層パネル、及びコンテキストブレッドクラムが含まれ得る。図１１Ｂは、ユーザインタフェース（上部中央）、フローパネル（下部中央）、インスペクタパネル（右端）、及びコンポーネントカタログ（左端）のプレビューを示すスクリーンショットを示す。図１１Ｃはフローパネルについてさらなる詳細を示すのであり、多くのコンポーネントとコンポーネント間の接続を伴った複雑なフロー図が示されている。図１１Ｄは、ユーザによって選択され得るコンポーネントのセットについての例を有するコンポーネントカタログの例を示す。コンポーネントカタログは、例えば、アバターバッジ、ボタンチャート、チップ、コンテナ、ダイアログ、アイコン、イメージ、フォーム、線形進捗(linear progress)、リンク、進捗スピナー、セレクト、タブパネル、テキスト、テキスト入力等に関するＵＩコンポーネントを含み得る。論理コンポーネントには、例えば、変換、オブジェクト作成、値を取得、文字列テンプレート、ブランチ、分割（スプリッタ）、スイッチ等が含まれ得る。他のコンポーネントとしてはデバッグ及びコンソールが含まれ得る。統合コンポーネントも含まれ得るのであり、一般的なRestコンポーネント又は、Stripe、Twilio、Salesforce、AWS等のベンダー固有の統合（インテグレーション）も含まれ得る。一部の実装例では、ユーザはコンポーネントカタログからアプリケーションフローパネル上へと、コンテナをドラッグ及びドロップする。また、以下にて詳述するように、ユーザは、コンポーネントを構成して、コンポーネントのノード間においてコールストリーム又はデータマッピングを形成することも可能である。

図１１Ｅは、インスペクタパネルの例について示す図である。インスペクタパネルは、例えば、コンテナスタイル、レイアウトスタイル、間隔、位置合わせ、ラベル、及び他の詳細事項の検査について支援できる。

カスタムコンポーネントの作成を支援することができる。例えば、コンポーネントカタログは、支援されている基本コンポーネントの初期セットを有することができ、アプリ開発者によって作成されたカスタムコンポーネントの追加によって時間の経過に従って充実化させていくことができる。追加のカスタムコンポーネントは、アプリ開発者によって作成されて、コンポーネントカタログに追加されることができる。１つの実装例では、アプリ開発者はＩＤＥプラグインを介してカスタムコンポーネントを作成して、VS CodeのようなＩＤＥに投入できる（ここでVisual Studio Codeは、ウェブアプリケーション及びクラウドアプリケーションの構築及びデバッグ用に再定義及び最適化されたコードエディタである）。コンポーネントカタログで提供されないコンポーネント又はマーケットプレイスで見つけられないコンポーネントがある場合、アプリ開発者はカスタムコンポーネントを作成することを選ぶ柔軟性を有していることになる。適切なインタフェースを実装しつつ、自らの選好する言語（例えば、ウェブに関して、例えばTypeScript又はJavaScript等）でコードを書くことでこれをなし得る。これらのカスタムコンポーネントはUIflowクラウドへと送ることができ、アプリ開発者（app dev）がこれらのコンポーネントをフローパネル内へとドラッグ及びドロップするに関して利用可能として、それらに他のコンポーネントを繋ぐことができる。

１つの実装例では、ＵＩフレームワークコンポーネントは、ＵＩコンポーネントとしてラッピングされることができ、また、任意の第三者ＡＰＩ又は統合がデータコンポーネントとしてラッピングされ得る。一旦準備がなされると、これらのコンポーネントはUIflowプレビューパネル又はフローパネル内へとドラッグされることができ、ここでユーザはコンポーネント間のフロー及びデータマッピングについてモデリングを行い始めることができる。図１２は、どのようにしてカスタムコードコンポーネントが生成され得るかについて示す。ＵＩフレームワークコンポーネントは、ＵＩコンポーネントとしてラッピングされ得る。また、任意の第三者ＡＰＩ又は統合は、データコンポーネントとしてラッピングされ得る。一旦準備がなされると、カスタムコンポーネントはＵＩプレビューパネル又はフローパネル内へとドラッグされることができ、ユーザがコンポーネント間のフロー及びデータマッピングについてモデリングを行うためにこれらを用い得る。

図１３は、例による方法についての流れ図である。ブロック１３０５では、ユーザがコンポーネントを選択する。ブロック１３１０では、ユーザは随意的にはコンポーネントを構成（コンポーネント内のブロックタイプを構成する等）できる。ブロック１３１５では、ユーザは、選択済みコンポーネント間のコールストリーム及びデータマッピングを定義してアプリケーションフローグラフを形成する。アプリケーションフローグラフは、ＵＩアプリケーションを生成するために用いられる。ブロック１３２０では、ユーザは随意的にＵＩアプリケーションをプレビューできる。ブロック１３２５では、ユーザは随意的にユーザアプリケーションのテストを行うことができる。ブロック１３３０では、ユーザは随意的に、ブレークポイントを用いてアプリケーションを通してステップ実行を行う等してＵＩアプリケーションをデバッグできる。ブロック１３３５では、ＵＩアプリケーションを生成するために必要とされている定義ファイル（或いは他の情報）が作成される。ブロック１３４０では、ＵＩアプリケーションが展開される。

図１４は、例による更なる詳細な方法についての流れ図である。ブロック１４では、ユーザは、ＵＩコンポーネント、データコンポーネント、論理コンポーネント、及び変換コンポーネントを含むコンポーネントカタログからコンポーネントを選択する。ブロック１４１０では、ユーザは随意的に、構成可能な選択済みコンポーネントを構成できる。ブロック１４１５では、ユーザは、ＵＩコマンド（例えば、マウスコマンド）を介して選択済みコンポーネントのノード間のコールストリーム及びデータマッピングを定義してアプリケーションフローグラフを形成する。ブロック１４２０では、ユーザは随意的に、対応するＵＩアプリケーションをプレビューする。ブロック１４２５では、ユーザは随意的に、ブレークポイントを設定してアプリケーションを通してステップ実行を行う等してＵＩアプリケーションをデバッグできる。ブロック１４３０では、ＵＩアプリケーションについてアプリケーション定義ファイルが生成される。ブロック１４３５では、ドッカーファイルが生成される。ブロック１４４０では、ドッカーファイルを用いてＵＩアプリケーションが展開される。

図１５は、別の操作方法についての流れ図である。ブロック１５０５では、システムはユーザコンポーネントを受信してコンポーネントを選択するのであって、各コンポーネントはコンポーネント挙動をモデリングするための各々のコンポーネントモデルを含む。ブロック１４１０では、システムはユーザインタフェースコマンドを受信して選択済みコンポーネントのノード間のコールストリーム及びデータマッピングを定義する。ブロック１４１５では、システムはＵＩストリームを介してアプリケーション論理及び状態をモデリングする。ブロック１４２０では、システムはフローエンジンによってＵＩアプリケーションについてのアプリケーション論理グラフを辿る。ブロック１４２５では、システムはＵＩアプリケーションを説明するファイルを生成する。

Flowlangの他の態様
Flowlangでは、全ての入力及び出力はしっかりと分類されており、即ち設計時においてデータタイプが既知となっている。これによって静的解析が可能となり、システムはエラー又は警告をユーザにアプリケーション実行前に伝達できる。

Flowlangは、デバッグすることを支援する機能を含み得る。例えば、Flowlangのいくつかの実装例では、ユーザは個々のコンポーネントにブレークポイントを設定し、フローを実行してコンポーネント上で一時停止することができ、これによってユーザは特定の時点におけるコンポーネント値を検査でき、そして「次へ」ボタンを押下して実行フローを続けていくことができる。実行を介してステップ実行するためのブレークポイントを設定することは、ループ又は論理の再帰的な部分をデバッグする際に特に有用である。

一部の実装例では、フローパネルは、異なる接続にて、コール接続又はデータマッピング接続のいずれかについて、ブレークポイントをアプリ開発者が追加することを可能とする。アプリが実行されると、コールの実行は各ブレークポイントで停止し（伝統的なコードをデバッグすることと同様）、アプリ開発者はデバッグする目的で実行中のその時点での全ての値を検査できる。アプリ開発者は、ブレークポイントでデータ値を変更してアプリケーションフローの残部に影響を及ぼすことができる。アプリ開発者は、アプリケーションがデバッグモードで実行されている際にコンポーネント及び接続を強調表示することによって実行経路を視覚的に見ることができる。アプリ開発者は、各実行ユニットを通してステップ実行を行えるのであり（ステップオーバー／ステップイン／ステップアウトに類似）、また、各ステップでアプリケーションがどのように実行されているかを観察できる。アプリ開発者は、アプリケーションの全体の状態を保存及び読み込むことができ、問題となる箇所をすぐに再現できる。

一部の例では、機能テストを支援できる。アプリ開発者は、同じ視覚的言語を用いて機能テストを作成することとなる。テスト環境は、開発環境内でこれらのテストを提供するのであり、また、テスト実施者が単一又は複数のテスト（テストスイート）を手動で又はスケジュールされた時間若しくはアクションで自動的に実行できるようにする。

その他の様々な機能及び最適化が支援され得る。ある実装では、ＭＶＦコールストリームは破線で表され、ＭＶＦデータマッピングは実線で表されている。１つの実装例では、ＭＶＦコールストリームは破線で表され、ＭＶＦデータマッピングは実線で表されている。１つの実装例では、コールノードのみが一緒に接続されることができる（ノードの入出力ペア）。１つの実装例では、データマッピングノードのみが一緒に接続できる（送信データのタイプに基づいたノードの入出力ペア）。

一部の実装例では、アプリ開発者は、異なる方法でコールストリームを強調表示できる。１つの例では、コンポーネントに対してマウスオーバー又は選択することが含まれ、これによって全てのインバウンド及びアウトバウンド接続が強調表示されることが結果として生じ得る。別の例では、出力ノードに対してマウスオーバー又は選択することが含まれ、これによって全ての下流コールストリームが強調表示されることが結果として生じる。さらに別の例では、入力ノードに対してマウスオーバー又は選択することが含まれ、これによって全ての上流コールストリームが強調表示されることが結果として生じる。

１つの実装例では、ノード並べ替えが支援されている。見た目のより良いフローグラフをもたらすために、アプリ開発者は、ドラッグすることによって入出力ノードを並び替えることができるのであり、これは接続重複を削減するためになされる。

１つの実装例では、自動レイアウト機能が支援されている。一部の実装例では、フローパネルは「自動レイアウト機能」をも有しており、コンポーネント及びノードを自動的に配置して、ストリームの交差が最小限の可能な限り最良のレイアウトをもたらす。

位置決めガイドを提供できるのであり、ユーザはコンポーネントを自由に移動させるなかで、フローパネルが中央、左端、及び右端の位置合わせに基づいてコンポーネントを他のコンポーネントと並べるために、垂直及び水平のガイド線を引くことになる。

接続弾力性をサポートできるのであり、ユーザがコンポーネントを移動させるなかで、接続（例えば、コールストリーミング接続又はデータマッピング接続等）が輪ゴムのように弾力性を保つようにできる。

インタフェース自動生成も支援され得るのであって、アプリ開発者があるコンポーネントから別のコンポーネントにメソッドを露出させたい場合、関連アクションリンクをクリックして、「インタフェース作成」をクリックして、そしてインタフェース露出先のコンポーネントを選ぶことを選択肢とし得る。これによって、インタフェース接続が正しいレベルで自動作成され、完全な接続がもたらされる。

コンポーネント及び接続のバージョン互換性が支援されていることができる。より新しいバージョンのコンポーネントが利用可能である場合、アプリ開発者は、全ての互換性チェックに合格した場合に、手動で又は自動でコンポーネントのアップグレードをなすことを選ぶことができる。アプリ開発者に対しては、コンポーネントのより新しいバージョンが利用可能となっているかについての通知をなし得る。不適合なコンポーネントがアプリケーション内にて用いられている場合には、アプリ開発者は通知を受ける。

関連性のあるコンポーネント／接続については（機械学習に基づいた）自動提案が支援されていることができる。一部の実装例では、ＵＩデザイナを支援するための提案をもたらすために機械学習手法が用いられる。最終UIflowグラフについてのデータ及びUIflowグラフの設計中のユーザ選択は、訓練セットデータベース内に格納され得る。ＵＩデザイナを支援するために機械学習アルゴリズムを用い得る。既存のアプリケーションフローグラフを訓練セットとして用いることによって、自動的に追加されるにふさわしい次のコンポーネントとしてどのコンポーネントが関連性を有しているかについて（例えば、GPT-3等の機械学習アルゴリズムを用いて）提案／予測し始めることができよう。同様にして、接続についても提案をもたらし得る。これらのモデルは、潜在的な非効率性を識別することもでき、また、目下の目的を達成するためのより良い方法についても示唆し得る。

ライブ協調もサポートされ得る。複数のアプリ開発者が同じアプリ且つ同じブランチにログインした場合、これらの者は一緒にライブで協調できる。

説明を目的として、上述の説明では、幾つもの詳細事項を記載した。もっとも、これらの詳細事項についての任意の所与の部分集合なくともこれらの開示の技術を実施できることに留意されたい。他の場合に関して述べるに、構造及び装置が概略図にて示されている。例えば、開示の技術は、上述の一部の実施態様において、ユーザインタフェース及び特定のハードウェアとの関連で説明されている。

本明細書において「１つの実施形態」、「幾つかの実施形態」又は「実施形態」に言及する場合、実施形態に関連して説明される特定の特徴、構造、又は特性が、開示の技術の少なくとも一部の実施形態に含まれていることを意味する。なお、本明細書の様々な箇所での「一部の実施形態において」という表現は、必ずしも全てが同じ実施形態を指しているわけではない。

上記詳細な説明の一部は、コンピュータメモリ内のデータビットに対するオペレーションの処理及び記号的表現で示されている。処理は、一般的には結果へと至る自己一貫的なステップのシーケンスとみなされ得る。諸ステップは物理量の物理的操作を伴い得る。これらの量は電気的な又は磁気的な信号の形式を有しており、これらは格納、移転、結合、比較、及び他の態様で操作され得る。これらの信号は、ビット、値、要素、記号、文字、項、数又はこれらに類するものを伴う形式で指され得る。

これらの用語及び類似の用語は、適切な物理量と関連付けられることができ、これらの量に付されるラベルとみなされ得る。先述から明らかなように別段の記載なき限り、本明細書を通じて、例えば「処理」或いは「演算」或いは「計算」或いは「決定」或いは「表示」或いはそれに類する用語を用いる箇所は、コンピュータシステムのレジスタ及びメモリ内の物理（電子）量として表されるデータを、コンピュータシステムのメモリ又はレジスタ又は他のそのような情報記憶、伝送若しくは表示装置内の物理量として同様に表される他のデータへと、操作及び変換するコンピュータシステム又は類似の電子コンピューティング装置の作用及び処理を指し得ることに留意されたい。

開示の技術は、記載されたオペレーションを行うための装置に関することもあり得る。この装置は、求められている目的のために特別に構築されることが可能であり、或いは、コンピュータ内に記憶されているコンピュータプログラムによって選択的に作動若しくは再構成される汎用コンピュータを備えることができる。

開示の技術は、完全なハードウェア実装、完全なソフトウェア実装、又はソフトウェア及びハードウェア要素の両方を含む実装の形式とされ得る。一部の実施形態では、技術はソフトウェアで実装されており、これにはファームウェア、常駐ソフトウェア、マイクロコード等含まれるもこれらには限らない。

さらに、開示の技術は、不揮発性のコンピュータ利用可能な或いはコンピュータ可読な媒体よりアクセス可能なコンピュータプログラム製品の形式とされ得るのであり、これはコンピュータ又は任意の命令実行システムによって用いられるための又はそれらとの関係を有するプログラムコードを提供する。本説明の目的との関係では、コンピュータ利用可能又はコンピュータ可読媒体は、命令実行システム、機器、又は装置によって或いはそれらとの関係で使用するためのプログラムを格納、保存、伝達、伝播、又は転送できる任意の装置とされ得る。

プログラムコードの格納及び／又は実行に適したコンピューティングシステム又はデータ処理システムは、システムバスを介してメモリ要素に直接又は間接的に結合された少なくとも１つのプロセッサ（例えば、ハードウェアプロセッサ）を含み得る。メモリ要素には、プログラムコードの実際の実行の際に利用されるローカルメモリ、バルクストレージ、及び実行中にバルクストレージからコードを取り出す回数を減らすために少なくとも一部のプログラムコードについて一時的なストレージを提供するキャッシュメモリが含まれ得る。

入出力装置（キーボード、ディスプレイ、ポインティング装置等を含むがこれらには限定されない）は、直接的に又は介在するＩ／Ｏコントローラを介してシステムに結合されることができる。

また、ネットワークアダプタをシステムに結合でき、それによってデータ処理システムが、介在する私設又は公衆ネットワークを介して、他のデータ処理システム又はリモートなプリンタ又は記憶装置に結合されるようにし得る。現行の利用可能なネットワークアダプタの種類を挙げれば、他もあるが、モデム、ケーブルモデム、及びイーサネットカードが挙げられる。

最後に述べるに、本明細書にて示された処理及び表示は、特定のコンピュータ又は他の装置と本質的に関連していないことがあり得る。本開示の教示事項によるプログラムと併せて様々な汎用システムを用い得るのであり、或いは、必要とされる方法のステップをなすためのより特化した装置を構築することがより利便性を有することとなることもあり得る。様々なこのようなシステムについて必要とされる構造は、後述の説明から明らかとなろう。また、開示の技術は何らかの特定のプログラミング言語との関係で説明されたわけではない。本開示にて説明された技術の教示事項を実装するために様々なプログラミング言語を用い得ることに留意されたい。

本開示の手法及び技術の実装例は例示及び説明のために提示されたものである。開示は網羅的であることは意図されておらず、また、本開示の手法及び技術を開示された厳密な形式に限定することは意図されていない。上述の教示に照らせば、多くの改変及び変形が可能となろう。本開示の手法及び技術の範囲はこの詳細な説明によって限定されてはならないことが意図されている。本開示の手法及び技術は、その精神又は必須特徴から逸脱せずにして他の具体的形式にても実装可能である。同様に、モジュール、ルーチン、特徴、属性、方法論及び他の態様の特定の命名及び分割態様は、必須又は重要ではなく、また、本開示の手法及び技術又はその特徴を実装する機序は、異なる名称、分割及び／又は形式を有し得る。また、本開示の技術のモジュール、ルーチン、特徴、属性、方法論及び他の態様は、ソフトウェア、ハードウェア、ファームウェア又はそれら３者の任意の組合せとして実装できる。また、コンポーネント（例としてはモジュール）がソフトウェアとして実装される場合、コンポーネントは、スタンドアロンプログラムとして、より大きなプログラムの一部として、複数の別個のプログラムとして、静的若しくは動的にリンクされたライブラリとして、カーネル読み込み可能モジュールとして、デバイスドライバとして、並びに／又はコンピュータプログラミングにおいて現在又は将来において知られているありとあらゆる別の態様で実装され得る。また、本開示の手法及び技術は、特定のプログラミング言語での実装又は特定のオペレーティングシステム若しくは環境での実装に限定されるものでは決してない。よって、本開示の手法及び技術については限定的にではなく例示的に開示している。

Claims (20)

1. システムであって：
   プロセッサと、メモリと、コンピュータプログラム命令とを含み：
   ユーザインタフェースアプリケーションを構築する視覚的フロー言語を有するユーザインタフェース設計スタジオであって、前記スタジオはコンポーネントカタログを含み、前記コンポーネントカタログ内の各コンポーネントは前記ユーザインタフェース設計スタジオのフローパネル内においてユーザインタフェースを操作する態様を表すために選択可能であり、また、各コンポーネントはコンポーネントモデルをカプセル化しており並びに１つ以上のノードを記述する少なくとも１つのブロックを含む、ユーザインタフェース設計スタジオ、を実装する、システムであって、
   ユーザは選択された前記コンポーネントのノード間のコールストリーム及びデータマッピングを定義してユーザインタフェースアプリケーションを定義できる、システム。
2. 請求項１に記載のシステムにおいて、前記コンポーネントカタログ内の前記コンポーネントはＵＩコンポーネント及びデータコンポーネントを含む、システム。
3. 請求項１に記載のシステムにおいて、前記コンポーネントカタログ内の前記コンポーネントは論理コンポーネント及び変換コンポーネントをさらに含む、システム。
4. 請求項１に記載のシステムにおいて、アプリケーション論理グラフィックが、前記定義されたユーザインタフェースアプリケーションに基づいて生成される、システム。
5. 請求項１に記載のシステムにおいて、前記ユーザインタフェース設計スタジオは、前記設計されたユーザインタフェースアプリケーションをプレビューするためのプレビューパネルを含む、システム。
6. 請求項１に記載のシステムにおいて、前記ユーザインタフェース設計スタジオは、ユーザが、ブレークポイントを定義することと、前記定義されたユーザインタフェースアプリケーションを前記定義されたブレークポイントを介してステップ実行することと、を支援するデバッガを含む、システム。
7. 請求項１に記載のシステムにおいて、少なくとも１つのコンポーネントがユーザによってカスタマイズされる、システム。
8. 請求項１に記載のシステムにおいて、定義されたユーザインタフェースアプリケーションについてファイルが生成されて、前記定義されたユーザインタフェースアプリケーションを展開する、システム。
9. 請求項９に記載のシステムにおいて、ドッカーイメージが生成されて、前記定義されたユーザインタフェースアプリケーションをクラウド及びエンタープライズネットワークの少なくとも１つを介してブラウザへと展開する、システム。
10. コンピュータ実装方法であって：
    視覚的フロー言語にて表されたユーザインタフェースアプリケーションのコンポーネントについてのユーザ選択を受信するステップと、
    前記コンポーネントについてのユーザ選択のノード間のコールストリーム及びデータマッピングについてのユーザ選択を受信するステップと、
    前記受信されたコンポーネントについてのユーザ選択と前記受信されたコールストリーム及びデータマッピングについてのユーザ選択とに基づいて、アプリケーションフローグラフを生成するステップと、
    前記アプリケーションフローグラフに基づいて、ユーザインタフェースアプリケーションを展開するのに要する情報を生成するステップと、を含む、コンピュータ実装方法。
11. 請求項１０に記載のコンピュータ実装方法において、各コンポーネントは、カプセル化されたコンポーネントモデルを含む、コンピュータ実装方法。
12. 請求項１１に記載のコンピュータ実装方法において、ＵＩストリームを通じてアプリケーション論理及び状態をモデリングするステップをさらに含む、コンピュータ実装方法。
13. 請求項１２に記載のコンピュータ実装方法において、ＵＩコンポーネントと、論理コンポーネントと、データコンポーネントと、変換コンポーネントとを含むコンポーネントカタログを提供するステップをさらに含む、コンピュータ実装方法。
14. コンピュータ実装方法であって：
    コンポーネントと、コンポーネント間の定義されたコールストリーム及びデータマッピングと、の取り合わせから、異なるコンポーネントタイプをユーザが選択するための視覚的フロー言語を提供するステップと、
    前記視覚的フロー言語を介して入力されたユーザコマンドを受信して、コンポーネントと、コールストリームと、データマッピングとを定義するステップと、
    ユーザインタフェースアプリケーションを生成するステップと、を含む、コンピュータ実装方法。
15. 請求項１４に記載のコンピュータ実装方法において、前記ユーザインタフェースアプリケーションを定義するドッカーイメージを生成するステップと、前記生成されたドッカーイメージを用いて前記ユーザインタフェースを展開するステップと、をさらに含む、コンピュータ実装方法。
16. 請求項１４に記載のコンピュータ実装方法において、前記異なるコンポーネントタイプは、ＵＩコンポーネント、論理コンポーネント、データコンポーネント、及び変換コンポーネントを含む、コンピュータ実装方法。
17. 請求項１４に記載のコンピュータ実装方法において、ＵＩストリームを通じてアプリケーション論理及び状態をモデリングするステップをさらに含む、コンピュータ実装方法。
18. 請求項１４に記載のコンピュータ実装方法において、前記受信されたコンポーネントについてのユーザ選択と前記受信されたコールストリーム及びデータマッピングについてのユーザ選択とに基づいて、アプリケーションフローグラフを生成するステップをさらに含む、コンピュータ実装方法。
19. 請求項１４に記載のコンピュータ実装方法において、前記ユーザインタフェースアプリケーションについてのアプリケーション論理グラフを生成するステップをさらに含む、コンピュータ実装方法。
20. フロントエンドＵＩアプリケーションを設計するためのコンピュータ実装方法であって：
    ユーザインタフェースアプリケーションを設計するための、視覚的フロー言語を含む設計スタジオと、
    前記視覚的フロー言語で表現されたＵＩアプリケーションに基づいてアプリケーション論理グラフを生成するためのフローエンジンと、を提供するステップを含む、コンピュータ実装方法。

Images