JP7231864B2 - 情報処理装置、情報処理方法およびプログラム - Google Patents

Description

本発明は、アプリケーションソフトウェアを生成する情報処理装置、情報処理方法およびプログラムに関する。

昨今、ユーザに高速なレスポンスを返すことができ、優れたＵＩ／ＵＸを提供できるシングルページアプリケーション（ＳＰＡ）が活用されている。シングルページアプリケーションは、１枚のＨＴＭＬに対してＪａｖａＳｃｒｉｐｔで動的に変更を加えながら画面の描画を実現しているのが特徴であり、ページ全体をロードするのは初回のみで、２回目以降はサーバからＪＳＯＮデータを受け取ることで必要箇所のみリロードする。サーバサイドで画面を生成する必要がなくなり、最小限のデータ転送でアプリケーションソフトウェアが動くシステムを形成できるため、ユーザ側の待ち時間が減り、ユーザの満足度に繋がる。

ところで、シングルページアプリケーションは最初にクライアントに送信されたページから次のページにＵＩが遷移しても、シングルページなので、ＵＲＩは同じとなりすべての画面が同じＵＲＩになってしまうという課題がある。

そのため、シングルページアプリケーションの遷移した先の任意の画面にブックマークができず、その画面に遷移するためには初期表示画面から必ず同じ遷移をたどらないと目的の画面を表示できない。

上記課題を解決するために、シングルページアプリケーションではルーティングという画面ごとに任意のＵＲＩを設定する技術がある。

特許文献１には、Ｗｅｂアプリケーションを使用するための各種画面間の遷移関係等が複雑な場合には、シングルページアプリケーションの開発が困難になることを解決する発明が記載されている。

特開２０１７－２２０２２１号公報

しかし、シングルページアプリケーションを開発する開発者としては、ルーティング技術により遷移するＵＩ全てにＵＲＩが紐付けられると、アプリケーションソフトウェアのユーザに直接ＵＲＩで遷移させたくないＵＩ（画面）がある場合、不都合が生じる。

例えば入力画面→入力内容の確認画面→申請担当者（承認者）の選択画面のような画面遷移をするアプリケーションソフトウェアの場合、アプリケーションソフトウェアのユーザには入力内容の確認画面に直接ＵＲＩで遷移させたり、ブックマークをさせたくない。

ルーティングによる任意のＵＲＩの紐付けでは、このようなＵＲＩで直接遷移させる画面と直接遷移できない画面の両方が混じったシングルページアプリケーションを作成するには複雑なルーティング設定を作らねばならず、開発者にとって困難な作業であった。

本発明の目的は、直接遷移できる画面と直接遷移できない画面とを混在させたアプリケーションソフトウェアの生成を容易に行う仕組みを提供することである。

上記課題を解決するために、本願発明の一実施形態による情報処理システムは、生成されるアプリケーションソフトウェアで表示される画面について識別情報を付与するか否かの指示を受け付ける表示アイテムを表示するように制御する表示制御手段と、前記表示アイテムに対して受け付けた前記指示に応じたアプリケーションソフトウェアを生成するように制御する制御手段であって、前記表示アイテムで識別情報を付与する指示を受け付けた第１の画面と、前記表示アイテムで識別情報を付与する指示を受け付けていない第２の画面とを表示可能な特定のアプリケーションソフトウェアであって、前記特定のアプリケーションソフトウェアが実行される際に、前記第１の画面の表示を指示するための前記第１の画面の識別情報を前記特定のアプリケーションソフトウェアのユーザに対して出力し、前記第２の画面の表示を指示するための前記第２の画面の識別情報を前記ユーザに対して出力しないように動作する前記特定のアプリケーションソフトウェアを生成可能な制御手段とを有する。

本発明により、単一であるリソースを一意に識別するための識別情報を用いて画面を切り替えて表示することが可能なアプリケーションの開発を容易に行う仕組みを提供することができる。

本実施形態のシステム構成図である。 本実施形態のプログラム開発装置、実行サーバ、データベースサーバ、クライアントＰＣのハードウェアブロック図である。 本実施形態のプログラム開発装置のソフトウェアの機能ブロック図である。 本実施形態システムの機能構成図である。 本実施形態のＷｅｂアプリケーション生成処理のフローチャートである。 本実施形態のルーティング設定処理のフローチャートである。 本実施形態の出力部２１０に表示される画面表示例である。 本実施形態の出力部２１０に表示される画面表示例である。 本実施形態のルーティング設定ファイルの例である。 本実施形態の出力部２１０に表示される画面表示例である。

以下、本発明の実施の形態を、図面を参照して詳細に説明する。

図１は、本発明に係わるプログラム開発装置（開発者がＷｅｂアプリケーション生成のために使用する情報処理装置）、プログラム開発サーバ、データベースサーバ、クライアントＰＣ（クライアント装置）、実行サーバ、Ｗｅｂサーバの構成の一例を示すシステム（情報処理システム）構成図である。

プログラム開発装置１０１は、開発者の操作に従って画面レイアウト及びデータベース検索指示などを定義する。なお、プログラム開発装置１０１では、開発者の入力受付を行い、後述するプログラム開発サーバ１０２に実際のプログラム生成処理、アプリケーション生成処理（アプリケーションソフトウェアの生成処理）を行うというように役割を分けてもよいし、プログラム開発装置１０１単体でプログラム生成、アプリケーションソフトウェア生成までを行ってもよい。

