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