JP2005092522A - 画面状態遷移システム、インターフェースシステム、画面状態遷移プログラム、インターフェースシステム用プログラム、画面状態遷移方法及びインターフェース方法 - Google Patents

Abstract

【課題】 単機能の画面の集合で一連の業務処理を行うことにより生じる複数画面の作成・保守という不都合を回避する。
【解決手段】 ユーザからの入力操作を受け付ける画面を表示させるための画面データ２１と、画面の第１状態と入力操作との組み合わせに対して業務処理を対応付け、さらに業務処理の処理結果に対して画面の第２状態を対応付けている画面状態遷移定義２２とを記憶する記憶部１０３と、画面を第１状態にて表示させ、入力操作を受け付けた場合に、画面状態遷移定義２２を参照して、業務処理の開始を指示し、処理結果を受け付けたら、画面を第２状態へ遷移させる制御部１０１と、を備える。
【選択図】 図２

Description

本発明は、多機能の単一画面で一連の業務を処理する場合に適するシステム、プログラム、及び方法に関する。

ユーザから直接操作を受け付けて、さまざまな処理を行うコンピュータシステムは、ユーザインターフェースに関する部分と、具体的な業務処理に関する業務処理ロジックとに分けることができる。

ユーザインターフェースの設計基準は、見た目がユーザに与える印象、操作性等さまざまな要素がある。そのため、ユーザインターフェースの設計には高い自由度が求められる。また、ユーザインターフェースは、さまざまな理由から頻繁に変更されることもある。

これに対して業務処理ロジックは、ユーザインターフェースの変更に伴って変更する必要はない。むしろ、ユーザインターフェースを変更する度に、業務処理ロジックまで変更しなければならないとすれば、不便である。

そこで、従来、ユーザインターフェースの変更と業務処理ロジックの変更とを、それぞれ独立して行うことができるコンピュータシステム等がある（例えば、特許文献１参照）。
特開２００２−２８７９６２号公報（第２図）

従来のシステムでは、単機能の複数画面の集合によって一連の業務を処理する場合は有効であったが、多機能の単一画面によって一連の業務を処理する場合には対応できなかった。多機能の単一画面で一連の業務を処理する場合、条件分岐が複雑で関連しあった処理が多数存在する非常に分かり難いプログラミングが必要であった。

本発明は、「画面の状態」という概念を導入し、多機能の単一画面で一連の業務を処理する場合であっても保守や改良がとても容易なシステム、プログラム、及び方法の提供を目的とする。

本発明の第１の特徴は、画面状態を遷移させるシステムであって、（１）ユーザからの入力操作を受け付ける画面を表示させるための画面データと、前記画面の第１状態と前記入力操作との組み合わせに対して業務処理を対応付け、さらに前記業務処理の処理結果に対して前記画面の第２状態を対応付けている画面状態遷移定義とを記憶する記憶部と、（２）前記画面を前記第１状態にて表示させ、前記入力操作を受け付けた場合に、前記画面状態遷移定義を参照して、前記業務処理の開始を指示し、前記処理結果を受け付けたら、前記画面を前記第２状態へ遷移させる制御部と、を備えることにある。

第１状態のときに画面に表示される項目と、第２状態のときに画面に表示される項目とは原則として同じである。同じとは、各項目が表示される位置、各項目のサイズが不変という意味である。ただし、各項目の「状態」は変化し得る。つまり、画面が第１状態のときの項目ａの状態と、画面が第２状態のときの項目ａの状態は同じとは限らない。例えば、画面が第１状態のときは項目ａの色を灰色とし、画面が第２状態のときは項目ａの色を黄色とする。

画面状態遷移定義とは、画面が第１状態のときに、（１−１）入力操作ａがなされたら、画面を第２状態に遷移させ、（１−２）入力操作ｂがなされたら、画面を第２状態とは異なる状態に遷移させることなどを定義したものである。

本発明の第２の特徴は、所定の処理を実行する１以上の他のシステムと、ユーザとのインターフェースシステムであって、（１）ユーザからの入力操作を受け付ける画面を表示させるための画面データと、前記画面の第１状態と前記入力操作との組み合わせに対して業務処理を対応付け、さらに前記業務処理の処理結果に対して前記画面の第２状態を対応付けている画面状態遷移定義と、前記業務処理と前記他のシステムに対する処理要求との対応を示すトランザクション変換定義とを記憶する記憶部と、（２）前記他のシステムへ前記処理要求を送信し、前記他のシステムから前記処理結果を受信する送受信部と、（３）前記画面を前記第１状態にて表示させ、前記入力操作を受け付けた場合に、前記画面状態遷移定義を参照して、前記業務処理を読み出し、前記トランザクション変換定義を参照して、前記処理要求を生成し、前記送受信部に前記処理要求を送信させ、前記送受信部が前記処理結果を受け付けたら、前記画面状態遷移定義を参照して、前記画面を前記第２状態へ遷移させる制御部と、を備えることにある。