なお、この実施形態においては、プログラム開発装置１０１で生成するアプリケーションソフトウェアはＷｅｂアプリケーションとしたが、これに限定するものではなく、携帯電話・スマートフォン・タブレットなどの情報処理装置で動作するアプリケーションソフトウェアや組込みソフトウェアなど、Ｗｅｂ技術による通信を利用したアプリケーションソフトウェアでなくてもよい。

また、本実施形態においては、プログラム開発装置１０１によってアプリケーションソフトウェアのプログラムを生成するとしたが、プログラムの生成に限定するものではなく、開発者の操作に従って設定された定義を用いて、アプリケーションソフトウェアが動作する環境を構築するとしてもよい。

プログラム開発サーバ１０２ａ～１０２ｂ（情報処理装置）は、プログラム開発装置１０１により入力された開発者の設定及び指示に従って、プログラムを生成する。プログラム開発サーバ１０２ａはＬＡＮなどのネットワーク１０７内に配置されてもよいし、プログラム開発サーバ１０２ｂはインターネット上やクラウド上に配置されてもよい。

データベースサーバ１０３ａ～１０３ｂ（情報処理装置）は、開発されたアプリケーションソフトウェアが使用するデータベースであり、また本発明では開発時にも動作確認などのために利用してもよい。例えば、開発者が利用するためにデータベースサーバ１０３は、プログラム開発装置１０１と同一の装置で構成されていてもよいし、ＬＡＮなどのネットワーク１０７内に配置されてもよい（データベースサーバ１０３ａ）。またインターネット上やクラウド上に配置されてもよい（データベースサーバ１０３ｂ）。また、プログラム開発装置１０１が、プログラム開発サーバ１０２と協調する場合には、プログラム開発サーバ１０２とデータベースサーバ１０３が同一の装置内に構成されていてもよい。

実行サーバ１０５（情報処理装置）は、プログラム開発装置１０１で生成されたアプリケーションプログラム（プログラム開発装置１０１で生成されたアプリケーションソフトウェアのプログラム）を実行する。実行サーバ１０５は、ＬＡＮなどのネットワーク１０７内に配置されてもよい（実行サーバ１０５）し、またインターネット上やクラウド上に配置されてもよい（実行サーバ１０５ｂ）。また、ネットワーク１０７、インターネット、クラウド上のデータベースサーバ１０３と接続して動作することが可能である。

クライアントＰＣ１０４ａ～１０４ｂ（情報処理装置）は、実行サーバ１０５と協調してプログラム開発装置１０１で開発したアプリケーションプログラムを動作させる、ユーザの入力端末である。ＬＡＮなどのネットワーク１０７内に配置されてもよい（クライアントＰＣ１０４ａ）し、またインターネット上やクラウド上に配置されてもよい（クライアントＰＣ１０４ｂ）。携帯端末などの情報処理装置であってもよい。

図２は、本発明に係わるプログラム開発装置１０１、実行サーバ１０５、データベースサーバ１０３、クライアントＰＣ１０４として適用可能な各ハードウェア構成の一例を示すブロック図である。

図２において、ＣＰＵ２０１は、少なくとも１つのプロセッサであり、システムバス２０４に接続される各デバイスを統括的に制御する。

また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるオペレーティングシステム（ＯＳ）や、各サーバ、クライアント、装置など情報処理装置の後述する各種機能を実現するためのプログラムが記憶されている。

ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア、一時待避領域等として機能する。

入力コントローラ２０５は、入力部２０９からの入力を制御する。この入力部２０９としては、情報処理装置では、キーボード、マウス等のポインティングデバイス、タッチパネルが挙げられる。

なお、入力部２０９がタッチパネルの場合、ユーザがタッチパネルに表示されたアイコンやカーソルやボタンに合わせて押下（指等でタッチ）することにより、各種の指示を行うことができることとする。

また、タッチパネルは、マルチタッチスクリーン等の、複数の指でタッチされた位置を検出することが可能なタッチパネルであってもよい。

出力コントローラ２０６は、出力部２１０の表示を制御する。この出力部２１０としては、例えば、ＣＲＴや液晶ディスプレイ等が挙げられる。尚、本体と一体になったノート型パソコンのディスプレイも含まれるものとする。また、プロジェクタであってもよいこととする。

外部メモリコントローラ２０７は、ブートプログラム、各種のアプリケーションソフトウェア、フォントデータ、ユーザファイル、編集ファイル、プリンタドライバ等を記憶する外部メモリ２１１へのアクセスを制御する。外部メモリ２１１には、各サーバ、クライアント、装置等の各種機能を実現するための各種テーブル、パラメータが記憶されている。この外部メモリ２１１としては、ハードディスク（ＨＤ）やフレキシブルディスク（ＦＤ）、ＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）、スマートメディア等が挙げられる。

なお、ＣＰＵ２０１は、例えばＲＡＭ２０２内の表示情報用領域へアウトラインフォント展開（ラスタライズ）処理を実行することにより、出力部２１０上での表示を可能としている。また、ＣＰＵ２０１は、出力部２１０上の不図示のマウスカーソル等での開発者指示を可能とする。

