以下、図面を参照して本発明の実施形態を詳細に説明する。
<第一実施形態>
図1は、本発明に係わるプログラム開発装置(開発者がWebアプリケーション生成のために操作する情報処理装置)、アプリケーションサーバ、データベースサーバ、アプリケーションクライアントの構成の一例を示すシステム(情報処理システム)構成図である。
プログラム開発装置101は、開発者の操作に従って画面レイアウト及びデータベース検索指示などを定義する。プログラム開発装置101は、プログラム生成、アプリケーション生成を行う。
なお、この実施形態においては、プログラム開発装置101で生成するアプリケーションはWebアプリケーションとしたが、これに限定するものではなく、携帯電話・スマートフォン・タブレットなどの情報処理装置で動作するアプリケーションや組込みソフトウェアなど、Web技術による通信を利用したアプリケーションでなくてもよい。
アプリケーションサーバ102は、プログラム開発装置101で開発されたアプリケーションを実行する。また、データベースサーバ103と接続して動作することが可能である。
データベースサーバ103は、開発されたアプリケーションが使用するデータベースであり、また本発明では開発時にも動作確認などのために利用してもよい。例えば、開発者が利用するためにデータベースサーバ103は、プログラム開発装置101や、アプリケーションサーバ102と同一の装置で構成されていてもよいし、LANなどのネットワーク105内に配置されてもよい。
アプリケーションクライアント104(情報処理装置)は、アプリケーションサーバ102と協調してプログラム開発装置101で開発したアプリケーションプログラムを動作させる、エンドユーザの入力端末である。この、アプリケーションクライアント104は、携帯端末などの情報処理装置であってもよいこととする。
なお、プログラム開発装置101、アプリケーションサーバ102、データベースサーバ103、および、アプリケーションクライアント104の何れかを、クラウドなどのインターネット上に配置してもよいし、いくつかの情報処理装置を一つの筐体としてもよい。
図2は、本発明に係わるプログラム開発装置101、アプリケーションサーバ102、データベースサーバ103、アプリケーションクライアント104として適用可能な各ハードウェア構成の一例を示すブロック図である。
図2において、CPU201は、システムバス204に接続される各デバイスを統括的に制御する。
また、ROM203あるいは外部メモリ211には、CPU201の制御プログラムであるオペレーティングシステム(OS)や、各サーバ、クライアント、装置など情報処理装置の後述する各種機能を実現するためのプログラムが記憶されている。
RAM202は、CPU201の主メモリ、ワークエリア、一時待避領域等として機能する。
入力コントローラ205は、入力部209からの入力を制御する。この入力部209としては、情報処理装置では、キーボード、マウス等のポインティングデバイス、タッチパネルが挙げられる。
なお、入力部209がタッチパネルの場合、ユーザがタッチパネルに表示されたアイコンやカーソルやボタンに合わせて押下(指等でタッチ)することにより、各種の指示を行うことができることとする。
また、タッチパネルは、マルチタッチスクリーン等の、複数の指でタッチされた位置を検出することが可能なタッチパネルであってもよい。
出力コントローラ206は、出力部210の表示を制御する。この出力部210としては、例えば、CRTや液晶ディスプレイ等が挙げられる。尚、本体と一体になったノート型パソコンのディスプレイも含まれるものとする。また、プロジェクタであってもよいこととする。
外部メモリコントローラ207は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザーファイル、編集ファイル、プリンタドライバ等を記憶する外部メモリ211へのアクセスを制御する。外部メモリ211には、各サーバ、クライアント、装置等の各種機能を実現するための各種テーブル、パラメータが記憶されている。この外部メモリ211としては、ハードディスク(HD)やフレキシブルディスク(FD)、PCMCIAカードスロットにアダプタを介して接続されるコンパクトフラッシュ(登録商標)、スマートメディア等が挙げられる。
なお、CPU201は、例えばRAM202内の表示情報用領域へアウトラインフォント展開(ラスタライズ)処理を実行することにより、出力部210上での表示を可能としている。また、CPU201は、出力部210上の不図示のマウスカーソル等でのユーザ指示を可能とする。
通信I/Fコントローラ208は、ネットワークを介して外部機器との通信制御処理を実行する。例えば、TCP/IPを用いた通信等が可能である。
本発明を実現するためのプログラム212は外部メモリ211に記録されており、必要に応じてRAM202にロードされることによりCPU201によって実行されるものである。
図3は、本発明の実施の形態のソフトウェア構成を示すブロック図の一例である。
プログラム開発装置101は、以下の機能部を備える。
IO定義受付部301は、アプリケーションに表示される画面やアイテム(入出力項目)の配置などのIO定義画面をユーザから受け付ける。
イベント表示画面定義部302は、IO定義画面のアクションイベントに対応して表示されるイベント表示画面をユーザから受け付ける。
表示画面データ受付部303は、イベント表示画面に表示されるアイテム(入出力項目)にプロトタイプアプリケーションで表示するデータの入力を受け付ける。
アプリケーション生成部304は、IO定義画面、イベント表示画面、プロトタイプアプリケーションで表示される入力されたデータをアクションイベントに対応して動作するように制御するプロトタイプアプリケーションを生成する。
アクションイベントデータ定義部305は、プロトタイプアプリケーションで表示される入力されたデータをアクションイベントに定義することを行う。
項目属性取得部306は、IO定義画面に定義された項目名や文字列の型情報などを取得する。
プロトタイプデータ記憶部307は、プロトタイプデータサンプル(プロトタイプデータのサンプルとなるデータ)を記憶している。
プロトタイプデータ取得部308は、プロトタイプデータサンプルからデータを抽出する。
プロトタイプデータ選択受付部309は、複数のプロトタイプデータサンプルからユーザの選択をドロップダウンリストなどから取得する。
項目名対応部310は、複数の項目名に対応する類義語のデータを有する名寄せの機能を果たす。
表示件数受付部311は、一覧表示をするプロトタイプアプリケーションを生成する際に何件分のリストを表示させるかをユーザから受け付ける。
図4は、プログラム開発装置101、アプリケーションサーバ102及びアプリケーションクライアント104の構成図である。
プログラム開発装置101は、リポジトリ定義部400、プロトタイプアプリケーション生成部410、リポジトリ定義エディタ部420を備える。なお、本発明のプロトタイプアプリケーションとは、本番環境のようにデータベースからデータを検索したり、算出したデータ結果から作図をしたりするアプリケーションとは異なり、予め設定された値や予め作図された図などを表示し、画面遷移や表示変更などを実際のアプリケーションのように模倣するモックアップとしてのアプリケーションとする。
アプリケーションサーバ102は、図4ではアプリケーションサーバ430に該当し、アプリケーションクライアント104は、Webブラウザ450を備える。
プログラム開発装置101は、プロトタイプ生成部410によりプロトタイプアプリケーション440を生成する。本発明での開発者とは、アプリケーションの受託開発者に限らず、ビジネスユーザや営業担当者などの広くプログラム開発装置101を使用する者を指す。
リポジトリ定義部400には、アプリケーション定義401、画面定義402、画面部品定義403、画面遷移定義404、画面部品定義402に紐づくアクション405、アクション405に紐づくプロトタイプデータ406が記憶されている。プロトタイプデータとは、プロトタイプアプリケーションを実行する際にアプリケーション画面に表示されるデータを指し、本番環境のようにデータベースからデータを検索したり、算出したデータ結果から作図をしたりするものではなく、開発者により予め設定されている値や図を指す。これら401〜406の定義は、アプリケーション開発ツールを介して、開発者によって入力設定または配置される。
アプリケーション定義401は、開発者が開発するアプリケーション全体の設定を保持する。
画面定義402は、アプリケーションに含まれる各画面に配置される各種画面部品定義403及び画面遷移定義404の情報を保持する。画面定義402は、各種部品に設定されるアクション405及びアクション405に紐づくプロトタイプデータ406の情報を含む。
プロトタイプアプリケーション生成部410は、開発者により設定されたリポジトリ定義部400を解析し、プロトタイプアプリケーションを生成する。また、プロトタイプアプリケーション生成後にアプリケーションサーバ430を起動させる。起動されたプロトタイプアプリケーションは、アプリケーションクライアント104のWebブラウザ450からアクセスすると、生成したプロトタイプアプリケーションの画面を表示する。
リポジトリ定義解析部411は、開発者により設定されたリポジトリ定義部400を解析する。
プロトタイプコード生成部412は、リポジトリ定義解析部411の解析結果に応じたプロトタイプアプリケーションのソースコードを生成する。
ソースコードコンパイル部413は、プロトタイプコード生成部412の生成したソースコードをコンパイルしアプリケーションサーバ430にデプロイする。
リポジトリ定義エディタ部420は、ユーザがリポジトリ定義400を設定するための手順の一例である。リポジトリ定義エディタ部420は、画面定義エディタ部421、画面プロパティエディタ部422、部品パレット部423、アクション選択部424、プロトタイプデータ入力部425を含む。
画面定義エディタ部421は、開発者が所望の画面レイアウトを直観的に作成するためのグラフィカルエディタである。
画面プロパティエディタ部422は、開発者が配置した各画面部品に対するプロパティを設定するエディタである。
部品パレット部423は、開発者が所望の画面部品をドラッグ&ドロップによって画面に配置するための部品(アイテム)一覧である。
アクション選択部424は、開発者がプロトタイプデータ406を設定する対象のアクションを選択するためのアクション(アクションイベント)一覧である。
プロトタイプデータ入力部425は、特定のアクション405に紐づくプロトタイプデータ406を直観的に設定するためのグラフィカルエディタである。
アプリケーションサーバ430は、プロトタイプアプリケーション生成部410が生成したプロトタイプアプリケーション440を実行するための装置である。
プロトタイプアプリケーション440は、プロトタイプアプリケーション生成部410が生成したアプリケーションである。プロトタイプアプリケーション440は、開発者として、プログラム開発装置101が生成するアプリケーションの表示内容や動作等を手軽に確認するためのモックアップアプリケーションである。プロトタイプアプリケーション440は、画面モジュール441、アクション制御モジュール442及びプロトタイプデータ443を含む。
画面モジュール441は、プロトタイプアプリケーション440のうちユーザインタフェースの機能を持つモジュールである。
アクション制御モジュール442は、画面モジュール441からユーザのアクション実行要求を受付け、該アクションに紐づいた動作を制御するモジュールである。
プロトタイプデータ443は、アクション制御モジュール442によって読込まれ、画面モジュール441に表示されるデータである。
また、図示はしないが、プロトタイプアプリケーションではなく、実際に動作するアプリケーションコード生成部も有している。アプリケーションコード生成部は、リポジトリ定義解析部411により、リポジトリ定義部400から、アプリケーション定義401、画面定義402、別に定義されたデータベース定義、データモデル定義、ビジネスプロセス定義、を読み込み解析する。Webアプリケーションコード生成部は、外部メモリ211に記憶されているコード生成ルールと、リポジトリ定義解析部411によって解析された内容とを用いて、ソースコードコンパイル部413を介し、コンパイル済Java(登録商標)コード及びHTML/JSP/JavaScript(登録商標)を含むWebアプリケーションモジュールを生成する。
図5は、Webアプリケーションのプロトタイプアプリケーション生成のフローチャートの一例を示す図である。なお、以下のフローチャートの各ステップは、各装置のCPU201が実行する。
図5のフローチャートは、開発者がプロトタイプアプリケーションを生成しようとする際にプログラム開発装置101で開始される処理の流れである。
まず、ステップS501において、プログラム開発装置101は、画面定義入力を受付ける。ステップS501の処理の詳細は図6を参照して後述する。
次に、ステップS502において、プログラム開発装置101は、プロトタイプデータ443の入力要求があったかを判定する。具体的には、アクション選択部424の一例である図12の1201及び1202、もしくは1203及び図13の1301が押下されたかを判定する。
ここでプロトタイプデータ443とは、開発者がプロトタイプアプリケーション440のアプリケーションの表示内容や動作を確認するために、画面に表示するデータを指す。データを表示する画面はWebブラウザ450でも、画面定義エディタ部であってもよい。
アクション制御モジュール442は、開発者によって設定された複数のプロトタイプデータのうち、プロトタイプアプリケーション440実行時のどのタイミングでどのデータを表示するかを制御する。また、アクション制御モジュール442は、画面に配置された部品が持つ各アクションに紐づいた動作を制御する。すなわち、プロトタイプデータはアクション(アクションイベント)に紐づく。
プログラム開発装置101は、開発者がこれから入力するプロトタイプデータが、どのアクションに紐づくものかを指定させるために、該押下を受付ける。
ステップS502において、プロトタイプデータ入力要求があったと判定した場合には、ステップS503に遷移する。
一方、ステップS502において、プロトタイプデータ入力要求がなかった場合には、ステップS504に遷移する。
なお、1201が押下された場合の、アクション選択部の一例を1202に示す。また、1203が押下された場合の、アクション選択部の一例を1301に示す。1301の例では、表示中の画面定義に含まれるアクション一覧を表示しているが、アプリケーション定義に含まれるアクション一覧を表示してもよい。
ステップS503に遷移すると、プログラム開発装置101は、ユーザからのプロトタイプデータの入力を受付ける。ステップS503の処理の詳細は図7を参照して後述する。その後、ステップS504へと処理を遷移する。
ステップS504において、プログラム開発装置101は、画面定義保存要求があったかを判定する。画面定義保存要求があったと判定した場合には、ステップS505に遷移し、画面定義保存要求がなかった場合には、ステップS506へと遷移する。
ステップS505に遷移すると、プログラム開発装置101は、画面定義をリポジトリ定義部400に保存する。その後、ステップS506へと処理を遷移する。
ステップS506に遷移すると、プログラム開発装置101は、プロトタイプ生成要求があったかを判定する。プロトタイプ生成要求があったと判定した場合には、ステップS507に遷移する。一方、プロトタイプ生成要求がなかった場合には、ステップS501に遷移する。
ステップS507へと遷移すると、プログラム開発装置101は、プロトタイプアプリケーションのソースコードを生成する。ステップS507の処理の詳細は図7を参照して後述する。
次に、ステップS508において、プログラム開発装置101は、ステップS507において生成したソースコードのコンパイルを行う。
ステップS509において、プログラム開発装置101は、ステップS508においてコンパイルしたプロトタイプアプリケーションをアプリケーションサーバ430にデプロイする。
以降は、プログラム開発装置101と、アプリケーションサーバ102、アプリケーションクライアント104が同じ情報処理装置で実施されている例で説明するが、それぞれが別の情報処理装置の場合は、それぞれの情報処理装置が、各アプリケーション(プロトタイプアプリケーションやWebブラウザなど)を起動して処理を実行する。
ステップS510において、プログラム開発装置101は、アプリケーションサーバ430にデプロイされたプロトタイプアプリケーションを起動する。
ステップS511において、プログラム開発装置101は、Webブラウザを起動し、プロトタイプアプリケーションのURLアクセスを開始する。
以上で、図5の説明を終了する。以降の処理は図9を参照して後述する。
次に、ステップS501の処理の詳細を図6を参照して説明する。
図6は、Webアプリケーションの画面定義の入力を受け付けるフローチャートの一例を示す図である。なお、以下のフローチャートの各ステップは、各装置のCPU201が実行する。
図6のフローチャートは、図5のフローチャートにおいて、ステップS501へと処理が遷移した際に開始される処理の流れである。
まず、ステップS601において、プログラム開発装置101は、開発者による画面部品の配置を受付ける。具体的には、部品パレット部423の一例である図10の1001から、画面定義エディタ部421の一例である1002へのドラッグ&ドロップ1003による部品の配置を受付ける。図10は、部品パレット部からボタン部品を画面定義エディタ部にドラッグ&ドロップした例を示している。画面部品の配置方法は、部品パレット部423から画面定義エディタ部421へのドラッグ&ドロップに限らず、既に配置した部品を移動する方法や、既に配置した部品をコピー&ペーストにより複製する方法であってもよい。また、一度配置した部品を削除できてもよい。
図10の場合は、1004のように、2つのテキスト入力欄(ID入力欄と名前入力欄)と、IDと名前を登録する登録ボタンを設けた画面イメージが作成されているイメージである。
次に、ステップS602において、プログラム開発装置101は、アクションイベントを含む部品が配置されたかを判定する。アクションイベントを含む部品が配置されたと判定した場合には、ステップS603に遷移し、アクションイベントを含む部品が配置されていない場合には、ステップS604に遷移する。
ステップS603に遷移すると、プログラム開発装置101は、アクションイベントを含む部品に設定されたアクションを登録する。具体的には、部品のソースコードにonClickというアクションを持つ部品の場合にアクションを登録する。画面定義402の一例である図21の2100には、本番環境に対応した“actions”の定義2102と、プロトタイプアプリケーションに対応した“examples”の定義2103を書き出す。なお、図21の例では、実施手段の一例としてデータ保持の形式をjsonファイルとしているが、データ保持の形式は他形式ファイルであってもデータベースであってもよい。その後、ステップS604へと遷移する。
次に、ステップS604において、プログラム開発装置101は、プロパティ入力要求のあったかを判定する。具体的には、選択された部品のプロパティ入力要求ボタンの一例である図11の1101が押下されたかを判定する。
プロパティ入力要求のあったと判定した場合、ステップS605に遷移し、プロパティ入力要求のなかった場合、画面定義入力受付処理を終了する。
ステップS605へと遷移すると、プログラム開発装置101は、開発者による画面部品に対するプロパティの入力を受付ける。具体的には、画面プロパティエディタ部422の一例である図11の1102を表示し、該画面部品が持つプロパティへの設定の入力を受付ける。図11の例では、開発者による直観的な操作を実現するために画面プロパティエディタ部422を該部品付近に表示しているが、画面内の特定の領域を画面プロパティエディタ部422として確保してもよい。また、画面プロパティエディタ部422をモーダルダイアログで表示してもよい。
以上で、図6の説明を終了する。
次に、ステップS503の処理の詳細を図7を参照して説明する。
図7は、Webアプリケーションのプロトタイプアプリケーションを生成する際に画面に表示するプロトタイプデータの入力を受け付けるフローチャートの一例を示す図である。なお、以下のフローチャートの各ステップは、各装置のCPU201が実行する。
図7のフローチャートは、図5のフローチャートにおいて、ステップS503へと処理が遷移した際に開始される処理の流れである。
まず、ステップS701において、プログラム開発装置101は、図5ステップS502において開発者が指定したアクションアイテムの設定を読込む。具体的には、次の二つを実施する。まず、開発者が選択した画面部品の画面部品定義403の一例である図10の1004の例である図21の2101を読込む。2101のデータは、図6のフローチャートのステップS605で、図11の1102から入力されたものとする。次に、開発者に選択された画面部品の本番環境に対応した“actions”の定義2102と、プロトタイプアプリケーションに対応した“examples”の定義2103を読込む。
次に、ステップS702において、プログラム開発装置101は、ステップS701で読込んだアクションアイテムの設定が画面遷移を伴うかを判定する。具体的には、画面部品定義403の一例である2101の画面遷移定義404の一例である”nextUi”プロパティ(1102内の次画面プロパティ)に値が設定されているかを判定する。本実施例では、プログラム開発装置101は、画面遷移定義404を画面部品定義403に保持しているが、アクション定義405に保持してもよい。
ステップS701で読込んだアクションアイテムの設定が画面遷移を伴うと判定した場合には、ステップS703に遷移し、ステップS701で読込んだアクションアイテムの設定が画面遷移を伴わない場合には、ステップS704に遷移する。
ステップS703へと遷移すると、プログラム開発装置101は、ステップS701で読込んだアクションアイテムの設定に伴う画面遷移の遷移先画面を表示する。具体的には、2101の”nextUi”に設定された画面である図13の1300を表示する。なお、図13の遷移先画面1302も、ユーザの操作(ステップS601)により事前に設定されているものとする。なお、1302のような画面は、現在表示されている画面定義エディタ部421を書き換える表示方法であっても、新たな画面定義エディタ部421を起動する表示方法であってもよい。
画面定義エディタ部421に表示される画面イメージ(遷移先画面)の初期表示アクションを読込み、これを開発者が指定したアクションとする。この処理後、ステップS704へと処理を遷移する。
ステップS704において、プログラム開発装置101は、S701で読込んだアクション、もしくはS703で読込んだアクションに既に設定されているプロトタイプデータ(たとえば、図22の2201のようなデータが既に設定されている場合はそのデータ)を画面上に表示する。
次に、ステップS705において、プログラム開発装置101は、開発者による、プロトタイプデータ表示部品の選択を受け付ける。ここでプロトタイプデータ表示部品とは、プロトタイプアプリケーションを動作させる際に予めデータ(プロトタイプデータ)を表示させておく部品のことを示す。具体的には、画面定義エディタ部421に表示された図13の1302のような一覧表の中にプロトタイプデータを表示する例である。同じ図である図14のプロトタイプデータ表示部品1402において、たとえば「Name」欄で図示しないマウスを右クリックし、1403の編集ボタンが押下されることで、プロトタイプデータ表示部品の選択を受け付けることができる。また、図17の1701のように一覧全体を選択後、表入力ボタン1702が押下されると、プロトタイプデータ表示部品の選択として、1701の一覧全体を選択することができる。
次のステップS706において、プログラム開発装置101は、開発者によるプロトタイプデータの入力を受付ける。具体的には、プロトタイプデータ入力部425の一例である図15のプロトタイプデータ入力ダイアログ1501を表示する。1501は、図14の1401において、「Name」欄で編集ボタンが押下された際に表示するプロトタイプデータ入力ダイアログである。1501の場合、ユーザから「Name」欄に「谷川 則之」というプロトタイプデータが入力されている例である。ユーザからの値の入力後、1501内の「OK」ボタンの押下により、ステップS707の入力確定か否かの判断を行う。
また、ステップS706の別の例として、プロトタイプデータ入力部425の一例を図18を参照して説明する。
図18のプロトタイプデータ入力ダイアログ1801は、図17において表入力ボタン1702が押下されると表示される画面イメージである。1801のテキスト入力欄には、1701に表示する一覧表に表示されるデータ群の入力を受け付ける。1801の場合は、1行目に「(空欄)」、「谷川 則之」、「(空欄)」、2行目に「1001」、「堀 亜衣」、「2019/10/10」、3行目に「1002」、山村 るり子」、「2019/09/18」というデータが入力されている。これらのデータ入力はファイル選択ボタン1802の押下により表示される図示しないファイル選択画面からCSVファイルや表計算ファイルが選択されることにより、そのファイルの内容を適応させても良い。
ユーザからテキスト入力欄への値の入力、もしくはファイル選択後のデータ反映後、1803の「OK」ボタンの押下により、ステップS707の入力確定か否かの判断を行う。
ステップS706では、言語によって表示するプロトタイプデータを切り替えるために、ロケールの指定を受付けてもよい。また、プロトタイプデータ入力受付方法として、モーダルダイアログを表示する方法を示しているが、該入力受付方法は、S705で開発者が選択した表示部品に対して直接入力を受付ける方法であってもよいし、外部ファイルによる一括入力であってもよい。
次のステップS707において、プログラム開発装置101は、開発者によるプロトタイプデータ入力が確定したかを判定する。具体的には、図15のプロトタイプデータ入力ダイアログ1501内の「OK」ボタンや図18の「OK」ボタン1803が押下されたかを判定する。なお、ステップS706の入力受付方法において、部品に対する直接入力を受付けた場合は、該部品からフォーカスが外れたかにより判定する。
プロトタイプデータ入力が確定したと判定された(「OK」ボタンが押下された)場合は、ステップS708に遷移し、プロトタイプデータ入力が確定していないと判定した場合は、ステップS706に遷移する。
ステップS708において、プログラム開発装置101は、開発者によって入力されたプロトタイプデータを画面定義402に書き出す。具体的には、画面定義402のアクション405に紐づくプロトタイプデータ406の一例である2201に書き出す。
なお、この方法では、実行するアクションによる遷移後画面で表示するデータの変更ができない。プロトタイプデータを遷移後画面の初期表示アクションに保持しているためであるが、遷移後画面で表示するプロトタイプデータを、実行するアクション側で保持することで、実行するアクションによる遷移後画面で表示するデータの変更を可能としてもよい。具体的には、2201の“onLoad”以下のオブジェクトを2103の“onClick”以下に保持することにより、画面を遷移する元のボタン(たとえば、図10の1000に配置された「登録」ボタン1003)に遷移後画面で表示するデータを持たせてもよい。
このように、プロトタイプデータを表示させた画面イメージをアクションイベントごとに画面を遷移させてプロトタイプアプリケーション上で表示することにより、実際に動作するアプリケーション(たとえばデータベースから検索したり、取り出したデータから作図したりする)を作る前に、モックアップとしてどのような動作をするのかのイメージを掴むことができる
以上で、図7の説明を終了する。
次に、ステップS507の処理の詳細を図8を参照して説明する。
図8は、Webアプリケーションのプロトタイプアプリケーションのソースコードを生成する処理の流れを説明するフローチャートの一例である。なお、以下のフローチャートの各ステップは、各装置のCPU201が実行する。
図8のフローチャートは、図5のフローチャートにおいて、ステップS507へと処理が遷移した際に開始される処理の流れである。
まず、ステップS801において、プログラム開発装置101は、リポジトリ定義部400から開発者が指定したアプリケーション定義401を読み込む。リポジトリ定義解析部411は、読み込んだ定義を解析したうえでROM203に記憶しておき、解析された定義は各生成部から適宜参照される。
ステップS802において、プログラム開発装置101は、リポジトリ定義部400からステップS801で読込んだアプリケーション定義401に含まれる画面定義402を読み込む。
ステップS803において、プログラム開発装置101は、リポジトリ定義部400からステップS802で読込んだ画面定義402に含まれる画面部品定義403を読込む。
ステップS804において、プログラム開発装置101は、リポジトリ定義部400からステップS802で読込んだ画面定義402に含まれる画面遷移定義404を読込む。
ステップS805において、プログラム開発装置101は、リポジトリ定義部400からステップS802で読込んだ画面定義402に含まれるプロトタイプデータ406を読込む。ここで読み込む画面定義402内のデータは、プロトタイプデータに対応した図21や図22の「examples」のデータであり、「actions」すなわち本番環境用のデータは使用しない。この2つのデータを持つことで、プロトタイプデータの画面定義と本番環境の画面定義を共通で作成可能になり、モックアップ用に作成したアプリケーション画面をそのままアプリケーションの画面として定義することができる。
ステップS806において、プログラム開発装置101は、ステップS801〜ステップS806で読込んだ情報を元に、プロトタイプコード生成部412でプロトタイプアプリケーションのソースコードを生成する。
以上で、図8の説明を終了する。
次に、図5のプロトタイプアプリケーション生成の処理後のアプリケーションサーバ102でのプロトタイプアプリケーション440の動作を説明するフローチャートを図9を参照して説明する。
図9は、図5ステップS509でデプロイされたプロトタイプアプリケーション440の動作の一例を示すフローチャートの一例である。なお、以下のフローチャートの各ステップは、アプリケーションサーバ102(430)のCPU201が実行する。
図9のフローチャートは、プロトタイプアプリケーション440がアプリケーションサーバ430にデプロイされたあとで起動され、アプリケーションクライアント104のWebブラウザ450からユーザのアクセスがあった際に開始される処理の流れである。
ステップS901において、アプリケーションサーバ430は、まずブラウザのロケール情報を読込む。このロケール情報により、プロトタイプデータの表示言語を切り替えることができる。
ステップS902において、アプリケーションサーバ430は、ユーザによるアクション実行要求を受付ける。
ステップS903において、アプリケーションサーバ430は、ユーザによるアクション実行要求があったかを判定する。具体的には、生成された画面部品の一例である図19の1901が押下されたかを判定する。このとき、ユーザは、アプリケーションを使用した際のイメージを再現するための動作を確認することが目的であるため、「ID」入力欄や「Name」入力欄1902にはユーザによる入力は必ずしも必要ではない。
ステップS903において、アクション実行要求があった(1901が押下された)と判定した場合は、ステップS904に遷移し、ユーザによるアクション実行要求がなかった場合は、ステップS902へと戻る。
ステップS904に遷移すると、アプリケーションサーバ430は、実行要求のあったアクションの設定を読込む。たとえば、図22の2200のアクションの設定の場合、2201の“examples”以下の処理を実行する。なお、本番環境では2202の“actions”以下の処理を行うが、この“actions”以下の処理は、モックアップ用アプリケーションができた後で、開発者により具体的に動作するようにコーディングされていく。
ステップS905において、アプリケーションサーバ430は、ステップS904で読込んだアクションが画面遷移を伴うかを判定する。アクションが画面遷移を伴うと判定した場合は、ステップS906に遷移し、アクションが画面遷移を伴わない場合は、ステップS907に遷移する。
ステップS906に遷移すると、アプリケーションサーバ430は、ステップS904で読込んだアクションに設定された遷移先画面を表示する。具体的な遷移先画面の一例として、登録者一覧リストである図20の2000を示す。
ステップS907において、アプリケーションサーバ430は、ステップS904で読込んだアクションに設定されたプロトタイプデータを表示する。具体的なプロトタイプデータの一例として図20の2001を示す。2001は、図22の2201のプロトタイプデータを反映したデータの例である。
なお、ステップS901で読込んだブラウザのロケール情報に従って、ステップS904で読込んだアクションに設定されたプロトタイプデータの表示言語を設定しても良い。また、該当ロケール情報に対するプロトタイプデータが存在しなかった場合のために、デフォルトのロケールを設定できてもよい。また、画面部品からユーザによる言語指定を受付け、それに従ってプロトタイプデータを表示してもよい。これらプロトタイプデータの表示言語のロケール対応により、多国籍の営業担当者やビジネスユーザでもシステムの動作を把握しやすくなるという効果がある。
以上で、図9の説明を終了する。
以上のような処理により、顧客に提案などを行う営業担当者やビジネスユーザなどが顧客の所望のアプリケーションのプロトタイプを直感的に作成することが可能となる。
また、本番用アプリケーションを生成する機能を有するプログラム開発装置における発明なので、本願発明で生成されるプロトタイプアプリケーションは、見た目や画面遷移が本番用アプリケーションと同じである。
すなわち、営業担当者が本番用アプリケーションと同じ画面の入出力項目(アイテム)や遷移画面を簡単に手直しでき、手直しされたIO定義画面や遷移画面は本番用アプリケーションへと反映されて、後日開発者が本番用アプリケーションを生成する際にそのまま使う事ができる。これによって、開発者と、営業担当者やビジネスユーザとに齟齬が生じるのを防ぎ、開発の手戻り発生を抑えられるという効果を有する。
<第二実施形態>
第一実施形態では、アプリケーションのプロトタイプデータを入力させてプロトタイプアプリケーションを生成する仕様を説明したが、第二実施形態では、プロトタイプデータのユーザの入力手間を減らすための手順について説明する。
図23は、プログラム開発装置101、アプリケーションサーバ102及びアプリケーションクライアント104の構成図である。
プログラム開発装置101は、リポジトリ定義部400及びプロトタイプアプリケーション生成部410を備える。
プログラム開発装置101は、アプリケーションを開発する開発者により設定されたリポジトリ定義部400の各定義を用いて、プロトタイプアプリケーション生成部410によりプロトタイプアプリケーションを生成する。
また、第二実施形態にはプロトタイプデータ設定部460と、プロトタイプサンプル管理部470とが追加される。
リポジトリ定義エディタ部420には、画面定義送信部426が追加される。
画面定義送信部426は、アプリケーション画面に配置される項目情報を含むUI定義情報を保持する。画面定義送信部426は、画面定義エディタ部422で配置された項目情報を含むUI情報(UIの項目名や文字列の型情報など)をプロトタイプデータ設定部460にある画面定義受信部461に送信する。
プロトタイプデータ設定部460は、画面定義受信部461、項目情報抽出部462、項目名463、型情報464、プロトタイプデータ取得部465、システム概要入力部466を有する。
画面定義受信部461は、画面定義送信部426から送られた配置された項目情報を含むUI情報を受信、保持する。
項目情報抽出部462は、受け取ったUI情報から項目名463と型情報464を抽出する。
プロトタイプデータ取得部465は、UI情報から抽出した項目名463と型情報464を用いて、プロトタイプデータサンプル管理部へアクセスし、項目名463と型情報464に適合するプロトタイプデータを抽出する。そして、抽出したプロトタイプデータをリポジトリ定義エディタ部420のプロトタイプデータ入力部424へ渡し、アプリケーション画面の該当項目にプロトタイプデータを出力させる。
システム概要入力部466は、フリーテキストでの入力を受け付ける。受け付けた内容はシステム概要解析部474へ渡す。
プロトタイプデータサンプル管理部470には、プロトタイプデータサンプル管理本体部471、類義語管理部472、システムカテゴリ管理部473、システム概要解析部474を有する。
プロトタイプデータサンプル管理本体部471は、プロトタイプデータ取得部465から受け取った項目名と型情報を用いて検索を行う。適合するプロトタイプデータがあれば、抽出し、プロトタイプデータ取得部465に渡す。
類義語管理部472は、プロトタイプデータ取得部465から受け取った項目名を用いて、プロトタイプデータサンプル管理本体部471に登録されていない項目名の類義語を検索する。類義語管理部472には複数の類義語を定義できるので、類義語を追加すればするほど、プロトタイプデータの検出効率が上がる。
システムカテゴリ管理部473は、プロトタイプデータサンプル管理本体部471でシステムカテゴリごとにプロトタイプデータを管理する。システムカテゴリはデフォルトなどユーザが自由に追加できる。システムカテゴリを追加することで、同じ項目名であっても、システムのカテゴリに合わせて適切なプロトタイプデータの例を抽出することができる。
システム概要解析部474は、システム概要入力部466から受け取った情報を用いて、形態素解析を行い、単語に分割し、プロトタイプデータサンプル管理本体部471で検索を実行する。これにより、システム概要に沿うプロトタイプデータの例を抽出できる可能性が上がる。
以上で、図23の説明を終了する。
次に、第二実施形態におけるプロトタイプデータのユーザの入力手間を減らすための処理手順を図24〜図26を参照して説明する。
図24は、プロトタイプデータサンプル登録処理の流れを説明するフローチャートの一例である。なお、以下のフローチャートの各ステップは、各装置のCPU201が実行する。
図24のフローチャートは、図6のフローチャートにおける、ステップS601の処理の後で実施する。なお、図24のフローチャートは、ステップS601の部品配置受付処理の後で、図7のステップS704の前であれば、いつ行っても良い。
まず、ステップS2401において、プログラム開発装置101は、ステップS601で配置された部品(入出力項目)の項目名(たとえば、図27の例では、2702のような「申請日」など)と入出力される文字の型情報(たとえば、図27の例では、2703のような日付型である「yyyymmdd」など)のUI情報の入力をユーザから受け付ける。なお、部品配置時には、図27のようなUI定義情報の各入出力項目には具体的な日付やデータは入力されていない。
ステップS2402において、プログラム開発装置101は、項目名と型情報に適合する実データ(プロトタイプデータサンプル)の登録を受け付ける。受け付けたプロトタイプデータサンプルの例を図28を参照して説明する。
図28の2801はプロトタイプデータサンプル管理本体部471が記憶するプロトタイプデータサンプルの例である。たとえば、「日付」データは、「日付型」の型形式で、実データ(プロトタイプデータサンプル)として、「20190918」が登録されている。これらの登録されたデータは、後日生成する他のシステムでも流用可能となり、登録できるデータの数に制限がないため、自由にデータ数を増やすことができる。そのため、このプロトタイプデータサンプルの蓄積が有用なデータとなる。
なお、このデータの登録は後述する図25と別に行う仕様で記載しているが、当初は図7のステップS706において入力されるプロトタイプデータをプロトタイプデータサンプルとして登録していってもよい。図24のフローチャートの説明に戻る。
次に、図24のステップS2403において、ステップS2402で受け付けたプロトタイプデータサンプルをファイルとして記憶する。なお、プロトタイプデータサンプルはデータベースに格納しても良いし、他の記憶手段で記憶しても良い。
以上で、図24の説明を終了する。
図25は、プロトタイプデータ自動生成処理の流れを説明するフローチャートの一例である。なお、以下のフローチャートの各ステップは、各装置のCPU201が実行する。
図25のフローチャートは、図7のフローチャートにおける、ステップS704の処理の際に実行される処理である。すなわち、遷移先画面を表示し、各入出力項目にプロトタイプデータをユーザが入力する画面に遷移する前に開始されるフローチャートである。
まず、ステップS2501において、プログラム開発装置101は、画面定義受信部461を用いて、配置された項目情報を含むUI定義情報を受け取る。たとえば、図27のUI定義情報の場合、2701の画面の生成データやUI情報(UIの項目名や文字の型情報など)を取得する。
ステップS2502において、プログラム開発装置101は、項目情報抽出部462を用いて、受け取ったUI定義情報から項目名463と型情報464(UI情報)を抽出する。たとえば、図27の場合、「申請日」という項目名2702の、型情報2703が「yyyymmdd」というUI情報を抽出する。
ステップS2503において、プログラム開発装置101は、プロトタイプデータ取得部465を用いて、プロトタイプデータサンプル管理部470にアクセスし、プロトタイプデータを抽出する。ステップS2503の具体的な処理は図26で後述する。
ステップS2504において、プログラム開発装置101は、ステップS2503で抽出された項目名と型情報に適合するプロトタイプデータのあるかどうかを判定する。項目名と型情報に適するプロトタイプデータがあったと判定した場合には、ステップS2505に遷移する。一方、項目名、型情報に適するプロトタイプデータがなかった場合には、プロトタイプデータ自動生成処理を終了し、次の図7のステップS706でユーザからの入力を受け付ける。
ステップS2505へと遷移すると、プログラム開発装置101は、プロトタイプデータ取得部465を用いて、プロトタイプデータ入力部425に抽出したプロトタイプデータを受け渡す。そして、プログラム開発装置101は、プロトタイプデータ入力部425を用いて該当項目にプロトタイプデータを登録する。登録されたプロトタイプデータの例を図30を参照して説明する。
図30は、図27のUI定義情報で定義されいるデータのプロトタイプデータの例である。「申請日」や「利用日」などの「日付」と異なる項目名に対しても「20190918」というプロトタイプデータが割り当てられている件は図26で後述する。
以上の処理により、プロトタイプアプリケーションを作成する際に表示するアイテムにプロトタイプデータをユーザが入力する手間を大幅に削減することができ、顧客に提案などを行う営業担当者やビジネスユーザ(顧客の意思決定者)などでも手軽にプロトタイプアプリケーション(予め設定された値や予め作図された図などを表示し、画面遷移や表示変更などを実際のアプリケーションのように模倣するモックアップとしてのアプリケーション)を作成することができる。
なお、プロトタイプデータとして一覧表示をする場合(たとえば、図20の2000)は、ユーザから、プロトタイプデータの抽出件数の入力を受け付け、入力を受け付けた抽出件数分のデータを一覧形式で表示できるようにプロトタイプデータを登録しても良い。図20の場合は、たとえば、プロトタイプデータの抽出件数を図示しない画面から3件と入力した場合の結果とみることができる。このように、プロトタイプデータを一覧表示するプロトタイプアプリケーションも自動で生成することができる。
その他、一覧表示する際に共通する文字列を検索した結果を示すかのようなデータを表示させるために、共通部分とそれ以外の部分を別にデータを登録しておいても良い。たとえば、氏名として「田中」「山本」と「史朗」「彩」「角栄」を別に登録しておく。プロトタイプデータとして複数件登録して表示する場合に、共通部分入力を設定すると、3件一覧表示する際にたとえば「田中史朗」「田中彩」「田中角栄」のように共通したデータを有するデータを登録できる。このように、共通部分を有するプロトタイプデータを生成することにより、一覧表示の結果画面があたかも検索した結果(前例では「田中」)のような表示のプロトタイプアプリケーションを生成することができる。
以上で、図25の説明を終了する。
図26は、プロトタイプデータサンプル管理部470からプロトタイプデータを抽出する処理の流れを説明するフローチャートの一例である。なお、以下のフローチャートの各ステップは、各装置のCPU201が実行する。
図26のフローチャートは、図25のフローチャートのステップS2503のサブルーチンとして実行される処理である。
まず、ステップS2601において、プログラム開発装置101は、プロトタイプデータサンプル管理本体部471を用いて、プロトタイプデータ取得部465から、項目名463と型情報464を受け取る。具体的には、図7のステップS703で表示している画面のUI定義情報を取得し、各入出力項目のUI情報(項目名463と型情報464)を取得する。
ステップS2602において、プログラム開発装置101は、必要な類義語が記憶されている類義語管理部472を用いて、項目名463が適合できる類義語があるかを判定する。適合する類義語があったと判定した場合には、ステップS2603に遷移し、適合する類義語がなかった場合には、ステップS2604に遷移する。
ステップS2602の具体的な判断を図27のUI定義情報の一例2701、図29の類義語管理部2901を参照しながら説明する。2901は、UI定義情報から受け取った項目名を、類義語管理部2901に問い合わせることにより、プロトタイプデータサンプル管理本体部で対応できる項目名に変更するための類義語辞書である。一例として、UI定義情報から「氏名」という項目名を取得したとする。類義語管理部472には、「氏名」「申請者」「承認者」といった項目名を、「名前」と同様の項目としてシステムが認識できるように登録されているため、「名前」以外の項目である「氏名」でもプロトタイプデータサンプル管理本体部で対応できるようになる。
たとえば、図27の入出力項目2702の項目名は、「申請日」であり、「申請日」という項目名に対応する類義語があるか、図29の2901を参照して判定する。2901には、「日付」2902の類義語として「申請日」2903が登録されているので、項目名が「申請日」のプロトタイプデータサンプルは「日付」から取得することになる。すなわち「申請日」にはプロトタイプデータサンプルに存在する「日付」という適合する項目名があった例である。図26のフローチャートの説明に戻る。
ステップS2603へと処理を遷移すると、プログラム開発装置101は、ステップS2601で取得した項目名(上記の場合「申請日」2702)のプロトタイプデータサンプルにおける新たな項目名(上記の場合「日付」2902)を取得する。
ステップS2604において、プログラム開発装置101は、プロトタイプデータサンプル管理本体部に、ステップS2601もしくはステップS2603で取得した項目名や項目の文字列の型情報が適合しているデータがあるかを判断する。適合するデータがあったと判定した場合には、ステップS2605に遷移し、適合する類義語がなかった場合には、図26のフローチャートの処理を終え、ステップS706でユーザからの入力を受け付ける。
ステップS2604の具体的な判断を図27のUI定義情報の一例2701、図28のプロトタイプデータサンプル管理本体部の記憶データ2801、図29の類義語管理部2901を参照しながら説明する。
たとえば、図27の入出力項目2702の項目名は、「申請日」であり、「申請日」という項目名に対応する新しい項目名「日付」を図29の2902から取得する。新しい項目名「日付」に適合するプロトタイプデータサンプルとして、図28のプロトタイプデータサンプル管理本体部の記憶データ2801に「日付」が登録されているかを判断する。図28の場合は、「日付」が2802に登録されているので、ステップS2605へと処理を遷移する。図26のフローチャートの説明に戻る。
ステップS2605へと処理を遷移すると、プログラム開発装置101は、ステップS2604で適合した項目名「日付」2802に登録されたプロトタイプデータサンプルとして、「20190918」2803を抽出し、プロトタイプデータとして記憶する。その後、図7のフローチャートへと戻り、以降の処理を実行して図8のフローチャートでプロトタイプアプリケーションを生成する。
以上のようにプログラム開発装置101によりプロトタイプデータが入力されたプロトタイプアプリケーションが生成される。生成されたプロトタイプアプリケーションの例を図27を参照して説明する。
図27の「申請日」2702や「利用日」には、たとえば、図29の類義語管理部2901のデータにより、類義語「日付」2902が適合され、図28のプロトタイプデータサンプルの「日付」2802に登録されている「20190918」が登録されている。同様に図27の「申請者」欄や「目的地」、「出発」、「到着」などの項目名も、図29の類義語管理部2901のデータにより、対応するプロトタイプデータサンプル内の項目名に適合され、プロトタイプデータサンプル2801のプロトタイプデータが登録されている。なお、「出発」と「到着」など、同じプロトタイプデータサンプルからプロトタイプデータを取得する際にプロトタイプデータサンプルが複数ある場合は、たとえば2つは異なるプロトタイプデータを使うようにしてもよい。また、図27の項目欄(たとえば、「出発」の入出力項目)にドロップダウンリストを表示して、ユーザに選択(図28の場合、「東京駅」、「泉岳寺駅」、「有楽町駅」からの選択)させる仕様としてもよい。
以上のようにして、生成される図27のプロトタイプアプリケーションの例のプロトタイプデータの例を図30に示す。以上で図26のフローチャートの説明を終了する。
以上の処理のように、UI定義情報のUI情報(UIの項目名や文字列の型情報など)から、プロトタイプデータサンプルを抽出し、プロトタイプデータとして入出力項目(アイテム)に登録する。すなわち、プロトタイプアプリケーションを容易に生成することができる。
また、類義語管理部472を有することにより、項目名の名寄せができ、少ないプロトタイプデータサンプルであってもプロトタイプデータを割り当てることができる。
また、一覧形式のプロトタイプデータを登録する場合は、登録したい件数の数字を入力するだけで、プロトタイプデータの一覧を登録したプロトタイプアプリケーションを生成することができる。
さらに、一覧形式でのプロトタイプデータを登録する場合に、文字列の一部を共通にすることにより、あたかも検索結果であるかのようなプロトタイプアプリケーションを生成することができる。
以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ(またはCPUやMPU)が記録媒体に格納されたプログラムを読み出し、実行することによっても本発明の目的が達成されることは言うまでもない。
この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記録した記録媒体は本発明を構成することになる。
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、CD−ROM、CD−R、DVD−ROM、磁気テープ、不揮発性のメモリカード、ROM、EEPROM、シリコンディスク等を用いることが出来る。
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているOS(オペレーティングシステム)等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPU等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
また、本発明は、複数の機器から構成されるシステムに適用しても、ひとつの機器から成る装置に適用しても良い。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
上記プログラムの形態は、オブジェクトコード、インタプリタにより実行されるプログラムコード、OS(オペレーティングシステム)に供給されるスクリプトデータ等の形態から成ってもよい。
さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。