(57)【要約】【課題】  改良されたＭＶＣアーキテクチャを提案し、それに適した実装に係る技術を提供する。【解決手段】  フロントエンドサーバが、表示されている第１の画面からのリクエストを受け付け、第１の画面専用入力コントローラ２３が、第１の画面に入力されたデータを取り込んでバッファに格納する。そして、リクエストに対応する処理部２６がバッファに格納された入力データに基づいて処理を実行し、実行結果のデータをバッファに格納する。さらに、実行結果のデータに対応する第２の画面の専用出力コントローラ２４が、バッファに格納された実行結果のデータを取得して、第２の画面を表示するためのデータを出力する。【選択図】  図４
2005196630.tif 000002
【特許請求の範囲】
【請求項１】
複数の画面を表示するための複数の画面データファイルを記憶する記憶部と、
複数の処理をそれぞれ実行する複数の処理実行部と、
前記複数の処理実行部に入出力されるデータを記憶するためのバッファと、
前記複数の画面のうち、対応する画面に入力されたデータを取得し、前記バッファへ格納する複数の入力コントローラと、
前記複数の画面のうち、対応する画面に、前記バッファに格納されているデータを表示させるために、前記対応する画面の前記画面データファイルを取得して出力する複数の出力コントローラと、
前記複数の画面のうち、表示中の第１の画面からリクエストを受け付けると、前記第１の画面に対応する入力コントローラを起動し、前記リクエストに基づいて前記複数の処理実行部のうちの一の処理実行部を選択して処理を実行させ、当該処理の実行結果に基づいて第２の画面に対応する出力コントローラを選択し、選択された出力コントローラを起動するイベントコントローラとを備えることを特徴とする情報処理システム。
【請求項２】
前記イベントコントローラにより起動された入力コントローラは、前記第１の画面に入力されたデータを取得して前記バッファへ格納し、
前記選択された出力コントローラは、前記バッファに格納されている、選択された前記一の処理実行部の実行結果のデータを、前記第２の画面へ埋め込むことを特徴とする請求項１記載の情報処理システム。
【請求項３】
コンピュータが、
表示されている第１の画面からのリクエストを受け付け、
前記第１の画面専用入力コントローラが、前記第１の画面に入力されたデータを取り込んでバッファに格納し、
前記リクエストに対応する処理実行部が前記バッファに格納された入力データに基づいて処理を実行し、実行結果のデータを前記バッファに格納し、
前記実行結果のデータに対応する第２の画面の専用出力コントローラが、前記バッファに格納された実行結果のデータを取得して、前記第２の画面を表示するためのデータを出力する、画面からのリクエストの処理方法。
【請求項４】
コンピュータに実行されると、
表示されている第１の画面からのリクエストを受け付け、
前記第１の画面専用入力コントローラが、前記第１の画面に入力されたデータを取り込んでバッファに格納し、
前記リクエストに対応する処理実行部が前記バッファに格納された入力データに基づいて処理を実行し、実行結果のデータを前記バッファに格納し、
前記実行結果のデータに対応する第２の画面の専用出力コントローラが、前記バッファに格納された実行結果のデータを取得して、前記第２の画面を表示するためのデータを出力する、画面からのリクエストを処理するためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＭＶＣ（Model-View-Controller）アーキテクチャに従う情報処理システムに関する。
【背景技術】
【０００２】
従来、システムの設計モデルにＭＶＣアーキテクチャという考え方がある。ＭＶＣアーキテクチャでは、システムの中心となる業務処理を行うモデルと、ユーザインタフェースなどの表示、出力を行うビューと、入力を受け取ってその内容に応じてビューおよびモデルを制御するコントローラとからなる（例えば、非特許文献１）。
【０００３】
【非特許文献１】Designing Enterprise Applications with the J2EE Platform ,Second Edition, Foreword by Rich Green, Sun Microsystems, Inc, July 2002
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ＭＶＣアーキテクチャは、機能ごとに分離することにより、開発に要する工数を削減し、さらに、いずれかで生じた仕様変更の影響が他に及ばないようにすることを目的としている。
【０００５】
しかしながら、従来提唱されているＭＶＣアーキテクチャでは、モデル、ビュー及びコントローラの関係が、上記の目的を達成するためには必ずしも十分ではなかった。つまり、モデル、ビュー及びコントローラの独立性が十分に担保されていなかったので、仕様変更などの影響が他に及んでしまうことがあった。
【０００６】
そこで、本発明の目的は、改良されたＭＶＣアーキテクチャを提案し、それに適した実装に係る技術を提供することである。
【課題を解決するための手段】
【０００７】
本発明の一つの実施態様に従う情報処理システムは、複数の画面を表示するための複数の画面データファイルを記憶する記憶部と、複数の処理をそれぞれ実行する複数の処理実行部と、前記複数の処理実行部に入出力されるデータを記憶するためのバッファと、前記複数の画面のうち、対応する画面に入力されたデータを取得し、前記バッファへ格納する複数の入力コントローラと、前記複数の画面のうち、対応する画面に、前記バッファに格納されているデータを表示させるために、前記対応する画面の前記画面データファイルを取得して出力する複数の出力コントローラと、前記複数の画面のうち、表示中の第１の画面からリクエストを受け付けると、前記第１の画面に対応する入力コントローラを起動し、前記リクエストに基づいて前記複数の処理実行部のうちの一の処理実行部を選択して処理を実行させ、当該処理の実行結果に基づいて第２の画面に対応する出力コントローラを選択し、選択された出力コントローラを起動するイベントコントローラとを備えることを特徴とする。
【０００８】
好適な実施形態では、前記イベントコントローラにより起動された入力コントローラは、前記第１の画面に入力されたデータを取得して前記バッファへ格納する。さらに、前記選択された出力コントローラは、前記バッファに格納されている、選択された前記一の処理実行部の実行結果のデータを、前記第２の画面へ埋め込むようにしてもよい。
【発明を実施するための最良の形態】
【０００９】
以下、本発明の一実施形態に係る情報処理システムについて、図面を用いて説明する。
【００１０】
本システムは、図１に示すように、バックエンドサーバ１と、フロントエンドサーバ２と、複数のクライアント３とを備える。本システムは、あるクライアント３に表示されたユーザインタフェース用の画面などに入力された情報に基づいて、フロントエンドサーバ２およびバックエンドサーバ１が所定の処理を実行し、その処理結果を同じクライアント３に表示する情報処理システムである。
【００１１】
バックエンドサーバ１、フロントエンドサーバ２およびクライアント３は、いずれも例えば汎用的なコンピュータシステムにより構成され、以下に説明する各サーバ１、２およびクライアント３内の個々の構成要素または機能は、例えば、コンピュータプログラムを実行することにより実現される。
【００１２】
バックエンドサーバ１では、例えば、ＲＤＢ（リレーショナルデータベース）などが動作している。１台のバックエンドサーバ１に対して、フロントエンドサーバ２が複数台備えられていてもよい（図１では便宜上１台のフロントエンドサーバのみ表示している）。
【００１３】
フロントエンドサーバ２は、クライアント３から種々のリクエストを受け、各リクエストに対応する処理をバックエンドサーバ１へ依頼する。この機能を実現するために、フロントエンドサーバ２は、イベントコントローラ２１と、画面データ記憶部２２と、クライアント３に表示されている画面からのデータ入力を制御する入力コントローラ２３と、クライアント３に表示する画面へのデータ出力を制御する出力コントローラ２４と、モデルＩＯ２５と、複数の処理部２６とを備える。
【００１４】
ところで、フロントエンドサーバ２はＭＶＣ（Model-View-Controller）アーキテクチャに従ったシステム設計および実装がされている。従って、ＭＶＣアーキテクチャのモデル５０に対応する構成は処理部２６であり、ビュー６０に対応する構成が画面データ記憶部２２に記憶されている画面データファイルであり、コントローラ７０に対応する構成が、イベントコントローラ２１、入力コントローラ２３、出力コントローラ２４、モデルＩＯ２５である。上記のようにＭＶＣアーキテクチャに従う本システムでは、詳細については後述するように、コントローラ７０は、ビュー６０からのリクエストを受けてモデル５０を起動して所定の処理を実行させる。さらに、コントローラ７０は、モデル５０から処理の完了通知を受けて、処理結果に対応するビュー６０を起動し、処理結果を表示させる。
【００１５】
イベントコントローラ２１は、モデル５０およびビュー６０に対して処理を振り分け、フロントエンドサーバ２内での処理フロー制御を行う。例えば、クライアントからのリクエストを受け付けると、そのリクエストに含まれている画面ＩＤをモデルＩＯ２５へ通知する。また、イベントコントローラ２１は、リクエストに含まれている画面ＩＤ、または画面ＩＤおよびリクエストの内容に基づいて、複数の処理部２６から一つの処理部２６を選択する。そして、イベントコントローラ２１は、選択された処理部２６に所定の処理を実行させる。さらに、処理部２６の処理が完了した後、イベントコントローラ２１は、そこでの処理結果に応じた画面データファイルを選択する。そして、選択された画面データファイルに対応する出力コントローラ２４が、モデルＩＯ２５に格納されている処理部２６での処理により得られたデータに基づいて、画面をクライアント３に表示するための処理を行う。
【００１６】
画面データ記憶部２２は、クライアント３に表示するためのユーザインタフェース用の複数の画面を表示するための画面データファイルを記憶する。各画面には、それぞれの画面を識別するための画面ＩＤが付されている。各画面データファイルは、例えばＨＴＭＬ（Hyper Text Markup Language）で記述されている。このＨＴＭＬファイルがクライアント３へ転送され、クライアント３に搭載されているＷｅｂブラウザ（図示しない）などにより画面が表示される。
【００１７】
入力コントローラ２３は、クライアント３に表示されている画面に対して入力されたデータを取得する。入力コントローラ２３は、一つの画面に対して一つ設けられている。つまり、各画面に専用の入力コントローラ２３が一つ用意されている。この画面と専用入力コントローラとの対応関係が後述するテーブル３０（図２参照）に定義されている。入力コントローラ２３は、対応する画面がクライアント３に表示されているときに、その画面に対して入力されたデータをクライアント３から取得する。ここで取得されたデータはモデルＩＯ２５へ通知される。
【００１８】
出力コントローラ２４は、所定のデータを画面に貼り付けて表示させるために、表示させる所定のデータと画面データファイルとを併せてクライアント３へ送信する。出力コントローラ２４も、一つの画面に対して一つの専用出力コントローラが設けられている。この画面と専用出力コントローラとの対応関係が後述するテーブル３０（図２参照）に定義されている。出力コントローラ２４は、モデルＩＯ２５からデータを取得する。そして、画面データ記憶部２２に記憶されている、自身に対応する画面データファイルに、その取得したデータを埋め込んでクライアント３へ送信する。
【００１９】
入力コントローラ２３および出力コントローラ２４のいずれにも、それぞれを識別するための入力コントローラＩＤおよび出力コントローラＩＤが付されている。また、各画面に対応する入力コントローラ２３および出力コントローラ２４は、入出力コントローラとして一体に構成しても良い。
【００２０】
モデルＩＯ２５は、モデル５０とビュー６０との間のデータ交換などのインタフェースをとる。モデルＩＯ２５は、モデル５０とビュー６０とがデータ交換を行うときに用いるバッファ２５１を備える。バッファ２５１は、各入力コントローラ２３、各出力コントローラ２４および各処理部２６から参照可能である。また、モデルＩＯ２５は、テーブル３０を参照して、画面データファイルに対応する入力コントローラ２３及び出力コントローラ２４を特定する。テーブル３０の一例を図２に示す。すなわち、テーブル３０は、画面ＩＤ３１と、入力コントローラＩＤ３２と、出力コントローラＩＤ３３とをデータ項目として含む。
【００２１】
モデルＩＯ２５は、例えば、イベントコントローラ２１から画面ＩＤの通知を受けると、テーブル３０を参照し、通知された画面ＩＤと対応する入力コントローラＩＤを特定する。そして、特定された入力コントローラＩＤと対応する入力コントローラ２３を起動する。このとき、モデルＩＯ２５は、この入力コントローラ２３が画面から取得したデータを受領し、バッファ２５１へ格納する。
【００２２】
また、各処理部２６は、バッファ２５１を参照してそれぞれの処理を実行すると、その処理結果がバッファ２５１に格納される。つまり、各処理部２６は、バッファ２５１に格納されている画面から入力されたデータに基づいて所定の処理を実行し、実行結果のデータを改めてバッファ２５１へ格納する。
【００２３】
各処理部２６は、それぞれ、予め定められている処理を実行する。いずれの処理部２６がどのタイミングで起動されるかは、イベントコントローラ２１が決定する。各処理部２６は、バッファ２５１から処理に必要なデータを取り込む。そして、例えば、バックエンドサーバ１へ処理を依頼するなど、所定の処理を実行する。そして、処理部２６は、処理が完了すると処理結果のデータをバッファ２５１へ格納する。
【００２４】
上記のような構成を備えた情報システムでの処理手順について、具体例を用いて以下に説明する。この例では、図３に示すように、あるクライアント３に検索画面１００が表示されている。この検索画面１００は、フロントエンドサーバ２から送られた画面データファイルに基づいて表示されている。ここで、ユーザが図示しない入力装置を用いて入力領域１１０に検索条件を入力し、検索ボタン１２０を押すと、クライアント３には検索結果画面２００が表示される。検索結果画面２００には、検索結果レコードの表示領域２３０と、表示された任意のレコードを選択するチェックボックス２１０と、選択されたレコードの削除指示を受け付ける削除ボタン２２０とを備える。削除ボタン２２０が押されると、チェックボックス２１０で選択されたレコードがバックエンドサーバ１から削除される。上記の例について、フロントエンドサーバ２で行われる処理について、図３および図４を用いて説明する。
【００２５】
まず、検索画面１００でユーザが所定の入力装置を使って検索ボタン１２０を押すと、クライアント３はこの操作を受け付け、フロントエンドサーバ２へ画面ＩＤを含むリクエスト（検索実行要求）を送信する（Ａ）。フロントエンドサーバ２では、イベントコントローラ２１がこのリクエストを受信し、モデルＩＯ２５へ画面ＩＤを通知する（Ｂ）。
【００２６】
モデルＩＯ２５は、テーブル３０を参照し、通知を受けた画面ＩＤと対応する入力コントローラＩＤの入力コントローラ２３に対して、データ取得を指示する（Ｃ）。
【００２７】
モデルＩＯ２５から指示を受けた入力コントローラ２３は、クライアント３で表示されている検索画面１００の検索条件の入力領域１１０に入力されたデータを取得する。ここで取得したデータは、モデルＩＯ２５のバッファ２５１に格納される。入力コントローラ２３が取得したデータがバッファ２５１に格納されると、モデルＩＯ２５はイベントコントローラ２１へデータ取得完了を通知する。
【００２８】
ここで、イベントコントローラ２１は、（Ａ）で受け付けた画面ＩＤに対応する処理部２６を選択する。すなわち、ここでは検索処理を実行するための処理部２６が選択される。この選択された処理部２６に対して、イベントコントローラ２６は、処理の実行を指示する（Ｄ）。
【００２９】
実行を指示された処理部２６は、モデルＩＯ２５のバッファ２５１から、検索画面１００で入力されていた検索条件を取得する。そして、バックエンドサーバ１のＲＤＢ１０へ、この検索条件で検索の実行を依頼する。そして、ＲＤＢ１０が検索を実行したその結果のデータを取得すると、処理部２６は、この検索結果のデータをバッファ２５１へ格納し、処理の完了をイベントコントローラ２１へ通知する。
【００３０】
イベントコントローラ２１は検索終了の通知を受けると、この処理結果を表示するための検索結果画面２００の画面データファイルを画面データ記憶部２２から取得する（Ｅ）。そして、この画面２００に対応する出力コントローラ２４に対して、画面２００に表示させるデータの取得を指示する。指示を受けた出力コントローラ２４は、モデルＩＯ２５のバッファ２５１から検索結果のデータを取得する。そして、ここで取得されたデータが、検索結果画面２００の画面データに埋め込まれてクライアント３へ送信される。
【００３１】
そして、クライアント３はここで送られたデータを受信して、図３に示すような検索結果画面２００を表示する。
【００３２】
ここで、（Ｂ）、（Ｄ）および（Ｅ）のように、処理の割り振りを行っているのは、イベントコントローラ２１である。つまり、コントローラ７０が、モデル５０またはビュー６０に対する呼び出しを行っている。従って、モデル５０とビュー６０との間で、いずれか一方が他方を直接呼び出すことはない。コントローラ７０がモデル５０およびビュー６０が行う処理のシーケンスを制御する。
【００３３】
次に、検索結果画面２００において、ユーザが削除対象となるレコードをチェックボックス２１０で指定し、削除する場合について説明する。上記の検索の場合は画面が遷移したが、以下のレコード削除の場合はこれとは異なり画面が遷移しない。つまり、指定されたレコードが削除され、残ったレコードが再度検索結果画面２００に表示される。この場合もまた、フロントエンドサーバ２は、図４のシーケンスチャートに従って動作するが、ここでは、特に削除対象レコードを示す情報の受け渡しについて説明する。
【００３４】
削除対象レコードがチェックボックス２１０で選択されているときに削除ボタン２２０が押されると、クライアント３はこの操作を受け付け、フロントエンドサーバ２へ画面ＩＤを含むリクエスト（削除実行要求）を送信する。フロントエンドサーバ２では、イベントコントローラ２１がこのリクエストを受信し、モデルＩＯ２５へ画面ＩＤを通知する。
【００３５】
モデルＩＯ２５は、テーブル３０を参照し、通知を受けた画面ＩＤと対応する入力コントローラＩＤの入力コントローラ２３に対して、データ取得を指示する。
【００３６】
モデルＩＯ２５から指示を受けた入力コントローラ２３は、クライアント３で表示されている検索結果画面２００のチェックボックス２１０に選択された行に対応するレコードＮｏを取得する。ここで取得したレコードＮｏは全て、モデルＩＯ２５のバッファ２５１に格納される。
【００３７】
入力コントローラ２３が取得したデータがバッファ２５１に格納されると、モデルＩＯ２５はイベントコントローラ２１へデータ取得完了を通知する。
【００３８】
ここで、イベントコントローラ２１は、削除ボタンが押された場合に起動されるべき処理部２６を選択する。すなわち、ここでは削除処理を実行するための処理部２６（削除処理部）が選択される。この選択された処理部２６（削除処理部）に対して、イベントコントローラ２１は、処理の実行を指示する。
【００３９】
実行を指示された処理部２６（削除処理部）は、モデルＩＯ２５のバッファ２５１から、検索結果画面２００で指定されていた削除対象レコードのレコードＮｏを取得する。そして、バックエンドサーバ１のＲＤＢ１０へ、このレコードの削除の実行を依頼する。
【００４０】
ここで、図３の画面２００では、削除対象レコードをユーザに選択させ、選択されたレコードをＲＤＢ１０から削除している。これに対して、例えば、図５に示す検索結果画面３００（検索結果画面２００とは異なる画面ＩＤを有する）は、削除しないレコードをユーザに選択させ、削除ボタン３２０が押されると、選択されなかったレコードを削除するものである。このいずれの画面からのリクエストであっても共通の処理部２６（削除処理部）が削除処理を実行する。従って、画面２００用の入力コントローラ２３と画面３００用の入力コントローラ２３とは、それぞれ異なる処理を行う。すなわち、画面２００用の入力コントローラ２３は、上述のようにチェックボックス２１０でチェックされている行のレコードＮｏを取得してバッファ２５１へ格納するが、画面３００用の入力コントローラ２３は、チェックボックス３１０でチェックされていない行のレコードＮｏを取得し、バッファ２５１へ格納する。これにより、いずれの画面の場合も、共通の処理部２６（削除処理部）が削除処理を実行できる。つまり、画面間の相違は、入力コントローラ２３で吸収されている。
【００４１】
一般の業務処理システムでは、業務処理の修正（モデル５０の変更）や、インタフェース画面のバージョンアップ（ビュー６０の変更）は頻繁に行われる。しかし、本システムではモデル５０とビュー６０の間にコントローラ７０が存在するため、モデル５０またはビュー６０の変更が影響を及ぼす範囲は限定的である。従って、モデル５０、ビュー６０およびコントローラ７０の独立性が高まり、それぞれの再利用性およびメンテナンス性が向上する。
【００４２】
なお、本発明では３つのコントローラを用いているが、システムの再利用性およびメンテナンス性を高める上で特に重要なのは入力コントローラ２３である。画面デザインはユーザの視認性および操作性に重点が置かれて決定されるが、決定されたデザインが処理部２６にとって必ずしも最適である訳ではない。画面から入力されたデータを機械的にモデルＩＯ２５に値を引き渡し、処理部２６を呼び出した場合は、処理部２６の先頭に画面を理解し、処理部２６が扱い易いデータ構造に変換する処理が必要になる。つまり処理部２６に画面デザインに対する情報が含まれてしまう。本来、処理部２６は複数の画面から利用されるのが望ましいので、新たな画面の追加、あるいは画面デザインが変更される度に処理部２６に修正が入るとモデル処理部の保守性は極端に悪化する。つまり、入力コントローラ２３は、各々の画面デザインに固有な処理を行い、各処理部２６の有効活用を可能とする機能を備えている。
【００４３】
同じように、処理部２６の処理結果をユーザの視認性や操作性を担保するために、必要な変換処理を行うのが出力コントローラ２４である。従来はビュー６０とモデル５０が直接データの授受を行う形態が多かったので、モデル５０の再利用性を向上させようとするとビュー６０の中に出力コントローラ２４の処理を記述することになっていた。ビュー６０は本来画面デザインそのものであり、そこに画面制御ロジックが混在すると生産性およびメンテナンス性が悪化する。本発明では出力コントローラ２４とモデルＩＯ２５が画面デザインと処理部２６を完全に分けているので、ビュー６０とモデル５０の生産性およびメンテナンス性が向上する。
【００４４】
上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。
【図面の簡単な説明】
【００４５】
【図１】本発明の一実施形態に係る情報処理システムの全体構成図である。
【図２】テーブルの構成の一例を示す図である。
【図３】クライアントに表示される画面遷移の一例を示す図である。
【図４】フロントエンドサーバでの処理手順を説明するためのシーケンスチャートである。
【図５】検索結果画面の一例を示す図である。
【符号の説明】
【００４６】
１…バックエンドサーバ、２…フロントエンドサーバ、３…クライアント、５０…ビュー、６０…モデル、７０…コントローラ。
【図１】
2005196630.tif 000003
【図２】
2005196630.tif 000004
【図３】
2005196630.tif 000005
【図４】
2005196630.tif 000006
【図５】
2005196630.tif 000007