画面データは、画面に表示されるボタン及びデータ入力領域などの各項目を構成するデータを含み、（１）記憶部は、さらに、（１−１）画面が第１状態であるときにボタンを表示させるか、データ入力領域を入力可能状態とするか、（１−２）画面が第２状態であるときにボタンを表示させるか、及びデータ入力領域を入力可能状態とするかについて定義するデータストア定義を記憶し、（２）制御部は、さらに、（２−１）画面を第１状態にて表示させる場合に、データストア定義を参照して、ボタンを表示又は非表示とし、データ入力領域を入力可能状態又は入力不可能状態とし、（２−２）画面を第２状態へ遷移させる場合に、データストア定義を参照して、ボタンを表示又は非表示とし、データ入力領域を入力可能状態又は入力不可能状態とする、ことが好ましい。

非表示とは完全に見えなくなるのではなく、ボタンの輪郭が不鮮明になったり、ボタンに記載されている文字がぼやけたりすることを含む。

本発明の第１の特徴によれば、入力操作を受け付けた場合に、その入力操作がなされた時の画面の状態とその入力操作の内容に応じて、予め定められた画面状態へ遷移する。第１の状態と第２の状態とで、画面を構成するボタンなどの各項目は共通である。つまり、入力操作を受け付ける前と後のそれぞれに対応する２つの画面を作成・管理する必要がない。

本発明の第２の特徴によれば、入力操作を受け付けた場合に、その入力操作がなされた時の画面の状態とその入力操作の内容に応じて、予め定められた処理要求が生成され、他のシステムに送信され、他のシステムから処理結果が返信され、その処理結果に応じて予め定められた画面状態へ遷移する。つまり、入力操作を受け付ける前と後のそれぞれに対応する２つの画面を作成・管理する必要がなく、しかもインターフェースシステムを変更しても、処理要求送信先である業務処理ロジックなどを変更する必要がない。

本発明の実施形態では、「画面の状態」という概念を導入し、以下の仕組みを作ることにより、同じ画面であっても、画面の「状態」の遷移を図で書いてその設計情報のまま動かすことが可能となる。

図１は、本発明を適用した業務処理システムの全体構成を示す。本システムは、端末１０と、フロントエンドシステム２０と、バックエンドシステム３０とを備える。端末１０およびバックエンドシステム３０は、それぞれ、複数備えていてもよい。フロントエンドシステム２０は、各端末１０および各バックエンドシステム３０と、それぞれ接続されている。また、本システムは、フロントエンドシステム２０を複数備えることも可能である。その場合、各フロントエンドシステム２０と端末１０とで、後述するデータストア２２０の内容の同期を取るようにしてもよいし、あるいは、データストア２２０をフロントエンドシステム２０の外部に備え、各フロントエンドシステム２０がデータストア２２０を共有するようにしてもよい。

端末１０は、図示しない入力装置と表示装置とを備え、ユーザに対して情報を表示し、それに対する入力を受け付ける。フロントエンドシステム２０は、端末１０と、バックエンドシステム３０とのインターフェースシステムとして機能する。すなわち、端末１０を介してユーザからの業務処理要求を受け付け、それに応じて、いずれか１以上のバックエンドシステム３０に対して業務処理要求を出力する。また、フロントエンドシステム２０は、業務処理結果を各バックエンドシステム３０から受け取る。

バックエンドシステム３０は、それぞれ、フロントエンドシステム２０から業務処理要求を受け付けて、所定の処理を行う。処理結果は、フロントエンドシステム２０へ返却される。さらに、処理結果に応じた情報が、フロントエンドシステム２０から端末１０へ返却される。

端末１０、フロントエンドシステム２０およびバックエンドシステム３０は、いずれもコンピュータシステムにより構成される。以下に説明する各構成または各機能は、例えば、コンピュータプログラムを実行することにより実現される。

図２は、フロントエンドシステム２０の構成を示す。フロントエンドシステム２０は、全体を制御する主制御部（制御手段、以下「ＣＰＵ」とする）１０１に記憶装置１０３が接続されている。ＣＰＵ１０１には、また、入出力制御部１０５を介して送受信部１０７が接続されている。さらに、プログラム領域とデータ領域を有するランダムアクセスメモリ（ＲＡＭ）１０４と、基本入出力システム（ＢＩＯＳ）などが記憶される図示していないリードオンリーメモリ（ＲＯＭ）とがＣＰＵ１０１に接続されている。

記憶装置１０３は、ハードディスク、フレキシブルディスク、光ディスク、光磁気ディスクなどのストレージ手段であり、画面データ２１、画面状態遷移定義２２、データストア定義２３、トランザクション変換定義２４、データ変換定義２５、電文定義２６などが格納されている。

画面データ２１は、端末１０の表示装置に表示させるための画面データである。画面データは、例えばＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式等であらかじめ作成されている。各画面データに基づいて表示された画面は、ユーザからの入力操作を受け付け、ＣＰＵ１０１がその操作内容に応じたフロントトランザクションをコールする。

例えば、図１１に、新規入力画面１００の画面データを端末１０の表示装置に表示したときの例を示す。新規入力画面１００は、処理モードの入力領域１１０と、確定ボタン１１２とを備える。確定ボタン１１２が押されると、フロントトランザクションｍｏｄｅＳｅｌｅｃｔメソッドがコールされる。つまり、画像データには、図１１に示す画面を表示し、フロントトランザクションをコールするためのデータが含まれる。

