JP2006146677A - アプリケーションの開発支援システム及びこの開発支援システムを用いたデータフォーマット生成方法並びにデータ処理システム - Google Patents

Abstract

【課題】入出力画面を有するアプリケーションにおける、入出力画面用のデータフォーマットの設計、及び画面用データをモデル用データに変換する受付プログラムの開発を容易にする。
【解決手段】業務データフォーマット１０１から入力データフォーマット１０５を生成し、さらにフォーマット変換定義１０４を生成するデータフォーマット変換定義モジュール１０３と、これにより生成された入力データフォーマット１０５におけるデータを入力するための入力画面を定義する入力画面定義モジュール１０７と、入力画面定義１０８及びフォーマット変換定義１０４を入力して入力画面識別ＩＤ付フォーマット変換定義１１０を生成するフォーマット変換関連定義モジュール１０９を有する。
【選択図】図１

Description

本発明は、データの入力画面を伴う計算機システムの設計技術であるアプリケーションの開発支援システム及びその方法（データフォーマット生成方法）並びに上記計算システムの運用技術であるデータ処理システムに関する。

近年、Webアプリケーションの設計技法として、MVCの考え方が広く認知されている。ここで、MとはModelの略であり、データモデルを表す。VとはViewの略であり、画面を表す。CとはControlの略であり、画面遷移の制御を表す。

MVCは、ModelとViewを分離して設計、開発することにより、開発及びメインテナンスの効率が改善すると言われている。例えば、画面の設計には、GUIツールを用いれば、高度なプログラミング知識を要せずとも開発が可能となるため、画面設計に関しては、プログラミング知識よりも業務知識が豊富な担当者に任せることができる。

しかし、データモデルが大きく、複雑になってくると、画面設計者がモデルを理解することが困難になるため、画面用のデータと、モデル用のデータを設計する必要が生じ、その結果、モデルの設計、開発者は、画面用のデータフォーマットと、画面用のデータとモデル用のデータ間の変換プログラムを設計、開発する必要性が生じる。

したがって、画面用のデータフォーマット及び、画面用とモデル用の二つのデータフォーマット間の変換プログラムの設計、開発が、アプリケーション開発の効率を改善する上での課題となっている。

特許文献１（特開平１０−３０７８８１号公報）には、標準フォーマットとローカルフォーマットを同一画面上に表示し、関連するエレメントを選択してリンクすることにより、フォーマット変換時に使用する変換テーブルを生成することが記載されている。（従来技術１）
また、近年データのフォーマットを記述する言語としてXML(eXtensible Markup Language)が注目されている。該XMLの概要については、渡辺竜生氏のXMLハンドブック（SOFT BANK出版、2001年1月30日）のp2〜3及び、p16〜19に記載されている。

また、XMLと関連の深い仕様としてXSLT(Extensible Stylesheet Language)がある。該XSLTの概要については、渡辺竜生氏のXMLハンドブック（SOFT BANK出版、2001年1月30日）のp97及び、p101〜111に記載されている。

特開平１０−３０７８８１号公報 渡辺竜生氏のXMLハンドブック（SOFT BANK出版、2001年1月30日）（p2〜3, p16〜19, p97, p101〜111参照）

入出力画面を有するアプリケーションの開発及びメインテナンスにおいて、画面用のデータフォーマット及び、画面用とモデル用の二つのデータフォーマット間の変換プログラムの設計、開発が、開発効率を改善する上での課題となっている。

フォーマット変換方法及び、その定義方法に関しては、従来技術１で述べたように、EDI（Electrical Data Interchange）の分野において、GUIを用いてフォーマット間の変換を定義する方法が知られている。

ただし、従来技術１では、二つのフォーマットが予め与えられていることが前提である。したがって、本技術を、入出力画面を有するアプリケーションの開発時に適用した場合、画面用データからモデル用データを生成することはできるが、画面用データを設計することはできない。

本発明は、モデル用データフォーマットから、画面用データフォーマットを容易に生成することを第１の目的とする。

また、画面用データをモデル用データに変換する受付プログラムを、全ての画面で共通のプログラムを利用することにより、受付プログラムの開発及びメインテナンス効率を改善することを第２の目的とする。

上記目的を達成するために、本発明は、データを入力する入力画面を有するアプリケーションの開発支援システム及び該システムを用いたデータフォーマット生成方法であって、業務データフォーマットから入力データフォーマットを生成するデータフォーマット変換定義モジュールを有することを特徴とする。

また、本発明は、データを入力する入力画面を有するアプリケーションの開発支援システム及び該システムを用いたデータフォーマット生成方法であって、前記入力画面から入力された入力データを処理する業務プログラムが対象とする業務データのフォーマットから前記入力画面が利用するための入力データのフォーマットを生成し、さらに該入力データから前記業務データを生成するためのフォーマット変換定義を生成するデータフォーマット変換定義モジュールと、該データフォーマット変換定義モジュールで生成された入力データフォーマットにおけるデータを入力するための入力画面を定義する入力画面定義モジュールと、該入力画面定義モジュールで定義された入力画面定義及び前記データフォーマット変換定義モジュールで生成されたフォーマット変換定義を入力して、前記入力画面定義を一意に特定するＩＤを有する入力画面識別ＩＤ付フォーマット変換定義を生成するフォーマット変換関連定義モジュールとを有することを特徴とする。

また、本発明は、前記データフォーマット変換定義モジュールにおいて、ＸＭＬで記述された前記業務データフォーマットに対して、データの入力対象となるタグか否かを判定する第１の判定処理部と、該前記第１の判定処理部でデータの入力対象となると判定されたタグについては該タグを残すように処理し、前記第１の判定処理部でデータの入力対象とならないと判定されたタグに対しては該タグの階層を削除した際その下の階層における子タグが個別に判別できる場合には前記タグを削除するように処理するタグ処理部とを有することを特徴とする。

