JP2004078264A - 画面遷移プログラムおよびインタプリタ装置 - Google Patents
画面遷移プログラムおよびインタプリタ装置 Download PDFInfo
- Publication number
- JP2004078264A JP2004078264A JP2002233349A JP2002233349A JP2004078264A JP 2004078264 A JP2004078264 A JP 2004078264A JP 2002233349 A JP2002233349 A JP 2002233349A JP 2002233349 A JP2002233349 A JP 2002233349A JP 2004078264 A JP2004078264 A JP 2004078264A
- Authority
- JP
- Japan
- Prior art keywords
- screen
- state
- stack
- transition
- node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Images
Landscapes
- Digital Computer Display Output (AREA)
- Devices For Executing Special Programs (AREA)
Abstract
【課題】画面遷移を伴うアプリケーションシステムを開発するたびに新たに開発する必要がない画面遷移プログラムを提供する。
【解決手段】画面遷移プログラムは、画面遷移定義ファイルにおいて指定された初期画面の画面IDを前記スタックに積むステップS1と、スタックの最上位の位置にある画面IDを取得するステップS2と、ステップS2において取得された画面IDに対応する画面内の処理を実行するステップS3と、ステップS3において画面内の処理を実行した結果としてスタック操作を取得し、取得されたスタック操作をスタックに対して実行するステップS4と、スタックが空状態になるまで、ステップS2〜S4を繰り返すステップS5とを包含する。
【選択図】 図6
【解決手段】画面遷移プログラムは、画面遷移定義ファイルにおいて指定された初期画面の画面IDを前記スタックに積むステップS1と、スタックの最上位の位置にある画面IDを取得するステップS2と、ステップS2において取得された画面IDに対応する画面内の処理を実行するステップS3と、ステップS3において画面内の処理を実行した結果としてスタック操作を取得し、取得されたスタック操作をスタックに対して実行するステップS4と、スタックが空状態になるまで、ステップS2〜S4を繰り返すステップS5とを包含する。
【選択図】 図6
Description
【0001】
【発明の属する技術分野】
本発明は、画面遷移プログラムおよびインタプリタ装置に関する。
【0002】
【従来の技術】
従来、画面遷移を伴うアプリケーションシステムは、画面遷移の仕様に基づいて個々に開発されてきた。
【0003】
【発明が解決しようとする課題】
従来、アプリケーションシステムを開発するたびに画面遷移プログラムを新たに開発する必要があったため、アプリケーションシステムの開発に多大な労力およびコストがかかっていた。また、画面遷移の仕様は開発過程において変更される可能性が高く、そのことがアプリケーションシステムの納品の遅れ、品質の低下を招く原因となっていた。
【0004】
本発明は、画面遷移を伴うアプリケーションシステムを開発するたびに新たに開発する必要がない画面遷移プログラムおよびそれを実行するためのインタプリタ装置を提供することを目的とする。
【0005】
また、本発明は、画面遷移を伴うアプリケーションシステムの開発期間を画期的に短縮するとともに、画面遷移を伴うアプリケーションシステムの品質を画期的に向上させることが可能な画面遷移プログラムおよびそれを実行するためのインタプリタ装置を提供することを目的とする。
【0006】
【課題を解決するための手段】
本発明の画面遷移プログラムは、画面遷移処理をコンピュータに実行させる画面遷移プログラムであって、前記コンピュータは、複数の画面と前記複数の画面のそれぞれに対応する少なくとも1つのスタック操作とを定義する画面遷移定義ファイルを格納する格納部と、前記遷移定義ファイルを参照しながら前記画面遷移プログラムを実行する処理部と、前記複数の画面に対応する複数の画面IDを管理するために使用されるスタックとを含み、前記画面遷移プログラムは、(a)前記画面遷移定義ファイルにおいて指定された初期画面の画面IDを前記スタックに積むステップと、(b)前記スタックの最上位の位置にある画面IDを取得するステップと、(c)前記ステップ(b)において取得された前記画面IDに対応する画面内の処理を実行するステップと、(d)前記ステップ(c)において前記画面内の処理を実行した結果としてスタック操作を取得し、前記取得されたスタック操作を前記スタックに対して実行するステップと、(e)前記スタックが空状態になるまで、前記ステップ(b)〜(d)を繰り返すステップとを包含し、これにより、上記目的が達成される。
【0007】
前記画面遷移定義ファイルは、階層型ツリーの形式で表現されており、前記ステップ(c)は、前記画面IDをキー項目として含むレコードを生成するステップと、前記キー項目に対応するノードを前記階層型ツリーの中から探索するステップと、前記探索されたノードに対応する画面内の処理を実行するステップとを包含してもよい。
【0008】
前記ステップ(d)は、前記画面IDを第1のキー項目として含み、かつ、前記スタック操作を第2のキー項目として含むレコードを生成するステップと、前記第1のキー項目と前記第2のキー項目とに対応するノードを前記階層型ツリーの中から探索するステップと、前記探索されたノードに対応するスタック操作を前記スタックに対して実行するステップとを包含してもよい。
【0009】
前記階層型ツリーは、現在のノードより1つ下位の階層にある1つのノードを指すポインタと現在のノードより1つ上位の階層にある1つのノードを指すポインタと現在のノードと同一の階層にある他の1つのノードを指すポインタとを含むテーブルによって表現されてもよい。
【0010】
前記格納部は、複数の画面内状態遷移定義ファイルをさらに格納し、前記複数の画面内状態遷移定義ファイルのそれぞれは、前記複数の画面のうち対応する1つの画面内で遷移可能な複数の状態を定義し、前記処理部は、前記複数の画面内状態遷移定義ファイルのうち選択された1つの画面内状態遷移定義ファイルを参照しながら、前記ステップ(c)の前記画面内の処理として画面内状態遷移プログラムをさらに実行し、前記画面内状態遷移プログラムは、(f)前記複数の画面内状態遷移定義ファイルのうち、前記ステップ(b)において取得された前記画面IDに対応する1つの画面内状態遷移定義ファイルを選択し、前記選択された画面内状態遷移定義ファイルに指定された初期状態を示す状態IDを現在の状態を示す現状態IDとして設定するステップと、(g)現状態IDを取得するステップと、(h)前記ステップ(b)において取得された前記画面IDと前記ステップ(g)において取得された前記現状態IDとに少なくとも応答して、前記画面IDに対応する1つの画面内で現在の状態を遷移させる処理を実行するステップと、(i)前記ステップ(h)において前記処理を実行した結果として、前記現在の状態から遷移すべき次の状態を示す次状態IDを少なくとも取得するステップと、(j)前記ステップ(h)において前記処理を実行した結果としてスタック操作が取得されたか否かを判定し、前記スタック操作が取得された場合には、前記画面遷移プログラムに復帰し、前記スタック操作が取得されなかった場合には、前記次状態IDを前記現状態IDとして設定した後に、前記ステップ(g)〜(i)を繰り返すステップとを包含してもよい。
【0011】
前記選択された画面内状態遷移定義ファイルは、階層型ツリーの形式で表現されており、前記ステップ(h)は、前記画面IDを第1のキー項目として含み、かつ、前記現状態IDを第2のキー項目として含むレコードを生成するステップと、前記第1のキー項目と前記第2のキー項目とに対応するノードを前記階層型ツリーの中から探索するステップと、前記探索されたノードに対応する処理を実行するステップとを包含してもよい。
【0012】
前記階層型ツリーは、現在のノードより1つ下位の階層にある1つのノードを指すポインタと現在のノードより1つ上位の階層にある1つのノードを指すポインタと現在のノードと同一の階層にある他の1つのノードを指すポインタとを含むテーブルによって表現されてもよい。
【0013】
本発明のインタプリタ装置は、複数の画面と前記複数の画面のそれぞれに対応する少なくとも1つのスタック操作とを定義する画面遷移定義ファイルを格納する格納部と、前記遷移定義ファイルを参照しながら画面遷移プログラムを実行する処理部と、前記複数の画面に対応する複数の画面IDを管理するために使用されるスタックとを備えたインタプリタ装置であって、前記画面遷移プログラムは、(a)前記画面遷移定義ファイルにおいて指定された初期画面の画面IDを前記スタックに積むステップと、(b)前記スタックの最上位の位置にある画面IDを取得するステップと、(c)前記ステップ(b)において取得された前記画面IDに対応する画面内の処理を実行するステップと、(d)前記ステップ(c)において前記画面内の処理を実行した結果としてスタック操作を取得し、前記取得されたスタック操作を前記スタックに対して実行するステップと、(e)前記スタックが空状態になるまで、前記ステップ(b)〜(d)を繰り返すステップとを包含し、これにより、上記目的が達成される。
【0014】
前記格納部は、複数の画面内状態遷移定義ファイルをさらに格納し、前記複数の画面内状態遷移定義ファイルのそれぞれは、前記複数の画面のうち対応する1つの画面内で遷移可能な複数の状態を定義し、前記処理部は、前記複数の画面内状態遷移定義ファイルのうち選択された1つの画面内状態遷移定義ファイルを参照しながら、前記ステップ(c)の前記画面内の処理として画面内状態遷移プログラムをさらに実行し、前記画面内状態遷移プログラムは、(f)前記複数の画面内状態遷移定義ファイルのうち、前記ステップ(b)において取得された前記画面IDに対応する1つの画面内状態遷移定義ファイルを選択し、前記選択された画面内状態遷移定義ファイルに指定された初期状態を示す状態IDを現在の状態を示す現状態IDとして設定するステップと、(g)現状態IDを取得するステップと、(h)前記ステップ(b)において取得された前記画面IDと前記ステップ(g)において取得された前記現状態IDとに少なくとも応答して、前記画面IDに対応する1つの画面内で現在の状態を遷移させる処理を実行するステップと、(i)前記ステップ(h)において前記処理を実行した結果として、前記現在の状態から遷移すべき次の状態を示す次状態IDを少なくとも取得するステップと、(j)前記ステップ(h)において前記処理を実行した結果としてスタック操作が取得されたか否かを判定し、前記スタック操作が取得された場合には、前記画面遷移プログラムに復帰し、前記スタック操作が取得されなかった場合には、前記次状態IDを前記現状態IDとして設定した後に、前記ステップ(g)〜(i)を繰り返すステップとを包含してもよい。
【0015】
【発明の実施の形態】
以下、図面を参照しながら本発明の実施の形態を説明する。
1.コンピュータシステムの構成
図1は、本発明の実施の形態のコンピュータシステム1の構成の一例を示す。
【0016】
コンピュータシステム1は、クライアントコンピュータ10と、サーバコンピュータ20とを含む。クライアントコンピュータ10とサーバコンピュータ20とは、ネットワーク30を介して接続されている。
【0017】
ネットワーク30は、任意のタイプのネットワークであり得る。ネットワーク30は、例えば、インターネットであり得る。
【0018】
クライアントコンピュータ10は、CPU11と、メモリ12と、入力部13と、表示部14と、ネットワークインタフェース部15とを含む。これらの構成要素11〜15は、例えば、内部バス16を介して相互に接続されている。
【0019】
メモリ12には、入力部13からの入力を受け付ける入力プログラムや、処理結果を表示部14に表示する表示プログラムが格納されている。
【0020】
CPU11は、メモリ12に格納されている入力プログラムや表示プログラムを実行する。入力プログラムを実行することにより、入力部13から入力されたデータをネットワークインタフェース部15、ネットワーク30を介してサーバコンピュータ20に送信することが可能になる。また、表示プログラムを実行することにより、サーバコンピュータ20から送信されてくる処理結果に基づいて表示部14に表示されている画面を他の画面に遷移させたり、表示部14に表示されている画面の一部を変更したりすることが可能になる。
【0021】
入力部13は、ユーザからの入力をクラアントコンピュータ10に入力することが可能なように構成されている。入力部13は、例えば、キーボードやマウスである。
【0022】
表示部14は、クライアントコンピュータ10および/またはサーバコンピュータ20による処理結果をユーザに提示することが可能なように構成されている。表示部14は、例えば、CRTディスプレイやLCDディスプレイである。
【0023】
ネットワークインタフェース部15は、ネットワーク30を介してサーバコンピュータ20と通信するために必要なデータフォーマットの変換やプロトコルの変換などの処理を行う。
【0024】
サーバコンピュータ20は、CPU(処理部)21と、メモリ(格納部)22と、ネットワークインタフェース部23とを含む。これらの構成要素21〜23は、例えば、内部バス24を介して相互に接続されている。
【0025】
メモリ22には、画面遷移処理を実現するプログラム(以下、画面遷移プログラムという)と、複数の画面とその複数の画面のそれぞれに対応する少なくとも1つのスタック操作とを定義する画面遷移定義ファイルとが格納されている。
【0026】
画面遷移プログラムと画面遷移定義ファイルとは、サーバコンピュータ20の出荷前にメモリ22に格納されてもよいし、サーバコンピュータ20の出荷後にメモリ22に格納されてもよい。例えば、画面遷移プログラムと画面遷移定義ファイルとが記録媒体に記録されている場合には、その画面遷移プログラムと画面遷移定義ファイルとは、入力装置(例えば、ディスクドライブ)を介してメモリ22にロードされ得る。なお、画面遷移プログラムと画面遷移定義ファイルとは同一の記録媒体に記録されていてもよいし、別々の記録媒体に記録されていてもよい。記録媒体は、フレキシブルディスク、CD−ROM、DVD−ROMなどの任意のタイプのコンピュータ読み取り可能な記録媒体であり得る。
【0027】
なお、画面遷移プログラムと画面遷移定義ファイルとがウェブサイト上で管理されている場合には、電子配信技術を利用して、画面遷移プログラムまたは画面遷移定義ファイルをメモリ22にロードするようにしてもよい。
【0028】
CPU21は、メモリ22に格納されている画面遷移定義ファイルを参照しながら、メモリ22に格納されている画面遷移プログラムを実行する。画面遷移プログラムを実行することにより、クライアントコンピュータ10から送信されてくるデータに基づいて画面遷移処理を行い、その画面遷移処理の結果をクライアントコンピュータ10に送信することが可能になる。
【0029】
CPU21が画面遷移定義ファイルを参照しながら画面遷移プログラムを実行することによって、サーバコンピュータ20は、画面遷移定義ファイルを解釈実行するインタプリタ装置として機能する。
【0030】
ネットワークインタフェース部23は、ネットワーク30を介してクライアントコンピュータ10と通信するために必要なデータフォーマットの変換やプロトコルの変換などの処理を行う。
【0031】
このようにして、クライアントコンピュータ10とサーバコンピュータ20とが協働することにより、クライアント−サーバ型のアプリケーションプログラムが実行される。
2.画面遷移を伴うアプリケーションシステムの開発手順
以下、画面遷移を伴うアプリケーションシステムの例として、請求書入力/入金伝票入力システムを例にとり、請求書入力/入金伝票入力システムの開発手順を説明する。その開発手順は以下のとおりである。
(1)画面遷移の設計
(2)画面遷移定義ファイルの作成
(3)画面遷移定義ファイルのインストール
(4)画面遷移プログラムの実行
なお、請求書入力/入金伝票入力システムの構成は、図1に示されるコンピュータシステム1の構成と同一であるとする。
2.1 画面遷移の設計
図2は、請求書入力/入金伝票入力システムにおける画面遷移の一例を示す。
【0032】
図2に示される例では、MENU画面(nenu)210、請求書番号入力画面(seikyuNo)220、請求書入力画面(seikyuMain)230、入金伝票番号入力画面(nyukinNo)240、入金伝票入力画面(nyukinMain)250、請求書一覧画面(seikyuList)260という6個の画面が定義されている。
【0033】
MENU画面210には、例えば、「請求書」ボタンと「入金伝票」ボタンと「終了」ボタンとが設けられている。「請求書」ボタンを押下することにより、MENU画面210は請求書番号入力画面220に遷移する。「入金伝票」ボタンを押下することにより、MENU画面210は入金伝票番号入力画面240に遷移する。「終了」ボタンを押下することにより、ログアウトする。
【0034】
請求書番号入力画面220には、例えば、請求書番号を入力するための請求書番号入力領域と「実行」ボタンと「一覧」ボタンと「戻る」ボタンとが設けられている。請求書番号入力領域に請求書番号を入力した後に「実行」ボタンを押下することにより、請求書番号入力画面220は請求書入力画面230に遷移する。「一覧」ボタンを押下することにより、請求書番号入力画面220は請求書一覧画面260に遷移する。「戻る」ボタンを押下することにより、請求書番号入力画面220はMENU画面210に遷移する。
【0035】
請求書入力画面230には、例えば、請求書の明細(例えば、得意先名称、請求金額、請求日、入金予定日、商品名、単価、数量、金額など)を入力するための請求書明細入力領域と「実行」ボタンと「戻る」ボタンとが設けられている。請求書明細入力領域に請求書の明細を入力した後に「実行」ボタンを押下することにより、請求書の明細がシステムに入力される。「戻る」ボタンを押下することにより、請求書入力画面230は、請求書番号入力画面220または請求書一覧画面260の一方(遷移元の画面)に遷移する。
【0036】
請求書一覧画面260には、例えば、請求書の一覧を表示するための領域と「請求書」ボタンと「入金伝票」ボタンと「戻る」ボタンとが設けられている。「請求書」ボタンを押下することにより、請求書一覧画面260は請求書入力画面230に遷移する。「入金伝票」ボタンを押下することにより、請求書一覧画面260は入金伝票入力画面250に遷移する。「戻る」ボタンを押下することにより、請求書一覧画面260は請求書番号入力画面220に遷移する。
【0037】
入金伝票番号入力画面240には、例えば、入金伝票番号を入力するための入金伝票番号入力領域と「実行」ボタンと「戻る」ボタンとが設けられている。入金伝票番号入力領域に入金伝票番号を入力した後に「実行」ボタンを押下することにより、入金伝票番号入力画面240は入金伝票入力画面250に遷移する。「戻る」ボタンを押下することにより、入金伝票番号入力画面240はMENU画面210に遷移する。
【0038】
入金伝票入力画面250には、例えば、入金伝票の明細(例えば、請求書番号、入金額、入金日、入金種別、手形期日など)を入力するための入金伝票明細入力領域と「実行」ボタンと「戻る」ボタンとが設けられている。入金伝票明細入力領域に入金伝票の明細を入力した後に「実行」ボタンを押下することにより、入金伝票の明細がシステムに入力される。「戻る」ボタンを押下することにより、入金伝票入力画面250は入金伝票番号入力画面240に遷移する。
【0039】
ある画面から他の画面への遷移は、スタック操作に対応づけて定義される。例えば、MENU画面210から請求書番号入力画面220への遷移は、”push seikyuNo”というスタック操作に対応づけられており、請求書番号入力画面220からMENU画面210への遷移は、”pop”というスタック操作に対応づけられており、MENU画面210からMENU画面210への遷移は、”peek”というスタック操作に対応づけられている。
【0040】
このように、ある画面から他の画面への遷移とスタック操作とを対応づけることにおり、どの画面からどの画面に遷移可能であるかを定義することが可能になる。
【0041】
ここで、スタック操作とは、スタックに対する操作をいう。
【0042】
図3は、スタックを模式的に示したものである。スタックは、N個の配列要素3101〜310Nを有する1次元の配列310と、次にアクセスすべき配列要素310iの位置を示すインデクス変数320とを用いて表現される。ここで、i=1、2、...、Nである。配列要素310iの値とインデクス変数320の値とは、スタック操作に応じて更新される。インデクス変数320の値をindexとすると、index=1のときスタックは初期状態(空き状態)である。
【0043】
スタック操作の例としては、例えば、”push X”、”pop”、”popAll”、”peek”が挙げられる。
【0044】
”push X”とは、indexによって指されている位置にある配列要素にXを代入し、indexを1つだけ増加させること(すなわち、スタックにXを積むこと)をいう。ここで、Xは任意のシンボルである。”pop”とは、indexを1つだけ減少させることをいう。”popAll”とは、indexを1にリセットすること(すなわち、スタックを空き状態にすること)をいう。”peek”とは、(index−1)によって指されている位置にある配列要素の値を参照すること(すなわち、スタックの最上位の位置にある配列要素の値を参照すること)をいう。
【0045】
上述したスタックは、例えば、プログラムによって実現され得る。例えば、オブジェクト指向のプログラミング技術では、スタックとそれに対するスタック操作とが1つのオブジェクトとして提供され得ることがよく知られている。
【0046】
図2に示されるような画面遷移は、例えば、公知のペトリネットを用いて好適に設計され得る。
【0047】
図4は、図2に示される画面遷移をペトリネットで表現したものである。図4の記法によっても、ある画面から他の画面への遷移がスタック操作に対応づけられていることが分かる。
2.2 画面遷移定義ファイルの作成
画面遷移定義ファイルは、複数の画面と、その複数の画面のそれぞれに対応する少なくとも1つのスタック操作とを定義する。
【0048】
図5Aは、図2に示される画面遷移を実現するように作成された画面遷移定義ファイルの一例を示す。
【0049】
図5Aに示される例では、画面遷移定義ファイルは、”root”ノード511を最上位のノードとする階層型ツリーの形式で表現されている。
【0050】
請求書入力/入金伝票入力システムにおける6個の画面は、それぞれ、”root”ノード511より1つ下位の階層にある6個のノード521〜526(すなわち、”nenu”ノード521、”seikyuNo”ノード522、”seikyuMain”ノード523、”nyukinNo”ノード524、”nyukinMain”ノード525、”seikyuList”ノード526)として表現されている。
【0051】
各画面に対応するスタック操作は、各画面に対応するノードより1つ下位の階層にあるノードとして表現されている。例えば、MENU画面210(図2)に対応する4つのスタック操作は、MENU画面210に対応する”menu”ノード521より1つ下位の階層にある4個のノード531〜534(すなわち、”peek”ノード531、”pop”ノード532、push seikyuNo”ノード533、”push nyukinNo”ノード534)として表現されている。
【0052】
なお、階層型ツリーとしては、複数の階層を有する任意のタイプのツリーを使用することができる。階層型ツリーは、例えば、バイナリー・サーチ・ツリーであり得る。
【0053】
図5Bは、図5Aに示される階層型ツリーをテーブル形式で表現した例を示す。
【0054】
図5Bに示される例では、階層型ツリーは、欄541〜欄545を有するテーブルによって表現されている。
【0055】
欄541は、ノードのアドレスを示す。
【0056】
欄542は、ノードの名称を示す。
【0057】
欄543は、ノードの階層(レベル)を示す。
【0058】
欄544は、子供ノード(すなわち、現在のノードより1つ下位の階層にある1つのノード)を指すポインタを示す。
【0059】
欄545は、親ノード(すなわち、現在のノードより1つ上位の階層にある1つのノード)を指すポインタを示す。
【0060】
欄546は、弟/妹ノード(すなわち、現在のノードと同一の階層にある他の1つのノード)を指すポインタを示す。
【0061】
ノード間のリンク(L Link、C link、R Link)は、欄544〜546に記載されるポインタによって実現される。
【0062】
図5Cは、画面遷移定義ファイルをXML言語の形式で表現した例を示す。図5Aに示される画面遷移定義ファイルと図5Cに示される画面遷移定義ファイルとは等価である。階層型ツリーのデータとXML言語とは、例えば、カスケードデータを仲介して、双方向に変換可能である。このような変換技術は周知であるのでここでは詳しい説明を省略する。
【0063】
なお、図5Aに示される画面遷移定義ファイルまたは図5Cに示される画面遷移定義ファイルを図4に示されるペトリネット形式の画面遷移から自動的に作成するようにしてもよい。
2.3 画面遷移定義ファイルのインストール
上記2.2で作成された画面遷移定義ファイルは、サーバコンピュータ20にインストールされる。画面遷移定義ファイルをサーバコンピュータ20にインストールする方法としては任意の方法を使用することができる。例えば、画面遷移定義ファイルがディスクに記録されている場合には、上述したように、ディスクドライブがディスクに記録されている画面遷移定義ファイルを読み出し、読み出された画面遷移定義ファイルをメモリ22に格納することにより、画面遷移定義ファイルのインストールを完了することができる。
2.4 画面遷移プログラムの実行
CPU21は、上記2.3でメモリ22にインストールされた画面遷移定義ファイルを参照しながら画面遷移プログラムを実行する。これにより、請求書入力/入金伝票入力システムにおける画面遷移が上記2.1で設計したとおりに実現される。
【0064】
例えば、請求書入力/入金伝票入力システムにおける画面遷移の仕様を変更する場合には、画面遷移定義ファイルを変更すれば足り、画面遷移プログラムを変更する必要はない。また、請求書入力/入金伝票入力システム以外の画面遷移を伴うアプリケーションシステムを設計、構築する場合でも、そのアプリケーションシステムにおける画面遷移の仕様に適合するように画面遷移定義ファイルを作成すれば足り、画面遷移プログラムを変更する必要はない。
【0065】
このように、画面遷移プログラムは、画面遷移を伴うすべてのアプリケーションシステムに共通に使用され得る。この意味で、この画面遷移プログラムは、サーバコンピュータ20を画面遷移定義ファイルを解釈実行するインタプリタ装置として動作させるためのコアプログラムということができる。
【0066】
画面遷移プログラムを画面遷移を伴うすべてのアプリケーションシステムに共通に使用することにより、画面遷移の仕様に適合するように画面遷移定義ファイルを作成しさえすれば、”プログラムレス”で(すなわち、新規に画面遷移プログラムを作成することなく)画面遷移を伴うアプリケーションシステムを開発することが可能になる。すなわち、画面遷移を伴うアプリケーションシステムを開発するたびに新たに画面遷移プログラムを開発する必要がない。その結果、画面遷移を伴う新たなアプリケーションシステムの開発期間を画期的に短縮することが可能になる。さらに、”プログラムレス”であるからバグをつくりこむ危険性がない。その結果、画面遷移を伴う新たなアプリケーションシステムの品質を画期的に向上させることが可能になる。
3.画面遷移プログラムの手順
図6は、画面遷移プログラムの手順を示す。画面遷移プログラムは、サーバコンピュータ20のCPU21によって実行される。以下、画面遷移プログラムの各ステップを詳細に説明する。
【0067】
ステップS1:画面遷移定義ファイルにおいて指定された初期画面の画面IDがスタックに積まれる。ここで、画面IDとは、画面を識別するための識別子をいう。
【0068】
ステップS2:スタックの最上位の位置にある画面IDが取得される。
【0069】
ステップS3:ステップS2において取得された画面IDに対応する画面内の処理が実行される。ここで、画面内の処理とは、1つの画面のみに関連する任意の処理をいう。
【0070】
ステップS4:ステップS3において画面内の処理を実行した結果としてスタック操作が取得される。さらに、取得されたスタック操作がスタックに対して実行される。
【0071】
ステップS5:スタックが空き状態か否かが判定される。「Yes」であれば処理は終了する。「No」であれば処理はステップS2に戻る。このように、スタックが空き状態になるまで、ステップS2〜S4が繰り返される。
【0072】
ステップS3における画面IDに対応する画面内の処理は、例えば、画面遷移プログラムからサブルーチンをコールすることによって実行される。このようなサブルーチンは、複数の画面IDに対して共通に設計されてもよいし、画面IDごとに別々に設計されてもよい。複数の画面IDに対して共通に設計されたサブルーチンを使用する場合には、例えば、そのサブルーチンをコールする時に画面IDを引数としてそのサブルーチンに渡してやればよい。ステップS4におけるスタック操作は、例えば、サブルーチンの戻り値として取得される。
【0073】
なお、画面遷移定義ファイルが図5Aに示されるように階層型ツリーの形式で表現されている場合には、ステップS2において取得された画面IDをキー項目として含むレコードを生成し、そのレコードのキー項目に対応するノードを階層型ツリーの中から探索し、その探索されたノードに対応する画面内の処理を行うことによってステップS3の処理を行うようにしてもよい。
【0074】
例えば、画面IDが”menu”である場合には、第1の項目(キー項目)が”menu”であり、第2の項目が*であるレコードが生成される。ここで、記号*は値が未定であることを示す。
【0075】
レコード:(”menu”,*)
レコードのキー項目”menu”に対応するノードが階層型ツリーの中から探索される。このような探索は、レコードのキー項目”menu”と”root”ノード511より1つ下位の階層のノードとを比較することにより行われる。その探索結果として”menu”ノード521が特定される。その結果、”menu”ノードに対応する画面(MENU画面210)内の処理が実行される。
【0076】
また、画面遷移定義ファイルが図5Aに示されるように階層型ツリーの形式で表現されている場合には、ステップS2において取得された画面IDを第1のキー項目として含み、かつ、ステップS4において取得されたスタック操作を第2のキー項目として含むレコードを生成し、そのレコードの第1のキー項目と第2のキー項目とに対応するノードを階層型ツリーの中から探索し、その探索されたノードに対応するスタック操作をスタックに対して実行することにより、ステップS4の処理を行うようにしてもよい。
【0077】
例えば、画面IDが”menu”であり、スタック操作が”push seikyuNo”である場合には、第1の項目(キー項目)が”menu”であり、第2の項目(キー項目)が”push seikyuNo”であるレコードが生成される。
【0078】
レコード:(”menu”,”push seikyuNo”)
レコードの第1のキー項目”menu”と第2のキー項目”push seikyuNo”に対応するノードが階層型ツリーの中から探索される。このような探索は、レコードの第1のキー項目である”menu”と”root”ノード511より1つ下位の階層のノードとを比較し、レコードの第2のキー項目である”push seikyuNo”と”menu”ノード521より1つ下位の階層のノードとを比較することにより行われる。その探索結果として”push seikyuNo”ノード533が特定される。その結果、”push seikyuNo”ノード533に対応するスタック操作”push seikyuNo”がスタックに対して実行される。
【0079】
以下、図7A〜図7Gを参照して、画面遷移とスタックの状態の遷移との関係を説明する。
【0080】
図7Aは、ログイン前のスタックの状態(初期状態)を示す。このとき、index=1である。
【0081】
図7Bは、ログイン直後のスタックの状態を示す。画面遷移定義ファイルには、ログイン直後に遷移する画面(初期画面)が指定されている。例えば、図5Aに示される画面遷移定義ファイルでは、MENU画面210が初期画面として指定されていると仮定する。この場合、ステップS1においてMENU画面210に対応する画面ID(例えば、”menu”)がスタックに積まれ、ステップS2においてMENU画面210に対応する画面IDが取得される。その結果、ステップS3においてMENU画面210内の処理が実行される。
【0082】
MENU画面210内の処理として「請求書」ボタンの押下というイベントが発生し、その処理の結果として”push seikyuNo”というスタック操作が取得されたと仮定する。この場合、”push seikyuNo”というスタック操作がスタックに対して実行される(ステップS4)。その結果、請求書番号入力画面220に対応する画面ID(例えば、”seikyuNo”)がスタックに積まれる。
【0083】
図7Cは、”push seikyuNo”というスタック操作がスタックに対して実行された直後のスタックの状態を示す。
【0084】
ステップS5においてスタックが空き状態であるか否かが判定される。判定結果は「No」であるので処理はステップS2に戻り、ステップS2において請求書番号入力画面220に対応する画面IDが取得される。その結果、ステップS3において請求書番号入力画面220内の処理が実行される。
【0085】
請求書番号入力画面220内の処理として「実行」ボタンの押下というイベントが発生し、その処理の結果として”push seikyuMain”というスタック操作が取得されたと仮定する。この場合、”push seikyuMain”というスタック操作がスタックに対して実行される(ステップS4)。その結果、請求書入力画面230に対応する画面ID(例えば、”seikyuMain”)がスタックに積まれる。
【0086】
図7Dは、”push seikyuMain”というスタック操作がスタックに対して実行された直後のスタックの状態を示す。
【0087】
ステップS5においてスタックが空き状態であるか否かが判定される。判定結果は「No」であるので処理はステップS2に戻り、ステップS2において請求書入力画面230に対応する画面IDが取得される。その結果、ステップS3において請求書入力画面230内の処理が実行される。
【0088】
請求書入力画面230内の処理として「戻る」ボタンの押下というイベントが発生し、その処理の結果として”pop”というスタック操作が取得されたと仮定する。この場合、”pop”というスタック操作がスタックに対して実行される(ステップS4)。その結果、indexが1だけ減少する。
【0089】
図7Eは、”pop”というスタック操作がスタックに対して実行された直後のスタックの状態を示す。
【0090】
ステップS5においてスタックが空き状態であるか否かが判定される。判定結果は「No」であるので処理はステップS2に戻り、ステップS2において請求書番号入力画面220に対応する画面IDが取得される。その結果、ステップS3において請求書番号入力画面220内の処理が実行される。
【0091】
請求書番号入力画面220内の処理として「戻る」ボタンの押下というイベントが発生し、その処理の結果として”pop”というスタック操作が取得されたと仮定する。この場合、”pop”というスタック操作がスタックに対して実行される(ステップS4)。その結果、indexが1だけ減少する。
【0092】
図7Fは、”pop”というスタック操作がスタックに対して実行された直後のスタックの状態を示す。
【0093】
ステップS5においてスタックが空き状態であるか否かが判定される。判定結果は「No」であるので処理はステップS2に戻り、ステップS2においてMENU画面210に対応する画面IDが取得される。その結果、ステップS3においてMENU画面210内の処理が実行される。
【0094】
MENU画面210内の処理として「終了」ボタンの押下というイベントが発生し、その処理の結果として”pop”というスタック操作が取得されたと仮定する。この場合、”pop”というスタック操作がスタックに対して実行される(ステップS4)。その結果、indexが1だけ減少する。
【0095】
図7Gは、”pop”というスタック操作がスタックに対して実行された直後のスタックの状態を示す。
【0096】
ステップS5においてスタックが空き状態であるか否かが判定される。判定結果は「Yes」であるので処理は終了する(ログアウトする)。
【0097】
このように、スタックは、複数の画面に対応する複数の画面IDを管理するために使用される。
【0098】
スタックの最上位の位置にある画面IDを取得すること(ステップS2)、その画面IDに対応する画面内の処理を行うこと(ステップS3)、その処理の結果として得られるスタック操作をスタックに対して行うこと(ステップS4)を繰り返すことにより、ある画面から他の画面への遷移を制御することが可能になる。
4.画面内状態遷移プログラムの手順
以下、図6のステップS3において実行される画面内の処理の一例として、画面内状態遷移処理を説明する。
【0099】
図8は、画面内状態遷移処理を実現するプログラム(以下、画面内状態遷移プログラムという)の手順を示す。画面内状態遷移プログラムは、サーバコンピュータ20のメモリ22に格納されており、CPU21によって実行される。以下、画面内状態遷移プログラムの各ステップを詳細に説明する。
【0100】
ステップS31:複数の画面内状態遷移定義ファイルのうち、ステップS2において取得された画面IDに対応する1つの画面内状態遷移定義ファイルが選択され、選択された画面内状態遷移定義ファイルに指定された初期状態を示す状態IDが現在の状態を示す現状態IDとして設定される。
【0101】
ステップS32:現状態IDが取得される。ここで、現状態IDの値は次に更新されるまで保持されているものとする。
【0102】
ステップS33:ステップS2において取得された画面IDとステップS32において取得された現状態IDとに少なくとも応答して、画面IDに対応する1つの画面内で現在の状態を遷移させる処理が実行される。
【0103】
ステップS34:ステップS33において処理を実行した結果として、現在の状態から遷移すべき次の状態を示す次状態IDが少なくとも取得される。
【0104】
ステップS35:ステップS33において処理を実行した結果として、スタック操作が取得されたか否かが判定される。「Yes」の場合には、処理は終了する(画面遷移プログラムに復帰する)。「No」の場合には、次状態IDを現状態IDとして設定した後に(ステップS36)、処理はステップS32に戻る。その結果、ステップS32〜S34が繰り返される。
【0105】
図9は、画面内状態遷移の仕様の一例として、MENU画面210内の状態遷移の仕様を示す。図9に示される例では、MENU画面210内の状態遷移は、「現状態」、「発生イベント」、「処理」、「結果(トークン値)」、「次状態」、「スタック操作」によって定義されている。
【0106】
例えば、図9に示されるテーブルの第2行は、現状態=”state02”においてイベント=”event01”が発生した場合には、”method02”の処理を行い、現状態を次状態=”state03”に遷移させ、スタック操作”push seikyuNo”を画面遷移プログラムに返すことを示している。
【0107】
画面内状態遷移定義ファイルは、1つの画面内における状態の遷移を定義する。
【0108】
図10Aは、図9に示されるMENU画面210内の状態遷移を実現するように作成された画面内状態遷移定義ファイルの一例を示す。
【0109】
図10Aに示される例では、画面内状態遷移定義ファイルは、”menu”ノード1011を最上位のノードとする階層型ツリーの形式で表現されている。
【0110】
MENU画面210における4つの状態は、それぞれ、”menu”ノード1011より1つ下位の階層にある4個のノード(すなわち、”state01”ノード1021、”state02”ノード1022、”state03”ノード1023、”state04”ノード1024)として表現されている。
【0111】
MENU画面210における3つの発生イベントは、それぞれ、”state02”ノード1022より1つ下位の階層にある3個のノード(すなわち、”event01”ノード1031、”event02”ノード1032、”event03”ノード1033)として表現されている。
【0112】
なお、画面内状態遷移定義ファイルが図10Aに示されるように階層型ツリーの形式で表現されている場合には、ステップS2において取得された画面IDを第1のキー項目として含み、かつ、ステップS32において取得された現状態IDを第2のキー項目として含むレコードを生成し、そのレコードの第1のキー項目と第2のキー項目とに対応するノードを階層型ツリーの中から探索し、その探索されたノードに対応する処理を行うことによってステップS33の処理を行うようにしてもよい。
【0113】
例えば、画面IDが”menu”であり、現状態IDが”state01”ある場合には、第1の項目(キー項目)が”menu”であり、第2の項目(キー項目)であり、第3の項目が*であるレコードが生成される。ここで、記号*は値が未定であることを示す。
【0114】
レコード:(”menu”,”state01”,*)
レコードの第1のキー項目”menu”と第2のキー項目”state01”に対応するノードが階層型ツリーの中から探索される。このような探索は、レコードの第1のキー項目である”menu”と”menu”ノード1011とを比較し、レコードの第2のキー項目である”state01”と”menu”ノード1011より1つ下位の階層のノードとを比較することにより行われる。その探索結果として”state01”ノード1021が特定される。その結果、”state01”に対応する処理(method01)が実行される。
【0115】
なお、例えば、画面IDが”menu”であり、現状態IDが”state02”ある場合において、イベント=event01が発生した場合には、画面IDが”menu”であり、現状態IDが”state01”ある場合には、第1の項目(キー項目)が”menu”であり、第2の項目(キー項目)が”state02”であり、第3の項目(キー項目)が”event01”であるレコードを生成し、このレコードを用いて階層型ツリーを探索するようにすればよい。
【0116】
図10Bは、画面内状態遷移定義ファイルをXML言語の形式で表現した例を示す。図10Aに示される画面内状態遷移定義ファイルと図10Bに示される画面内状態遷移定義ファイルとは等価である。階層型ツリーのデータとXML言語とは、例えば、カスケードデータを仲介して、双方向に変換可能である。このような変換技術は周知であるのでここでは詳しい説明を省略する。
【0117】
なお、図10Aに示される画面内状態遷移定義ファイルまたは図10Bに示される画面内状態遷移定義ファイルを図9に示される状態遷移から自動的に作成するようにしてもよい。
【0118】
なお、画面遷移を伴うアプリケーションの開発を例にとり説明したが、本発明の適用はこれに限定されない。本発明は、状態遷移を伴うアプリケーションシステム(例えば、通信を伴うアプリケーションシステム)の開発に広く適用することができる。
【0119】
【発明の効果】
上述したように、本発明の画面遷移プログラムは、画面遷移を伴うすべてのアプリケーションシステムに共通に使用され得る。この意味で、この画面遷移プログラムは、コンピュータを画面遷移定義ファイルを解釈実行するインタプリタ装置として動作させるためのコアプログラムということができる。
【0120】
画面遷移プログラムを画面遷移を伴うすべてのアプリケーションシステムに共通に使用することにより、画面遷移の仕様に適合するように画面遷移定義ファイルを作成しさえすれば、”プログラムレス”で(すなわち、新規に画面遷移プログラムを作成することなく)画面遷移を伴うアプリケーションシステムを開発することが可能になる。すなわち、画面遷移を伴うアプリケーションシステムを開発するたびに新たに画面遷移プログラムを開発する必要がない。その結果、画面遷移を伴う新たなアプリケーションシステムの開発期間を画期的に短縮することが可能になる。さらに、”プログラムレス”であるからバグをつくりこむ危険性がない。その結果、画面遷移を伴う新たなアプリケーションシステムの品質を画期的に向上させることが可能になる。
【図面の簡単な説明】
【図1】本発明の実施の形態のコンピュータシステム1の構成の一例を示す図
【図2】請求書入力/入金伝票入力システムにおける画面遷移の一例を示す図
【図3】スタックを模式的に示す図
【図4】図2に示される画面遷移をペトリネットで表現した図
【図5A】図2に示される画面遷移を実現するように作成された画面遷移定義ファイルの一例を示す図
【図5B】図5Aに示される階層型ツリーをテーブル形式で表現した例を示す図
【図5C】画面遷移定義ファイルをXML言語の形式で表現した例を示す図
【図6】画面遷移プログラムの手順を示すフローチャート
【図7A】画面遷移に関連してスタックの状態の遷移を説明するための図
【図7B】画面遷移に関連してスタックの状態の遷移を説明するための図
【図7C】画面遷移に関連してスタックの状態の遷移を説明するための図
【図7D】画面遷移に関連してスタックの状態の遷移を説明するための図
【図7E】画面遷移に関連してスタックの状態の遷移を説明するための図
【図7F】画面遷移に関連してスタックの状態の遷移を説明するための図
【図7G】画面遷移に関連してスタックの状態の遷移を説明するための図
【図8】画面内状態遷移プログラムの手順を示すフローチャート
【図9】画面内状態遷移の仕様の一例として、MENU画面210内の状態遷移の仕様を示す図
【図10A】図9に示されるMENU画面210内の状態遷移を実現するように作成された画面内状態遷移定義ファイルの一例を示す図
【図10B】画面内状態遷移定義ファイルをXML言語の形式で表現した例を示す図
【符号の説明】
1 コンピュータシステム
10 クライアントコンピュータ
20 サーバコンピュータ
30 ネットワーク
【発明の属する技術分野】
本発明は、画面遷移プログラムおよびインタプリタ装置に関する。
【0002】
【従来の技術】
従来、画面遷移を伴うアプリケーションシステムは、画面遷移の仕様に基づいて個々に開発されてきた。
【0003】
【発明が解決しようとする課題】
従来、アプリケーションシステムを開発するたびに画面遷移プログラムを新たに開発する必要があったため、アプリケーションシステムの開発に多大な労力およびコストがかかっていた。また、画面遷移の仕様は開発過程において変更される可能性が高く、そのことがアプリケーションシステムの納品の遅れ、品質の低下を招く原因となっていた。
【0004】
本発明は、画面遷移を伴うアプリケーションシステムを開発するたびに新たに開発する必要がない画面遷移プログラムおよびそれを実行するためのインタプリタ装置を提供することを目的とする。
【0005】
また、本発明は、画面遷移を伴うアプリケーションシステムの開発期間を画期的に短縮するとともに、画面遷移を伴うアプリケーションシステムの品質を画期的に向上させることが可能な画面遷移プログラムおよびそれを実行するためのインタプリタ装置を提供することを目的とする。
【0006】
【課題を解決するための手段】
本発明の画面遷移プログラムは、画面遷移処理をコンピュータに実行させる画面遷移プログラムであって、前記コンピュータは、複数の画面と前記複数の画面のそれぞれに対応する少なくとも1つのスタック操作とを定義する画面遷移定義ファイルを格納する格納部と、前記遷移定義ファイルを参照しながら前記画面遷移プログラムを実行する処理部と、前記複数の画面に対応する複数の画面IDを管理するために使用されるスタックとを含み、前記画面遷移プログラムは、(a)前記画面遷移定義ファイルにおいて指定された初期画面の画面IDを前記スタックに積むステップと、(b)前記スタックの最上位の位置にある画面IDを取得するステップと、(c)前記ステップ(b)において取得された前記画面IDに対応する画面内の処理を実行するステップと、(d)前記ステップ(c)において前記画面内の処理を実行した結果としてスタック操作を取得し、前記取得されたスタック操作を前記スタックに対して実行するステップと、(e)前記スタックが空状態になるまで、前記ステップ(b)〜(d)を繰り返すステップとを包含し、これにより、上記目的が達成される。
【0007】
前記画面遷移定義ファイルは、階層型ツリーの形式で表現されており、前記ステップ(c)は、前記画面IDをキー項目として含むレコードを生成するステップと、前記キー項目に対応するノードを前記階層型ツリーの中から探索するステップと、前記探索されたノードに対応する画面内の処理を実行するステップとを包含してもよい。
【0008】
前記ステップ(d)は、前記画面IDを第1のキー項目として含み、かつ、前記スタック操作を第2のキー項目として含むレコードを生成するステップと、前記第1のキー項目と前記第2のキー項目とに対応するノードを前記階層型ツリーの中から探索するステップと、前記探索されたノードに対応するスタック操作を前記スタックに対して実行するステップとを包含してもよい。
【0009】
前記階層型ツリーは、現在のノードより1つ下位の階層にある1つのノードを指すポインタと現在のノードより1つ上位の階層にある1つのノードを指すポインタと現在のノードと同一の階層にある他の1つのノードを指すポインタとを含むテーブルによって表現されてもよい。
【0010】
前記格納部は、複数の画面内状態遷移定義ファイルをさらに格納し、前記複数の画面内状態遷移定義ファイルのそれぞれは、前記複数の画面のうち対応する1つの画面内で遷移可能な複数の状態を定義し、前記処理部は、前記複数の画面内状態遷移定義ファイルのうち選択された1つの画面内状態遷移定義ファイルを参照しながら、前記ステップ(c)の前記画面内の処理として画面内状態遷移プログラムをさらに実行し、前記画面内状態遷移プログラムは、(f)前記複数の画面内状態遷移定義ファイルのうち、前記ステップ(b)において取得された前記画面IDに対応する1つの画面内状態遷移定義ファイルを選択し、前記選択された画面内状態遷移定義ファイルに指定された初期状態を示す状態IDを現在の状態を示す現状態IDとして設定するステップと、(g)現状態IDを取得するステップと、(h)前記ステップ(b)において取得された前記画面IDと前記ステップ(g)において取得された前記現状態IDとに少なくとも応答して、前記画面IDに対応する1つの画面内で現在の状態を遷移させる処理を実行するステップと、(i)前記ステップ(h)において前記処理を実行した結果として、前記現在の状態から遷移すべき次の状態を示す次状態IDを少なくとも取得するステップと、(j)前記ステップ(h)において前記処理を実行した結果としてスタック操作が取得されたか否かを判定し、前記スタック操作が取得された場合には、前記画面遷移プログラムに復帰し、前記スタック操作が取得されなかった場合には、前記次状態IDを前記現状態IDとして設定した後に、前記ステップ(g)〜(i)を繰り返すステップとを包含してもよい。
【0011】
前記選択された画面内状態遷移定義ファイルは、階層型ツリーの形式で表現されており、前記ステップ(h)は、前記画面IDを第1のキー項目として含み、かつ、前記現状態IDを第2のキー項目として含むレコードを生成するステップと、前記第1のキー項目と前記第2のキー項目とに対応するノードを前記階層型ツリーの中から探索するステップと、前記探索されたノードに対応する処理を実行するステップとを包含してもよい。
【0012】
前記階層型ツリーは、現在のノードより1つ下位の階層にある1つのノードを指すポインタと現在のノードより1つ上位の階層にある1つのノードを指すポインタと現在のノードと同一の階層にある他の1つのノードを指すポインタとを含むテーブルによって表現されてもよい。
【0013】
本発明のインタプリタ装置は、複数の画面と前記複数の画面のそれぞれに対応する少なくとも1つのスタック操作とを定義する画面遷移定義ファイルを格納する格納部と、前記遷移定義ファイルを参照しながら画面遷移プログラムを実行する処理部と、前記複数の画面に対応する複数の画面IDを管理するために使用されるスタックとを備えたインタプリタ装置であって、前記画面遷移プログラムは、(a)前記画面遷移定義ファイルにおいて指定された初期画面の画面IDを前記スタックに積むステップと、(b)前記スタックの最上位の位置にある画面IDを取得するステップと、(c)前記ステップ(b)において取得された前記画面IDに対応する画面内の処理を実行するステップと、(d)前記ステップ(c)において前記画面内の処理を実行した結果としてスタック操作を取得し、前記取得されたスタック操作を前記スタックに対して実行するステップと、(e)前記スタックが空状態になるまで、前記ステップ(b)〜(d)を繰り返すステップとを包含し、これにより、上記目的が達成される。
【0014】
前記格納部は、複数の画面内状態遷移定義ファイルをさらに格納し、前記複数の画面内状態遷移定義ファイルのそれぞれは、前記複数の画面のうち対応する1つの画面内で遷移可能な複数の状態を定義し、前記処理部は、前記複数の画面内状態遷移定義ファイルのうち選択された1つの画面内状態遷移定義ファイルを参照しながら、前記ステップ(c)の前記画面内の処理として画面内状態遷移プログラムをさらに実行し、前記画面内状態遷移プログラムは、(f)前記複数の画面内状態遷移定義ファイルのうち、前記ステップ(b)において取得された前記画面IDに対応する1つの画面内状態遷移定義ファイルを選択し、前記選択された画面内状態遷移定義ファイルに指定された初期状態を示す状態IDを現在の状態を示す現状態IDとして設定するステップと、(g)現状態IDを取得するステップと、(h)前記ステップ(b)において取得された前記画面IDと前記ステップ(g)において取得された前記現状態IDとに少なくとも応答して、前記画面IDに対応する1つの画面内で現在の状態を遷移させる処理を実行するステップと、(i)前記ステップ(h)において前記処理を実行した結果として、前記現在の状態から遷移すべき次の状態を示す次状態IDを少なくとも取得するステップと、(j)前記ステップ(h)において前記処理を実行した結果としてスタック操作が取得されたか否かを判定し、前記スタック操作が取得された場合には、前記画面遷移プログラムに復帰し、前記スタック操作が取得されなかった場合には、前記次状態IDを前記現状態IDとして設定した後に、前記ステップ(g)〜(i)を繰り返すステップとを包含してもよい。
【0015】
【発明の実施の形態】
以下、図面を参照しながら本発明の実施の形態を説明する。
1.コンピュータシステムの構成
図1は、本発明の実施の形態のコンピュータシステム1の構成の一例を示す。
【0016】
コンピュータシステム1は、クライアントコンピュータ10と、サーバコンピュータ20とを含む。クライアントコンピュータ10とサーバコンピュータ20とは、ネットワーク30を介して接続されている。
【0017】
ネットワーク30は、任意のタイプのネットワークであり得る。ネットワーク30は、例えば、インターネットであり得る。
【0018】
クライアントコンピュータ10は、CPU11と、メモリ12と、入力部13と、表示部14と、ネットワークインタフェース部15とを含む。これらの構成要素11〜15は、例えば、内部バス16を介して相互に接続されている。
【0019】
メモリ12には、入力部13からの入力を受け付ける入力プログラムや、処理結果を表示部14に表示する表示プログラムが格納されている。
【0020】
CPU11は、メモリ12に格納されている入力プログラムや表示プログラムを実行する。入力プログラムを実行することにより、入力部13から入力されたデータをネットワークインタフェース部15、ネットワーク30を介してサーバコンピュータ20に送信することが可能になる。また、表示プログラムを実行することにより、サーバコンピュータ20から送信されてくる処理結果に基づいて表示部14に表示されている画面を他の画面に遷移させたり、表示部14に表示されている画面の一部を変更したりすることが可能になる。
【0021】
入力部13は、ユーザからの入力をクラアントコンピュータ10に入力することが可能なように構成されている。入力部13は、例えば、キーボードやマウスである。
【0022】
表示部14は、クライアントコンピュータ10および/またはサーバコンピュータ20による処理結果をユーザに提示することが可能なように構成されている。表示部14は、例えば、CRTディスプレイやLCDディスプレイである。
【0023】
ネットワークインタフェース部15は、ネットワーク30を介してサーバコンピュータ20と通信するために必要なデータフォーマットの変換やプロトコルの変換などの処理を行う。
【0024】
サーバコンピュータ20は、CPU(処理部)21と、メモリ(格納部)22と、ネットワークインタフェース部23とを含む。これらの構成要素21〜23は、例えば、内部バス24を介して相互に接続されている。
【0025】
メモリ22には、画面遷移処理を実現するプログラム(以下、画面遷移プログラムという)と、複数の画面とその複数の画面のそれぞれに対応する少なくとも1つのスタック操作とを定義する画面遷移定義ファイルとが格納されている。
【0026】
画面遷移プログラムと画面遷移定義ファイルとは、サーバコンピュータ20の出荷前にメモリ22に格納されてもよいし、サーバコンピュータ20の出荷後にメモリ22に格納されてもよい。例えば、画面遷移プログラムと画面遷移定義ファイルとが記録媒体に記録されている場合には、その画面遷移プログラムと画面遷移定義ファイルとは、入力装置(例えば、ディスクドライブ)を介してメモリ22にロードされ得る。なお、画面遷移プログラムと画面遷移定義ファイルとは同一の記録媒体に記録されていてもよいし、別々の記録媒体に記録されていてもよい。記録媒体は、フレキシブルディスク、CD−ROM、DVD−ROMなどの任意のタイプのコンピュータ読み取り可能な記録媒体であり得る。
【0027】
なお、画面遷移プログラムと画面遷移定義ファイルとがウェブサイト上で管理されている場合には、電子配信技術を利用して、画面遷移プログラムまたは画面遷移定義ファイルをメモリ22にロードするようにしてもよい。
【0028】
CPU21は、メモリ22に格納されている画面遷移定義ファイルを参照しながら、メモリ22に格納されている画面遷移プログラムを実行する。画面遷移プログラムを実行することにより、クライアントコンピュータ10から送信されてくるデータに基づいて画面遷移処理を行い、その画面遷移処理の結果をクライアントコンピュータ10に送信することが可能になる。
【0029】
CPU21が画面遷移定義ファイルを参照しながら画面遷移プログラムを実行することによって、サーバコンピュータ20は、画面遷移定義ファイルを解釈実行するインタプリタ装置として機能する。
【0030】
ネットワークインタフェース部23は、ネットワーク30を介してクライアントコンピュータ10と通信するために必要なデータフォーマットの変換やプロトコルの変換などの処理を行う。
【0031】
このようにして、クライアントコンピュータ10とサーバコンピュータ20とが協働することにより、クライアント−サーバ型のアプリケーションプログラムが実行される。
2.画面遷移を伴うアプリケーションシステムの開発手順
以下、画面遷移を伴うアプリケーションシステムの例として、請求書入力/入金伝票入力システムを例にとり、請求書入力/入金伝票入力システムの開発手順を説明する。その開発手順は以下のとおりである。
(1)画面遷移の設計
(2)画面遷移定義ファイルの作成
(3)画面遷移定義ファイルのインストール
(4)画面遷移プログラムの実行
なお、請求書入力/入金伝票入力システムの構成は、図1に示されるコンピュータシステム1の構成と同一であるとする。
2.1 画面遷移の設計
図2は、請求書入力/入金伝票入力システムにおける画面遷移の一例を示す。
【0032】
図2に示される例では、MENU画面(nenu)210、請求書番号入力画面(seikyuNo)220、請求書入力画面(seikyuMain)230、入金伝票番号入力画面(nyukinNo)240、入金伝票入力画面(nyukinMain)250、請求書一覧画面(seikyuList)260という6個の画面が定義されている。
【0033】
MENU画面210には、例えば、「請求書」ボタンと「入金伝票」ボタンと「終了」ボタンとが設けられている。「請求書」ボタンを押下することにより、MENU画面210は請求書番号入力画面220に遷移する。「入金伝票」ボタンを押下することにより、MENU画面210は入金伝票番号入力画面240に遷移する。「終了」ボタンを押下することにより、ログアウトする。
【0034】
請求書番号入力画面220には、例えば、請求書番号を入力するための請求書番号入力領域と「実行」ボタンと「一覧」ボタンと「戻る」ボタンとが設けられている。請求書番号入力領域に請求書番号を入力した後に「実行」ボタンを押下することにより、請求書番号入力画面220は請求書入力画面230に遷移する。「一覧」ボタンを押下することにより、請求書番号入力画面220は請求書一覧画面260に遷移する。「戻る」ボタンを押下することにより、請求書番号入力画面220はMENU画面210に遷移する。
【0035】
請求書入力画面230には、例えば、請求書の明細(例えば、得意先名称、請求金額、請求日、入金予定日、商品名、単価、数量、金額など)を入力するための請求書明細入力領域と「実行」ボタンと「戻る」ボタンとが設けられている。請求書明細入力領域に請求書の明細を入力した後に「実行」ボタンを押下することにより、請求書の明細がシステムに入力される。「戻る」ボタンを押下することにより、請求書入力画面230は、請求書番号入力画面220または請求書一覧画面260の一方(遷移元の画面)に遷移する。
【0036】
請求書一覧画面260には、例えば、請求書の一覧を表示するための領域と「請求書」ボタンと「入金伝票」ボタンと「戻る」ボタンとが設けられている。「請求書」ボタンを押下することにより、請求書一覧画面260は請求書入力画面230に遷移する。「入金伝票」ボタンを押下することにより、請求書一覧画面260は入金伝票入力画面250に遷移する。「戻る」ボタンを押下することにより、請求書一覧画面260は請求書番号入力画面220に遷移する。
【0037】
入金伝票番号入力画面240には、例えば、入金伝票番号を入力するための入金伝票番号入力領域と「実行」ボタンと「戻る」ボタンとが設けられている。入金伝票番号入力領域に入金伝票番号を入力した後に「実行」ボタンを押下することにより、入金伝票番号入力画面240は入金伝票入力画面250に遷移する。「戻る」ボタンを押下することにより、入金伝票番号入力画面240はMENU画面210に遷移する。
【0038】
入金伝票入力画面250には、例えば、入金伝票の明細(例えば、請求書番号、入金額、入金日、入金種別、手形期日など)を入力するための入金伝票明細入力領域と「実行」ボタンと「戻る」ボタンとが設けられている。入金伝票明細入力領域に入金伝票の明細を入力した後に「実行」ボタンを押下することにより、入金伝票の明細がシステムに入力される。「戻る」ボタンを押下することにより、入金伝票入力画面250は入金伝票番号入力画面240に遷移する。
【0039】
ある画面から他の画面への遷移は、スタック操作に対応づけて定義される。例えば、MENU画面210から請求書番号入力画面220への遷移は、”push seikyuNo”というスタック操作に対応づけられており、請求書番号入力画面220からMENU画面210への遷移は、”pop”というスタック操作に対応づけられており、MENU画面210からMENU画面210への遷移は、”peek”というスタック操作に対応づけられている。
【0040】
このように、ある画面から他の画面への遷移とスタック操作とを対応づけることにおり、どの画面からどの画面に遷移可能であるかを定義することが可能になる。
【0041】
ここで、スタック操作とは、スタックに対する操作をいう。
【0042】
図3は、スタックを模式的に示したものである。スタックは、N個の配列要素3101〜310Nを有する1次元の配列310と、次にアクセスすべき配列要素310iの位置を示すインデクス変数320とを用いて表現される。ここで、i=1、2、...、Nである。配列要素310iの値とインデクス変数320の値とは、スタック操作に応じて更新される。インデクス変数320の値をindexとすると、index=1のときスタックは初期状態(空き状態)である。
【0043】
スタック操作の例としては、例えば、”push X”、”pop”、”popAll”、”peek”が挙げられる。
【0044】
”push X”とは、indexによって指されている位置にある配列要素にXを代入し、indexを1つだけ増加させること(すなわち、スタックにXを積むこと)をいう。ここで、Xは任意のシンボルである。”pop”とは、indexを1つだけ減少させることをいう。”popAll”とは、indexを1にリセットすること(すなわち、スタックを空き状態にすること)をいう。”peek”とは、(index−1)によって指されている位置にある配列要素の値を参照すること(すなわち、スタックの最上位の位置にある配列要素の値を参照すること)をいう。
【0045】
上述したスタックは、例えば、プログラムによって実現され得る。例えば、オブジェクト指向のプログラミング技術では、スタックとそれに対するスタック操作とが1つのオブジェクトとして提供され得ることがよく知られている。
【0046】
図2に示されるような画面遷移は、例えば、公知のペトリネットを用いて好適に設計され得る。
【0047】
図4は、図2に示される画面遷移をペトリネットで表現したものである。図4の記法によっても、ある画面から他の画面への遷移がスタック操作に対応づけられていることが分かる。
2.2 画面遷移定義ファイルの作成
画面遷移定義ファイルは、複数の画面と、その複数の画面のそれぞれに対応する少なくとも1つのスタック操作とを定義する。
【0048】
図5Aは、図2に示される画面遷移を実現するように作成された画面遷移定義ファイルの一例を示す。
【0049】
図5Aに示される例では、画面遷移定義ファイルは、”root”ノード511を最上位のノードとする階層型ツリーの形式で表現されている。
【0050】
請求書入力/入金伝票入力システムにおける6個の画面は、それぞれ、”root”ノード511より1つ下位の階層にある6個のノード521〜526(すなわち、”nenu”ノード521、”seikyuNo”ノード522、”seikyuMain”ノード523、”nyukinNo”ノード524、”nyukinMain”ノード525、”seikyuList”ノード526)として表現されている。
【0051】
各画面に対応するスタック操作は、各画面に対応するノードより1つ下位の階層にあるノードとして表現されている。例えば、MENU画面210(図2)に対応する4つのスタック操作は、MENU画面210に対応する”menu”ノード521より1つ下位の階層にある4個のノード531〜534(すなわち、”peek”ノード531、”pop”ノード532、push seikyuNo”ノード533、”push nyukinNo”ノード534)として表現されている。
【0052】
なお、階層型ツリーとしては、複数の階層を有する任意のタイプのツリーを使用することができる。階層型ツリーは、例えば、バイナリー・サーチ・ツリーであり得る。
【0053】
図5Bは、図5Aに示される階層型ツリーをテーブル形式で表現した例を示す。
【0054】
図5Bに示される例では、階層型ツリーは、欄541〜欄545を有するテーブルによって表現されている。
【0055】
欄541は、ノードのアドレスを示す。
【0056】
欄542は、ノードの名称を示す。
【0057】
欄543は、ノードの階層(レベル)を示す。
【0058】
欄544は、子供ノード(すなわち、現在のノードより1つ下位の階層にある1つのノード)を指すポインタを示す。
【0059】
欄545は、親ノード(すなわち、現在のノードより1つ上位の階層にある1つのノード)を指すポインタを示す。
【0060】
欄546は、弟/妹ノード(すなわち、現在のノードと同一の階層にある他の1つのノード)を指すポインタを示す。
【0061】
ノード間のリンク(L Link、C link、R Link)は、欄544〜546に記載されるポインタによって実現される。
【0062】
図5Cは、画面遷移定義ファイルをXML言語の形式で表現した例を示す。図5Aに示される画面遷移定義ファイルと図5Cに示される画面遷移定義ファイルとは等価である。階層型ツリーのデータとXML言語とは、例えば、カスケードデータを仲介して、双方向に変換可能である。このような変換技術は周知であるのでここでは詳しい説明を省略する。
【0063】
なお、図5Aに示される画面遷移定義ファイルまたは図5Cに示される画面遷移定義ファイルを図4に示されるペトリネット形式の画面遷移から自動的に作成するようにしてもよい。
2.3 画面遷移定義ファイルのインストール
上記2.2で作成された画面遷移定義ファイルは、サーバコンピュータ20にインストールされる。画面遷移定義ファイルをサーバコンピュータ20にインストールする方法としては任意の方法を使用することができる。例えば、画面遷移定義ファイルがディスクに記録されている場合には、上述したように、ディスクドライブがディスクに記録されている画面遷移定義ファイルを読み出し、読み出された画面遷移定義ファイルをメモリ22に格納することにより、画面遷移定義ファイルのインストールを完了することができる。
2.4 画面遷移プログラムの実行
CPU21は、上記2.3でメモリ22にインストールされた画面遷移定義ファイルを参照しながら画面遷移プログラムを実行する。これにより、請求書入力/入金伝票入力システムにおける画面遷移が上記2.1で設計したとおりに実現される。
【0064】
例えば、請求書入力/入金伝票入力システムにおける画面遷移の仕様を変更する場合には、画面遷移定義ファイルを変更すれば足り、画面遷移プログラムを変更する必要はない。また、請求書入力/入金伝票入力システム以外の画面遷移を伴うアプリケーションシステムを設計、構築する場合でも、そのアプリケーションシステムにおける画面遷移の仕様に適合するように画面遷移定義ファイルを作成すれば足り、画面遷移プログラムを変更する必要はない。
【0065】
このように、画面遷移プログラムは、画面遷移を伴うすべてのアプリケーションシステムに共通に使用され得る。この意味で、この画面遷移プログラムは、サーバコンピュータ20を画面遷移定義ファイルを解釈実行するインタプリタ装置として動作させるためのコアプログラムということができる。
【0066】
画面遷移プログラムを画面遷移を伴うすべてのアプリケーションシステムに共通に使用することにより、画面遷移の仕様に適合するように画面遷移定義ファイルを作成しさえすれば、”プログラムレス”で(すなわち、新規に画面遷移プログラムを作成することなく)画面遷移を伴うアプリケーションシステムを開発することが可能になる。すなわち、画面遷移を伴うアプリケーションシステムを開発するたびに新たに画面遷移プログラムを開発する必要がない。その結果、画面遷移を伴う新たなアプリケーションシステムの開発期間を画期的に短縮することが可能になる。さらに、”プログラムレス”であるからバグをつくりこむ危険性がない。その結果、画面遷移を伴う新たなアプリケーションシステムの品質を画期的に向上させることが可能になる。
3.画面遷移プログラムの手順
図6は、画面遷移プログラムの手順を示す。画面遷移プログラムは、サーバコンピュータ20のCPU21によって実行される。以下、画面遷移プログラムの各ステップを詳細に説明する。
【0067】
ステップS1:画面遷移定義ファイルにおいて指定された初期画面の画面IDがスタックに積まれる。ここで、画面IDとは、画面を識別するための識別子をいう。
【0068】
ステップS2:スタックの最上位の位置にある画面IDが取得される。
【0069】
ステップS3:ステップS2において取得された画面IDに対応する画面内の処理が実行される。ここで、画面内の処理とは、1つの画面のみに関連する任意の処理をいう。
【0070】
ステップS4:ステップS3において画面内の処理を実行した結果としてスタック操作が取得される。さらに、取得されたスタック操作がスタックに対して実行される。
【0071】
ステップS5:スタックが空き状態か否かが判定される。「Yes」であれば処理は終了する。「No」であれば処理はステップS2に戻る。このように、スタックが空き状態になるまで、ステップS2〜S4が繰り返される。
【0072】
ステップS3における画面IDに対応する画面内の処理は、例えば、画面遷移プログラムからサブルーチンをコールすることによって実行される。このようなサブルーチンは、複数の画面IDに対して共通に設計されてもよいし、画面IDごとに別々に設計されてもよい。複数の画面IDに対して共通に設計されたサブルーチンを使用する場合には、例えば、そのサブルーチンをコールする時に画面IDを引数としてそのサブルーチンに渡してやればよい。ステップS4におけるスタック操作は、例えば、サブルーチンの戻り値として取得される。
【0073】
なお、画面遷移定義ファイルが図5Aに示されるように階層型ツリーの形式で表現されている場合には、ステップS2において取得された画面IDをキー項目として含むレコードを生成し、そのレコードのキー項目に対応するノードを階層型ツリーの中から探索し、その探索されたノードに対応する画面内の処理を行うことによってステップS3の処理を行うようにしてもよい。
【0074】
例えば、画面IDが”menu”である場合には、第1の項目(キー項目)が”menu”であり、第2の項目が*であるレコードが生成される。ここで、記号*は値が未定であることを示す。
【0075】
レコード:(”menu”,*)
レコードのキー項目”menu”に対応するノードが階層型ツリーの中から探索される。このような探索は、レコードのキー項目”menu”と”root”ノード511より1つ下位の階層のノードとを比較することにより行われる。その探索結果として”menu”ノード521が特定される。その結果、”menu”ノードに対応する画面(MENU画面210)内の処理が実行される。
【0076】
また、画面遷移定義ファイルが図5Aに示されるように階層型ツリーの形式で表現されている場合には、ステップS2において取得された画面IDを第1のキー項目として含み、かつ、ステップS4において取得されたスタック操作を第2のキー項目として含むレコードを生成し、そのレコードの第1のキー項目と第2のキー項目とに対応するノードを階層型ツリーの中から探索し、その探索されたノードに対応するスタック操作をスタックに対して実行することにより、ステップS4の処理を行うようにしてもよい。
【0077】
例えば、画面IDが”menu”であり、スタック操作が”push seikyuNo”である場合には、第1の項目(キー項目)が”menu”であり、第2の項目(キー項目)が”push seikyuNo”であるレコードが生成される。
【0078】
レコード:(”menu”,”push seikyuNo”)
レコードの第1のキー項目”menu”と第2のキー項目”push seikyuNo”に対応するノードが階層型ツリーの中から探索される。このような探索は、レコードの第1のキー項目である”menu”と”root”ノード511より1つ下位の階層のノードとを比較し、レコードの第2のキー項目である”push seikyuNo”と”menu”ノード521より1つ下位の階層のノードとを比較することにより行われる。その探索結果として”push seikyuNo”ノード533が特定される。その結果、”push seikyuNo”ノード533に対応するスタック操作”push seikyuNo”がスタックに対して実行される。
【0079】
以下、図7A〜図7Gを参照して、画面遷移とスタックの状態の遷移との関係を説明する。
【0080】
図7Aは、ログイン前のスタックの状態(初期状態)を示す。このとき、index=1である。
【0081】
図7Bは、ログイン直後のスタックの状態を示す。画面遷移定義ファイルには、ログイン直後に遷移する画面(初期画面)が指定されている。例えば、図5Aに示される画面遷移定義ファイルでは、MENU画面210が初期画面として指定されていると仮定する。この場合、ステップS1においてMENU画面210に対応する画面ID(例えば、”menu”)がスタックに積まれ、ステップS2においてMENU画面210に対応する画面IDが取得される。その結果、ステップS3においてMENU画面210内の処理が実行される。
【0082】
MENU画面210内の処理として「請求書」ボタンの押下というイベントが発生し、その処理の結果として”push seikyuNo”というスタック操作が取得されたと仮定する。この場合、”push seikyuNo”というスタック操作がスタックに対して実行される(ステップS4)。その結果、請求書番号入力画面220に対応する画面ID(例えば、”seikyuNo”)がスタックに積まれる。
【0083】
図7Cは、”push seikyuNo”というスタック操作がスタックに対して実行された直後のスタックの状態を示す。
【0084】
ステップS5においてスタックが空き状態であるか否かが判定される。判定結果は「No」であるので処理はステップS2に戻り、ステップS2において請求書番号入力画面220に対応する画面IDが取得される。その結果、ステップS3において請求書番号入力画面220内の処理が実行される。
【0085】
請求書番号入力画面220内の処理として「実行」ボタンの押下というイベントが発生し、その処理の結果として”push seikyuMain”というスタック操作が取得されたと仮定する。この場合、”push seikyuMain”というスタック操作がスタックに対して実行される(ステップS4)。その結果、請求書入力画面230に対応する画面ID(例えば、”seikyuMain”)がスタックに積まれる。
【0086】
図7Dは、”push seikyuMain”というスタック操作がスタックに対して実行された直後のスタックの状態を示す。
【0087】
ステップS5においてスタックが空き状態であるか否かが判定される。判定結果は「No」であるので処理はステップS2に戻り、ステップS2において請求書入力画面230に対応する画面IDが取得される。その結果、ステップS3において請求書入力画面230内の処理が実行される。
【0088】
請求書入力画面230内の処理として「戻る」ボタンの押下というイベントが発生し、その処理の結果として”pop”というスタック操作が取得されたと仮定する。この場合、”pop”というスタック操作がスタックに対して実行される(ステップS4)。その結果、indexが1だけ減少する。
【0089】
図7Eは、”pop”というスタック操作がスタックに対して実行された直後のスタックの状態を示す。
【0090】
ステップS5においてスタックが空き状態であるか否かが判定される。判定結果は「No」であるので処理はステップS2に戻り、ステップS2において請求書番号入力画面220に対応する画面IDが取得される。その結果、ステップS3において請求書番号入力画面220内の処理が実行される。
【0091】
請求書番号入力画面220内の処理として「戻る」ボタンの押下というイベントが発生し、その処理の結果として”pop”というスタック操作が取得されたと仮定する。この場合、”pop”というスタック操作がスタックに対して実行される(ステップS4)。その結果、indexが1だけ減少する。
【0092】
図7Fは、”pop”というスタック操作がスタックに対して実行された直後のスタックの状態を示す。
【0093】
ステップS5においてスタックが空き状態であるか否かが判定される。判定結果は「No」であるので処理はステップS2に戻り、ステップS2においてMENU画面210に対応する画面IDが取得される。その結果、ステップS3においてMENU画面210内の処理が実行される。
【0094】
MENU画面210内の処理として「終了」ボタンの押下というイベントが発生し、その処理の結果として”pop”というスタック操作が取得されたと仮定する。この場合、”pop”というスタック操作がスタックに対して実行される(ステップS4)。その結果、indexが1だけ減少する。
【0095】
図7Gは、”pop”というスタック操作がスタックに対して実行された直後のスタックの状態を示す。
【0096】
ステップS5においてスタックが空き状態であるか否かが判定される。判定結果は「Yes」であるので処理は終了する(ログアウトする)。
【0097】
このように、スタックは、複数の画面に対応する複数の画面IDを管理するために使用される。
【0098】
スタックの最上位の位置にある画面IDを取得すること(ステップS2)、その画面IDに対応する画面内の処理を行うこと(ステップS3)、その処理の結果として得られるスタック操作をスタックに対して行うこと(ステップS4)を繰り返すことにより、ある画面から他の画面への遷移を制御することが可能になる。
4.画面内状態遷移プログラムの手順
以下、図6のステップS3において実行される画面内の処理の一例として、画面内状態遷移処理を説明する。
【0099】
図8は、画面内状態遷移処理を実現するプログラム(以下、画面内状態遷移プログラムという)の手順を示す。画面内状態遷移プログラムは、サーバコンピュータ20のメモリ22に格納されており、CPU21によって実行される。以下、画面内状態遷移プログラムの各ステップを詳細に説明する。
【0100】
ステップS31:複数の画面内状態遷移定義ファイルのうち、ステップS2において取得された画面IDに対応する1つの画面内状態遷移定義ファイルが選択され、選択された画面内状態遷移定義ファイルに指定された初期状態を示す状態IDが現在の状態を示す現状態IDとして設定される。
【0101】
ステップS32:現状態IDが取得される。ここで、現状態IDの値は次に更新されるまで保持されているものとする。
【0102】
ステップS33:ステップS2において取得された画面IDとステップS32において取得された現状態IDとに少なくとも応答して、画面IDに対応する1つの画面内で現在の状態を遷移させる処理が実行される。
【0103】
ステップS34:ステップS33において処理を実行した結果として、現在の状態から遷移すべき次の状態を示す次状態IDが少なくとも取得される。
【0104】
ステップS35:ステップS33において処理を実行した結果として、スタック操作が取得されたか否かが判定される。「Yes」の場合には、処理は終了する(画面遷移プログラムに復帰する)。「No」の場合には、次状態IDを現状態IDとして設定した後に(ステップS36)、処理はステップS32に戻る。その結果、ステップS32〜S34が繰り返される。
【0105】
図9は、画面内状態遷移の仕様の一例として、MENU画面210内の状態遷移の仕様を示す。図9に示される例では、MENU画面210内の状態遷移は、「現状態」、「発生イベント」、「処理」、「結果(トークン値)」、「次状態」、「スタック操作」によって定義されている。
【0106】
例えば、図9に示されるテーブルの第2行は、現状態=”state02”においてイベント=”event01”が発生した場合には、”method02”の処理を行い、現状態を次状態=”state03”に遷移させ、スタック操作”push seikyuNo”を画面遷移プログラムに返すことを示している。
【0107】
画面内状態遷移定義ファイルは、1つの画面内における状態の遷移を定義する。
【0108】
図10Aは、図9に示されるMENU画面210内の状態遷移を実現するように作成された画面内状態遷移定義ファイルの一例を示す。
【0109】
図10Aに示される例では、画面内状態遷移定義ファイルは、”menu”ノード1011を最上位のノードとする階層型ツリーの形式で表現されている。
【0110】
MENU画面210における4つの状態は、それぞれ、”menu”ノード1011より1つ下位の階層にある4個のノード(すなわち、”state01”ノード1021、”state02”ノード1022、”state03”ノード1023、”state04”ノード1024)として表現されている。
【0111】
MENU画面210における3つの発生イベントは、それぞれ、”state02”ノード1022より1つ下位の階層にある3個のノード(すなわち、”event01”ノード1031、”event02”ノード1032、”event03”ノード1033)として表現されている。
【0112】
なお、画面内状態遷移定義ファイルが図10Aに示されるように階層型ツリーの形式で表現されている場合には、ステップS2において取得された画面IDを第1のキー項目として含み、かつ、ステップS32において取得された現状態IDを第2のキー項目として含むレコードを生成し、そのレコードの第1のキー項目と第2のキー項目とに対応するノードを階層型ツリーの中から探索し、その探索されたノードに対応する処理を行うことによってステップS33の処理を行うようにしてもよい。
【0113】
例えば、画面IDが”menu”であり、現状態IDが”state01”ある場合には、第1の項目(キー項目)が”menu”であり、第2の項目(キー項目)であり、第3の項目が*であるレコードが生成される。ここで、記号*は値が未定であることを示す。
【0114】
レコード:(”menu”,”state01”,*)
レコードの第1のキー項目”menu”と第2のキー項目”state01”に対応するノードが階層型ツリーの中から探索される。このような探索は、レコードの第1のキー項目である”menu”と”menu”ノード1011とを比較し、レコードの第2のキー項目である”state01”と”menu”ノード1011より1つ下位の階層のノードとを比較することにより行われる。その探索結果として”state01”ノード1021が特定される。その結果、”state01”に対応する処理(method01)が実行される。
【0115】
なお、例えば、画面IDが”menu”であり、現状態IDが”state02”ある場合において、イベント=event01が発生した場合には、画面IDが”menu”であり、現状態IDが”state01”ある場合には、第1の項目(キー項目)が”menu”であり、第2の項目(キー項目)が”state02”であり、第3の項目(キー項目)が”event01”であるレコードを生成し、このレコードを用いて階層型ツリーを探索するようにすればよい。
【0116】
図10Bは、画面内状態遷移定義ファイルをXML言語の形式で表現した例を示す。図10Aに示される画面内状態遷移定義ファイルと図10Bに示される画面内状態遷移定義ファイルとは等価である。階層型ツリーのデータとXML言語とは、例えば、カスケードデータを仲介して、双方向に変換可能である。このような変換技術は周知であるのでここでは詳しい説明を省略する。
【0117】
なお、図10Aに示される画面内状態遷移定義ファイルまたは図10Bに示される画面内状態遷移定義ファイルを図9に示される状態遷移から自動的に作成するようにしてもよい。
【0118】
なお、画面遷移を伴うアプリケーションの開発を例にとり説明したが、本発明の適用はこれに限定されない。本発明は、状態遷移を伴うアプリケーションシステム(例えば、通信を伴うアプリケーションシステム)の開発に広く適用することができる。
【0119】
【発明の効果】
上述したように、本発明の画面遷移プログラムは、画面遷移を伴うすべてのアプリケーションシステムに共通に使用され得る。この意味で、この画面遷移プログラムは、コンピュータを画面遷移定義ファイルを解釈実行するインタプリタ装置として動作させるためのコアプログラムということができる。
【0120】
画面遷移プログラムを画面遷移を伴うすべてのアプリケーションシステムに共通に使用することにより、画面遷移の仕様に適合するように画面遷移定義ファイルを作成しさえすれば、”プログラムレス”で(すなわち、新規に画面遷移プログラムを作成することなく)画面遷移を伴うアプリケーションシステムを開発することが可能になる。すなわち、画面遷移を伴うアプリケーションシステムを開発するたびに新たに画面遷移プログラムを開発する必要がない。その結果、画面遷移を伴う新たなアプリケーションシステムの開発期間を画期的に短縮することが可能になる。さらに、”プログラムレス”であるからバグをつくりこむ危険性がない。その結果、画面遷移を伴う新たなアプリケーションシステムの品質を画期的に向上させることが可能になる。
【図面の簡単な説明】
【図1】本発明の実施の形態のコンピュータシステム1の構成の一例を示す図
【図2】請求書入力/入金伝票入力システムにおける画面遷移の一例を示す図
【図3】スタックを模式的に示す図
【図4】図2に示される画面遷移をペトリネットで表現した図
【図5A】図2に示される画面遷移を実現するように作成された画面遷移定義ファイルの一例を示す図
【図5B】図5Aに示される階層型ツリーをテーブル形式で表現した例を示す図
【図5C】画面遷移定義ファイルをXML言語の形式で表現した例を示す図
【図6】画面遷移プログラムの手順を示すフローチャート
【図7A】画面遷移に関連してスタックの状態の遷移を説明するための図
【図7B】画面遷移に関連してスタックの状態の遷移を説明するための図
【図7C】画面遷移に関連してスタックの状態の遷移を説明するための図
【図7D】画面遷移に関連してスタックの状態の遷移を説明するための図
【図7E】画面遷移に関連してスタックの状態の遷移を説明するための図
【図7F】画面遷移に関連してスタックの状態の遷移を説明するための図
【図7G】画面遷移に関連してスタックの状態の遷移を説明するための図
【図8】画面内状態遷移プログラムの手順を示すフローチャート
【図9】画面内状態遷移の仕様の一例として、MENU画面210内の状態遷移の仕様を示す図
【図10A】図9に示されるMENU画面210内の状態遷移を実現するように作成された画面内状態遷移定義ファイルの一例を示す図
【図10B】画面内状態遷移定義ファイルをXML言語の形式で表現した例を示す図
【符号の説明】
1 コンピュータシステム
10 クライアントコンピュータ
20 サーバコンピュータ
30 ネットワーク
Claims (9)
- 画面遷移処理をコンピュータに実行させる画面遷移プログラムであって、
前記コンピュータは、複数の画面と前記複数の画面のそれぞれに対応する少なくとも1つのスタック操作とを定義する画面遷移定義ファイルを格納する格納部と、前記遷移定義ファイルを参照しながら前記画面遷移プログラムを実行する処理部と、前記複数の画面に対応する複数の画面IDを管理するために使用されるスタックとを含み、
前記画面遷移プログラムは、
(a)前記画面遷移定義ファイルにおいて指定された初期画面の画面IDを前記スタックに積むステップと、
(b)前記スタックの最上位の位置にある画面IDを取得するステップと、
(c)前記ステップ(b)において取得された前記画面IDに対応する画面内の処理を実行するステップと、
(d)前記ステップ(c)において前記画面内の処理を実行した結果としてスタック操作を取得し、前記取得されたスタック操作を前記スタックに対して実行するステップと、
(e)前記スタックが空状態になるまで、前記ステップ(b)〜(d)を繰り返すステップと
を包含する、画面遷移プログラム。 - 前記画面遷移定義ファイルは、階層型ツリーの形式で表現されており、
前記ステップ(c)は、
前記画面IDをキー項目として含むレコードを生成するステップと、
前記キー項目に対応するノードを前記階層型ツリーの中から探索するステップと、
前記探索されたノードに対応する画面内の処理を実行するステップと
を包含する、請求項1に記載の画面遷移プログラム。 - 前記ステップ(d)は、
前記画面IDを第1のキー項目として含み、かつ、前記スタック操作を第2のキー項目として含むレコードを生成するステップと、
前記第1のキー項目と前記第2のキー項目とに対応するノードを前記階層型ツリーの中から探索するステップと、
前記探索されたノードに対応するスタック操作を前記スタックに対して実行するステップと
を包含する、請求項2に記載の画面遷移プログラム。 - 前記階層型ツリーは、現在のノードより1つ下位の階層にある1つのノードを指すポインタと現在のノードより1つ上位の階層にある1つのノードを指すポインタと現在のノードと同一の階層にある他の1つのノードを指すポインタとを含むテーブルによって表現される、請求項2に記載の画面遷移プログラム。
- 前記格納部は、複数の画面内状態遷移定義ファイルをさらに格納し、前記複数の画面内状態遷移定義ファイルのそれぞれは、前記複数の画面のうち対応する1つの画面内で遷移可能な複数の状態を定義し、前記処理部は、前記複数の画面内状態遷移定義ファイルのうち選択された1つの画面内状態遷移定義ファイルを参照しながら、前記ステップ(c)の前記画面内の処理として画面内状態遷移プログラムをさらに実行し、
前記画面内状態遷移プログラムは、
(f)前記複数の画面内状態遷移定義ファイルのうち、前記ステップ(b)において取得された前記画面IDに対応する1つの画面内状態遷移定義ファイルを選択し、前記選択された画面内状態遷移定義ファイルに指定された初期状態を示す状態IDを現在の状態を示す現状態IDとして設定するステップと、
(g)現状態IDを取得するステップと、
(h)前記ステップ(b)において取得された前記画面IDと前記ステップ(g)において取得された前記現状態IDとに少なくとも応答して、前記画面IDに対応する1つの画面内で現在の状態を遷移させる処理を実行するステップと、
(i)前記ステップ(h)において前記処理を実行した結果として、前記現在の状態から遷移すべき次の状態を示す次状態IDを少なくとも取得するステップと、
(j)前記ステップ(h)において前記処理を実行した結果としてスタック操作が取得されたか否かを判定し、前記スタック操作が取得された場合には、前記画面遷移プログラムに復帰し、前記スタック操作が取得されなかった場合には、前記次状態IDを前記現状態IDとして設定した後に、前記ステップ(g)〜(i)を繰り返すステップと
を包含する、請求項1に記載の画面遷移プログラム。 - 前記選択された画面内状態遷移定義ファイルは、階層型ツリーの形式で表現されており、
前記ステップ(h)は、
前記画面IDを第1のキー項目として含み、かつ、前記現状態IDを第2のキー項目として含むレコードを生成するステップと、
前記第1のキー項目と前記第2のキー項目とに対応するノードを前記階層型ツリーの中から探索するステップと、
前記探索されたノードに対応する処理を実行するステップと
を包含する、請求項5に記載の画面遷移プログラム。 - 前記階層型ツリーは、現在のノードより1つ下位の階層にある1つのノードを指すポインタと現在のノードより1つ上位の階層にある1つのノードを指すポインタと現在のノードと同一の階層にある他の1つのノードを指すポインタとを含むテーブルによって表現される、請求項6に記載の画面遷移プログラム。
- 複数の画面と前記複数の画面のそれぞれに対応する少なくとも1つのスタック操作とを定義する画面遷移定義ファイルを格納する格納部と、
前記遷移定義ファイルを参照しながら画面遷移プログラムを実行する処理部と、
前記複数の画面に対応する複数の画面IDを管理するために使用されるスタックと
を備えたインタプリタ装置であって、
前記画面遷移プログラムは、
(a)前記画面遷移定義ファイルにおいて指定された初期画面の画面IDを前記スタックに積むステップと、
(b)前記スタックの最上位の位置にある画面IDを取得するステップと、
(c)前記ステップ(b)において取得された前記画面IDに対応する画面内の処理を実行するステップと、
(d)前記ステップ(c)において前記画面内の処理を実行した結果としてスタック操作を取得し、前記取得されたスタック操作を前記スタックに対して実行するステップと、
(e)前記スタックが空状態になるまで、前記ステップ(b)〜(d)を繰り返すステップと
を包含する、インタプリタ装置。 - 前記格納部は、複数の画面内状態遷移定義ファイルをさらに格納し、前記複数の画面内状態遷移定義ファイルのそれぞれは、前記複数の画面のうち対応する1つの画面内で遷移可能な複数の状態を定義し、
前記処理部は、前記複数の画面内状態遷移定義ファイルのうち選択された1つの画面内状態遷移定義ファイルを参照しながら、前記ステップ(c)の前記画面内の処理として画面内状態遷移プログラムをさらに実行し、
前記画面内状態遷移プログラムは、
(f)前記複数の画面内状態遷移定義ファイルのうち、前記ステップ(b)において取得された前記画面IDに対応する1つの画面内状態遷移定義ファイルを選択し、前記選択された画面内状態遷移定義ファイルに指定された初期状態を示す状態IDを現在の状態を示す現状態IDとして設定するステップと、
(g)現状態IDを取得するステップと、
(h)前記ステップ(b)において取得された前記画面IDと前記ステップ(g)において取得された前記現状態IDとに少なくとも応答して、前記画面IDに対応する1つの画面内で現在の状態を遷移させる処理を実行するステップと、
(i)前記ステップ(h)において前記処理を実行した結果として、前記現在の状態から遷移すべき次の状態を示す次状態IDを少なくとも取得するステップと、
(j)前記ステップ(h)において前記処理を実行した結果としてスタック操作が取得されたか否かを判定し、前記スタック操作が取得された場合には、前記画面遷移プログラムに復帰し、前記スタック操作が取得されなかった場合には、前記次状態IDを前記現状態IDとして設定した後に、前記ステップ(g)〜(i)を繰り返すステップと
を包含する、請求項8に記載のインタプリタ装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002233349A JP2004078264A (ja) | 2002-08-09 | 2002-08-09 | 画面遷移プログラムおよびインタプリタ装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002233349A JP2004078264A (ja) | 2002-08-09 | 2002-08-09 | 画面遷移プログラムおよびインタプリタ装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004078264A true JP2004078264A (ja) | 2004-03-11 |
Family
ID=32018496
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002233349A Withdrawn JP2004078264A (ja) | 2002-08-09 | 2002-08-09 | 画面遷移プログラムおよびインタプリタ装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2004078264A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008276585A (ja) * | 2007-05-01 | 2008-11-13 | Nippon Syst Wear Kk | 組込み装置、その開発システム、開発プログラム、データの転送方法およびデータ構造 |
-
2002
- 2002-08-09 JP JP2002233349A patent/JP2004078264A/ja not_active Withdrawn
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008276585A (ja) * | 2007-05-01 | 2008-11-13 | Nippon Syst Wear Kk | 組込み装置、その開発システム、開発プログラム、データの転送方法およびデータ構造 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8141033B2 (en) | Object oriented based methodology for modeling business functionality for enabling implementation in a web based environment | |
AU2005229697B2 (en) | Method and apparatus for metadata driven business logic processing | |
US7925719B2 (en) | Object oriented based, business class methodology for generating quasi-static web pages at periodic intervals | |
AU2012100128A4 (en) | A computer implemented system and method for indexing and optionally annotating use cases and generating test scenarios therefrom | |
US8904342B2 (en) | System and method for rapid development of software applications | |
US9575875B2 (en) | Computer implemented system and method for indexing and annotating use cases and generating test scenarios therefrom | |
US11468229B2 (en) | Describing changes in a workflow based on changes in structured documents containing workflow metadata | |
US20230102947A1 (en) | Providing operations in accordance with worksheet relationships and data object relationships | |
US20080098025A1 (en) | Electronic catalog | |
JP7221799B2 (ja) | 情報処理システム、及び情報処理システムの制御方法 | |
US20080263018A1 (en) | Method and System for Mapping Business Objects to Relational Database Tables | |
CN117055766A (zh) | 基于Ant Design的树形数据处理方法、装置、介质及电子设备 | |
WO2005054988A2 (en) | System and method for configuring a graphical user interface based on data type | |
US20050114851A1 (en) | System and method for configuring a graphical user interface based on data type | |
JP2004078264A (ja) | 画面遷移プログラムおよびインタプリタ装置 | |
JP2019095850A (ja) | 文書処理装置およびプログラム | |
US20050114642A1 (en) | System and method for managing OSS component configuration | |
JP4624870B2 (ja) | デモ作成システム | |
US20230401212A1 (en) | System for creating and accessing digital cards stored in decentralized content storage | |
JP4918278B2 (ja) | 顧客向けlsiデータ提供システム | |
CN116992095A (zh) | 数据模型的查询方法、装置、存储介质及终端设备 | |
CN115268895A (zh) | 前端代码及其模板生成方法、电子设备及存储介质 | |
WO2023244295A1 (en) | Control system for controlling management of digital cards stored in decentralized content storage | |
JP5235545B2 (ja) | スキーマ変換装置、プログラム及びスキーマ生成方法 | |
CN112948228A (zh) | 一种面向流数据的多模数据库评测基准系统及其构建方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A300 | Withdrawal of application because of no request for examination |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20051101 |