画面状態遷移定義２２は、画面の「状態」が遷移する順番を定義する。例えば、各画面がコールするフロントトランザクションに対する応答に応じて、遷移する画面の「状態」を定義する。

図３に、画面状態遷移定義２２の内容の例を示す。図３では、遷移元２２１と、アクション２２２と、ＢＬ（ビジネスロジック）処理２２３と、遷移先２２４とがそれぞれ対応付けられている。遷移元２２１は、ページＩＤ２２１ａと状態ＩＤ２２１ｂとを含む。アクション２２２は、ＩＤ２２２ａとボタン２２２ｂとその説明２２２ｃとを含む。ＢＬ処理２２３は、メソッド名２２３ａとその説明２２３ｂと返却値２２３ｃとその説明２２３ｄとを含む。遷移先２２４は、ページＩＤ２２４ａと状態ＩＤ２２４ｂとファイル名２２４ｃとを含む。

図３に示すように、遷移元であっても遷移先であっても、ページＩＤは”ｃｈｉｔ”ただ一つだけであり、ファイル名もｃｈｉｔ．ａｓｐｘただ一つだけである。ページの「状態」は遷移するが、ページそのものは遷移しないからである。

ここに示す例では、以下のことが定義されている。例えば、ページＩＤ２２１ａが”ｃｈｉｔ”で状態ＩＤ２２１ｂが”ｍｏｄｅＣｈｏｉｃｅ”であるとき、つまり端末１０の表示装置の画面に処理選択画面（図１１）が表示されているときに、ユーザからアクションＩＤ２２２ａに対応する操作（画面上の確定ボタン１１２のクリック）を受けたとき、フロントトランザクションとしてメソッド名２２３ａに示されている”ｍｏｄｅＳｅｌｅｃｔ”メソッドがコールされ、「処理分岐」処理が行われる。そして、返却値２２３ｃに応じて、どの状態に遷移するかを状態ＩＤ２２４ｂに示す。なお、前記の如く、返却値２２３ｃが０〜４のいずれであっても、遷移先のページＩＤ２２４ａは”ｃｈｉｔ”である。

図４に、図３の定義内容に沿った画面状態の遷移の流れを示す。

例えば、画面「状態」が”ｍｏｄｅＣｈｏｉｃｅ”４０１であるときに、「確定」ボタンが押され、「処理分岐」４０３の返却値２２３ｃが「０」なら、つまり説明２２３ｄに示すように伝票取得に失敗したなら、画面「状態」は”ｍｏｄｅＣｈｏｉｃｅ”４０１のままである。

しかし、返却値２２３ｃが「１」なら、つまり説明２２３ｄに示すように伝票の「新規」作成が指示されたなら、画面「状態」は”ｃｈｉｔＩｎｓｅｒｔ”４０５へ遷移する。返却値２２３ｃが「２」なら、つまり説明２２３ｄに示すように伝票の「照会」が指示されたなら、画面「状態」は”ｃｈｉｔＶｉｅｗ”４０７へ遷移する。返却値２２３ｃが「３」なら、つまり説明２２３ｄに示すように伝票の「訂正」が指示されたなら、画面「状態」は”ｃｈｉｔＵｐｄａｔｅ”４０９へ遷移する。返却値２２３ｃが「４」なら、つまり説明２２３ｄに示すように伝票の「削除」が指示されたなら、画面「状態」は”ｃｈｉｔＥｎｄｏｒｓｅ”４１５へ遷移する。

画面「状態」が”ｃｈｉｔＩｎｓｅｒｔ”４０５であるときに、「入力完了」ボタンが押され、「新規伝票チェック」処理４１１の返却値２２３ｃが「０」なら、つまり説明２２３ｄに示すように伝票チェックに失敗したなら、画面「状態」は”ｃｈｉｔＩｎｓｅｒｔ”４０５のままである。しかし、返却値２２３ｃが「１」なら、つまり説明２２３ｄに示すように伝票チェックに成功したなら、画面「状態」は”ｃｈｉｔＥｎｄｏｒｓｅ”４１５へ遷移する。

画面「状態」が”ｃｈｉｔＵｐｄａｔｅ”４０９であるときに、「入力完了」ボタンが押され、「伝票修正」処理４１３の返却値２２３ｃが「０」なら、つまり説明２２３ｄに示すように伝票チェックに失敗したなら、画面「状態」は”ｃｈｉｔＵｐｄａｔｅ”４０９のままである。しかし、返却値２２３ｃが「１」なら、つまり説明２２３ｄに示すように伝票チェックに成功したなら、画面「状態」は”ｃｈｉｔＥｎｄｏｒｓｅ”４１５へ遷移する。

そして、画面「状態」が”ｃｈｉｔＥｎｄｏｒｓｅ”４１５であるときに、「実行」ボタンが押され、「伝票登録」処理４１７の返却値２２３ｃが「０」なら、つまり説明２２３ｄに示すように伝票登録に失敗したなら、画面「状態」は”ｃｈｉｔＥｎｄｏｒｓｅ”４１５のままである。しかし、返却値２２３ｃが「１」なら、つまり説明２２３ｄに示すように伝票登録に成功したなら、画面「状態」は”ｍｏｄｅＣｈｏｉｃｅ”４０１へ遷移する。