通信Ｉ／Ｆコントローラ２０８は、ネットワークを介して外部機器との通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信等が可能である。

本発明を実現するためのプログラム２１２は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。

図３は、本発明の実施の形態のソフトウェア構成を示すブロック図の一例である。

プログラム開発装置１０１は、以下の機能部を備える。

定義部３０１は、アプリケーションソフトウェアによって表示される画面やアイテム（入出力項目）の配置などの画面定義情報と、アプリケーションソフトウェアの画面が次の画面に遷移する手順を定義する画面遷移定義情報と、を開発者から受け付ける機能部である。

第１の設定部３０２は、画面定義情報内にある画面を識別する画面コードを、シングルページアプリケーションの遷移先ＵＲＩとして付与するかの入力をユーザから受け付ける機能部である。シングルページアプリケーションは、ページ遷移先のＵＲＩを画面とレンダリング（紐付け、対応付け）させるルーティングライブラリを有しており、第１の設定部３０２で遷移先ＵＲＩとして画面コードを付与すると受け付けられたＵＩ画面は、次の第２の設定部で設定されるＵＲＩで直接レンダリングされた画面を表示できる。

なお、本発明では、シングルページアプリケーションの所在をＵＲＩにより指定しているが、ＵＲＩではなくてもリソースを一意に識別するための識別情報であればよい。また、本発明はシングルページアプリケーションについて記載しているが、必ずしもシングルページアプリケーションでなくてもよく、単一のＵＲＩを用いて画面を切り替えて表示することが可能なアプリケーションソフトウェアであればよい。

第２の設定部３０３は、シングルページアプリケーションのＵＲＩに、第１の設定部で画面コードを付与すると受け付けられた画面コードを付与する機能部である。第２の設定部で付与された画面コードにより、シングルページアプリケーションの画面遷移する複数のＵＩ画面にＵＲＩを付与することができ、シングルページアプリケーションでありながら画面コードが付与されたＵＩ画面には直接遷移することができる。

画面識別情報ユニーク判断部３０４は、画面コードがユニークであるかどうかを判断する。画面コードがアプリケーションソフトウェア内でユニークでない場合は、ＵＲＩが被る可能性があるため、プログラム生成エラーと判断される。

図４は、プログラム開発装置１０１、実行サーバ１０５及びクライアントＰＣ１０４の構成図である。

プログラム開発装置１０１は、リポジトリ定義部４００、Ｗｅｂアプリケーション生成部４１０を備える。

実行サーバ１０５は、図４では実行サーバ４２０に該当し、クライアントＰＣ１０４は、クライアントＰＣ４４０に該当する。

プログラム開発装置１０１は、Ｗｅｂアプリケーション生成部４１０によりコンパイル済みＪａｖａ（登録商標）コード４２１とＨＴＭＬ／ＪＳＰ／ＪａｖａＳｃｒｉｐｔ（登録商標）などのソースコード４２２（シングルページアプリケーション含む）を生成する。

リポジトリ定義部４００には、アプリケーション定義４０１、画面定義４０２、画面遷移定義４０３、アクションバインド定義４０４、データモデル定義４０５，ビジネスプロセス定義４０６，データベース定義４０７、生成時設定情報４０８を有している。なお、リポジトリ定義部４００の情報は外部メモリ２１１に記憶されている。

アプリケーション定義４０１は、開発者が開発するアプリケーションソフトウェア全体の設定を保持する。この定義の中には、アプリケーションソフトウェアをシングルページアプリケーションとするか否かの定義も登録されている。

画面定義４０２は、アプリケーションソフトウェア画面に配置される各種項目のレイアウトの定義情報を保持し、入力項目定義情報及び出力項目定義情報を含む。入力項目定義情報は、生成されたアプリケーションソフトウェアの画面を介して当該アプリケーションソフトウェアのエンドユーザが入力する入力項目を定義した情報である。出力項目定義情報は、生成されたアプリケーションソフトウェアの画面に出力する出力項目を定義した情報である。以降、入力項目及び出力項目をまとめて入出力項目と呼ぶ。また、画面間の遷移情報を定義した画面遷移定義４０３の情報も有する。

アクションバインド定義４０４は、データの取得先として外部サイトからデータを取得するための取得先の管理や、取得後のデータの変換方法などを定義している。

データモデル定義４０５は、データベースのテーブルの項目の定義情報を保持する。画面定義４０２の中の入出力項目の各項目には、データモデル定義４０５の項目を対応づけることができる。

ビジネスプロセス定義４０６は、アプリケーションソフトウェアにおけるデータを処理するためのロジックの定義情報を保持する。

データベース定義４０７は、アプリケーションソフトウェアが接続するデータベースに係る情報（データベースサーバ１０３のＩＰアドレス、接続ユーザ、接続パスワード等）を定義する。

生成時設定情報４０８は、第１の設定部３０２において取得された画面コードを遷移先ＵＲＩとして付与するか（ルーティング設定を生成するか）、付与する場合は付与されたＵＲＩ情報が保持されている。

なお、リポジトリ定義部は、生成するアプリケーションソフトウェアの定義を記憶する手段の一例である。

