(57)【要約】      （修正有）【課題】アプリケーション設定ファイルから、選択したプラットフォームにおける画面、画面連携処理、データ処理等の機能ソースコードを自動的に生成する。【解決手段】開発支援プログラムは、デザインファイルｆｄから画面レイアウトのソースコードｓｄを生成可能な画面レイアウトジェネレーターを備える画面レイアウト生成部と、ビュー定義ファイルｆｖから画面連携処理のソースコードｓｖを生成可能な画面連携処理ジェネレーターを備える連携処理実装部と、機能定義ファイルｆｆからデータ処理機能ロジックのソースコードｓｆを生成可能な機能状態ジェネレーターを備える機能状態実装部とを備える。画面レイアウト生成部は、デザインファイルｆｄからテキストファイルである中間ファイルｆｔを生成するコンテキストローダーＣＬを生成可能とし、画面レイアウト生成部が中間ファイルｆｔから画面レイアウトのソースコードｓｄを生成する。【選択図】図１
2020166668.tif 000002
【特許請求の範囲】
【請求項１】
ＳＶＧファイルであるデザインファイルと、テキストファイルであるビュー定義ファイルと、テキストファイルである機能定義ファイルを含む設定ファイルから、選択したプラットフォームに対応するネイティブアプリケーションのソースコードを生成可能なネイティブアプリケーション開発支援プログラムであって、前記デザインファイルから画面レイアウトのソースコードを生成可能なプラットフォームごとの画面レイアウトジェネレーターを備える画面レイアウト生成部と、前記ビュー定義ファイルから画面連携処理のソースコードを生成可能なプラットフォームごとの画面連携処理ジェネレーターを備える連携処理実装部と、前記機能定義ファイルからデータ処理機能ロジックのソースコードを生成可能なプラットフォームごとの機能状態ジェネレーターを備える機能状態実装部とを備え、前記連携処理実装部は前記画面連携処理のソースコードを、前記機能状態実装部は前記データ処理機能ロジックのソースコードを、それぞれ前記画面レイアウトのソースコード内に自動生成可能としたことを特徴とする、ネイティブアプリケーション開発支援プログラム。
【請求項２】
前記画面レイアウト生成部は、デザインファイルから編集可能なテキストファイルである中間ファイルを生成可能なコンテキストローダーを生成可能とし、前記画面レイアウト生成部が該中間ファイルから画面レイアウトのソースコードを自動生成可能としたことを特徴とする、請求項１に記載のネイティブアプリケーション開発支援プログラム。
【請求項３】
前記デザインファイルは、ａｉファイルである画面レイアウトデザインをＳＶＧファイルに変換して保存したものであることを特徴とする、請求項２に記載のネイティブアプリケーション開発支援プログラム。
【請求項４】
前記中間ファイルは、その記述内にマーカーを設定可能とし、画面レイアウトのソースコードの自動生成時に、中間ファイルの編集部分のうち前記マーカーによって規定された範囲のみがソースコードに反映されるように構成したことを特徴とする、請求項３に記載のネイティブアプリケーション開発支援プログラム。
【請求項５】
請求項１乃至４のいずれか一項に記載のネイティブアプリケーション開発支援プログラムにより生成されたソースコードを含むネイティブアプリケーション。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、スマートフォンやパソコン上で動作するネイティブアプリケーションの開発の支援を行うプログラムに関し、より詳細には、Ａｄｏｂｅ  Ｉｌｌｕｓｔｒａｔｏｒ(登録商標)によって作成したデザインファイル（ａｉファイル）を含む設定ファイルから、ネイティブアプリケーションの画面レイアウト及びそのソースコード、さらに、ネイティブアプリケーションの仕様書に基づき定義された複数の画面間を遷移する画面連携処理命令のソースコード、各画面におけるデータ処理等の機能状態を実現する命令を定義するソースコードを自動的に生成するプログラムに関する。
【背景技術】
【０００２】
スマートフォンのネイティブアプリケーションや、インターネットブラウザ用のプログラム（以下、「Ｊａｖａ（登録商標）ファイル等」）と記す。）によるＷＥＢアプリケーションの開発は、大きく（１）Ｖｉｅｗ（画面構成）、（２）Ｃｏｎｔｒｏｌｌｅｒ（画面遷移）、（３）Ｍｏｄｅｌ（機能実装）の３種類に分けられる。従来のアプリケーション開発工程においては、デザイナーが作成した画面デザインのａｉファイルやｐｓｄファイルとデザイン仕様書に基づき、プログラマーがＪａｖａファイル等のソースコードを１行づつ作成していた。
【０００３】
しかし、一般的にプログラミングの知識が少ないデザイナーは、機能の実装方法への考慮に乏しい画面デザインを作成しがちであり、一方、一般的にデザイン知識の少ないプログラマーが機能実装を行う場合には、デザイナーが意図した通りの画面デザインが表示されないという問題も起こりがちであった。また、アプリケーションの更新や修正等のカスタマイズを行う場合には、都度新たなデザインファイルと仕様書に基づきソースコードを作成・変更しなければならず、さらに、特定のプラットフォーム（オペレーションシステム）に対応するアプリケーションを異なるプラットフォームへ移植しようとする場合には、異なるソースコードをプログラミングする必要があるため、時間と労力を必要とするという問題があった。
【０００４】
かかる問題に対し、たとえば特許文献１に開示されたＷｅｂ画面開発支援システムでは、ＨＴＭＬファイルからなる画面生成ベースファイルの編集画面上に、段組みレイアウトや各種の画像構成要素であるＨＴＭＬ部品を選択して配置し、さらに、各ＨＴＭＬ部品の制御機能（ビジネスロジック）とそれを発動させる関数及びイベントとを部品機能定義ファイルによって関連付けることにより、個別のソースコードのプログラミングを必要とせずにアプリケーションを開発可能としている。しかし、かかる先行技術では、予め準備された段組みレイアウトやＨＴＭＬ部品自体の変更は容易には行えないため、画面レイアウトやデザインの自由度は限定されざるを得ない。
【０００５】
一方、特許文献２に開示されたＷＥＢアプリケーション開発支援装置では、ソースプログラムジェネレーターによって、画面デザインを定義するＨＴＭＬファイルと画面遷移やビジネスロジックを定義する独自のフォーマットで記述されたＸＭＬファイルとをまとめ、Ｊａｖａファイル等のソースプログラムを生成するものである。マルチプラットフォームに対応可能であるだけでなく、Ｊａｖａファイルよりも平易なＸＭＬファイルでビジネスロジックを記述でき、これをソースプログラムに反映可能としているため、ユーザに優しいカスタマイズ環境を提供可能としている。しかし、かかる先行技術では、デザイナーは画面デザインをＨＴＭＬファイルで、ビジネスロジックをＸＭＬファイルで作成する必要があり、一定のコーディングスキルが必要とされるため、画面デザインがａｉファイルやｐｓｄファイルの場合、必ずしも最終的に意図した通りのデザインが表示されるようにソースプログラムが生成されるとは限らず、上記問題の解決には至らなかった。
【特許文献１】特開２０１６−１１０２０６号公報
【特許文献２】特開２００２−３６６３５２号公報
【０００６】
ところで、グラフィックデザイン分野の業務においては、ベクターイメージ編集ソフトウェア（ドローソフト）であるＡｄｏｂｅ  Ｉｌｌｕｓｔｒａｔｏｒ(登録商標：以下「Ｉｌｌｕｓｔｒａｔｏｒ」と記す。)が普及しており、デファクトスタンダードとなっている。一方、ＷＥＢデザインの分野においては、従来はＰｈｏｔｏｓｈｏｐ（登録商標）やＦｉｒｅｗｏｒｋｓ（登録商標）等のソフトウェアが多用されていた。Ｐｈｏｔｏｓｈｏｐは画像加工に特化したソフトウェアで、画像が重要なＷＥＢデザインでは有利な点が多いが、ベクターイメージは取り扱えず、イラストやレイアウト定義には不向きであり、ファイルサイズが大きくなるという問題もあった。また、Ｆｉｒｅｗｏｒｋｓはベクターイメージと画像データを同時に扱えるという利点があるが、デザイナーにおける普及率が低いという問題があった。
【０００７】
これに対し、Ｉｌｌｕｓｔｒａｔｏｒは、レイアウト定義や文字組みが容易で、イラストデータの取扱いに優れ、動作が軽いという利点を有する。また、アートボード機能により１つのファイル内に複数のデザインを作成・管理できるほか、異なるプラットフォームに対応するレスポンシブデザインの作成も容易であり、ａｉファイルをＳＶＧファイルとして保存可能であるという特徴を有する。
【０００８】
ＳＶＧ（Ｓｃａｌａｂｌｅ  Ｖｅｃｔｏｒ  Ｇｒａｐｈｉｃｓ）は、Ｗ３Ｃ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ）によって開発されオープン標準として勧告されているＸＭＬベースの２次元ベクター形式フォーマットである。ベクター形式故に図形や文字の歪みのない拡大縮小が自在であり、レイヤー機能により、写真やイラストなどのビットマップデータと図形等のベクターデータを個別に取り扱え、共存させて画面表示が可能という優れた特徴を備える。また、フォーマット自体が回転・移動・拡大などの各種の要素を備え、ＪａｖａＳｃｒｉｐｔとの親和性も高いため、インタラクティブな双方向性のある画面変化の表示やアニメーションなど多様な表現に適している。そのため、ＳＶＧファイルをサポートするウェブブラウザやオペレーションシステムの一般化に伴い、ネイティブアプリケーションのデザイン制作の分野においてもＩｌｌｕｓｔｒａｔｏｒが普及しつつある。しかし、ネイティブアプリケーションの制作においては、デザイナーが作成したａｉファイルと仕様書に基づいてプログラマーがＪａｖａファイルのソースコードを逐一コーディングしていく作業自体は変わらないため、意図した通りの画面デザインが表示されない、更新やカスタマイズ、マルチプラットフォームへの対応においてプログラミングに時間や労力を要するといった根本的な問題は残されていた。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明は、上記の問題を解決するべく創作されたものであり、ＳＶＧファイルとして保存したデザインファイルを含むネイティブアプリケーションの設定ファイルから、任意に選択したプラットフォームに対応する画面レイアウトの表示、画面連携処理命令、各画面におけるデータ処理等の機能状態を実現する命令を定義するソースコードを自動的に生成可能とするネイティブアプリケーション開発支援プログラムを提供することを課題とする。
【課題を解決するための手段】
【００１０】
前記課題を解決するために、請求項１に係る発明は、ＳＶＧファイルであるデザインファイルと、テキストファイルであるビュー定義ファイルと、テキストファイルである機能定義ファイルを含む設定ファイルから、選択したプラットフォームに対応するネイティブアプリケーションのソースコードを生成可能なネイティブアプリケーション開発支援プログラムであって、前記デザインファイルから画面レイアウトのソースコードを生成可能なプラットフォームごとの画面レイアウトジェネレーターを備える画面レイアウト生成部と、前記ビュー定義ファイルから画面連携処理のソースコードを生成可能なプラットフォームごとの画面連携処理ジェネレーターを備える連携処理実装部と、前記機能定義ファイルからデータ処理機能ロジックのソースコードを生成可能なプラットフォームごとの機能状態ジェネレーターを備える機能状態実装部とを備え、前記連携処理実装部は前記画面連携処理のソースコードを、前記機能状態実装部は前記データ処理機能ロジックのソースコードを、それぞれ前記画面レイアウトのソースコード内に自動生成可能としたことを特徴とする。
【００１１】
設定ファイルに含まれるデザインファイル、ビュー定義ファイル、機能定義ファイルのうち、デザインファイルは、ネイティブアプリケーションの各画面における画像等個々のデザイン要素のデータやレイアウト定義情報データであるＳＶＧファイルから成る。また、テキストファイルであるビュー定義ファイル、モデル定義ファイルは、ネイティブアプリケーションの仕様書に基づいて既存のライブラリから選択して設定したファイルである。本発明における「テキストファイル」は、たとえばＸＭＬファイルであるが、必ずしもこれに限定されない。また、前記プラットフォームとしては、ｉＯＳやＡｎｄｒｏｉｄの開発で広く用いられるＪａｖａ、Ｋｏｔｌｉｎ、Sｗｉｆｔ、Ｏｂｊｅｃｔｉｖｅ−Ｃ、ＪａｖａＳｃｒｉｐｔ（登録商標）等であるが、必ずしもこれらのみに限定されず、ネイティブアプリケーション開発に適用可能なオブジェクト指向型のコンパイラプログラミング言語のプラットフォームを追加可能とする。
【００１２】
請求項２に係る発明は、請求項１に記載のネイティブアプリケーション開発支援プログラムであって、前記画面レイアウト生成部は、デザインファイルから編集可能なテキストファイルである中間ファイルを生成可能なコンテキストローダーを生成可能とし、前記画面レイアウト生成部が該中間ファイルから画面レイアウトのソースコードを自動生成可能としたことを特徴とする。
【００１３】
コンテキストローダーは、コンテキストクラスローダーともいわれ、一般的にはＪａｖａ等のオブジェクト指向開発言語において、クラスのロードやリソース（ファイル）の検索を担当するオブジェクトであり、プログラムの内部的メモリ構造にクラスを読み込んで、ソースコードを生成するジェネレーターに渡す処理を行う。本発明に係るコンテキストローダーは、設定ファイルからデザインファイル、ビュー定義ファイルを読みだして、所定のプラットフォームに対応する画面レイアウトジェネレーターを起動するランチャーとしての役割を果たすとともに、ＳＶＧファイルであるデザインファイルを読み込み、ＸＭＬとしてトップレベルから再帰的にタグをパースして取得したタグ情報に基づきテキストファイルである中間ファイルを生成可能とするレイアウト解析器として機能する。
【００１４】
請求項３に係る発明は、請求項２に記載のネイティブアプリケーション開発支援プログラムであって、前記デザインファイルは、ａｉファイルである画面レイアウトデザインをＳＶＧファイルに変換して保存したものであることを特徴とする。
【００１５】
請求項４に係る発明は、請求項３に記載のネイティブアプリケーション開発支援プログラムであって、前記中間ファイルは、その記述内にマーカーを設定可能とし、画面レイアウトのソースコードの自動生成時に、中間ファイルの編集部分のうち前記マーカーによって規定された範囲のみがソースコードに反映されるように構成したことを特徴とする。
【００１６】
請求項５に係る発明は、請求項１乃至４のいずれか一項に記載のネイティブアプリケーション開発支援プログラムにより生成されたソースコードを含むネイティブアプリケーションである。
【００１７】
Ｉｌｌｕｓｔｒａｔｏｒでの画面レイアウト制作は、作業領域であるアートボードを設定してアートワークを制作するのが一般的である。アートボードはグループ化された複数のアートワークのレイヤーであり、制作されたアートボードはaｉファイルとして保存されるが、Ｉｌｌｕｓｔｒａｔｏｒでは、プラグインの機能によりＳＶＧファイルとして書き出して保存することができる。ＳＶＧ形式はＸＭＬに準拠しているため、ＸＭＬコードを編集して画像の効果を変更・追加できるほか、ＪａｖａＳｃｒｉｐｔコマンドを実行するイベントを定義することにより、画面遷移等の連携処理やユーザのアクションに対応したオブジェクトの動作等のインタラクティビティの追加が可能となる。
【００１８】
本発明における画面レイアウト生成部は、コンテキストローダーを生成した上で、読み込んだ設定ファイルの中の任意のＳＶＧファイルからコンテキストローダーが一旦テキストファイルである中間ファイルを生成し、該中間ファイルから所定の画面レイアウトジェネレーターがソースコードを自動的に生成するように構成される。中間ファイルはテキストファイルであるため、必要に応じてテキストエディタによって編集することで、生成されるソースコードには編集結果が自動的に反映される。
【００１９】
一方、ネイティブアプリケーションの画面間の連携処理の実装は、連携処理実装部が設定ファイル中のビュー定義ファイルを読み込み、画面連携処理ジェネレーターがビュー定義ファイルから直接画面連携処理のソースコードを生成して、画面レイアウトデザインのソースコード内に実装する。また、データ処理機能ロジックについては、機能状態実装部が設定ファイル中の機能定義ファイルをコンテキストファイルに変換して読み込み、機能状態ジェネレーターがコンテキストファイルから直接ソースコードを生成して、画面レイアウトデザインのソースコード内に実装する。
【発明の効果】
【００２０】
本願発明に係るネイティブアプリケーション開発支援プログラムの構成によれば、以下のような効果を奏する。
（１）ａｉファイルとして制作されたデザインファイルからプラットフォーム別のネイティブアプリケーションのソースコードの生成を画面レイアウトジェネレーターに自動的に行わせることができるため、プログラマーによるソースコードのコーディング作業を大幅に簡略化でき、開発に係る労力と時間の大幅な削減が可能となる。
（２）ａｉファイルと仕様書から直接ソースコードを作成するのではなく、一旦テキストファイルである中間ファイルを生成するプロセスを介することで、作成されたネイティブアプリケーション画面に軽微な修正や画面上の効果の変更・追加が必要となった場合に、ａｉファイル自体の修正を行うことなく、中間ファイルを編集することで容易に修正・変更・追加を反映させることができ、修正・変更・追加作業の負担も軽減できる。
（３）ａｉファイルをＳＶＧファイルに変換したオブジェクトにより画面デザインのソースコードを生成することにより、画面デザイン要素が元のａｉファイルに忠実に再現可能となるため、デザイン知識の乏しいプログラマーによるコーディングに比べて実装後のデザイナーの違和感も少なくできる。
（４）編集の容易な中間ファイルの形で各種の画面デザイン要素をクラス化でき、高度なプログラミング知識を有しない者でもインスタンスの変更が容易となるため、一旦作成した画面デザイン要素を汎用性の高い資産として活用が可能となる。
【発明を実施するための最良の形態】
【００２１】
以下、本発明の実施形態について図面に基づいて詳細に説明する。実施形態に係るネイティブアプリケーション開発支援プログラム（以下「開発支援プログラム１」と記す。）は、たとえばＪａｖａに代表される単一のオブジェクト指向言語によって構成される。図１は、開発支援プログラム１を構成するモジュールと、各モジュールにより生成又は処理される各ファイルを示す概要図である。なお、図中の各モジュールは機能構成の概念を示すものであり、必ずしも物理的に独立したプログラムモジュールに限られるものではなく、複数のモジュールが単一のモジュールに統合されたり、個々の機能が複数のモジュールによって実現されることを排除するものではない。
【００２２】
設定ファイルＦは、少なくとも、ＳＶＧファイルであるデザインファイルｆｄと、テキストファイルであるビュー定義ファイルｆｖと、テキストファイルである機能定義ファイルｆｆとから成る。デザインファイルｆｄは、ネイティブアプリケーションを構成する各画面レイアウトデザインをＩｌｌｕｓｔｒａｔｏｒで制作し、作成したａｉファイルのアートボードをＳＶＧファイルに変換して保存したものである。ビュー定義ファイルｆｖと機能定義ファイルｆｆは、ネイティブアプリケーションの仕様書に基づき、画面構成やその遷移や挙動等の画面仕様、個別の機能とその処理内容、テーブルデータ構造、エンティティ間の関係性などの設定を定義したテキストファイルである。
【００２３】
開発支援プログラム１は、大きく分けて、画面レイアウト生成部１０、連携処理実装部２０、機能状態実装部３０の各モジュールとから構成される。画面レイアウト生成部１０は画面レイアウトジェネレーター１１を、連携処理実装部２０は画面連携処理ジェネレーター２１を、機能状態実装部３０は機能状態ジェネレーター３１をそれぞれ備え、各ジェネレーター１１、２１、３１は、所定のファイルを読み込んでＪａｖａファイルのソースコードを生成可能とする。なお、各ジェネレーター１１、２１、３１は、プラットフォームごとの実クラスとして予め定義されている。
【００２４】
図２は、実施形態に係る開発支援プログラム１の起動から設定ファイルＦの読み込み、及び画面レイアウトのソースコードｓｄの生成に至る処理手順の概略を示す処理フロー図である。開発支援プログラム１は、所定の設定ファイルＦを検索して読み込み（１００）、任意のプラットフォームを指定することで（１０１）、画面レイアウト生成部１０において画面レイアウトのソースコードの生成ロジック（２００）を開始する。ここで、プラットフォームの指定により、起動するジェネレーターの実クラスが決定される。プラットフォームと起動するジェネレーターの関係は、たとえば表１の通りである。
【表１】
2020166668.tif 000003
【００２５】
生成ロジック（２００）では、画面レイアウト生成部１０は、はじめにコンテキストローダーＣＬのインスタンス（View::DSLContextLoader）を生成し、コンテキストローダーＣＬが設定ファイルＦのソースディレクトリ内のデザインファイルｆｄ、ビュー定義ファイルｆｖを読み出してファイルごとに逐次的に処理を実行する。コンテキストローダーＣＬが実行する処理は、ファイルの種類によって異なる。読み出したファイルがデザインファイルｄｆである場合（２０１）は、コンテキストローダーＣＬはＳＶＧファイルを処理して画面レイアウトのソースコードｓｄを生成する（３００）。一方、読み出したファイルがビュー定義ファイルｆｖである場合（２０２）は、これを連携処理実装部２０に送り、画面連携処理ジェネレーター２１が連携処理のソースコードｓｖを画面レイアウトのソースコードｓｄ内に生成し、画面連携処理を定義するオブジェクトが実装される。そして、すべてのファイルの処理が終わると生成ロジック（２００）は終了する。
【００２６】
図３は、コンテキストローダーＣＬによる前記ＳＶＧファイル処理の工程（３００）を示すフロー図である。ＳＶＧファイル処理工程（３００）では、はじめにＸＭＬファイルをＪａｖａにおけるＳＶＧオブジェクトに変換するパース処理を行うインスタンスであるＳＶＧFilePaser（デザインファイル解析器）を生成する。ＳＶＧFilePaserはＳＶＧファイルｆｄのタグを読み込んでタグ名と属性を取得し（３０１）、ＸＭＬとしてトップレベルタグからタグに挟まれた子要素を再帰的にパース処理し、パース結果のオブジェクト（ＳＶＧPaserContext）を生成する（３０２）。ＳＶＧFilePaserはこの工程を繰り返してタグ情報を処理し、ＳＶＧPaserContextへと追加する。なお、デザインファイルｆｄ内にＰＮＧ画像やＪＰＧ画像が存在する場合は、それらの画像ファイルのリストがそのままＳＶＧPaserContextに追加される。以上の工程を繰り返してすべてのＳＶＧファイルのパース処理が終わると処理を終了し、コンテキストローダーＣＬでの処理に復帰する。その後、コンテキストローダーＣＬはＳＶＧPaserContextのパース結果からＪａｖａで記述された中間ファイルｆｔを生成し（３０３）、画面レイアウトジェネレーター１１が中間ファイルｆｔを読み込んで画面レイアウトのソースコードｓｄを生成する（３０４）。
【００２７】
なお、ＳＶＧファイルごとに中間ファイルを生成するか否かはＳＶＧファイルの元になるａｉファイルに識別子を設けることにより選択可能とすることができる。たとえば、アートワークの保存の際のアートボード名が「＠」で始まる場合には、中間ファイルｆｔの生成時に自動的にテキストエディタを開く手動モードに入り、中間ファイルｆｔの編集後に手動でこれをビュー定義ファイルとして保存した上で（３０５）、画面連携処理ジェネレーター２１を起動して画面連携処理のソースコードｓｖを生成させるよう構成する。一方、アートボード名が「＠」で始まらない場合は、中間ファイルｆｔを生成せず、自動的に画面レイアウトジェネレーター１１に画面レイアウトのソースコードｓｄを生成させるように構成する。なお、デザインファイルｆｄ内にビュー定義ファイルｆｖが含まれる場合には、ファイルの内容をコンテキストローダーＣＬでそのまま読み出し、画面連携処理ジェネレーター２１に画面連携処理のソースコードｓｖを生成させるように構成する。
【００２８】
本発明に係る開発支援プログラム１の特徴は、読み込んだデザインファイルｆｄの中のＳＶＧファイルから直接Ｊａｖａのソースコードを生成するのではなく、一旦中間ファイルｆｔの形に変換した上で画面レイアウトジェネレーター１１に渡して画面レイアウトのソースコードｓｄを生成させる点にある。まず、画面レイアウトジェネレーター１１が自動的にソースコードを生成するため、開発者は１行１行Ｊａｖａファイルを書く必要がなくなり、大幅に開発時間を減らすことができる。また、画面レイアウトジェネレーター１１は、ＳＶＧファイルをＪａｖａにおけるＳＶＧオブジェクトへとパース処理した中間ファイルｆｔから画面レイアウトのソースコードｓｄを生成するので、デザインファイルｆｄが忠実に再現される。これにより、最終的に実装されるネイティブアプリケーションの画面レイアウトデザインは、デザイナーが当初Ｉｌｌｕｓｔｒａｔｏｒで制作したものと比べて違和感を感じさせない仕上りとなる。さらに、ネイティブアプリケーションのリリース後に画面レイアウトデザインの修正を行う場合にも、ソースコードを直接書き換える必要はなくなる。単に修正後のａｉファイルを読み込ませることにより自動的にソースコードに修正が反映され、また、中間ファイルｆｔを直接編集することで修正結果をソースコードに反映させることができるため、修正作業の迅速化と開発者の負担軽減が図られる。
【００２９】
図４は、実施形態に係る開発支援プログラム１の機能実装部３０の起動から設定ファイルＦ中の機能定義ファイルｆｆの読み込み、及び機能ロジックのソースコードｓｆの生成に至る処理手順の概略を示す処理フロー図である。
開発支援プログラム１は、機能実装部３０の機能状態ジェネレーター３１を起動し（４０１）、設定ファイルＦ内の機能定義ファイルｆｆを読み込んで（４０２）データ処理機能ロジックのソースコードｓｆを生成させる（４０３）。機能実装部３０の起動時に、プラットフォームの指定により、起動するジェネレーターの実クラスが決定される。プラットフォームと起動するジェネレーターの関係は、たとえば表２の通りである。
【表２】
2020166668.tif 000004
【００３０】
また、機能実装部３０は、データ処理機能ロジックに係る状態遷移図を作成するためのGeneratorDotのインスタンスを生成する。状態遷移図はグラフ構造であり、ノード（図形）とエッジ（図形と図形の関連）をプレーンテキストであるＤｏｔ言語で記述され、ネイティブアプリケーションのデータ処理機能の処理手順を定義する。なお、GeneratorDotのインスタンスとしては、既存のツール（レイアウトエンジン）を使用することができる。
【００３１】
生成ロジック（４０２）ではソースコードの実装先である画面レイアウトのソースコードｓｄに生成先としてソースコードファイルが存在しない場合には、まず大枠のスケルトンの生成を行い、その後、機能定義ファイルｆｆごとの個別のデータ処理機能ロジックのソースコードｓｆの生成を行う。一方、ソースコードファイルが存在する場合には、個別のソースコードの生成のみを行う。
【００３２】
なお、個別のデータ処理機能ロジックのソースコードｓｆは、コードの記述をマーカーで区切るように構成してもよい。マーカーは、たとえば「  //  ％％  」（前後及び中央のスペースは任意の個数でもよい。）と記述する。かかるマーカーを用いることで、１つのテキストファイルの中で、このマーカーとなる行よりも下側の部分の記述は手動で編集したとしてもソースコード生成時には自動的に上書きされて更新されるが、マーカーより上の部分に人間が書いた記述は保全されるようにすることができる。
【００３３】
かかるマーカーは、デザインファイルｆｄから生成される中間ファイルｆｔにも適用可能である。たとえば、ネイティブアプリケーション上において、表示するキャラクター（人物等）の画像を動かしたい場合（たとえば、目の瞬きや口の動き）、キャラクターの輪郭や目、口そのものの形状はデザインファイルｆｄから画面レイアウトジェネレーター１１が自動生成する。一方、目の瞬きや口の動き（たとえば、口の「パクパク」動作）のアニメーションについては、中間ファイルｆｔのマーカーとなる行より上の部分の記述を適宜手動で編集することで自在に付加・変更することができる。さらに、ユーザーからの画面のタップのタイミングや画面上の座標によってキャラクターにインタラクティブなリアクションをさせる命令も付加・変更できる。
【００３４】
すなわち、中間ファイルｆｔにマーカーを適用することで、結果的にＩｌｌｕｓｔｒａｔｏｒのレイヤー毎に一つの関数を生成させるかの如き効果を奏するため、必ずしも機能定義ファイルｆｔであらかじめ定義しなくても、デザインファイルｆｄのみでキャラクター等の動作やレスポンスを実現するソースコードを生成可能とできる。また、デザインファイルｆｄの段階で描画するための「枠」だけを生成しておき、該「枠」の中身を実装者が事後的に手動コーディング可能とすることもできる。
【００３５】
以上のとおり、実施形態に係る開発支援プログラム１は、ネイティブアプリケーションのソースコードを自動生成する工程において、Ｉｌｌｕｓｔｒａｔｏｒで作成したａｉファイルを一旦ＳＶＧファイルに変換して、マーカーを設定可能な中間ファイルｆｔを生成するプロセスを設けることにより、「すべてを自動生成としない」という選択を可能としている。マーカーを設けることで、マーカー以降の所定のソースコードは常に上書きされて自動生成されるが、マーカーよりも上の部分は実装者が手動コーディング可能となるため、カスタマイズや先を見越した設計が可能となる。これにより、実装者の意図に基づいて自動生成部分と手動コーディング部分を使い分けることができ、柔軟な実装が可能となるだけでなく、一旦作成した画面デザイン要素を汎用性の高い資産として活用が可能となるのである。
【００３６】
以上、本発明の実施形態につき、添付の図面を参照しつつ説明したが、本発明は、必ずしも上述した実施形態の構成のみに限定されるものではなく、本発明の目的を達成し、効果を有する範囲内において、適宜変更実施することが可能なものである。
【産業上の利用可能性】
【００３７】
本発明は、スマートフォンやパソコン上で動作するネイティブアプリケーションの開発に適用可能である。
【図面の簡単な説明】
【００３８】
【図１】開発支援プログラム１の概要図
【図２】画面レイアウト生成部における画面レイアウトのソースコードの生成処理の行程を示す処理フロー図
【図３】画面レイアウト生成部におけるＳＶＧファイル処理の工程を示すフロー図
【図４】機能実装部における機能ロジックのソースコードの生成処理の行程を示す処理フロー図
【符号の説明】
【００３９】
Ｆ     設定ファイル
１    開発支援プログラム
１０  画面レイアウト生成部
１１  画面レイアウトジェネレーター
２０  連携処理実装部
２１  画面連携処理ジェネレーター
３０  機能実装部
３１  機能状態ジェネレーター
ａｉ  ａｉファイル
ｆｄ  デザインファイル
ｆｖ  ビュー定義ファイル
ｆｆ  機能定義ファイル
ｆｔ  中間ファイル
Ｓ    ソースコード（ネイティブアプリケーション）
ｓｄ  ソースコード（画面レイアウト）
ｓｖ  ソースコード（画面連携処理）
ｓｆ  ソースコード（機能ロジック）
【図１】
2020166668.tif 000005
【図２】
2020166668.tif 000006
【図３】
2020166668.tif 000007
【図４】
2020166668.tif 000008