ＣＰＵ１０１は、端末１０の表示装置に表示する画面を制御する。例えば、ＣＰＵ１０１は、画面データ２１を取得して、送受信部１０７を介して端末１０の表示装置へ出力する。また、ＣＰＵ１０１は、端末１０の表示装置に表示されている画面の入力領域（例えば、処理モードの入力領域１１０）に入力されたデータを受け付けて、データストア２２０に記憶する。さらに、データストア２２０からデータを取得して、表示装置に表示させるために画面データ２１と併せて、送受信部１０７を経由して端末１０の表示装置へ出力する。

また、ＣＰＵ１０１は、バックエンドシステムから送受信部１０７を経由して処理結果を示す返却値を受け付ける。そして、ＣＰＵ１０１は、その返却値に応じて、画面状態遷移定義２２に定義されている状態へ遷移させる。

データストア定義２３は、データストア２２０に記憶される各データ項目の項目ＩＤ、各状態における各項目の属性などを定義する。

図５に示すように、例えば、データストア定義のデータ項目は、項目ＩＤ２３１と、データ型２３２と、日本語名２３３と、属性２３４とを含む。項目ＩＤ２３１は、画面に表示される各項目の識別子である。項目ＩＤ２３１は、フロントエンドシステム２０において一意に識別できるように命名されている。データ型２３２は、各項目のデータ型を示す。日本語名２３３は、各項目ＩＤ２３１の日本語名称である。属性２３４は、各状態（ｍｏｄｅＣｈｏｉｃｅ、ｃｈｉｔＩｎｓｅｒｔ、ｃｈｉｔＶｉｅｗ、ｃｈｉｔＥｎｄｏｒｓｅ、ｃｈｉｔＵｐｄａｔｅ）において各項目（ＳＹＯＲＩ＿ＭＯＤＥ、ＳＹＢＴ１、ＤＮＰＹＵ＿ＮＯ１など）が書き込み可かリードオンリーかを示す。

図１１は”ｍｏｄｅＣｈｏｉｃｅ”状態を示し、図１２は”ｃｈｉｔＶｉｅｗ”状態を示し、図１３は”ｃｈｉｔＵｐｄａｔｅ”状態を示し、図１４は”ｃｈｉｔＥｎｄｏｒｓｅ”状態を示す。図１１〜１４に示すように、各状態において表示される項目は共通する。ただし、各項目が書き込み可又はリードオンリーのいずれの「状態」かは図によって異なる。

図５に示すように、例えば、項目ＩＤ”ＳＨＯＲＩ＿ＭＯＤＥ”、”ＳＹＢＴ１”及び”ＤＮＰＹＵ＿ＮＯ１”は”ｍｏｄｅＣｈｏｉｃｅ”状態のときは書き込み可だが、それ以外の状態の時はリードオンリーである。これは、図１１に示す”ｍｏｄｅＣｈｏｉｃｅ”状態では処理モード入力領域１１０、種別コード入力領域１１３及び伝票Ｎｏ入力領域１１４は書き込み可であるが、図１２〜１４に示す他の状態においては、各入力領域１１０〜１１４がリードオンリーとなることを意味する。

図１５に示すように、例えば複数の項目（コントロール）をヘッダ項目部、明細項目部などに分けて、各項目部に属する項目（コントロール）をまとめて有効／無効のいずれかに設定することができる。

具体的には、４、５、１５〜１７行に示すように、”ｍｏｄｅＣｈｏｉｃｅ”状態では、”ＣｈａｎｇｅＨｅａｄｅｒＳｔａｔｅ（）”の引数が”Ｔｒｕｅ”であるから、”ＳＨＯＲＩ＿ＭＯＤＥ”、”ＳＹＢＴ１”及び”ＤＮＰＹＵ＿ＮＯ１”の各コントロールはいずれも”ＲｅａｄＯｎｌｙ”ではなく、”Ｅｎａｂｌｅｄ”となる。

一方、４、６、２８〜４１行に示すように、”ｍｏｄｅＣｈｏｉｃｅ”状態では、”ＣｈａｎｇｅＭｅｉｓａｉＳｔａｔｅ（）”の引数が”Ｆａｌｓｅ”であるから、２８〜４１行の各コントロールはいずれも”ＲｅａｄＯｎｌｙ”となる。

なお、図１５に示すソースコードの例では、項目をヘッダ項目部、明細項目部、フッタ項目部の３つのグループに分けて有効／無効の設定を行ったが、これは一例に過ぎない。各項目を４以上のグループに分けて有効／無効の設定をしても良く、またグループ分けをせずに各項目毎に各画面状態における有効／無効を設定しても良い。グループ分けをする／しないに関わらず、図５に示すように、各画面状態において各項目が如何なる状態にあるかが定義されれば良い。