Ｗｅｂアプリケーション生成部４１０は、開発者により設定されたリポジトリ定義部４００を解析し、コンパイル済Ｊａｖａ（登録商標）コード４２１及びソースコード４２２を含むＷｅｂアプリケーション（シングルページアプリケーション含む）を生成する。

リポジトリ定義解析部４１１は、開発者により設定されたリポジトリ定義部４００を解析する。

生成設定情報解析部４１２は、生成時設定情報４０８から画面コードを遷移先ＵＲＩとして付与するか（ルーティング設定を生成するか、）を取得し、ルーティング設定を生成する場合は、ルーティング設定生成部４１５へ処理を依頼する。

ルーティング設定生成部４１５は、ルーティング設定解析部４１６とルーティング設定出力部４１７からなる。ルーティング設定生成部４１５は、ルーティング設定解析部４１６において、生成設定情報解析部４１２からの情報と画面定義４０２から、画面定義情報の解析を行う。ルーティング設定出力部４１７は、ルーティング設定解析部４１６の解析に従い、ルーティング設定ファイルの出力を行う。ルーティング設定ファイルの例は図９において後述する。

Ｗｅｂアプリケーションコード生成部４１３は外部メモリ２１１に記憶されているコード生成ルールと、リポジトリ定義解析部４１１、及び生成設定情報解析部３１２によって解析された内容とを用いて、アプリケーションソフトウェアのソースコードを生成する。

ソースコードコンパイル部４１４は、Ｗｅｂアプリケーションコード生成部４１３の生成したソースコードをコンパイルし、コンパイル済Ｊａｖａ（登録商標）コード４２１と、シングルページアプリケーション、ルーティング設定ファイルを含むソースコード４２２を実行サーバ４２０にデプロイする。

実行サーバ４２０は、Ｗｅｂアプリケーション生成部４１０が生成したコンパイル済Ｊａｖａ（登録商標）コード４２１、ソースコード４２２を含むＷｅｂアプリケーションを記憶し、Ｗｅｂアプリケーションを起動する。

クライアントＰＣ４４０は、Ｗｅｂブラウザ４４１から実行サーバ４２０のＵＲＩを指定してシングルページアプリケーションをダウンロードし、Ｗｅｂブラウザ４４１において、ユーザ操作を受け付け、生成されたＷｅｂアプリケーションを実行する。

図５は、Ｗｅｂアプリケーション生成のフローチャートの一例を示す図である。なお、以下のフローチャートの各ステップは、プログラム開発装置１０１のＣＰＵ２０１が実行する。

図５のフローチャートは、開発者がリポジトリ定義部４００にある各定義を定義した後に、Ｗｅｂアプリケーションを生成しようとする際にプログラム開発装置１０１で開始される処理の流れである。具体的に各ステップの処理を以下で説明する。

まず、ステップＳ５０１において、プログラム開発装置１０１のＣＰＵ２０１は、外部メモリ２１１に記憶されているリポジトリ定義部４００のアプリケーション定義４０１をＲＡＭ２０２に読み込む。

次に、ステップＳ５０２において、プログラム開発装置１０１のＣＰＵ２０１は、外部メモリ２１１に記憶されているリポジトリ定義部４００のデータモデル定義４０５をＲＡＭ２０２に読み込む。

ステップＳ５０３において、プログラム開発装置１０１のＣＰＵ２０１は、外部メモリ２１１に記憶されているリポジトリ定義部４００の画面定義４０２をＲＡＭ２０２に読み込む。読み込んだ画面定義４０２を参照して、ステップＳ５０８において画面生成を行う。以下の処理も同様である。

ステップＳ５０４において、プログラム開発装置１０１のＣＰＵ２０１は、外部メモリ２１１に記憶されているリポジトリ定義部４００のアクションバインド定義４０４をＲＡＭ２０２に読み込む。

ステップＳ５０５において、プログラム開発装置１０１のＣＰＵ２０１は、外部メモリ２１１に記憶されているリポジトリ定義部４００のビジネスプロセス定義４０６をＲＡＭ２０２に読み込む。

ステップＳ５０６において、プログラム開発装置１０１のＣＰＵ２０１は、外部メモリ２１１に記憶されているリポジトリ定義部４００のデータベース定義４０７をＲＡＭ２０２に読み込む。

ステップＳ５０７において、プログラム開発装置１０１のＣＰＵ２０１は、シングルページアプリケーションのルーティング設定を生成する。ステップＳ５０７では、たとえば図９のようなルーティング設定ファイルが生成される。ステップＳ５０７の詳細は図６を参照して後述する。

ステップＳ５０８において、プログラム開発装置１０１のＣＰＵ２０１は、ＲＡＭ２０２に読み込んだリポジトリ定義部４００の各定義・各ファイルから情報を取得し、アプリケーションソフトウェアのソースコードを生成する。

なお、生成されたソースコードにはプログラミング言語が記載されたファイルに加え、ＨＴＭＬ、ＪＳＰ、ＪａｖａＳｃｒｉｐｔ（登録商標）等のアプリケーションソフトウェア、本発明で用いるシングルページアプリケーションやステップＳ５０７で生成されるルーティング設定ファイル（図９）なども含まれる。

