(57)【要約】【課題】アプリケーションの設計を変更させる必要性が生じた場合に、より低コスト、短時間で対応できるようにする技術を提供する。【解決手段】言語展開装置２０は、アプリケーション・プログラム３の仕様を変更すべき状況が発生すると、その仕様の変更に応じて入力データ１に対して処理すべき処理内容を示す仕様データ２４を参照して、入力データ１更新用の言語２３を生成する。データ更新装置３０は、その言語２３に従い、入力データ１を処理して出力データ２を生成する。それにより、アプリケーション・プログラム３を新たに作成することなく、仕様の変更に対応させる。【選択図】図１
2007172645.tif 000002
【特許請求の範囲】
【請求項１】
対象となるアプリケーション・プログラムに入力される各データ項目のデータ値を入力データのデータ項目のデータ値から求める処理の定義を記憶する仕様データ記憶部と、
該仕様データ記憶部に記憶された処理の定義に基づいて、取得した入力データのデータ更新を行うことにより出力データを生成し、前記対象となるアプリケーション・プログラムへ送信するデータ更新手段と
を有することを特徴とするデータ更新装置。
【請求項２】
対象となるアプリケーション・プログラムに入力される各データ項目のデータ値を入力データのデータ項目のデータ値から求める処理の定義を記憶する仕様データ記憶部と、
該仕様データ記憶部に記憶された処理の定義に基づいて、取得した入力データを出力データに更新する処理手順を明記した更新処理言語を生成する言語生成部と、
前記言語生成部が生成した更新処理言語に基づき、取得した入力データのデータ更新を行うことにより出力データを生成し、前記対象となるアプリケーション・プログラムへ送信するデータ更新手段と
を有することを特徴とするデータ更新装置。
【請求項３】
前記仕様データ記憶部に記憶されている処理の定義として、前記対象となるアプリケーション・プログラムに入力される各データ項目のデータ値を入力データのデータ項目のデータ値から求める計算式を定義している
ことを特徴とする請求項１または２記載のデータ更新装置。
【請求項４】
対象となるアプリケーション・プログラムに入力される各データ項目のデータ値を入力データのデータ項目のデータ値から求める処理の定義を記憶する仕様データ記憶部にアクセス可能なコンピュータが、
該仕様データ記憶部に記憶された処理の定義に基づいて、取得した入力データのデータ更新を行うことにより出力データを生成し、前記対象となるアプリケーション・プログラムへ送信するデータ更新ステップ
を実行することを特徴とするデータ更新方法。
【請求項５】
対象となるアプリケーション・プログラムに入力される各データ項目のデータ値を入力データのデータ項目のデータ値から求める処理の定義を記憶する仕様データ記憶部にアクセス可能なコンピュータが、
該仕様データ記憶部に記憶された処理の定義に基づいて、取得した入力データを出力データに更新する処理手順を明記した更新処理言語を生成する言語生成ステップと、
前記言語生成部が生成した更新処理言語に基づき、取得した入力データのデータ更新を行うことにより出力データを生成し、前記対象となるアプリケーション・プログラムへ送信するデータ更新ステップと
を実行することを特徴とするデータ更新方法。
【請求項６】
前記仕様データ記憶部に記憶されている処理の定義として、前記対象となるアプリケーション・プログラムに入力される各データ項目のデータ値を入力データのデータ項目のデータ値から求める計算式を定義している
ことを特徴とする請求項４または５記載のデータ更新方法。
【請求項７】
対象となるアプリケーション・プログラムに入力される各データ項目のデータ値を入力データのデータ項目のデータ値から求める処理の定義を記憶する仕様データ記憶部にアクセス可能なコンピュータに、
該仕様データ記憶部に記憶された処理の定義に基づいて、取得した入力データのデータ更新を行うことにより出力データを生成し、前記対象となるアプリケーション・プログラムへ送信するデータ更新ステップ
を実行させるデータ更新プログラム。
【請求項８】
対象となるアプリケーション・プログラムに入力される各データ項目のデータ値を入力データのデータ項目のデータ値から求める処理の定義を記憶する仕様データ記憶部にアクセス可能なコンピュータに、
該仕様データ記憶部に記憶された処理の定義に基づいて、取得した入力データを出力データに更新する処理手順を明記した更新処理言語を生成する言語生成ステップと、
前記言語生成部が生成した更新処理言語に基づき、取得した入力データのデータ更新を行うことにより出力データを生成し、前記対象となるアプリケーション・プログラムへ送信するデータ更新ステップと
を実行させるデータ更新プログラム。
【請求項９】
前記仕様データ記憶部に記憶されている処理の定義として、前記対象となるアプリケーション・プログラムに入力される各データ項目のデータ値を入力データのデータ項目のデータ値から求める計算式を定義している
ことを特徴とする請求項７または８記載のデータ更新プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーション・プログラムで処理する入力データ、及びそれを処理させる内容のうちの少なくとも一方を変更する場合に、その変更に容易に対応するための技術に関する。
【背景技術】
【０００２】
現在では、データの処理にコンピュータなどのデータ処理装置が広く用いられている。それにより、プログラムはデータ処理に欠かせない存在となっている。このようなことから、項目やエンティティ、及び入出力などの設計情報を入力してアプリケーション・プログラム（以下、「アプリケーション」と略記）のソースコードを自動生成する機能を備えたＣＡＳＥ（Computer Aided SoftwareEngineering ）ツールは無くてはならないものとなっている（特許文献３）。
【０００３】
アプリケーションは、設計（仕様）の変更により、新規に作成しなければならない。つまり、アプリケーションを別に新たに作成するか、或いは既存のアプリケーションに対してアップデートしなければならない。新規に作成したアプリケーションは、それをＣＡＳＥツールで自動生成したか否かに係わらず、その動作を確認しなければならない。その確認のためには、面倒で時間がかかる作業を行わなければならない。このため、たとえ変更であっても、新たな設計が決定してからアプリケーションを実際の業務などに使える状態となるまでに長い時間が必要なのが実情となっている。
【０００４】
上記設計の変更は、これまでは行う頻度は比較的に小さかったが、最近では、その頻度は大きくなる傾向にある。特に、サービスを提供する業者にその傾向は顕著である。これは、顧客の獲得やその維持のために、利便性やサービス性などで他との差別化を図る必要が大きくなっているためである。
【特許文献１】特開２０００−２３２４８０号公報
【特許文献２】特開平０２−１４８３３２号公報
【特許文献３】特開２０００−０５６９７４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上述したように、動作確認の必要から、新規に作成したアプリケーションは直ちに使うことができない。その動作確認のための労力も小さくはない。このようなことから、設計の変更は、変更した部分の多さに係わらず、長い時間とコストのかかるものとなっている。それにより、より低コスト、短時間でその変更に対応できるようにすることが強く望まれていた。
【０００６】
その変更に対応可能な従来の技術としては、特許文献２に記載されたものがある。その特許文献２に記載のインターフェースプログラムは、インターフェース定義体ファイル１９を参照し、インターフェース用ファイル１５から該当するデータを入力し、対応する処理プログラムの入力用ファイルに出力するようになっている。それにより、インターフェース用ファイル１５から任意のデータを入力用ファイルに格納できるようになっている。      
【０００７】
しかし、上記設計の変更は、扱うデータの変更のみで対応できるとは限らない。例えば新たにサービスを提供する場合、新しいデータ項目の追加、或いはデータを用いた処理内容の変更等が行われることが多い。特許文献２に記載のインターフェースプログラムでは、そのような変更には対応できない。このことから、事実上、設計の変更に対応できるようなものではなかった。
【０００８】
本発明は、アプリケーションの設計を変更させる必要性が生じた場合に、より低コスト、短時間で対応できるようにする技術を提供することを目的とする。
【課題を解決するための手段】
【０００９】
図１は、本発明の原理図である。図１を参照して、本発明の言語展開装置、データ更新装置、及びデータ処理方法について説明する。
データ更新装置３０は、入力データ１を処理して、アプリケーション・プログラム（以下、「アプリケーション」と略記）３が適切に処理を行えるような出力データ２を生成するものである。そのような出力データを生成するために、入力データ１を取得する入力データ取得部３１、及びそれが取得した入力データ１を更新して出力データ２を生成するデータ更新部３２を備えている。
【００１０】
アプリケーション３の前にデータ更新装置３０を配置し、それに入力データ１を処理（更新）して出力データ２を生成させる場合、入力データ１を構成するデータの項目や形式、データの内容、或いはアプリケーション３に行わせる処理の内容などに変更が生じても、そのような変更にデータ更新装置３０のみで対応させることが可能となる。それにより、アプリケーション３の仕様を変更すべき状況が発生しても、新たにアプリケーション３を作成したり、或いはそれをアップデートするといった必要性を回避することが可能となる。この結果、そのような状況が発生しても、より迅速、容易、且つ低コストで対応できることとなる。
【００１１】
言語展開装置２０は、そのような状況が生じた場合に、アプリケーション３が適切に処理できるように入力データ１を更新するための更新処理言語２３を自動的に生成するものである。その生成は、入力データ１に対して処理すべき処理内容を示す仕様データ２４を参照して行う。その処理内容は、入力データ１を構成するデータ項目のデータ（データ値）を用いて行うべき計算式を含むものである。そのために、仕様データ２４を取得する仕様データ取得部２１、及びその仕様データ２４を参照して更新処理言語２３を生成する言語生成部２２を備えている。
【００１２】
この装置２０が更新処理言語２３を生成することにより、データ更新装置３０はその言語２３により入力データ１を処理して、アプリケーション３が適切な処理を行える出力データ２を生成することが可能となる。
【発明の効果】
【００１３】
本発明は、アプリケーション・プログラムが処理を行う前の入力データを別に前処理させる。その前処理を設けることにより、入力データを構成するデータの内容（データ値）、或いはアプリケーション・プログラムに行わせる処理（計算処理）の内容などの変更によってアプリケーション・プログラムの仕様を変更すべき状況が発生しても、その変更に前処理の段階で対応することができるようになる。入力データを構成するデータの項目や形式等の変更も行わせることができる。このため、そのような状況が発生しても、新たにアプリケーション・プログラムを作成したり、或いはそれをアップデートするといった必要性も回避できることとなる。この結果、そのような状況の発生に対し、より迅速、容易、且つ低コストで対応できることとなる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の実施の形態について、図面を参照しながら詳細に説明する。
図２は、本実施の形態による言語展開装置、及びデータ更新装置が適用されたネットワークシステムの構成を示す図である。
【００１５】
そのシステムは、図２に示すように、インターネット２０５と接続されたＷｅｂシステム２０１と、例えば顧客に対するサービスの提供に伴う代金を徴収するための計算業務用に構築されたレガシーシステム２０２と、新規サービスの企画・立案等を行う業務部門２０３に割り当てられた不図示の複数の端末装置と、が通信ネットワーク（ここではＬＡＮとする）などの２０４によって接続させることで構築されている。本実施の形態による言語展開装置、及びデータ更新装置は、Ｗｅｂシステム２０１に搭載される形で適用されている。
【００１６】
上記レガシーシステム２０２は、例えば電話、電気、或いはガスなどの使用量に応じた代金を請求するための請求書発行用に構築されたものである。特に図示していないが、１台以上のサーバから構成されている。その代金（請求額）は、その計算用に開発したアプリケーション・プログラム（以下「アプリケーション」と略記）を１台のサーバが実行することで計算される。
【００１７】
図３は、上記Ｗｅｂシステム２０１の構成を示す図である。
そのシステム２０１は、図３に示すように、インターネット２０５と不図示のルータを介して接続されたＷｅｂサーバ３０１と、そのＷｅｂサーバ３０１がユーザから受けた要求を引き継いで処理を行うアプリケーションサーバ３０２と、各種データを管理するデータベース（ＤＢ）サーバ３０３と、をＬＡＮ３０４に接続させることで構築されている。本実施の形態による言語展開装置、及びデータ更新装置は、アプリケーションサーバ３０２に搭載されたＣＰＵが、ハードディスク装置３０２ａに格納されたプログラムを実行することで実現される。
【００１８】
電話や電気、及びガスなどを扱う業種では、サービスの自由化に伴い、新たな割引サービスの企画・立案が急務となっている。新たな割引サービスの決定、つまり料金の改定には、アプリケーションにおける仕様（設計）の変更が伴う。このため、その改定をアプリケーションに反映させるには長い時間がかかる。その反映は、サービスを決定する部門→アプリケーションの保守・管理を行う部門といったように、異なる部門を経由して行われるため、更に長い時間がかかるのが実情である。これらのことは、新たなサービスを決定しても、そのサービスの提供を開始するまでに長い時間がかかるということを意味する。本実施の形態では、それを以下のようにして回避している。図４以降の説明図を参照して詳細に説明する。
【００１９】
図４は、上記アプリケーションサーバ３０２の機能構成を示す図である。
そのサーバ３０２は、ハードディスク装置３０２ａに格納されたプログラムを実行することにより、計算ロジック部４０１、及びマルチ言語展開部４０２を実現させる。
【００２０】
計算ロジック部４０１は、従量レコード（入力データ）４０３を入力し、それを処理して得られる請求レコード４０４を出力するものである。その従量レコード４０３は、例えば一人の顧客に対して請求書を発行するうえで必要なデータをまとめたものである。顧客を示すデータ（住所、名前、など）や、受け取ったサービスの程度を示す従量データ（例えばガスではガス使用量を示すデータである）などが含まれる。請求レコード４０４は、請求書に印字すべきデータをまとめたものである。計算ロジック部４０１は、都道府県テーブル４０５、都市料金テーブル４０６、及び従量料金テーブル４０７を参照して、従量レコード４０３に格納されたデータを用いた計算処理を行い、その処理結果を含むデータを格納した請求レコード４０４を出力する。
【００２１】
本実施の形態では、従量レコード４０３、及び請求レコード４０４はＸＭＬ（eXtensible Markup Language）で記述されたものを採用している。これは、ＸＭＬには、必要なタグを独自に定義して使うことができる、テキスト形式のデータである（内容を容易に見ることができる）、特定メーカーによる規格でない、といった利点を備えているためである。そのようなものを採用していることから、以降、従量レコード４０３は入力インスタンス、請求レコード４０４は出力インスタンスとも呼ぶことにする。
【００２２】
上記都道府県テーブル４０５は、例えば都道府県別に、そこに存在する区市町村の人口をテーブル形式で格納したものである。都市料金テーブル４０６は、顧客の住所に対応する区市町村の人口に応じた固定料金（都市料金）を課金するために、その人口に応じた料金の対応関係を定義したテーブルである。従量料金テーブル４０７は、従量が多いほど単価を安くするために、従量に応じた単価の対応関係を定義したテーブルである。請求レコード４０４にデータ（計算処理結果）として格納する請求額は、例えば基本料金（顧客の契約時に決まる料金）、従量に単価（従量に応じて従量料金テーブル４０７を参照して得られる単価）を掛けて得られる従量料金、及び顧客の住所によって決まる都市料金（都道府県テーブル４０５を参照して顧客が住む区市町村の人口を特定し、その特定した人口に応じて都市料金テーブル４０６を参照して求める料金）を加算して得られる合計金額に、契約時に規定された割引率を掛けて得たものである。
【００２３】
上記従量レコード４０３は、例えばレガシーシステム２０２、インターネット２０５に接続された、営業を行う社員が使用する端末装置、或いは業務部門２０３の端末装置から送信され、それを処理して出力する請求レコード４０４は、レガシーシステム２０２に送信される。それにより、レガシーシステム２０２は、アプリケーションサーバ３０２から受信した請求レコード４０４を処理して請求書の発行を行うようになっている。
【００２４】
このようにして、本実施の形態では、レガシーシステム２０２に従量レコード４０３を処理させて請求書を発行させるのではなく、その従量レコード４０３を計算ロジック部４０１が処理して得られる請求レコード４０４を処理させて請求書を発行させている。それにより、従量レコード４０３を２段階に分けて処理するようにさせている。
【００２５】
そのように処理を２段階に分けて行うようにすると、計算ロジック４０１に行わせる処理の内容を変更させることにより、新たに決定した割引サービスに対応できるようになる。新たに決定した割引サービスに対応するために、レガシーシステム２０２に実行させるアプリケーションを新たに用意する必要性は回避できるようになる。このため、新たな割引サービスが決定しても、即ちアプリケーションの仕様の変更が必要な状況となっても、新たにアプリケーションを用意する従来と比較して、より迅速、且つ容易に対応できることとなる。
【００２６】
マルチ言語展開部４０２は、従量レコード４０３から請求レコード４０４を生成するための仕様をそれぞれ定義したドキュメント４０８を参照して、その生成用の言語（以降、種類としての言語と区別するために「更新処理言語」と呼ぶ）を生成する。本実施の形態では、種類の異なる複数の更新処理言語を生成するようになっている。計算ロジック部４０１は、マルチ言語展開部４０２が生成した複数の更新処理言語のうちの一つに従い、従量レコード４０３から請求レコード４０４を生成する。
【００２７】
図５は、計算ロジック部４０１が動作する仕組みを説明する図である。
図５に示すように、マルチ言語展開部４０２は、複数の更新処理言語として、ＸＳＬＴ（eXtensible Style LanguageTransformation ）５０１、及びコンパイルして実行するソースコード５０２を生成する。ＸＳＬＴ５０１は、ＸＳＬＴエンジン５０３により処理（実行）され、ソースコード５０２は、コンパイルして得られるモジュール５０４にされて実行される。ソースコード５０２を生成するのは、そのモジュール５０４の実行速度はＸＳＬＴ５０１のそれと比較して高速であるためである。言い換えればより短時間に従量レコード（図５中では「入力インスタンス」と表記）４０３から請求レコード（図５中では「出力インスタンス」と表記）４０４を生成できるためである。ソースコード５０２を記述する言語としては、Ｊａｖａ、Ｃ、などといった様々な種類のものを採用することができる。その言語がＪａｖａであれば（マルチ言語展開部４０２がＪａｖａコード断片を生成するのであれば）モジュール５０４はバイトコードを経て変換されるネイティブコード（Ｊａｖａクラス）である。
【００２８】
モジュール５０４は、それが正しい動作を行うか否か確認した後に用いられる。ＸＳＬＴ５０１は、モジュール５０４と比較して、より容易に動作確認を行うことができる。例えば図１８に示すように、従量レコード４０３から生成した請求レコード４０４を表形式で表示するためのＸＳＬＴを用意した場合には、極めて迅速、且つ容易に動作確認を行うことができる。このようなことから、新たに決定した割引サービスにより迅速、且つ容易に対応できることとなる。そのように対応できることによって、その対応にかかるコストもより抑えられることとなる。
【００２９】
新たに作成したアプリケーションは、それがアップデートにより作成したとしても、全体的な動作確認を行う必要がある。しかし、そのアプリケーションの機能の一部を計算ロジック部４０１に行わせるようにすると、その一部を別のアプリケーションとして切り離した形となって、そのためにマルチ言語展開部４０２が生成するＸＳＬＴ５０１、及びソースコード５０２の規模は小さくなり、その機能は狭い範囲に限定されることになる。このため、たとえソースコード５０２だけを生成の対象にしたとしても、新たにアプリケーションを作成する場合と比較して、新たに決定した割引サービスに対してより迅速、容易、且つ低コストに対応できることとなる。アプリケーションを作成する側にとっては、機能の一部を削減する形となるため、その作成をより容易に行えるようになるという利点が得られることとなる。
【００３０】
計算ロジック部４０１は、ユーザプログラム５０５の制御下で動作する。そのユーザプログラム５０５は、従量レコード（入力インスタンス）４０３から請求レコード（出力インスタンス）４０４の生成用に開発したものであり、それを実行するデータ処理装置は特に限定されるものではない。つまり、アプリケーションサーバ３０２の他に、Ｗｅｂサーバ３０１、レガシーシステム２０２を構成するサーバ、業務部門２０３の端末装置、及びインターネット２０５と接続可能な端末装置（営業担当の社員が使う端末装置、など）の何れに実行させても良いものである。営業担当の社員が使う端末装置に実行させられるようにした場合には、その営業担当は現在、実施しているサービス、或いは実施が決定している次のサービスに合わせた提案を顧客に対して行えることとなる。
【００３１】
そのユーザプログラム５０５は、計算ロジック部４０１に処理させる従量レコード４０３を指定し、計算ロジック部４０１に実行させる対象（ここではＸＳＬＴ５０１、或いはモジュール５０４）を選択するためのルールラッパークラスを作り、それを呼び出す。呼び出されたルールラッパークラス５０６は、例えば環境設定値を参照して、ＸＳＬＴ５０１（動的駆動方式）及びモジュール５０４（静的駆動方式）のうちの何れか一方を計算ロジック部４０１に実行させる。それにより、環境設定値により指定されたものを用いて従量レコード４０３から請求レコード４０４を生成させ、その生成結果を取得するようになっている。
【００３２】
上記環境設定値は、新たに割引サービスが決定した直後はＸＳＬＴ５０１を指定するものであり、モジュール５０４の動作確認後は、それを指定するものに変更される。それにより、新たに決定した割引サービスの実施をより早い時点（短期間）で行えるように、モジュール５０４の動作確認後は、そのサービスの実施に伴う従量レコード４０３の処理をより迅速に行えるようにさせている。
【００３３】
以降は、上記ＸＳＬＴ５０１に注目して、それを生成するマルチ言語展開部４０２の動作、及びそれを実行する計算ロジック部４０１の動作について詳細に説明する。
図６は、ドキュメント４０８の構成を示す図である。
【００３４】
そのドキュメント４０８は、図６に示すように、ルール一覧定義部、マクロ定義部、共通部、及び項目仕様部から構成される。共通部は、タイトル部、及び共通変数記述部から構成され、項目仕様部は、ルール定義部、ルール内変数記述部、出力インスタンス記述部、及び項目仕様記述部から構成される。
【００３５】
ルール一覧定義部には、項目仕様部を構成するドキュメントを作成するうえでのインターフェースが記述される。マクロ定義部には、その作成に必要なマクロが定義される。それらは他のドキュメント４０８にも固定的に用いることができるものである。
【００３６】
共通部を構成するタイトル部には、ドキュメント４０８のタイトルや作成情報（作成日や作成者、など）が記述される。共通変数記述部には、従量レコード４０３から請求レコード４０４を生成するうえで共通に用いる変数の定義が記述される。
【００３７】
項目仕様部を構成するルール定義部には、ルール（項目仕様）の名称や、ＸＳＬＴ５０１を生成するうえでの実行方式の定義が記述される。ルール内変数記述部には、ルール定義部に記述されたルール内のローカル変数の定義が記述される。出力インスタンス部には、出力インスタンス（請求レコード）４０４の定義（タグやその属性、など）が記述される。項目仕様記述部には、項目別に、そのデータの変換仕様の内容が記述される。
【００３８】
ここで、図７に示すように、入力インスタンス（従量レコード）４０３から、「人口」タグの値を更新し、「unit」属性として“人”を追加し、「人口」タグの「year」属性を更新し、「research」属性を削除するという４つの変更点（１）〜（４）が存在する出力インスタンス（請求レコード）４０４を生成する場合を例にとって、上記ドキュメント４０８、ＸＳＬＴ５０１の生成方法、及びそのＸＳＬＴ５０１による出力インスタンス４０４の生成方法について詳細に説明する。
【００３９】
先ず、図７に示す出力インスタンス４０４を生成するためのＸＳＬＴ５０１用のドキュメント４０８について詳細に説明する。ここでは、図８、及び図９を参照して、項目仕様部を構成する各部についてのみ詳細に説明する。
【００４０】
図８、及び図９に示すように、ドキュメント４０８を構成する各部は、表の形で作成される。その形式は予め定めたものとしている。このため、その作成は、表を構成する欄のなかでデータ入力が必要な欄に入力すべきデータを入力する形で行うようになっている。
【００４１】
ルール定義部には、図８（ａ）に示すように、ルール名、実行方式、及び備考を記述する欄が設けられている。ここではルール名として「メインルール名」、実行方式として「通常出力（方式）」が記述されている。
【００４２】
ルール内変数記述部には、図８（ｂ）に示すように、区分、種別、ｇｅｔ使用、変数名、型、初期値、備考を記述する欄が設けられている。それら各欄において、「区分」欄は、その行が有効か否か指定するためのものであり、デフォルト（省略した場合）は有効である。これは他でも同様である。「種別」欄は、ローカル変数の種別を指定するためのものであり、デフォルトは通常変数である。「初期値」欄は、ローカル変数の初期値を指定するためのものである。
【００４３】
出力インスタンス部には、図８（ｃ）に示すように、区分、ｓｅｔ使用、タグ生成、対象インスタンス名、型、初期値、備考を記述する欄が設けられている。それら各欄において、「タグ生成」欄は、項目仕様（タグ名）全体を囲むタグを生成するか否か指定するためのものである。「○」或いは「×」を記述するか、或いは省略することで指定する。省略時は「○」を記述したと見なされる。「対象インスタンス名」欄は、出力の対象とするインスタンスをタグ名で指定するためのものである。その欄に記述された「県」は「県」タグで囲まれた部分が出力の対象になることを表している。
【００４４】
ルール定義部に設けられた「実行方式」欄には、上記「通常出力（方式）」以外に「差分更新（方式）」が記述される。通常出力方式は、出力インスタンス４０４の項目（ここではタグ名、或いは属性名が対応）毎に、そのデータ、或いはそのデータを得る処理方法を指定する方式である。他方の差分更新方式は、入力インスタンス４０３と出力インスタンス４０４間で異なる部分の処理方法のみを指定する方式である。つまり入力インスタンス４０３、或いは出力インスタンス４０４のみに存在する項目、或いはデータを更新（操作）する項目毎に、その処理方法のみを指定する方式である。このようなことから、項目仕様記述部には、図９（ａ）及び（ｂ）に示すように、指定された実行方式に応じてデータが記述される。
【００４５】
項目仕様記述部には、図９（ａ）及び（ｂ）に示すように、区分、項目名、操作、処理、及び条件１を記述する欄が設けられている。通常出力方式が指定された場合、項目名、処理の２つの欄がデータ入力必須となる。このとき、「項目名」欄は、出力インスタンス４０４を構成させる項目の名称の記述用となる。属性名は「＠unit」のように先頭に「＠」を付して記述するようにさせている。「処理」欄は、その項目のデータ、或いはそれを取得するための処理内容の記述用となる。「操作」欄の記述は無視される。「条件１」欄は、「処理」欄に内容が記述された処理を実行する条件の記述用であり、特に図示していないが、その記述用の欄は他にも存在する。
【００４６】
他方の差分更新方式が指定された場合には、項目名、及び操作の２つの欄がデータ入力必須となる。このとき、「項目名」欄は、入力インスタンス４０３、或いは出力インスタンス４０４のみに存在する項目の名称の記述用となり、「操作」欄は、その項目に対する操作の種別の記述用となる。その種別は、更新、追加、削除の３つである。更新は、項目のデータの更新を指示し、追加は、入力インスタンス４０３には無い項目を追加することを指示する。削除は、出力インスタンス４０４に含ませないために、入力インスタンス４０３に存在する項目の削除を指示する。このようなことから、「操作」欄に更新、或いは追加が記述された場合には、「処理」欄の記述は必須となる。
【００４７】
図９（ａ）に示す項目仕様記述部の「処理」欄に記述された「＄入力＿県」、「＄人口の変化」及び「＄年度の変化」のように「＄」が先頭に付された文字列は、ルール内変数記述部に記述されたローカル変数名である（図８（ｂ）参照）。例えば「＄入力＿県／人口＋＄人口の変化」は、「人口」タグのデータ（ここでは８８３８４５）にローカル変数「＄人口の変化」の値を加算する処理（計算式）を表している。ローカル変数「＄人口の変化」には「１０」が代入（図８（ｂ）参照）されている場合には、その加算結果は８８３８５５（＝８８３８４５＋１０）となる。これは他においても同様である。
【００４８】
図９（ｂ）に示す項目仕様記述部の「処理」欄に記述された「＄入力＿県／＃」、「＄入力＿県／人口／＃」のように「＄」が先頭、「＃」が最後に付された文字列は、入力インスタンス４０３の対応するデータを用いることを表している。例えば「＄入力＿県／人口／＃＋＄年度の変化」は、「項目名」欄の記述が「＠year」であることから、その値（ここでは１９９９）にローカル変数「＄年度の変化」の値を加算する処理（計算式）を表している。ローカル変数「＄年度の変化」に１が代入（図８（ｂ）参照）されている場合には、その加算結果は２０００（＝１９９９＋１）となる。これは他においても同様である。
【００４９】
通常出力方式では、出力インスタンス４０４に存在する全ての項目を項目仕様記述部に記述しなければならない。差分更新方式では、入出力インスタンス４０３、４０４間で異なる項目（変更点）だけを項目仕様記述部に記述すれば良い。このため、出力インスタンス４０４に存在する項目の数に比して変更点が少ない場合には、差分更新方式を選択することで項目仕様記述部、更にはドキュメント４０８をより容易に用意できることとなる。
【００５０】
その差分更新方式では、例えば図１０に示すように、入力インスタンス４０３に追加された「名産」タグを出力インスタンス４０４にも追加するのであれば、通常出力方式とは異なり、ドキュメント４０８を更新する必要はない。例えば図１１に示すように、入力インスタンス４０３のデータから人口密度を計算し、その計算結果を「人口密度」タグのデータとして出力インスタンス４０４に追加するのであれば、即ち入力インスタンス４０３と出力インスタンス４０４間に異なる点が生じたのであれば、差分更新方式、通常出力方式ともにドキュメント４０８（少なくとも項目仕様記述部）の更新が必要となる。
【００５１】
このようにして、本実施の形態では、生成するＸＳＬＴ５０１（ソースコード５０２を含む）の仕様を決定するデータを表形式で入力させるようにしている。その表形式でデータを入力させることで、生成に用いられる言語の仕様などはユーザが知らなくとも良い存在となり、その言語を知らない人もその言語で記述された更新処理言語（ここではＸＳＬＴ５０１やソースコード５０２）を生成させられるようになる。その言語を知っている人にとっても、その生成をより容易に行わせられるようになる。
【００５２】
次に、上記ドキュメント４０８を参照してＸＳＬＴ５０１を生成するマルチ言語展開部４０２、及びそのＸＳＬＴにより出力インスタンス４０４を生成する計算ロジック部４０１の動作について詳細に説明する。それらは、上述したように、アプリケーションサーバ３０２に搭載されたＣＰＵが、ハードディスク装置３０２ａに格納されたプログラムを実行することで実現される。
【００５３】
始めに、通常出力方式の場合のそれらの動作について図１２〜図１４を参照して詳細に説明する。
図１２は、通常出力方式におけるＸＳＬＴ生成処理のフローチャートである。通常出力方式では、始めに図１２を参照して、マルチ言語展開部４０２の動作について詳細に説明する。ここでは、項目仕様記述部（図９（ａ）参照）に着目して説明する。出力の対象として考慮するのは、出力インスタンス記述部（図８（ｃ）参照）の「対象インスタンス名」欄に名称が記述されたタグに囲まれた範囲である。
【００５４】
先ず、ステップＳ１１では、項目仕様記述部のなかで参照の対象とする行（最初は先頭の行である）を指定し、その行の「区分」欄の記述が有効であれば、その「項目名」欄に記述された内容をタグ（開始タグ）として生成する。続くステップＳ１２では、現在、参照している行の下の行の「項目名」欄に「＠」が付いた項目名がないか否か判定する。タグに持たせた属性データは、そのタグ名を項目名として「項目名」欄に記述した行の下に続けて記述するように決めている。このため、現在、参照している行に項目名として名称が記述されたタグが属性データを持っている場合、その行の下に続けてその属性データが記述されることから、判定はＹＥＳとなってステップＳ１３に移行する。そうでない場合には、判定はＮＯとなってステップＳ１５に移行する。
【００５５】
ステップＳ１３では、「<xsl:value-of>」タグ内のｓｅｌｅｃｔ属性（“”内に記述される）に、「処理」欄の処理内容を記述する形でそのタグ（要素）を生成し、ステップＳ１１で生成したタグの終了タグを生成し、その生成後に、「項目名」欄に「＠」が先頭の項目名が記述されていない行まで参照の対象とする行を移動させる。その後は、ステップＳ１４に移行して、参照の対象となる行がないか否か判定する。項目仕様記述部に参照すべき行が無くなった場合、参照の対象とする行まで移動させる間に行が無くなることから、判定はＹＥＳとなり、終了タグを生成していないタグの終了タグを生成した後、一連の処理を終了する。そうでない場合には、判定はＮＯとなって上記ステップＳ１１に戻り、参照の対象となる行を変えて、同様の処理を実行する。
【００５６】
例えば参照しているのが１行目であれば、ステップＳ１１では「＜名前＞」タグを生成し、ステップＳ１３では、「＜ｘｓｌ：ｖａｌｕｅ−ｏｆ  ｓｅｌｅｃｔ＝“＄入力＿県／名前”／＞」、及び「＜／名前＞」がその順序で生成されることになる。
【００５７】
上記ステップＳ１２の判定がＮＯとなって移行するステップＳ１５では、先頭に「＠」が付いた項目名では「<xsl:attribute> 」タグを生成し、そのname属性（“”内に記述される）に「＠」を除いた項目名を記述する。つまり例えば項目仕様記述部の４行目を参照しているのであれば「＜ｘｓｌ：ａｔｔｒｉｂｕｔｅ  ｎａｍｅ＝“ｕｎｉｔ”＞」タグを生成する。「処理」欄の内容は、「<xsl:value-of>」タグ内のｓｅｌｅｃｔ属性として記述する。つまり、続けて「＜ｘｓｌ：ｖａｌｕｅ−ｏｆ  ｓｅｌｅｃｔ＝“”ｓｑｋｍ“”／＞」タグを生成する。そのようなタグの生成は、「＠」が付いた項目名が記述された行数分、行う。そのようなことを行った後に、ステップＳ１３には移行する。
【００５８】
このようにして、通常出力方式における生成処理では、タグ（要素）単位でＸＳＬＴ５０１を生成していくようにしている。その生成処理を実行することにより、図１３に示すようなＸＳＬＴ５０１が生成される。
【００５９】
その図１３中では、図９（ａ）に示す項目仕様記述部の行（行番号は「No. 」欄に記述されている）との対応関係を示してある。１行目に対応する部分の上の部分は、ルール定義部、及びルール内変数記述部を参照して生成される。「＜ｘｓｌ：ｖａｒｉａｂｌｅ  ｎａｍｅ＝“入力＿県”ｓｅｌｅｃｔ＝“ｃｕｒｒｅｎｔ（）”／＞」、「＜ｘｓｌ：ｖａｒｉａｂｌｅ  ｎａｍｅ＝“年度の変化”ｓｅｌｅｃｔ＝“ｎｕｍｂｅｒ（１）”／＞」、及び「＜ｘｓｌ：ｖａｒｉａｂｌｅ  ｎａｍｅ＝“人口の変化”ｓｅｌｅｃｔ＝“ｎｕｍｂｅｒ（１０）”／＞」はルール内変数記述部の１〜３行目の記述によって生成されたものである。
【００６０】
上述したようにして生成されたＸＳＬＴ５０１をマルチ言語展開部４０１から受け取った計算ロジック部４０１は、図１４に示す入力インスタンス更新処理を実行することにより、入力インスタンス４０３を更新する形で出力インスタンス４０４を生成する。次に図１４を参照して、その更新処理について詳細に説明する。
【００６１】
先ず、ステップＳ２１では、出力インスタンス４０４の「名前」タグの値（データ）として入力インスタンス４０３の「名前」タグの値を取得する。以降、同様に、出力インスタンス４０４の「都市」タグの値（データ）として入力インスタンス４０３の「都市」タグの値を、出力インスタンス４０４の「面積」タグの値（データ）として入力インスタンス４０３の「面積」タグの値を、出力インスタンス４０４の「名前」タグが持つunit属性の値（データ）として入力インスタンス４０３の「名前」タグが持つunit属性の値を、それぞれ取得する（ステップＳ２２〜Ｓ２４）。その後はステップＳ２５に移行する。
【００６２】
ステップＳ２５では、出力インスタンス４０４の「人口」タグの値（データ）として、入力インスタンス４０３の「人口」タグの値にローカル変数「人口の変化」の値を加算した値を取得する。次のステップＳ２６では、出力インスタンス４０４の「人口」タグにunit属性を追加し、その属性値として「人」を設定する。その次のステップＳ２７では、出力インスタンス４０４の「人口」タグが持つyear属性の値として、入力インスタンス４０３の「人口」タグが持つyear属性の値にローカル変数「年度の変化」の値を加算した値を設定する。それを設定すると、ステップＳ２８に移行して、ステップＳ２１〜Ｓ２７の各処理結果を出力する形で出力インスタンス（図中「ｏｕｔｐｕｔ．ｘｍｌ」と表記）４０４を生成した後、一連の処理を終了する。
【００６３】
上記更新処理を実行することにより、計算ロジック部４０１は図７に示す入力インスタンス４０３を入力して、図７に示す出力インスタンス４０４を生成し出力することになる。
【００６４】
次に差分更新方式の場合のマルチ言語展開部４０２、及び計算ロジック部４０１の動作について、図１５〜図１７を参照して詳細に説明する。
図１５は、差分更新方式におけるＸＳＬＴ生成処理のフローチャートである。差分更新方式でも通常出力方式と同じく、始めに図１５を参照して、マルチ言語展開部４０２の動作について詳細に説明する。
【００６５】
上述したように、差分更新方式では、入出力インスタンス４０３、４０４間で異なる部分（変更点）だけを項目仕様記述部に記述する。このことから、先ず、ステップＳ３１では、項目仕様記述部に記述されていない項目を全て出力インスタンス４０４にコピーするためのＸＳＬＴの記述を生成する。続くステップＳ３２では、項目仕様記述部のなかで参照の対象とする行（最初は先頭の行である）を指定し、その行の「区分」欄の記述が有効であれば、「<xsl:template match=“”> 」の“”内にその「項目名」欄の内容を記述したタグを生成する。それ以外には、ルール内変数記述部を参照して、ローカル変数を定義するＸＳＬＴを記述し、更には「<xsl:copy>」タグを生成する。ステップＳ３３には、その後に移行する。
【００６６】
ステップＳ３３では、現在、参照している行より下の行の「項目名」欄に、同じタグで「＠」が付いた項目名がないか否か判定する。現在、参照している行の「項目名」欄に項目名として名称が記述されたタグの持つ属性データを変更するような場合、判定はＮＯとなってステップＳ３６に移行する。そうでない場合には、即ちタグのデータだけを変更する場合には、判定はＹＥＳとなってステップＳ３４に移行する。
【００６７】
ステップＳ３４では、「操作」欄の記述に応じて、「<xsl:value-of>」タグ内のｓｅｌｅｃｔ属性（“”内に記述される）に、「処理」欄の処理内容を記述する形でそのタグ（要素）を生成し、ステップＳ３２で生成したタグの終了タグを生成し、その生成後に、他のタグの名称が「項目名」欄にされている行まで参照の対象とする行を移動させる。その後は、ステップＳ３５に移行して、参照の対象となる行がないか否か判定する。項目仕様記述部に参照すべき行が無くなった場合、参照の対象とする行まで移動させる間に行が無くなることから、判定はＹＥＳとなり、終了タグを生成していないタグの終了タグを生成した後、一連の処理を終了する。そうでない場合には、判定はＮＯとなって上記ステップＳ３２に戻り、参照の対象となる行を変えて、同様の処理を実行する。
【００６８】
上記ステップＳ３３の判定がＮＯとなって移行するステップＳ３６では、参照する行をその下に移動させて、「<xsl:apply-templates select=“@*”> 」タグを生成する。続くステップＳ３７では、参照している行の「操作」欄の記述が「追加」でないか否か判定する。その記述が「追加」でなかった場合、判定はＹＥＳとなってステップＳ３８に移行し、「操作」欄の記述（ここでは更新、或いは削除、である）に応じたＸＳＬＴの記述を後に行うことを決定した後、ステップＳ３４に移行する。そうでない場合には、判定はＮＯとなってステップＳ３９に移行し、項目追加用の「<xsl:value-of>」タグを生成した後、ステップＳ３４に移行する。
【００６９】
ステップＳ３８でＸＳＬＴの記述を後に行うことを決定していた場合、ステップＳ３５の判定がＹＥＳとなると、その記述を行った後に一連の処理を終了する。それにより、記述すべきＸＳＬＴを全て記述するようになっている。
【００７０】
図１５は、上記更新処理を実行することで生成されるＸＳＬＴ５０１を示す図である。
図１５に示すように、同一のタグ内でデータの他に追加、或いは更新する属性が存在している場合、そのための記述は同じ「＜ｘｓｌ：ｔｅｍｐｌａｔｅ＞」タグ内で行われる。タグの持つ属性だけを更新、或いは削除するような場合には、そのための記述はそれぞれ一つの「＜ｘｓｌ：ｔｅｍｐｌａｔｅ＞」タグ内で行われる。そのタグの記述は、ステップＳ３５の判定がＹＥＳとなって生成されるものである。更新では、「<xsl:value-of>」タグが生成されるが、削除ではそのようなタグは生成されない。
【００７１】
上述したようにして生成されたＸＳＬＴ５０１をマルチ言語展開部４０１から受け取った計算ロジック部４０１は、図１７に示す入力インスタンス更新処理を実行することにより、入力インスタンス４０３を更新する形で出力インスタンス４０４を生成する。次に図１７を参照して、その更新処理について詳細に説明する。
【００７２】
先ず、ステップＳ４１では、入力インスタンス４０３をコピーした後、入力インスタンス４０３内の「人口」タグを検索し、その検索によりそのタグを抽出できたか否か判定する。そのタグを抽出できた場合、判定はＹＥＳとなってステップＳ４２に移行する。そうでない場合には、判定はＮＯとなってステップＳ４６に移行する。
【００７３】
ステップＳ４２では、出力インスタンス４０４の「人口」タグの値（データ）として、入力インスタンス４０３の「人口」タグの値にローカル変数「人口の変化」の値を加算した値を取得する。次のステップＳ４３では、出力インスタンス４０４の「人口」タグにunit属性を追加し、その属性値として「人」を設定する。その次に移行するステップＳ４４では、入力インスタンス４０３の「人口」タグにyear属性があるか否か判定する。その属性が存在していた場合、判定はＹＥＳとなってステップＳ４５に移行する。そうでない場合には、判定はＮＯとなってステップＳ４６に移行する。
【００７４】
ステップＳ４５では、出力インスタンス４０４の「人口」タグが持つyear属性の値として、入力インスタンス４０３の「人口」タグが持つyear属性の値にローカル変数「年度の変化」の値を加算した値を設定し、ｒｅｓｅａｒｃｈ属性を削除する。そのようなことを行うと、ステップＳ４６に移行し、コピーした入力インスタンス４０３にステップＳ４２、Ｓ４３、及びＳ４５の処理結果を反映させる形で出力インスタンス（図中「ｏｕｔｐｕｔ．ｘｍｌ」と表記）４０４を生成した後、一連の処理を終了する。ステップＳ４１、或いはＳ４４からステップＳ４６に移行した場合には、コピーした入力インスタンス４０３、或いはその入力インスタンス４０３にステップＳ４２、及びＳ４３の処理結果を反映させたものを出力インスタンス４０４として生成することになる。
【００７５】
なお、本実施の形態では、計算ロジック部（データ更新装置）４０１、及びマルチ言語展開部（言語展開装置）４０２を同じアプリケーションサーバ３０２（データ処理装置）上で実現させているが、異なるデータ処理装置上で実現させても良い。入力インスタンス（従量レコード）４０３は、レガシーシステム２０２に渡す前に計算ロジック部４０１に処理させているが、その処理の内容によっては、それを複数に分割しても良い。つまり、計算ロジック部４０１のようなものを複数、用意して、それらにそれぞれ割り当てた処理を行わせるようにしても良い。
【００７６】
上述したようなアプリケーションサーバ３０２の動作、或いはその変形例の動作を実現させるようなプログラム（データ更新プログラム）は、ＣＤ−ＲＯＭ、ＤＶＤ、或いは光磁気ディスク等の記録媒体に記録させて配布しても良い。或いは、公衆網等で用いられる伝送媒体を介して、そのプログラムの一部、若しくは全部を配信するようにしても良い。そのようにした場合には、ユーザはプログラムを取得してコンピュータなどのデータ処理装置にロードすることにより、そのデータ処理装置を用いて本発明を適用させたデータ更新装置、或いは言語展開装置を実現させることができる。このことから、記録媒体は、プログラムを配信する装置がアクセスできるものであっても良い。
【図面の簡単な説明】
【００７７】
【図１】本発明の原理図である。
【図２】本実施の形態による言語展開装置、及びデータ更新装置が適用されたネットワークシステムの構成を示す図である。
【図３】Ｗｅｂシステムの構成を示す図である。
【図４】アプリケーションサーバの機能構成を示す図である。
【図５】計算ロジック部が動作する仕組みを説明する図である。
【図６】ドキュメントの構成を示す図である。
【図７】入力インスタンスと出力インスタンス例を示す図である。
【図８】ドキュメントを構成する各部を説明する図である。
【図９】ドキュメントを構成する項目仕様記述部を説明する図である。
【図１０】仕様変更における対処法の違いを説明する図である（その１）。
【図１１】仕様変更における対処法の違いを説明する図である（その２）。
【図１２】ＸＳＬＴ生成処理のフローチャートである（通常出力方式）。
【図１３】通常出力方式で生成されたＸＳＬＴを示す図である。
【図１４】入力インスタンス更新処理のフローチャートである（通常出力方式）。
【図１５】ＸＳＬＴ生成処理のフローチャートである（差分更新方式）。
【図１６】差分更新方式で生成されたＸＳＬＴを示す図である。
【図１７】入力インスタンス更新処理のフローチャートである（差分更新方式）。
【図１８】出力インスタンスの表示方法を説明する図である。
【符号の説明】
【００７８】
１    入力データ
２    出力データ
３    アプリケーション・プログラム
２０    言語展開装置
２１    仕様データ取得部
２２    言語生成部
２３    言語
２４    仕様データ
３０    データ更新装置
３１    入力データ取得部
３２    データ更新部
３０２    アプリケーションサーバ
３０２ａ    ハードディスク装置
４０１    計算ロジック部
４０２    マルチ言語展開部
４０３    従量レコード（入力インスタンス）
４０４    請求レコード（出力インスタンス）
４０８    ドキュメント
５０１    ＸＳＬＴ
５０２    ソースコード
５０３    ＸＳＬＴエンジン
５０４    モジュール
【図１】
2007172645.tif 000003
【図２】
2007172645.tif 000004
【図３】
2007172645.tif 000005
【図４】
2007172645.tif 000006
【図５】
2007172645.tif 000007
【図６】
2007172645.tif 000008
【図７】
2007172645.tif 000009
【図８】
2007172645.tif 000010
【図９】
2007172645.tif 000011
【図１０】
2007172645.tif 000012
【図１１】
2007172645.tif 000013
【図１２】
2007172645.tif 000014
【図１３】
2007172645.tif 000015
【図１４】
2007172645.tif 000016
【図１５】
2007172645.tif 000017
【図１６】
2007172645.tif 000018
【図１７】
2007172645.tif 000019
【図１８】
2007172645.tif 000020