データストア２２０は、表示画面ごとに、各画面で入出力されるデータを一時的に記憶する。具体的には、データストア２２０は、表示画面の入力領域に入力されたデータ、および表示画面へ出力するためのデータを、項目ＩＤ２３１ごとに格納する領域を有する。

トランザクション変換定義２４は、フロントトランザクションからバックエンドシステムのトランザクションへの変換定義である。

図６に示すように、例えば、トランザクション変換定義２４は、フロントトランザクション２４１とバックエンドのトランザクション２４２とを対応付けて記憶する。各バックエンドトランザクション２４２は、いずれかのバックエンドシステム３０に対する業務処理要求である。例えば、一のフロントトランザクションを実行するために、複数のバックエンドシステム３０で処理を行う必要があるときは、一のフロントトランザクション２４１に、複数のバックエンドトランザクション２４２が、対応付けられる。複数のバックエンドトランザクションが対応付けられるときには、各トランザクションをシーケンシャル（直列的）に実行する場合（２４２ａ）と、パラレル（同時実行または並列的）に実行する場合（２４２ｂ）とがある。

ＣＰＵ１０１は、トランザクション変換定義２４を参照して、フロントトランザクションからバックエンドのトランザクションへ変換する。また、ＣＰＵ１０１は、データ変換定義２５を参照してバックエンドトランザクションに対応する電文を生成する。

図７に示すように、例えば、データ変換定義２５は、バックエンドのトランザクションで使用する上り電文と下り電文とを対応付けて記憶する。具体的には、データ変換定義として、バックエンドのトランザクション２５１と、上り電文２５２と、下り電文と２５３とを対応付けて記憶する。

また、各電文のフォーマットは、電文定義２６として記憶されている。電文定義の例は、図８に示すように、電文名２６１と、桁数２６２と、電文におけるフィールド名２６３と、表示画面での入出力項目２６４とを対応付けて記憶する。なお、入出力項目２６４は、項目ＩＤ２３１と対応している。

ＣＰＵ１０１は、電文の生成、および分解を行う。例えば、ＣＰＵ１０１は、トランザクション変換定義２４に基づいてフロントトランザクションからバックエンドトランザクションを生成し、データ変換定義２５に基づいて必要な上り電文を生成する。生成された電文は、送受信部１０７へ出力される。

上り電文の生成は、具体的には、以下のように行う。ＣＰＵ１０１が、データ変換定義２５を参照して、バックエンドトランザクション２５１に対応する上り電文２５２を取得する。さらに、ＣＰＵ１０１は、その電文のフォーマットを電文定義２６から取得する。そして、ＣＰＵ１０１は、入出力項目２６４に示すデータをデータストア２２０から取得して、上り電文を生成する。

また、ＣＰＵ１０１は、送受信部１０７から下り電文を受け付け、電文定義２６を参照して、受け取った下り電文から、データを取り出す。取り出された各データは、データストア２２０の入出力項目２６４に示す位置へ格納される。

送受信部１０７は、バックエンドシステム３０と電文の送受信をする。送受信部１０７は、１のバックエンドシステム３０に対して一つ存在するとしても良い。

次に、上記構成を備える本システムにおいて、図３に示す画面状態遷移定義（検索入力画面から店名入力画面または検索エラー画面への遷移）を例に、画面状態が遷移するときの処理手順ついて説明する。処理手順のフローチャートは、図９に示す。

ＣＰＵ１０１が、図１３に示す修正入力状態の画面１３０の画面データを画面データ２１から取得し、かつ修正入力状態における各項目の属性データをデータストア定義２３から取得して、端末１０の表示装置に対して出力すると、端末１０の表示装置に修正入力状態の画面１３０が表示される（Ｓ１００）。

かかる状態の画面に対して、ユーザが商品コードを商品コード入力領域１３１に、数量を数量入力領域１３２に、数量合計を数量合計入力領域１３３に、税抜合計を税抜合計入力領域１３４に、税込み合計を税込合計入力領域１３５に、伝票発行日を発行日入力領域１３６に、商品納品日を納品日入力領域１３７に入力して、入力完了ボタン１３８を押す。ＣＰＵ１０１は、各入力領域に入力されたデータを取り込んで、データストア２２０に格納する（Ｓ１１０）。

入力完了ボタン１３８が押されると、ＣＰＵ１０１は、画面状態遷移定義２２を参照して、フロントトランザクションとしてｕｐｄａｔｅＣｈｉｔメソッドをコールする（Ｓ１２０）。ＣＰＵ１０１は、トランザクション変換定義２４を参照して、フロントトランザクションをそれに対応するバックエンドトランザクションへ変換する（Ｓ１３０）。さらに、ＣＰＵ１０１は、データ変換定義２５を参照して、バックエンドトランザクションに対応する電文の種類を判定し、その電文フォーマットを電文定義２６から取得する。ＣＰＵ１０１は、必要なデータをデータストア２２０から取得して、電文を生成して入出力制御部１０５を介して送受信部１０７へ渡す。送受信部１０７が、バックエンドシステム３０へ上り電文を送信する（Ｓ１４０）。

バックエンドシステム３０は、受信した電文を読み、所定の処理を実行し、その結果（返却値およびデータ）を下り電文を用いて返却する。