ステップＳ５０９において、プログラム開発装置１０１のＣＰＵ２０１は、ステップＳ５０８にて生成したアプリケーションプログラム群を実行サーバ１０５に配置（デプロイ）する。これにより、実行サーバ１０５上でアプリケーションが動作するようになる。

以上で、図５のフローチャートの説明を終了する。

次に、ステップＳ５０７の処理の詳細を図６を参照して説明する。

図６は、Ｗｅｂアプリケーション生成時のルーティング設定処理の流れを説明するフローチャートの一例を示す図である。なお、以下のフローチャートの各ステップは、各装置のＣＰＵ２０１が実行する。

図６のフローチャートは、図５のフローチャートにおいて、ステップＳ５０７へと処理が遷移した際に開始される処理の流れである。

まず、ステップＳ６０１において、プログラム開発装置１０１のＣＰＵ２０１は、アプリケーション定義４０１をＲＡＭ２０２に読み込む。

次に、ステップＳ６０２において、プログラム開発装置１０１のＣＰＵ２０１は、ステップＳ６０１において取得したアプリケーション定義４０１の情報により処理を分ける。アプリケーションソフトウェアをシングルページアプリケーションとして生成すると登録されている場合は、ステップＳ６０３へと処理を遷移し、シングルページアプリケーションとしてアプリケーションソフトウェアを生成しないと登録されている場合は図６のフローチャートの処理を終了する。

ステップＳ６０３に処理を遷移すると、プログラム開発装置１０１のＣＰＵ２０１は、アプリケーションソフトウェアの１つの画面定義４０２をＲＡＭ２０２に読み込む。読み込まれる画面定義情報の一部を定義する画面を図７、図８を参照して説明する。

図７、図８は、本実施形態において出力部２１０に表示される画面表示例であり、図７の設定画面７００や図８の設定画面８００は、図５のフローチャートを実施する前にユーザによって予め入力を受け付けている設定画面の例である。

図７、図８は、プログラム開発装置１０１の出力部２１０によって出力され、プログラム開発装置１０１のディスプレイに表示される画面の表示例である。また、図７、図８は、プログラム開発装置１０１によるアプリケーションソフトウェアの開発段階で、これから生成するアプリケーションソフトウェアに関する設定を開発者（プログラム開発装置１０１のユ―ザー）から受け付ける設定画面の表示例である。

また、図１０に、入力画面１００１、確認画面１００２、選択画面１００３として、図７の画面で設定された内容を反映して生成されたアプリケーションソフトウェアを実行した場合にクライアントＰＣ１０４のディスプレイに表示される画面の表示例を示す。すなわち、図１０の各表示例は、生成されたアプリケーションソフトウェアのユーザ（クライアントＰＣ１０４のユーザ）に向けて出力された画面である。また、図１０の各表示例は、クライアントＰＣ１０４の出力部２１４によって出力され、クライアントＰＣ１０４のディスプレイに表示される表示例である。図１０は、クライアントＰＣ１０４のユーザである勤務者が、自身の勤務形態を申請・登録することが可能なアプリケーションソフトウェア（プログラム開発装置１０１で生成されたアプリケーションソフトウェア）での表示例を示している。入力画面１００１でユーザ（勤務者）が自分の名前、性別、勤務形態を入力し（入力画面１００１は、「山田 太郎」、「男」、「在宅勤務」と入力した例）、「入力確認へ」と記載されたボタンアイコンをクリックすると確認画面１００２が表示される。確認画面１００２では、入力画面１００１で入力された内容が表示される。ユーザが表示内容を見て、入力内容に誤りがないことを確認した場合に、「担当者選択へ」と記載されたボタンアイコンをクリックする。入力内容に誤りがある場合はブラウザの戻るボタンを操作して入力画面１００１を再度表示させ、入力内容を修正する。確認画面１００２で「担当者選択へ」と記載されたボタンアイコンがクリックされると、選択画面１００３が表示される。ユーザは、選択画面１００３で承認を行う担当者（例えば自分の上司）を選択し、決定ボタンをクリックする。決定ボタンがクリックされると、選択された承認担当者に、申請内容（入力画面１００１で入力された内容）が通知され、承認担当者が承認を行うことができるようになる。以上のような動作を想定したアプリケーションソフトウェアである。

タブ７０３を選択したことによって表示される図７の設定画面７００は、図１０の入力画面１００１に対応した設定画面である。タブ７０４を選択したことによって表示される図８の設定画面８００は、図１０の確認画面１００２に対応した設定画面である。タブ７０５は、図１０の選択画面１００３に対応した設定画面を表示させるための指示を受け付けるタブである。それぞれの設定画面において、これから生成するアプリケーションソフトウェアによって表示される画面のうち、対応する画面のＵＲＩを、クライアントＰＣ１０４のユーザに提示（出力）するか否かを設定することができる。