また、本発明は、前記データフォーマット変換定義モジュールにおいて、ＸＭＬで記述された前記業務データフォーマットに対して、データの入力対象となるタグか否かを判定する第１の判定処理部と、該第１の判定処理部でデータの入力対象とならないと判定されたタグに対して、該タグの階層を削除した際、その下の階層における子タグの名称が重複しているか否かを判定する第２の判定処理部と、前記第１の判定処理部でデータの入力対象となると判定されたタグについては該タグを残し、前記第２の判定処理部で重複していると判定されたタグについては該タグを残すかまたは子タグの名称の前に該タグの名称を追加し、前記第２の判定処理部で重複していないと判定されたタグについては該タグを削除する処理を行うタグ処理部とを有することを特徴とする。

また、本発明は、前記第２の判定処理部は、前記データの入力対象とならないと判定されたタグの階層において同一構造内にその下の階層の子タグの名称が重複しているか否かを判定する部分と、前記データの入力対象とならないと判定されたタグの階層において異なる構造内にその下の階層の子タグの名称が重複しているか否かを判定する部分とを有することを特徴とする。

また、本発明は、クライアントの入力画面を通して入力、送信された入力画面ＩＤ付きのデータを受付け、前記入力画面に応じた業務データを生成し、該生成された業務データを業務モジュールに提供して実行するデータ処理システムであって、受付モジュールのフォーマット変換呼出しに対して、入力画面ごとに定義されたフォーマット変換を実現するフォーマット変換モジュールを有することを特徴とする。

また、本発明は、クライアントの入力画面を通して入力、送信された入力画面ＩＤ付きのデータを受付け、前記入力画面に応じた業務データを生成し、該生成された業務データを業務モジュールに提供して実行するデータ処理システムであって、各入力画面の入力項目に対する検証項目を定義した各種の入力画面定義及び各種の入力画面識別ＩＤ付フォーマット変換定義を各種の入力画面ＩＤに対応させて管理する入力画面定義管理データベースと、クライアントの入力画面から送信される入力画面ＩＤ付きの入力データを受付ける受付モジュールと、前記入力画面定義管理データベースにより管理された各種の入力画面定義から前記受付モジュールで受付けた入力画面ＩＤに対応する入力画面定義を選択し、該選択された入力画面定義に基づいて前記受付モジュールで受付けた入力データを検証する入力データ検証モジュールと、前記入力画面定義管理データベースにより管理された各種の入力画面識別ＩＤ付フォーマット変換定義から前記入力データ検証モジュールで検証された入力画面ＩＤに対応するフォーマット変換定義を選択し、該選択されたフォーマット変換定義に基づき前記入力データ検証モジュールで検証された入力データを業務データに変換するフォーマット変換モジュールとを備え、該フォーマット変換モジュールで変換された業務データを業務モジュールに提供するように構成したことを特徴とする。

また、本発明は、前記フォーマット変換モジュールにおいて、フォーマット変換定義は、単純な階層構造の入力データフォーマットから必要なタグを追加した多層の階層構造を有する業務データフォーマットに変換する定義であることを特徴とする。

本発明によれば、入力画面を有するアプリケーションにおいて、入力画面とデータ受付プログラムの開発およびメインテナンス工数を大幅に削減するという効果がある。

また、本発明によれば、クライアントの入力画面を通して入力、送信された入力画面ＩＤ付きの入力データから、入力画面識別ＩＤ付フォーマット変換定義を利用した業務データに変換して業務モジュールに提供できるデータ処理システムを実現することができる。

以下、本発明を実施するための最良の形態について図面に基づいて詳細に説明する。

まず、本発明に係るデータの入力画面を伴う計算機システムの設計技術であるデータフォーマット生成方法を実現する設計・開発等のアプリケーションの開発支援システム（データフォーマット生成システム）及びその方法の実施例について図１〜図１０を用いて説明する。

図１には、本発明に係るデータ定義方法（データフォーマット生成方法）を実現する設計・開発等のアプリケーション支援システム（データフォーマット生成システム）の一実施例の全体構成図を示す。

図１に示すとおり、本発明を実現するアプリケーションの開発支援システムは、データフォーマット変換定義モジュール１０３、入力画面定義モジュール１０７、フォーマット変換関連定義モジュール１０９から構成される。

データフォーマット変換定義モジュール１０３は、受付プログラム設計者１０２が利用し、業務データフォーマット１０１を入力とし、入力データフォーマット１０５と、業務データフォーマット１０１と入力データフォーマット１０５の間の変換定義であるフォーマット変換定義１０４を出力する。

入力画面定義モジュール１０７は、入力画面設計者１０６が利用し、入力データフォーマット１０５を入力とし、入力画面定義１０８を出力する。入力画面定義１０８には、入力データフォーマット１０５が含まれる。

フォーマット変換関連定義モジュール１０９は、入力画面設計者１０５が利用し、フォーマット変換定義１０４と入力画面定義１０８を入力とし、入力画面識別ＩＤ付フォーマット変換定義１１０を出力する。

以下、各モジュールについて詳しく説明する。

まず、データフォーマット変換定義モジュール１０３について説明する。

業務データフォーマット変換定義モジュール１０３は、業務データフォーマット１０１を入力とし、入力データフォーマット１０５と、業務データフォーマット１０１と入力データフォーマット１０５の間のフォーマット変換定義１０４を出力する。

ここで、業務データフォーマット１０１とは、演算、集計、登録などの業務処理ごと、あるいは業務ごとに定義されたデータの構造である。例えば、流通業界においては、ｅｂＸＭＬ、ＪＥＤＩＣＯＳ ＸＭＬ、金融業界においてはＸＢＲＬなどと、ＸＭＬのフォーマットで定義されている。