送受信部１０７を介して下り電文を受信すると、ＣＰＵ１０１は、下り電文を解析して、データストア２２０に格納すべきデータがある場合は、格納する（Ｓ１５０）。ＣＰＵ１０１は、返却値および画面状態遷移定義２２に基づいて、遷移する画面状態を決定する。すなわち、返却値が１（伝票チェック成功）であるときは、画面状態はｃｈｉｔＥｎｄｏｒｓｅ（伝票登録）へ遷移する（Ｓ１６０、Ｓ１７０）。返却値が０（伝票チェック失敗）であるときは、画面状態はｃｈｉｔＵｐｄａｔｅ（伝票修正）のままである。

このようにして、フロントエンドシステム２０は、各定義情報に従ってユーザからの業務処理要求を実行することができる。特に、入力されたアクションによってコールするフロントトランザクションの実体は、トランザクション変換定義により定まる。このため、画面のレイアウト等を変更するために、画面データを更新しても、業務処理のロジックを変更する必要がない。つまり、ユーザからの入力受け付けと、業務処理とを分離することができ、それぞれ独立して修正や変更をすることが可能となる。この結果、システムの拡張性、メンテナンス性が向上する。

また、図３に示したように、ページもファイル名も一つだけ、つまり画面は常に同じでその状態が遷移するだけであるから、複数の画面を用意し、それら画面間を遷移する場合に比して、保守や設計変更が容易である。

これは、図３に示したように、画面状態遷移定義として、画面の状態とアクションの組み合わせに応じて起動する処理と、その処理結果（返却値）に応じて遷移する状態を対応付けているからである。

なお、図５には、説明の簡略化のため、状態に応じて遷移する項目の属性として「○：書き込み可」と「×：リードオンリー」だけを例示した。しかし、状態に応じて遷移する属性はこれだけには限られない。例えば、図１１と図１２に示した処理モード入力領域１１０を比較すれば明らかなように、入力領域内の色を遷移させても良い。つまり、処理モード入力領域１１０の色を”ｍｏｄｅＣｈｏｉｃｅ”状態のときは「白」、”ｃｈｉｔＩｎｓｅｒｔ”状態の時は「青」、”ｃｈｉｔＶｉｅｗ”状態のときは「灰色」としても良い。

例えば、図１１と図１２に示した確定ボタン１１２を比較すれば明らかなように、ボタンを表示する／しないを遷移させても良い。つまり、”ｍｏｄｅＣｈｏｉｃｅ”状態のときは確定ボタン１１２を表示するが、”ｃｈｉｔＶｉｅｗ”状態のときは確定ボタン１１２を非表示としても良い。その他、リストボックスの表示内容、エラーチェック仕様、入力操作仕様などを画面の状態に応じて遷移させても良い。

また、図３に示したように、ＢＬ処理２２３において伝票取得失敗、伝票チェック失敗、伝票登録失敗など返却値が０の場合について、遷移先２２１のページＩＤ２２１ａと状態ＩＤ２２１ｂは、遷移元２２４のページＩＤ２２４ａと状態ＩＤ２２４ｂと同じとした。このように、入力値にエラーがあったら自動的に元の状態に戻すことにより、煩雑となりがちなエラー発生時の画面の状態遷移が記述不要となった。

なお、上記実施形態の説明では、各定義情報は、図面に表形式で表示して説明した。しかし、本実施形態で実装する場合、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式に変換されたものを用いる。以下、この定義形式の変換装置について説明する。

定義形式変換装置５０は、スプレッドシート形式の定義情報記憶部６０から表形式のスプレッドシートで記述された定義情報を入力として受け付け、ＸＭＬ形式に変換し、ＸＭＬ形式定義情報記憶部７０に出力する。その構成図を図１０に示す。

定義形式変換装置５０は、複数の定義変換部５１と、いずれかの定義変換部５１を選択する選択部５２とを備える。各定義変換部５１は、それぞれ、画面状態遷移定義２２、データストア定義２３、トランザクション変換定義２４などの各定義情報と対応している。

定義形式変換装置５０は、コンピュータシステムにより構成される。以下に説明する各構成または各機能は、例えば、コンピュータプログラムを実行することにより実現される。

スプレッドシート形式定義情報記憶部６０には、スプレッドシートで作成された図３、図５〜図８に示す表形式の定義情報が記憶されている。定義形式変換装置５０は、各スプレッドシートを入力として受け付ける。そして、選択部５２が、スプレッドシートのファイル名から、いずれの定義情報であるかを判別する。判別の結果、入力されたスプレッドシートと対応する定義変換部５１が選択される。選択された定義変換部５１は、スプレッドシートを読み込み、所定の変換ルールに基づいてＸＭＬ形式に変換する。具体的には、各定義変換部５１は、ＸＭＬのひな型を保有している。そして、スプレッドシートのセルを読み込んで、そのひな型に当てはめてＸＭＬ形式に変換する。ＸＭＬ形式の定義情報は、ＸＭＬ形式定義情報記憶部７０に格納される。

これにより、一般的なスプレッドシートで作成した定義情報を、他の表現形式に変換することができる。