タブである７０３～７０５は、それぞれのアプリケーションソフトウェアの画面毎のタブである。タブ７０３は入力画面に関する画面定義設定の一部の例であり、タブ７０４は確認画面、タブ７０５は選択画面に関する画面定義設定の例である。図７の設定画面での設定対象のアプリケーションソフトウェアは、タブ７０３に対応する入力画面「ｉｎｐｕｔＦｏｒｍ」（図１０の入力画面１００１）にユーザが登録後、タブ７０４に対応する確認画面である、ユーザに入力項目が正しいかの確認画面「ｃｏｎｆｉｒｍａｔｉｏｎ」（図１０の確認画面１００２）を表示する。その後、タブ７０５に対応する選択画面である、担当者の選択画面「ＰＩＣ」（図１０の選択画面１００３）を表示する。図１０のそれぞれの入出力項目（画面定義４０２）は図５のフローチャートを実施する前にユーザ（プログラム開発装置１０１のユーザである開発者）により設定されている。

本実施形態の詳細な課題について記載する。

たとえば、図７での定義の対象である（図１０のような）アプリケーションソフトウェアはタブ７０３での設定対象である入力画面１００１からタブ７０４での設定対象である確認画面１００２、タブ７０５での設定対象である選択画面１００３へと順番に遷移することを想定されている。シングルページアプリケーションのルーティング設定を行えば、それぞれの画面に対して、画面の識別情報（画面コード）を付与して、該当する画面に直接遷移することができる。たとえば、確認画面１００２の場合は、“ｌｏｃａｌｈｏｓｔ：８０８０／＿ｍａｒｋｅｔＡｐｐ／＃ｃｏｎｆｉｒｍａｔｉｏｎ”とＵＲＩを指定すれば、ルーティング設定を実施していれば、確認画面１００２に直接遷移できる。しかし、確認画面１００２（すなわち、タブ７０４の設定対象の画面）は入力画面１００１（すなわち、タブ７０３の設定対象の画面）に入力された値を確認するための画面であるため、上記ＵＲＩを直接入力しても意味がない。すなわち、ルーティング設定をさせたくない画面を含むシングルページアプリケーションを生成する必要がある。シングルページアプリケーションのルーティング設定技術は、通常のマルチページアプリケーションと同じ様にするためにＵＲＩの紐付けをする技術であり、ルーティング設定をさせない画面を生成することは考慮されていない。図７の説明に戻る。

図７で選択されているタブ７０３で表示される設定画面７００の画面コード入力欄７０１には「ｉｎｐｕｔＦｏｒｍ」が入力されている。画面コード入力欄７０１の値は、タブ７０３のタブ名に対応させているが、タブ７０３と画面コード入力欄７０１は同じでなくてもよく、タブ名と画面コードが異なる場合は２つを紐付けるデータなどで管理されていれば良い。画面コード入力欄７０１に入力される値（設定対象の画面のＵＲＩの末尾の文字列となる値）は、初期値をタブ名とし、初期値をユーザが文字列を入力することにより変更できるようにしてもよい。

チェックボックス７０２は、図７で開いている設定画面（この場合、タブ７０３の指定で表示される設定画面７００）での設定対象となる画面（入力画面１００１）にルーティング設定を行うかの設定をユーザに入力させるチェックボックス（表示アイテム）である。設定画面７００では、タブ７０３での設定対象の画面（入力画面）は直接遷移させても良い画面なので、チェックボックス７０２にはチェックが入っている。すなわち、チェックボックス７０２は、生成されるアプリケーションソフトウェアで表示される画面であって、設定対象である画面について識別情報（ＵＲＩ）を付与するか否かの指示を受け付ける表示アイテムである。

図８の設定画面８００は、タブ８０４（図７のタブ７０４と同じもの）（「ｃｏｎｆｉｒｍａｔｉｏｎ」画面を選択するタブ）を選択した場合に表示される設定画面であり、確認画面の画面定義設定の入力画面が表示されている。画面コード入力欄８０１には、画面コード名である「ｃｏｎｆｉｒｍａｔｉｏｎ」が入力されている。

チェックボックス８０２は、図８で開いているタブ（この場合８０４）での設定対象の画面にルーティング設定を行うかの設定をユーザに入力させるチェックボックスである。設定画面８００では、タブ８０４での設定対象の入力確認画面は直接遷移させたくない画面なので、チェックボックス８０２にはチェックが入っていない。図６のフローチャートの説明に戻る。

図６のステップＳ６０３で読み込んだ画面定義情報を用いて以降の処理を実行する。

ステップＳ６０４において、プログラム開発装置１０１のＣＰＵ２０１は、ステップＳ６０３で読み込まれた画面定義情報の画面コード名（画面コード入力欄７０１や８０１入力されているコード名）が一意（ユニーク）であるか判別する。一意であれば、ステップＳ６０６へと処理を遷移し、一意でなければ、ステップＳ６０５へと遷移しエラーと判断されて、アプリケーション生成処理を中断する。この条件分岐により画面コード名のユニーク性を保証し、ルーティング設定させている場合はＵＲＩに対する画面をユニークに設定することができる。

ステップＳ６０６へと処理を遷移すると、プログラム開発装置１０１のＣＰＵ２０１は、ステップＳ６０３で読み込まれた画面定義情報のルーティング設定を行うか否か（７０２や８０２）を判別する。ルーティング設定を行う（チェックボックスがＯＮの）場合はステップＳ６０７へと処理を遷移し、ルーティング設定を行わない（チェックボックスがＯＦＦの）場合はステップＳ６０８へと処理を遷移する。