次に、上記XMLで記述したデータフォーマットの実施例を示す。
<発注企業>
<企業名> ○×株式会社</企業名>
<電話番号>123456789</電話番号>
</発注企業>
ここで、「<」と「>」、または「</」と「>」で囲まれた文字列をタグと呼ぶ。「<」で始まるタグを開始タグ、「</」で始まるタグを終了タグと呼ぶ。そして、「<」「>」で囲まれる文字列と「</」と「>」で囲まれる文字列が同一のタグを一組とみなし、一組のタグに囲まれた文字列を、タグに対応するデータとする。この例だと、○×株式会社は企業名に対応するデータであり、123456789は電話番号に対応するデータである。また、ＸＭＬでは階層構造を定義することも可能であり、<企業名> ○×株式会社</企業名>と<電話番号>123456789</電話番号>全体が、発注企業に対応するデータとなる。

ＸＭＬは、このようにデータのフォーマットを定義できるメタ言語であり、このメタ言語の定義は、Ｗ３Ｃの勧告となっている（http://www.w3.org/XML/）。

また、上記ＸＭＬと関連の深い仕様としてＸＳＬＴ(Extensible Stylesheet Language)がある。これはＸＭＬで記述されたドキュメントを他の形式に変換するための仕様であり、Ｗ３Ｃの勧告となっている（http://www.w3.org/Style/XSL/）。他の形式の中には、ＸＭＬも含まれており、ＸＭＬで記述されたデータフォーマットの変換にも利用できる。

このように業務データフォーマット１０１は、発注業務の場合、図２及び図３の左側ウィンドウ並びに図４に示すようなデータ構造を有することになる。しかも、業務データフォーマット１０１は、通常、入力画面とは無関係に定義されていて、しかも複雑なデータ構造を有するため、入力画面を設計するのが困難となる。

そこで、入力画面の設計がし易い、単純なデータ構造（必要最小限の階層構造）を有する入力データフォーマット１０５にデータフォーマット変換定義モジュール１０３を用いて図６に示す処理フローに従って変換することが必要となる。図３の右側ウィンドウ並びに図５に発注業務の場合の生成された単純なデータ構造（必要最小限の階層構造）を有する入力データフォーマット１０５を示す。

また、入力データフォーマット１０５とは、アプリケーションの利用者が、Web上の画面を通して入力する単純なデータ構造を有するデータのフォーマットでもある。ただし、入力データフォーマット１０５は、入力画面ごとに設計、開発する必要がある。その結果、入力画面設計者１０６は、入力画面定義モジュール１０７を用いて、入力データフォーマット１０５の各要素を入力画面上に配置するデータ入力部品と対応付けることにより、入力画面を容易に設計することが可能となる。

図２には、データフォーマット変換定義モジュール１０９に発注業務に関する業務データフォーマットを読み込んだ実施例を示す。即ち、業務データフォーマットが読み込まれた時点で図２の左側のウィンドウには、業務データフォーマット１０１がディレクトリ構造で表示される。しかし、業務データフォーマットが読み込んだ時点では入力データが生成されていないので、図２の右側のウィンドウは表示されない。

図３の左側のウィンドウには、読み込まれた業務データフォーマット１０１のディレクトリ構造を示し、右側のウィンドウにはデータフォーマット変換定義モジュール１０３を用いて発注業務データから生成された単純なデータ構造（必要最小限の階層構造）を示す入力データフォーマット１０５を示す。

図２の左側のウィンドウにおいて、ディレクトリの階層構造は、ＸＭＬの階層構造に相当する。ディレクトリとファイルの記号の右横に記載された文字がＸＭＬのタグ名に相当する。子タグを持つタグはディレクトリ、子タグを持たないタグはファイルとして表記されている。

発注業務データの中で、特定のディレクトリを選択し、編集メニューの「入力データ生成」を選択すると、図３に示すとおり、右側のウィンドウに入力データのフォーマットが表示される。即ち、図３は、発注業務データの発注ディレクトリを選択し、入力データ生成を選択した例を示す。

図４及び図１６には、ＸＭＬの階層構造に相当するディレクトリの階層構造を有する入力画面が設計しずらい業務データフォーマット１０１を示す。図４は発注業務の場合を示し、図１６は通勤手当申請業務の場合を示す。図１６において、枠で囲ったタグは、図１５に示す入力データフォーマット１０５において削除されたタグを示す。

図５及び図１５は、データフォーマット変換定義モジュール１０３を用いて例えば図６に示す処理フローに従って生成され、入力画面の設計が容易になった入力データフォーマット１０５を示す。図５は発注業務の場合を示し、図１５は通勤手当申請業務の場合を示す。

入力データフォーマットの生成時には、ディレクトリとして表示されている、要素を削除している。これは、ディレクトリで表示されている要素には、入力画面を用いてデータを入力しないため、入力画面作成時には、データ入力部品と対応付ける必要がなく、入力画面作成の観点から見ると、不要なタグであるためである。図３の左右のウィンドウ、あるいは図４と図５を比較すると、データ入力に直接関係しない部署情報のタグおよび担当者のタグ等が削除されている。しかし、同じ親タグにおいて同一構造において複数発生する場合や同じ親タグで異なる構造において同一名称の子タグが発生する場合には、選択された発注企業タグ及び受注企業タグは残されている。

ただし、データの繰返し構造を残す場合（同じ親タグにおいて同一構造において複数発生する場合、即ち図４及び図５において発注企業または受注企業が複数存在する場合）、階層を示すタグを取り除くとその下の要素タグ（子タグ）の名称が重複する場合（同じ親タグで異なる構造において同一名称の子タグが発生する場合、即ち図４及び図５において要素タグ（子タグ）としての企業コード、企業名漢字のタグが、発注企業タグ、受注企業タグの下の階層において重複して存在する場合）など、単純にタグを削除できず、残すケースが存在する。