なお、ここではスプレッドシート形式からＸＭＬ形式へ変換したが、他の形式へ変換してもよい。

例えば、ユーザからの入力と業務処理との対応（トランザクション変換定義）、または、業務処理の処理結果と表示する画面状態との対応（画面遷移定義）を、スプレッドシート形式の定義情報として作成すれば、プログラミングすることなく、簡単に実装することができる。

本発明を適用した業務処理システムの全体構成を示す図である。 フロントエンドシステムの構成例を示す図である。 画面状態遷移定義の内容の一例を示す図である。 図３の定義内容に沿った画面状態の遷移の流れを示す図である。 データストア定義の内容の一例を示す図である。 トランザクション変換定義の内容の一例を示す図である。 データ変換定義の内容の一例を示す図である。 電文定義の内容の一例を示す図である。 画面状態を遷移させるときの処理手順を示すフローチャートである。 スプレッドシート形式の定義情報を、ＸＭＬ形式に変換する定義形式変換装置の構成例を示す図である。 新規伝票入力画面を端末の表示装置に表示したときの一例を示す図である。 伝票照会画面を端末の表示装置に表示したときの一例を示す図である。 伝票修正画面を端末の表示装置に表示したときの一例を示す図である。 伝票登録画面を端末の表示装置に表示したときの一例を示す図である。 項目（コントロール）を複数のグループに分け、各グループ毎に項目の有効／無効を設定する具体例を示す図である。

符号の説明

１０…端末、 ２０…フロントエンドシステム、 ３０…バックエンドシステム、
１０１…主制御部（ＣＰＵ）、 １０３…記憶装置、
１０４…ランダムアクセスメモリ（ＲＡＭ）、 １０５…入出力制御部、
１０７…送受信部

Claims (11)

1. ユーザからの入力操作を受け付ける画面を表示させるための画面データと、前記画面の第１状態と前記入力操作との組み合わせに対して業務処理を対応付け、さらに前記業務処理の処理結果に対して前記画面の第２状態を対応付けている画面状態遷移定義とを記憶する記憶部と、
   前記画面を前記第１状態にて表示させ、前記入力操作を受け付けた場合に、前記画面状態遷移定義を参照して、前記業務処理の開始を指示し、前記処理結果を受け付けたら、前記画面を前記第２状態へ遷移させる制御部と、を備える画面状態遷移システム。
2. 所定の処理を実行する１以上の他のシステムと、ユーザとのインターフェースシステムであって、
   ユーザからの入力操作を受け付ける画面を表示させるための画面データと、前記画面の第１状態と前記入力操作との組み合わせに対して業務処理を対応付け、さらに前記業務処理の処理結果に対して前記画面の第２状態を対応付けている画面状態遷移定義と、前記業務処理と前記他のシステムに対する処理要求との対応を示すトランザクション変換定義とを記憶する記憶部と、
   前記他のシステムへ前記処理要求を送信し、前記他のシステムから前記処理結果を受信する送受信部と、
   前記画面を前記第１状態にて表示させ、前記入力操作を受け付けた場合に、前記画面状態遷移定義を参照して、前記業務処理を読み出し、前記トランザクション変換定義を参照して、前記処理要求を生成し、前記送受信部に前記処理要求を送信させ、前記送受信部が前記処理結果を受け付けたら、前記画面状態遷移定義を参照して、前記画面を前記第２状態へ遷移させる制御部と、を備えるインターフェースシステム。
3. 前記画面データは、前記画面に表示されるボタン及びデータ入力領域を構成するデータを含み、
   前記記憶部は、さらに、前記画面が前記第１状態であるときに前記ボタンを表示させるか、及び前記データ入力領域を入力可能状態とするか、並びに前記画面が前記第２状態であるときに前記ボタンを表示させるか、及び前記データ入力領域を入力可能状態とするかについて定義するデータストア定義を記憶し、
   前記制御部は、さらに、前記画面を前記第１状態にて表示させる場合に、前記データストア定義を参照して、前記ボタンを表示又は非表示とし、前記データ入力領域を入力可能状態又は入力不可能状態とし、前記画面を前記第２状態へ遷移させる場合に、前記データストア定義を参照して、前記ボタンを表示又は非表示とし、前記データ入力領域を入力可能状態又は入力不可能状態とする、請求項２に記載のインターフェースシステム。
4. 前記画面状態遷移定義又はトランザクション変換定義の少なくとも一方が、スプレッドシートで作成された定義情報のファイルを受け付けて、他の表現形式で同一の定義内容を示す定義ファイルへ変換する定義情報変換装置で変換された定義である請求項２に記載のインターフェースシステム。
5. 前記画面状態遷移定義、トランザクション変換定義又はデータストア定義の少なくとも一つが、スプレッドシートで作成された定義情報のファイルを受け付けて、他の表現形式で同一の定義内容を示す定義ファイルへ変換する定義情報変換装置で変換された定義である請求項３に記載のインターフェースシステム。
6. コンピュータに、
   ユーザからの入力操作を受け付ける画面を表示させるための画面データと、前記画面の第１状態と前記入力操作との組み合わせに対して業務処理を対応付け、さらに前記業務処理の処理結果に対して前記画面の第２状態を対応付けている画面状態遷移定義とを記憶するステップと、
   前記画面を前記第１状態にて表示させ、前記入力操作を受け付けた場合に、前記画面状態遷移定義を参照して、前記業務処理の開始を指示するステップと、
   前記処理結果を受け付けたら、前記画面状態遷移定義を参照して、前記画面を前記第２状態へ遷移させるステップと、を実行させるための画面状態遷移プログラム。