ステップＳ６０７へと処理を遷移すると、プログラム開発装置１０１のＣＰＵ２０１は、現在読み込んでいる画面定義の設定を「ｈｉｓｔｏｒｙ：ｔｒｕｅ」としてルーティング設定ファイルに出力する。出力されたルーティング設定ファイルの例を図９を参照して説明する。

図９は、本発明の実施形態に係るルーティング設定ファイルの一例を示す図である。

図９の要素９０１が、図７の設定画面７００で設定された画面「ｉｎｐｕｔＦｏｒｍ」（入力画面）のルーティング設定の内容である。設定画面７００では、チェックボックス７０２がＯＮになっている（チェックが入っている）ので、画面ＵＩ（ルーティング設定ファイル９００の場合、設定画面７００での設定対象である「ｉｎｐｕｔＦｏｒｍ」）は、「ｈｉｓｔｏｒｙ」パラメータが「ｔｒｕｅ」となり、ルーティング設定が実行される。すなわち、ＵＲＩに「ｉｎｐｕｒＦｏｒｍ」という識別情報を付けてＵＲＩとＵＩ画面とをレンダリングする。

一方、ステップＳ６０８へと処理を遷移すると、プログラム開発装置１０１のＣＰＵ２０１は、現在読み込んでいる画面定義の設定を「ｈｉｓｔｏｒｙ：ｆａｌｓｅ」としてルーティング設定ファイルに出力する。出力されたルーティング設定ファイルの例を図９を参照して説明する。

図９の要素９０２が、図８の設定画面８００で設定された画面「ｃｏｎｆｉｒｍａｔｉｏｎ」（確認画面）のルーティング設定の内容である。設定画面８００では、チェックボックス８０２がＯＦＦになっている（チェックがつけられなかった）ので、画面ＵＩ（ルーティング設定ファイル９００の場合、設定画面８００での設定対象である「ｃｏｎｆｉｒｍａｔｉｏｎ」）は、「ｈｉｓｔｏｒｙ」パラメータが「ｆａｌｓｅ」となり、ルーティング設定が実行されない。すなわち、ＵＲＩとＵＩ画面とのレンダリングを行わない。図６のフローチャートの説明に戻る。図１０を参照して、ＵＲＬとＵＩ画面のレンダリングの関係を説明する。

図１０の入力画面１００１は設定画面７００のチェックボックス７０２のようにルーティング設定が実行されている設定（すなわち、９０１のように「ｈｉｓｔｏｒｙ」パラメータが「ｔｒｕｅ」）になっているので、ＵＲＩはアドレスバー１００４のように“ｌｏｃａｌｈｏｓｔ：８０８０／＿ｍａｒｋｅｔＡｐｐ／＃ｉｎｐｕｔＦｏｒｍ”と表示されており、このＵＲＩにより１００１の入力画面に直接遷移することができる。また、入力画面１００１をブックマークすることが可能である。さらに、アドレスバーに出力されたＵＲＩをコピーしてショートカットを作成することも可能である。

一方、確認画面１００２は設定画面８００のチェックボックス８０２のようにルーティング設定が実行されない設定（すなわち、９０２のように「ｈｉｓｔｏｒｙ」パラメータが「ｆａｌｓｅ」）になっているので、ＵＲＩはアドレスバー１００５のように、“ｌｏｃａｌｈｏｓｔ：８０８０／＿ｍａｒｋｅｔＡｐｐ／＃／”と表示されており、確認画面１００２はＵＲＩとはレンダリングされていない。アドレスバー１００５に表示された“ｌｏｃａｌｈｏｓｔ：８０８０／＿ｍａｒｋｅｔＡｐｐ／＃／”という文字列をコピーして、空白のアドレスバーにペーストして検索を行っても、確認画面１００２は表示されない。この場合、エラー表示がされるか、生成されたシンブルアプリケーションのトップページが表示されることとなる。すなわち、確認画面１００２に遷移するための識別情報は生成されたアプリケーションソフトウェアのユーザ（クライアントＰＣ１０４のユーザ）には出力されない。そのため、確認画面１００２をブックマークすることが不可能である。さらに、確認画面１００２へのショートカットを作成することも不可能である。

以上のように、画面毎にＵＲＩとＵＩ画面をレンダリングするかしないかを容易に設定できる効果を有する。すなわち、生成されるアプリケーションソフトウェアによって表示される複数の画面のそれぞれについて、ＵＲＩを対応付けるかどうか（生成されるアプリケーションソフトウェアのユーザに対して出力するか否か）を、チェックボックスへのチェック操作という簡単な操作で容易に設定できる。

次のステップＳ６０９において、プログラム開発装置１０１のＣＰＵ２０１は、他にレンダリングする画面が有るかどうかにより処理を分ける。他に画面がある場合には、ステップＳ６０３へと処理を戻し、他に画面がない場合は図６のフローチャートの処理を終了する。

以上の処理により、シングルページアプリケーションの開発を容易に行う仕組みを提供することができる。

具体的には、シングルページアプリケーションにおいて、ルーティング設定を行うページと行わないページを混在させたアプリケーションソフトウェアをＧＵＩから容易に作成することができ、高度な技術者でなくてもシングルページアプリケーションを作成できる効果を有する。