図５において、発注企業、受注企業のタグが残っているのは、企業コード、企業名漢字のタグが、発注企業タグ、受注企業タグの下に存在し、発注企業タグ、受注企業タグを削除すると、企業コードタグ、企業名漢字タグが重複し、発注企業に関するものか、受注企業に関するものなのか、判別できなくなるためである。

このようなケースに対応するため、データフォーマット変換定義モジュール１０３を用いて図６に示す処理フローに基づき、第２階層以下のタグを削除すべきか否か判定する。ただし、第１階層のタグはデータを入力するために必要であり、必ず残すものとする。

次に、データフォーマット変換定義モジュール１０３を用いて業務データフォーマット１０１から入力データフォーマット１０５を生成する処理フローの一実施例について図６を用いて具体的に説明する。

まず、第１階層のタグは必ず残す必要があるため、第２階層から始めるために第２階層を選択する（処理ステップ６０１）。次に、選択した階層の中で、一組のタグを選択する（処理ステップ６０２）。次に、選択した一組のタグが、データ入力対象の一組のタグか否か判定する（処理ステップ６０３）。入力対象の一組のタグである場合、処理ステップ６０４に進む。そうでない場合（図４において、例えば、発注企業タグ、受注企業タグ、部署情報タグ、担当者タグ等の場合）には処理ステップ６０５に進む。処理ステップ６０４では選択した一組のタグを残す（削除しない）。

処理ステップ６０５では、選択した一組のタグと、同一名称で、かつ同一の親タグを持つタグが存在するか否かを判定する。存在する場合（図４に示す業務データの中で、例えば同一の親タグである一組の発注タグに同一名称である発注企業タグが複数存在する場合）には各々の発注企業を判別できるようにデータを入力する必要があり、選択した一組の発注企業タグを残す処理ステップ６０４に進む。存在しない場合（図４に示す業務データの中で、例えば発注企業タグが一つの場合）には、処理ステップ６０６に進む。

処理ステップ６０６では、選択した一組のタグの全ての子タグについて、異なる構造（図４に示す業務データの中で、例えば発注企業及び受注企業）の中に同一名称のタグが存在しないか否かを判定する。存在しない場合には処理ステップ６０７に進み、存在する場合には処理ステップ６０４に進む。ここで、図４に示す業務データの中で、企業コードタグや企業名漢字タグが、「選択した一組の発注企業タグの全ての子タグについて、異なる構造（図４に示す業務データの中で、例えば発注企業及び受注企業）の中の同一名称のタグ」に相当し、存在すると判定されることになる。企業コードタグと企業名漢字タグは、異なる構造である発注する発注企業と発注を受ける受注企業の各々に含まれ、両方共発注企業と受注企業とに判別できるようにデータを入力する必要があるため、発注企業タグおよび受注企業タグは残すことになる。

以上説明したように、データ入力対象のタグおよび階層を取り除くと要素の名称が重複する場合には要素を判別できるように階層を示すタグは残すことになる。

処理ステップ６０７では、いずれにしろ、データを入力する必要もなく、判別できるように区分けする必要もないため、選択した一組のタグを削除する。

次に、処理ステップ６０８では、選択した一組のタグと同一階層の中で、未処理の一組のタグの有無を判定する。存在する場合には、戻り、処理ステップ６０２から再び実行する。存在しない場合には、処理ステップ６０９に進む。

処理ステップ６０９では、選択した一組のタグが、最下層の一組のタグでないか否かを判定する。最下層の一組のタグでない場合、処理ステップ６１０に進む。最下層の一組のタグの場合には、入力データフォーマットを生成する処理を終了する。

なお、上記実施例において以下のように変更して実施することも可能である。即ち、図６に示す処理ステップ６０６の判定結果がＮｏ．であった場合、処理ステップ６０４において選択した一組のタグを残す処理を実行せずに、選択した一組のタグの名称を、その子タグの名称の前に追加した後に、処理ステップ６０７の選択した一組のタグを削除する処理を実行する。図４に業務データの場合、<発注企業>の子タグの名称の前に、発注企業が追加されて、<発注企業／企業コード/>、<発注企業／企業名漢字/>、・・・となり、<発注企業></発注企業>が削除され；<受注企業>の子タグの名称の前に、受注企業が追加されて、<受注企業／企業コード/>、<受注企業／企業名漢字/>、・・・となり、<受注企業><／受注企業>が削除される。

以上説明したように、データの入力、即ち入力画面の設計に関係しないタグは削除されて例えば図５に示す単純な構造を有する入力データフォーマット１０５が生成されることになる。

次に、業務データフォーマット１０１及び変換された入力データフォーマット１０５を基にデータフォーマット変換定義モジュール１０３を用いてフォーマット変換定義１０４を生成する一実施例について図７及び図８を用いて説明する。

図７には、フォーマット変換定義１０４の一実施例を示す。ここで、フォーマット変換定義は、入力データフォーマット１０５を業務データフォーマット１０１に変換する定義であり、XSLT（eXtensible Stylesheet Language）により記載されている。

図８には、データフォーマット変換定義モジュール１０３を用いてフォーマット変換定義１０４を生成する処理フローを示す。ます、処理ステップ８０１において、業務データと入力データとを読み込む。次に、処理ステップ８０２において、フォーマット変換定義１０４の中の共通の固定文字列を生成する。図７において、<?xml version＝“1.0” encoding＝“Shift_JIS”?>のタグから、<xsl:output method＝“xml” encoding＝“Shift_JIS” indent＝“yes”/>の部分である。この部分には、使用しているXMLやXSLTのバージョンなどが指定されています。