7. 所定の処理を実行する１以上の他のシステムと、ユーザとのインターフェースシステムとするために、コンピュータに、
   ユーザからの入力操作を受け付ける画面を表示させるための画面データと、前記画面の第１状態と前記入力操作との組み合わせに対して業務処理を対応付け、さらに前記業務処理の処理結果に対して前記画面の第２状態を対応付けている画面状態遷移定義と、前記業務処理と前記他のシステムに対する処理要求との対応を示すトランザクション変換定義とを記憶するステップと、
   前記画面を前記第１状態にて表示させ、前記入力操作を受け付けた場合に、前記画面状態遷移定義を参照して、前記業務処理を読み出し、前記トランザクション変換定義を参照して、前記処理要求を生成するステップと、
   前記他のシステムへ前記処理要求を送信するステップと、
   前記他のシステムから前記処理結果を受信するステップと、
   前記画面状態遷移定義を参照して、前記画面を前記第２状態へ遷移させるステップと、を実行させるためのインターフェースシステム用プログラム。
8. 前記画面データは、前記画面に表示されるボタン及びデータ入力領域を構成するデータを含み、
   コンピュータに、さらに、
   前記画面が前記第１状態であるときに前記ボタンを表示させるか、及び前記データ入力領域を入力可能状態とするか、並びに前記画面が前記第２状態であるときに前記ボタンを表示させるか、及び前記データ入力領域を入力可能状態とするかについて定義するデータストア定義を記憶するステップと、
   前記画面を前記第１状態にて表示させる場合に、前記データストア定義を参照して、前記ボタンを表示又は非表示とし、前記データ入力領域を入力可能状態又は入力不可能状態とするステップと、
   前記画面を前記第２状態へ遷移させる場合に、前記データストア定義を参照して、前記ボタンを表示又は非表示とし、前記データ入力領域を入力可能状態又は入力不可能状態とするステップと、を実行させるための請求項７に記載のインターフェースシステム用プログラム。
9. 記憶手段が、ユーザからの入力操作を受け付ける画面を表示させるための画面データと、前記画面の第１状態と前記入力操作との組み合わせに対して業務処理を対応付け、さらに前記業務処理の処理結果に対して前記画面の第２状態を対応付けている画面状態遷移定義とを記憶するステップと、
   制御手段が、前記画面を前記第１状態にて表示させ、前記入力操作を受け付けた場合に、前記画面状態遷移定義を参照して、前記業務処理の開始を指示し、前記処理結果を受け付けたら、前記画面状態遷移定義を参照して、前記画面を前記第２状態へ遷移させるステップと、を有する画面状態遷移方法。
10. 所定の処理を実行する１以上の他のシステムと、ユーザとのインターフェースシステムとするために、
    記憶手段が、ユーザからの入力操作を受け付ける画面を表示させるための画面データと、前記画面の第１状態と前記入力操作との組み合わせに対して業務処理を対応付け、さらに前記業務処理の処理結果に対して前記画面の第２状態を対応付けている画面状態遷移定義と、前記業務処理と前記他のシステムに対する処理要求との対応を示すトランザクション変換定義とを記憶するステップと、
    制御手段が、前記画面を前記第１状態にて表示させ、前記入力操作を受け付けた場合に、前記画面状態遷移定義を参照して、前記業務処理を読み出し、前記トランザクション変換定義を参照して、前記処理要求を生成するステップと、
    送信手段が、前記他のシステムへ前記処理要求を送信するステップと、
    受信手段が、前記他のシステムから前記処理結果を受信するステップと、
    制御手段が、前記画面状態遷移定義を参照して、前記画面を前記第２状態へ遷移させるステップと、を有するインターフェース方法。
11. 前記画面データは、前記画面に表示されるボタン及びデータ入力領域を構成するデータを含み、
    前記記憶手段が、前記画面が前記第１状態であるときに前記ボタンを表示させるか、及び前記データ入力領域を入力可能状態とするか、並びに前記画面が前記第２状態であるときに前記ボタンを表示させるか、及び前記データ入力領域を入力可能状態とするかについて定義するデータストア定義を記憶するステップと、
    前記制御手段が、前記画面を前記第１状態にて表示させる場合に、前記データストア定義を参照して、前記ボタンを表示又は非表示とし、前記データ入力領域を入力可能状態又は入力不可能状態とし、前記画面を前記第２状態へ遷移させる場合に、前記データストア定義を参照して、前記ボタンを表示又は非表示とし、前記データ入力領域を入力可能状態又は入力不可能状態とするステップと、をさらに有する請求項１０に記載のインターフェース方法。