以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読み出し、実行することによっても本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記録した記録媒体は本発明を構成することになる。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、ＤＶＤ－ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク等を用いることが出来る。

また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、ひとつの機器から成る装置に適用しても良い。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

上記プログラムの形態は、オブジェクトコード、インタプリタにより実行されるプログラムコード、ＯＳ（オペレーティングシステム）に供給されるスクリプトデータ等の形態から成ってもよい。

さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

１０１ プログラム開発装置
１０２ プログラム開発サーバ
１０３ データベースサーバ
１０４ クライアントＰＣ
１０５ 実行サーバ
１０７ ネットワーク

Claims (14)

1. 生成されるアプリケーションソフトウェアで表示される画面について識別情報を付与するか否かの指示を受け付ける表示アイテムを表示するように制御する表示制御手段と、
   前記表示アイテムに対して受け付けた前記指示に応じたアプリケーションソフトウェアを生成するように制御する制御手段を有し、
   前記制御手段は、前記表示アイテムで識別情報を付与する指示を受け付けた第１の画面と、前記表示アイテムで識別情報を付与する指示を受け付けていない第２の画面とを表示可能な特定のアプリケーションソフトウェアであって、前記特定のアプリケーションソフトウェアが実行される際に、前記第１の画面の表示を指示するための前記第１の画面の識別情報を前記特定のアプリケーションソフトウェアのユーザに対して出力し、前記第２の画面の表示を指示するための前記第２の画面の識別情報を前記ユーザに対して出力しないように動作する前記特定のアプリケーションソフトウェアを生成可能
   とすることを特徴とする情報処理システム。
2. 前記第１の画面はブックマーク可能であり、前記第２の画面はブックマーク不可能であることを特徴とする請求項１に記載の情報処理システム。
3. 前記第２の画面は前記第１の画面において特定の操作を受け付けた場合に表示される画面であることを特徴とする請求項１または２に記載の情報処理システム。
4. 前記特定のアプリケーションソフトウェアはシングルページアプリケーションであることを特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
5. 前記制御手段は、生成されるアプリケーションソフトウェアがシングルページアプリケーションでない場合には、前記表示アイテムに対して受け付けた前記指示に応じた処理を行わないように制御することを特徴とする請求項４に記載の情報処理システム。
6. 前記表示制御手段は、前記表示アイテムに対する入力に応じて、前記表示アイテムの表示形態をオンの表示形態かオフの表示形態のいずれかに切り替えるように制御することを特徴とする請求項１乃至５のいずれか１項に記載の情報処理システム。
7. 前記識別情報はＵＲＩであることを特徴とする請求項１乃至６のいずれか１項に記載の情報処理システム。
8. 前記第１の画面の識別情報は、前記第１の画面を表示した際にブラウザのアドレスバーに表示される情報であることを特徴とする請求項１乃至７のいずれか１項に記載の情報処理システム。
9. 生成されるアプリケーションソフトウェアで表示される画面の識別情報となる値をユーザから入力された値に基づいて設定する設定手段を更に有することを特徴とする請求項１乃至８のいずれか１項に記載の情報処理システム。
10. 生成されるアプリケーションソフトウェアで表示される複数の画面のそれぞれについて前記設定手段で設定された識別情報が、他の画面の識別情報に対してユニークであるかを判定する判定手段を更に有し、
    前記制御手段は、前記判定手段でユニークでないと判定された識別情報がある場合には、アプリケーションソフトウェアの生成を中断するように制御することを特徴とする請求項９に記載の情報処理システム。
11. 前記制御手段は、それぞれユーザによって設定された情報である、入力項目定義情報と、出力情報定義情報と、項目のレイアウトの定義情報とを含む画面定義情報に基づいてアプリケーションソフトウェアを生成するように制御し、
    前記表示アイテムに対して受け付けた前記指示に基づいて前記画面定義情報が定義されることを特徴とする請求項１乃至１０のいずれか１項に記載の情報処理システム。
12. 生成されるアプリケーションソフトウェアで表示される画面について識別情報を付与するか否かの指示を受け付ける表示アイテムを表示するように制御する表示制御ステップと、
    前記表示アイテムに対して受け付けた前記指示に応じたアプリケーションソフトウェアを生成するように制御する制御ステップを有し、
    前記制御ステップは、前記表示アイテムで識別情報を付与する指示を受け付けた第１の画面と、前記表示アイテムで識別情報を付与する指示を受け付けていない第２の画面とを表示可能な特定のアプリケーションソフトウェアであって、前記特定のアプリケーションソフトウェアが実行される際に、前記第１の画面の表示を指示するための前記第１の画面の識別情報を前記特定のアプリケーションソフトウェアのユーザに対して出力し、前記第２の画面の表示を指示するための前記第２の画面の識別情報を前記ユーザに対して出力しないように動作する前記特定のアプリケーションソフトウェアを生成可能
    とすることを特徴とする情報処理システムの制御方法。
13. コンピュータを、請求項１乃至１１のいずれか１項に記載された情報処理システムの各手段として機能させるためのプログラム。
14. コンピュータを、請求項１乃至１１のいずれか１項に記載された情報処理システムの各手段として機能させるためのプログラムを格納したコンピュータが読み取り可能な記憶媒体。

Images