処理ステップ８０３において、ＸＳＬＴを適用するタグ名を指定しています。これは、図２の中で、変換対象として選択されたディレクトリの名称である。ここでは、「発注」が選択されている。

処理ステップ８０４では、処理ステップ８０３において設定された名称の一組の開始タグと終了タグを作成する。処理ステップ８０５以下で作成されるタグは、全て、この開始タグと終了タグの間に追加される。

まず、処理ステップ８０５は、ｎ＝１とする。これは、第１階層を選択している。次に、処理ステップ８０６は、ｎ＝ｎ＋１とし、さらに１つ深い階層を選択している。本実施例において、最初に処理ステップ８０６を実行した場合には、第２階層、すなわち発注企業タグを選択している。

次に、処理ステップ８０７は、選択している階層の中で未処理のタグの有無を確認する。本実施例において、最初に処理ステップ８０７を実行した場合には、発注企業タグが存在するため、yesとなる。このように、処理ステップ８０７がyesの場合には、処理ステップ８０８を実行し、noの場合には、処理ステップ８１２を実行する。

処理ステップ８０８では、未処理のタグを選択し、同一名称のタグを作成する。最初に処理ステップ８０８を実行した場合には、発注企業の開始タグと終了タグが生成される。

次に、処理ステップ８０９では、処理ステップ８０８において選択したタグが、子タグを有しないか否かを確認する。子タグを有する場合には、処理ステップ８１０を実行し、そうでない場合には、処理ステップ８０６に戻る。本実施例において、最初に処理ステップ８０９を実行した場合には、発注企業タグの子タグとして、企業コードが存在するため、No.となり、処理ステップ８０６に戻ることになる。処理ステップ８０７、処理ステップ８０８を実行し、再び処理ステップ８０９を実行すると、今回は、企業コードには子タグが存在しないため、処理ステップ８１０を実行する。

処理ステップ８１０、処理ステップ８１１では、業務データの各タグに対応する値を、入力データの中から抽出するためのタグを作成する。即ち、処理ステップ８１０では、入力データの中から、処理ステップ８０８で作成したタグ名と同一名称のタグを選択する。同一名称のタグが、入力データの中に複数存在する場合には、親タグの名称が同一のタグを選択する。処理ステップ８１１では、選択したタグに対応する値を、入力データから抽出するためのタグを作成する。本実施例において、初めて処理ステップ８１１を選択した場合には、入力データの中から企業コードタグに対応するデータを抽出するための次のタグを作成する。<xsl:value-of-select＝“発注/発注企業/企業コード”/>
処理ステップ８１１を実行した後、処理ステップ８０７に戻って実行される。本実施例では、子タグを持たない企業名漢字タグが存在するため、処理ステップ８０８、８０９、８１０、８１１を再び実行される。

その後、部署情報タグは、子タグを有するため、処理ステップ８０６に戻り、ｎ＝４となり、部署コードタグを処理する。

同様の処理を繰返し、連絡先タグを処理した後に、処理ステップ８０７を実行すると、同一階層に未処理タグが存在しないため、No.となり、処理ステップ８１２を実行する。該処理ステップ８１２では、一つ階層を戻る。本実施例では、一つ階層を戻っても、未処理タグが存在しないので。処理ステップ８１２を繰返し、ｎ＝２となった段階で、受注企業タグが存在するため、処理ステップ８０８、８０９、８１０、８１１を繰り返す。

受注企業タグに囲まれたタグを全て処理した後に、処理ステップ８１２を実行すると、ｎ＝１となり、処理ステップ８１３を実行して終了する。

以上説明したように、データフォーマット変換定義モジュール１０３を用いて図７に示すようなフォーマット変換定義１０４が入力データフォーマット毎に生成されることになる。

次に、入力画面定義モジュール１０７について図９を用いて説明する。入力画面定義モジュール１０７は、入力データフォーマット１０７の各々を入力とし、該各々に対応した入力画面定義１０８を出力する。即ち、入力画面定義１０８は、入力データフォーマット毎に設計されて定義されて入力データフォーマットを含んだ状態で、フォーマット変換関連定義モジュール１０９に提供されることになる。各入力画面定義１０８には、各入力データフォーマット１０５が含まれている。図９には、入力画面定義モジュール１０７に、所定の発注入力データを読み込み、所定の発注入力画面を設計した一実施例を示す。図９に示すとおり、入力画面定義モジュールは、入力データを表示するウィンドウ９１と、画面設計ウィンドウ９２から構成される。

例えば、画面右端のツールバーの中から、「AB｜」と記載されたテキスト入力部品を選択し、入力データウィンドウ９１の中の企業コードを図９に示すとおり、画面設計ウィンドウ９２の中にドラッグ＆ドロップすると、テキスト入力部品（品名、商品コード等からなる）が、企業コードと対応付けられた形で配置される。

次に、フォーマット変換関連定義モジュール１０９について図１０を用いて説明する。フォーマット変換関連定義モジュール１０９は、入力画面定義モジュール１０７を用いて設計されて定義された入力画面定義１０８と、データフォーマット変換定義モジュール１０３を用いて定義されたフォーマット変換定義１０４を入力とし、入力画面識別ＩＤ付フォーマット変換定義を出力する。入力画面識別ＩＤ付フォーマット変換定義１１０とは、図７に示すフォーマット変換定義１０４に、その変換定義が、どの入力画面定義に関するものなのかを示す識別ＩＤを追加したものである。具体的には、入力画面定義に含まれるForm ＩＤを図７に示すフォーマット変換定義１０４に追加する。

図１０には、フォーマット変換関連定義モジュール１０９の画面イメージを示す。図１０では、入力画面定義モジュール１０７上の、ファイルメニューから、フォーマット変換関連定義を選択した場合に、表示されるダイアログを示す。図１０において、Form ＩＤとは、入力画面を一意に識別するＩＤである。予め作成したフォーマット変換定義を、本ダイアログ上で指定し、登録ボタンをクリックすることにより、入力画面識別ＩＤ付フォーマット変換定義１１０を作成する。

次に、本発明に係る入力画面識別ＩＤ付フォーマット変換定義を利用した申請システム（データ処理システム）の実施例について図１１〜図１３を用いて説明する。

図１１には、申請システム（データ処理システム）の一実施例の構成を示す。図１１に示すシステムでは、申請者１１０１が、クライアント１１０２に表示される入力画面（例えば通勤手当申請の場合図１４に示す入力画面となる。）を通してデータを入力し、該入力された送信データ１１０３をサーバ１１００に送信する。該送信データ１１０３には、入力画面を特定する入力画面ＩＤと、入力データが含まれる。この際、クライアント１１０２の画面には、サーバ１１００の入力画面定義管理ＤＢ１１１２に蓄積された図１２に示す入力画面定義管理テーブル１２０１を表示し、入力画面を選択することも可能である。サーバ１１００においては、受付プログラム１１０４が、送信データ１１０３を受信し、検証処理呼出し１１０５が実行される。検証処理呼出し１１０５は、入力画面サーバ・サービス１１０９に対して入力データ検証処理１１１０を実行する。入力データ検証処理１１１０には、入力データが入力画面定義時に定義された制約条件（例えば、入力項目毎の最大文字数や、数値（例えば発注業務などの場合における発注金額や発注数量、また通勤手当申請などの場合における片道金額や定期代期間など）／文字の種別など）を満たすか否かを検証する。更に、受付プログラム１１０４は、前処理呼出し１１０５が終了すると、フォーマット変換呼出し１１０６を実行する。フォーマット変換呼出し１１０６は、入力画面サーバ・サービス１１０９のフォーマット変換処理１１１１（入力画面定義管理ＤＢ１１１２に蓄積された多数の入力画面識別ＩＤ付フォーマット変換定義を参照して上記特定された入力画面ＩＤに対応する入力画面定義およびフォーマット変換定義（制約条件など）を検索（抽出）し、図１に示すように、該検索（抽出）された入力画面定義に基づいて入力画面定義モジュール１０７を用いて入力データフォーマット１０５（例えば発注業務の場合には図５に示し、通勤手当申請業務の場合には図１５に示す。）に逆変換し、さらに逆変換された入力データフォーマット１０５を基にデータフォーマット変換定義モジュール１０３を用いて上記入力データに応じた検索されたフォーマット変換定義を実行し、変換処理結果である業務データを取得する。）を実行し、変換処理結果である業務データ１１０７（例えば発注業務の場合には図４に示し、通勤手当申請業務の場合には図１６に示す。なお、枠で囲んだタグは入力データから業務データを生成するときに追加される。）を業務プログラム１１０８に提供する。フォーマット変換処理１１１１は、入力画面定義管理ＤＢ１１１２に蓄積された多数の入力画面識別ＩＤ付フォーマット変換定義を参照することにより、入力画面／フォーマット変換関連情報を利用して上記特定された入力画面ＩＤに対応する入力データに応じたフォーマット変換定義を検索して実行し、変換処理結果である業務データ１１０７を取得する。

入力画面定義管理ＤＢ１１１２に蓄積された多数の入力画面ＩＤに対応する多数の情報のフォーマットは図１２に示すとおりである。入力画面定義管理テーブル１２０１には、多数の入力画面ＩＤに対応する多数の入力画面定義（制約条件等）が格納されている。入力画面定義管理テーブル１２０１は、入力画面ＩＤと入力画面定義の二つのカラムから構成される。入力画面ＩＤは、上述したとおり、入力画面定義時（入力画面設計時）に設定される、入力画面定義を一意に特定するためのＩＤである。入力画面定義のカラムには、入力画面定義の実体が格納される。入力画面識別ＩＤ付フォーマット変換管理テーブル１２０２には、多数の入力画面ＩＤに対応する多数のフォーマット変換定義が格納されている。入力画面識別ＩＤ付フォーマット変換管理テーブル１２０２は、入力画面ＩＤとフォーマット変換定義の二つのカラムから構成される。入力画面ＩＤは、上述したとおり、入力画面定義時（入力画面設計時）に設定される、入力画面定義を一意に特定するためのＩＤである。フォーマット変換定義のカラムには、フォーマット変換定義の実体が格納される。ここで、各フォーマット変換定義は、同一レコードの入力画面ＩＤが示す入力画面定義を基にクライアント１１０２から送信された入力データを業務データに変換するためのフォーマット変換定義である。

次に、サーバ１１００における受付プログラム１１０４等の処理フローについて図１３を用いて説明する。即ち、サーバ１１００において、送信データ受信処理ステップ１３０１では、クライアント１１０２から送信された送信データ１１０３を受信し、送信データ１１０３の中から、入力データと入力画面ＩＤを取り出す。次に、データ検証処理ステップ１３０２では、検証処理呼出しプログラム１１０５に従って、上記取り出された入力画面ＩＤと入力データを引数として、入力画面サーバ・サービス１１０９の入力データ検証処理１１１０を呼び出す。該呼び出された入力データ検証処理１１１０は、入力画面定義管理テーブル１２０１に蓄積された多数の入力画面定義から入力画面ＩＤをキーとして入力画面ＩＤに対応する入力画面定義を選択して取得し、入力データが該取得された入力画面定義に定義された制約条件を満たすか否かを検証する。ここで制約条件とは、例えば、入力項目毎の最大文字数や、数値／文字の種別などである。次に、処理ステップ１３０３では、データ検証処理ステップ１３０２の結果に基づき、処理を分岐する。全ての入力項目が制約条件を満たす場合には、フォーマット変換呼出しプログラム１１０６に従って、フォーマット変換処理１１１１を呼び出してフォーマット変換処理ステップ１３０４に進み、それ以外の場合には、受信メッセージ送信処理ステップ１３０６に進む。

次に、フォーマット変換処理ステップ１３０４では、入力画面サーバ・サービス１１０９に対して、入力画面ＩＤと検証済みの入力データを提供し、フォーマット変換処理１１１１を呼び出す。該呼び出されたフォーマット変換処理１１１１は、入力画面識別ＩＤ付フォーマット変換定義管理ＤＢ１１１２に蓄積された多数のフォーマット変換定義から入力画面ＩＤをキーとして該入力画面ＩＤに対応するフォーマット変換定義を選択して取得し、入力データを該取得されたフォーマット変換定義に基づいて業務データ１１０７に変換してフォーマット変換呼出しプログラム１１０６に従って出力する。

次に、業務処理ステップ１３０５では、業務データ１１０７を引数として、審査等の業務プログラム１１０９である業務モジュールを呼び出して審査等の業務モジュールが実行されることになる。

次に、サーバ１１００において、受信メッセージ送信処理ステップ１３０６では、審査等の業務処理結果、あるいは、データ検証処理１３０２の処理結果を元に受信メッセージを作成し、クライアントソフト１１０２に送信する。

以上説明したように、上記実施例によれば、クライアントの入力画面を通して入力、送信された入力画面ＩＤ付きのデータを受付け、前記入力画面に応じた業務データを生成し、該生成された業務データを業務モジュールに提供して実行する入力画面識別ＩＤ付フォーマット変換定義を利用したデータ処理システムを提供できることになる。

本発明に係るデータを入力する入力画面を有するアプリケーションの開発支援システムの一実施例を示す全体構成の説明図である。 図１に示すデータフォーマット変換定義モジュールの実装画面の説明図で、左側ウィンドウには発注業務に関する業務データフォーマットを読み込んだ一実施例を示す図である。 図１に示すデータフォーマット変換定義モジュールの実装画面の一実施例を示す説明図で、左側ウィンドウには発注業務に関する業務データフォーマットを読み込んだ一実施例を示し、右側ウィンドウには発注業務に関する業務データから生成された入力データフォーマットの一実施例を示す図である。 本発明に係る発注業務に関する業務データのフォーマットの一実施例を示すＸＭＬである。 本発明に係る発注業務に関する業務データから生成された入力データフォーマットの一実施例を示す図である。 図１に示すデータフォーマット変換定義モジュールを用いたデータフォーマット変換処理の一実施例を示すフローチャートである。 本発明に係る入力データから業務データを生成するフォーマット変換定義の一実施例を示す図である。 図１に示すデータフォーマット変換定義モジュールを用いてフォーマット変換定義を生成する処理フローの一実施例を示す図である。 図１に示す入力画面定義モジュールの実装画面の一実施例を示す説明図である。 図１に示すフォーマット変換関連定義モジュールの実装画面の一実施例を示す説明図である。 本発明に係る入力画面識別ＩＤ付フォーマット変換定義を利用した申請データ処理システムの一実施例を示すシステム構成図である。 図１１に示す申請データ処理システムを構成する入力画面定義管理データベースで管理するテーブルのフォーマットの一実施例を示す図である。 図１１に示すサーバにおける受付プログラムの一実施例を示すフローチャートである。 本発明に係る通勤手当申請業務に関するクライアントから入力画面を用いて入力する入力データの表示の一実施例を示す図である。 本発明に係る通勤手当申請業務に関する入力データフォーマットの一実施例を示す図である。 本発明に係る通勤手当申請業務に関する業務データフォーマットの一実施例を示す図である。

符号の説明

９１…入力データウィンドウ、 ９２…画面設計ウィンドウ、 １０１…業務データフォーマット、 １０２…受付プログラム設計者、 １０３…データフォーマット変換定義モジュール、 １０４…フォーマット変換定義、 １０５…入力データフォーマット、 １０６…入力画面設計者、 １０７…入力画面定義モジュール、 １０８…入力画面定義、 １０９…フォーマット変換関連定義モジュール、 １１０…入力画面識別ＩＤ付フォーマット変換定義、 １１００…サーバ、 １１０１…申請者、 １１０２…クライアント、 １１０３…送信データ、 １１０４…受付プログラム、 １１０５…検証処理呼出し、 １１０６…フォーマット変換呼出し、 １１０７…業務データ、 １１０８…業務プログラム（業務モジュール）、 １１０９…入力画面サーバ・サービス、 １１１０…入力データ検証処理、 １１１１…フォーマット変換処理、 １１１２…入力画面定義管理ＤＢ。

Claims (9)

1. データを入力する入力画面を有するアプリケーションの開発支援システムであって、
   前記入力画面から入力された入力データを処理する業務プログラムが対象とする業務データのフォーマットから前記入力画面が利用するための入力データのフォーマットを生成し、さらに該入力データから前記業務データを生成するためのフォーマット変換定義を生成するデータフォーマット変換定義モジュールと、
   該データフォーマット変換定義モジュールで生成された入力データフォーマットにおけるデータを入力するための入力画面を定義する入力画面定義モジュールと、
   該入力画面定義モジュールで定義された入力画面定義及び前記データフォーマット変換定義モジュールで生成されたフォーマット変換定義を入力して、前記入力画面定義を一意に特定するＩＤを有する入力画面識別ＩＤ付フォーマット変換定義を生成するフォーマット変換関連定義モジュールとを有することを特徴とするアプリケーションの開発支援システム。
2. 前記データフォーマット変換定義モジュールにおいて、
   ＸＭＬで記述された前記業務データフォーマットに対して、データの入力対象となるタグか否かを判定する第１の判定処理部と、
   該前記第１の判定処理部でデータの入力対象となると判定されたタグについては該タグを残すように処理し、前記第１の判定処理部でデータの入力対象とならないと判定されたタグに対しては該タグの階層を削除した際その下の階層における子タグが個別に判別できる場合には前記タグを削除するように処理するタグ処理部とを有することを特徴とする請求項１に記載のアプリケーションの開発支援システム。
3. 前記データフォーマット変換定義モジュールにおいて、
   ＸＭＬで記述された前記業務データフォーマットに対して、データの入力対象となるタグか否かを判定する第１の判定処理部と、
   該第１の判定処理部でデータの入力対象とならないと判定されたタグに対して、該タグの階層を削除した際、その下の階層における子タグの名称が重複しているか否かを判定する第２の判定処理部と、
   前記第１の判定処理部でデータの入力対象となると判定されたタグについては該タグを残し、前記第２の判定処理部で重複していると判定されたタグについては該タグを残すかまたは子タグの名称の前に該タグの名称を追加し、前記第２の判定処理部で重複していないと判定されたタグについては該タグを削除する処理を行うタグ処理部とを有することを特徴とする請求項１に記載のアプリケーションの開発支援システム。
4. 前記第２の判定処理部は、前記データの入力対象とならないと判定されたタグの階層において同一構造内にその下の階層の子タグの名称が重複しているか否かを判定する部分と、前記データの入力対象とならないと判定されたタグの階層において異なる構造内にその下の階層の子タグの名称が重複しているか否かを判定する部分とを有することを特徴とする請求項２に記載のアプリケーションの開発支援システム。
5. データを入力する入力画面を有するアプリケーションの開発支援システムを用いたデータフォーマット生成方法であって、
   データフォーマット変換定義モジュールを用いることによって、前記入力画面から入力された入力データを処理する業務プログラムが対象とする業務データのフォーマットから前記入力画面が利用するための入力データのフォーマットを生成し、さらに該入力データから前記業務データを生成するためのフォーマット変換定義を生成する第１のステップと、
   入力画面定義モジュールを用いることによって、前記第１のステップで生成された入力データフォーマットにおけるデータを入力するための入力画面を定義する第２のステップと、
   フォーマット変換関連定義モジュールを用いることによって、第２のステップで定義された入力画面定義及び前記第１のステップで生成されたフォーマット変換定義を入力して、前記入力画面定義を一意に特定するＩＤを有する入力画面識別ＩＤ付フォーマット変換定義を生成する第３のステップとを有することを特徴とするアプリケーションの開発支援システムを用いたデータフォーマット生成方法。
6. 前記第１のステップにおいて、
   ＸＭＬで記述された前記業務データフォーマットに対して、データの入力対象となるタグか否かを判定する第１の判定処理ステップと、
   該前記第１の判定処理ステップでデータの入力対象となると判定されたタグについては該タグを残すように処理し、前記第１の判定処理ステップでデータの入力対象とならないと判定されたタグに対しては該タグの階層を削除した際その下の階層における子タグが個別に判別できる場合には前記タグを削除するように処理するタグ処理ステップとを有することを特徴とする請求項５に記載のアプリケーションの開発支援システムを用いたデータフォーマット生成方法。
7. 前記第１のステップにおいて、
   ＸＭＬで記述された前記業務データフォーマットに対して、データの入力対象となるタグか否かを判定する第１の判定処理ステップと、
   該第１の判定処理ステップでデータの入力対象とならないと判定されたタグに対して、該タグの階層を削除した際、その下の階層における子タグの名称が重複しているか否かを判定する第２の判定処理ステップと、
   前記第１の判定処理ステップでデータの入力対象となると判定されたタグについては該タグを残し、前記第２の判定処理ステップで重複していると判定されたタグについては該タグを残すかまたは子タグの名称の前に該タグの名称を追加し、前記第２の判定処理ステップで重複していないと判定されたタグについては該タグを削除する処理を行うタグ処理ステップとを有することを特徴とする請求項５に記載のアプリケーションの開発支援システムを用いたデータフォーマット生成方法。
8. クライアントの入力画面を通して入力、送信された入力画面ＩＤ付きのデータを受付け、前記入力画面に応じた業務データを生成し、該生成された業務データを業務モジュールに提供して実行するデータ処理システムであって、
   各入力画面の入力項目に対する検証項目を定義した各種の入力画面定義及び各種の入力画面識別ＩＤ付フォーマット変換定義を各種の入力画面ＩＤに対応させて管理する入力画面定義管理データベースと、
   クライアントの入力画面から送信される入力画面ＩＤ付きの入力データを受付ける受付モジュールと、
   前記入力画面定義管理データベースにより管理された各種の入力画面定義から前記受付モジュールで受付けた入力画面ＩＤに対応する入力画面定義を選択し、該選択された入力画面定義に基づいて前記受付モジュールで受付けた入力データを検証する入力データ検証モジュールと、
   前記入力画面定義管理データベースにより管理された各種の入力画面識別ＩＤ付フォーマット変換定義から前記入力データ検証モジュールで検証された入力画面ＩＤに対応するフォーマット変換定義を選択し、該選択されたフォーマット変換定義に基づき前記入力データ検証モジュールで検証された入力データを業務データに変換するフォーマット変換モジュールとを備え、
   該フォーマット変換モジュールで変換された業務データを業務モジュールに提供するように構成したことを特徴とするデータ処理システム。
9. 前記フォーマット変換モジュールにおいて、フォーマット変換定義は、単純な階層構造の入力データフォーマットから必要なタグを追加した多層の階層構造を有する業務データフォーマットに変換する定義であることを特徴とする請求項８に記載のデータ処理システム。

Images