(57)【要約】【課題】プロパティファイルの設定内容を  Ｊａｖａ（登録商標）アプリケーションプログラムで利用する場合における手順を統一化すると共にアプリケーション固有の機能を独自に実装できるようにする。【解決手段】設定ファイル分析機能２０３により、プロパティファイル２０６を分析し、プロパティファイル２０６中の設定値より、どの設定オブジェクトを生成するのかを決定し、この決定に基づき、設定オブジェクト生成機能２０４により、当該設定オブジェクト２０７を生成し、生成した設定オブジェクト２０７に対して、プロパティファイル２０６中の設定値を、ルールに則り格納することで、設定オブジェクト２０７の内容は、プロパティファイル２０６と同じ状態になり、さらに、設定ファイル検証機能２０５により、当該設定オブジェクト２０７の内容に対して、アプリケーション固有の機能を実装させ、呼び出し元の業務プログラムＡ２０２に引き渡す。【選択図】図２
2010079400.tif 000002
【特許請求の範囲】
【請求項１】
プログラムされたコンピュータ処理によって、呼び出し元の Java（登録商標）アプリケーションのプロパティファイルを読み込み、該プロパティファイルの各設定項目とその設定値を呼び出し元の Java（登録商標）アプリケーションに引き渡すシステムであって、
プログラムされたコンピュータ処理を実行する手段として、
複数の Java（登録商標）アプリケーションが共通に利用する設定項目と設定値をテキストで記述したプロパティファイルを記憶装置に記憶する記憶処理手段と、
呼び出し元の Java（登録商標）アプリケーションが利用するプロパティファイルを読み出し、該プロパティファイルにおける各設定項目と各設定項目の設定値を抽出するファイル分析手段と、
該ファイル分析手段が抽出した当該プロパティファイルの設定項目と設定値を格納する第１の設定オブジェクトを生成する設定オブジェクト生成手段と、
該設定オブジェクト生成手段が生成した第１の設定オブジェクトを読み込み、該第１の設定オブジェクトに格納された設定項目と設定値に対する上記呼び出し元の Java（登録商標）アプリケーション固有の検証を行うファイル検証手段と
を有し、
上記ファイル検証手段での検証結果に応じて、上記第１の設定オブジェクトに格納された当該プロパティファイルの設定項目と設定値の上記呼び出し元の Java（登録商標）アプリケーションへの引き渡しを制御することを特徴とするプロパティファイル読み込みシステム。
【請求項２】
請求項１に記載のプロパティファイル読み込みシステムであって、
上記記憶処理手段が記憶するプロパティファイルは、当該プロパティファイルに対して生成される上記第１の設定オブジェクトの生成に用いる第２の設定オブジェクトを指定する設定項目と設定値を含み、
上記設定オブジェクト生成手段は、
上記プロパティファイルに含まれる設定項目と設定値で指定される第２の設定オブジェクトを利用して、上記第１の設定オブジェクトを生成する
ことを特徴とするプロパティファイル読み込みシステム。
【請求項３】
請求項２に記載のプロパティファイル読み込みシステムであって、
上記設定オブジェクト生成手段は、
上記ファイル分析手段が抽出した当該プロパティファイルの設定項目に対応する設定値の入出力に用いる入力用アクセサメソッドと出力用アクセサメソッドを、上記第２の設定オブジェクトから抽出して上記第１の設定オブジェクトに格納すると共に、格納した入力用アクセサメソッドで入力される当該プロパティファイルの設定値を上記第１の設定オブジェクトに格納する
ことを特徴とするプロパティファイル読み込みシステム。
【請求項４】
請求項３に記載のプロパティファイル読み込みシステムであって、
上記ファイル分析手段が抽出した当該プロパティファイルの設定項目と、上記第２の設定オブジェクトに格納される入力用アクセサメソッドと出力用アクセサメソッドのそれぞれの名称は、予め定められた変換ルールで対応付けられており、
上記設定オブジェクト生成手段は、
上記ファイル分析手段が抽出した当該プロパティファイルの設定項目に上記予め定められた変換ルールで対応付けられた入力用アクセサメソッドと出力用アクセサメソッドを上記第２の設定オブジェクトから抽出する
ことを特徴とするプロパティファイル読み込みシステム。
【請求項５】
請求項３もしくは請求項４のいずれかに記載のプロパティファイル読み込みシステムであって、
上記ファイル検証手段は、
上記設定オブジェクト生成手段が生成した上記第１の設定オブジェクトを読み込み、
該第１の設定オブジェクトに格納された出力用アクセサメソッドを用いて該第１の設定オブジェクトに格納されている設定値を取得し、
取得した設定値を用いて、上記呼び出し元の Java（登録商標）アプリケーション固有の検証を行う
ことを特徴とするプロパティファイル読み込みシステム。
【請求項６】
プログラムされたコンピュータ処理によって、呼び出し元の Java（登録商標）アプリケーションのプロパティファイルを読み込み、該プロパティファイルの各設定項目とその設定値を呼び出し元の Java（登録商標）アプリケーションに引き渡すシステムのプロパティファイル読み込み方法であって、
プログラムされたコンピュータ処理手順として、請求項１から請求項５のいずれかに記載のプロパティファイル読み込みシステムにおける各手段が実行する処理手順を含み、
該各手段の処理手順により、
呼び出し元の Java（登録商標）アプリケーションへのプロパティファイルの各設定項目とその設定値の引き渡し制御を行うことを特徴とするプロパティファイル読み込み方法。
【請求項７】
コンピュータを、請求項１から請求項５のいずれかに記載のプロパティファイル読み込みシステムにおける各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、 Java（登録商標）アプリケーションプログラムで利用するプロパティファイルの情報（設定内容）を読み込む技術に係り、特に、プロパティファイルの設定内容をプログラムで利用する場合における手順を統一化すると共に、アプリケーション固有の機能を独自に実装することができる技術に関するものである。
【背景技術】
【０００２】
一般的に、 Java（登録商標）アプリケーションソフトウェア（プログラム）を開発する時には、動作環境に関する設定情報（例：データベースのＩＤやパスワード）や、利用者ごとの設定情報（例：利用者のメールアドレス等）をプロパティファイルに記載し、開発した当該プログラムの開始時に、プロパティファイルの情報を読み込み、各種の設定内容を自動的に取り込むことで当該プログラムが動作する。
【０００３】
このように、プロパティファイルに設定情報を記載することで、ソースコードから、動作環境に依存する設定を外部で管理できるようになる。また、プロパティファイルは単純なテキストファイルである為に、エンドユーザであっても利用できるという利点があり、広く利用されている。
【０００４】
従来の Java（登録商標）アプリケーション開発におけるプロパティファイルの情報を取り込む技術としては次の（１）、（２）の技術がある。
【０００５】
（１）最も一般的な手段として、Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ（登録商標）社が標準として公開している、コンピュータを制御する為のプログラムの手続き群である Java（登録商標）標準ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を利用して、任意のロジックにより、プロパティファイルの内容を取得する技術がある。
【０００６】
（２）プロパティファイルの定義書から自動的にソースコードを生成することによりプロパティファイルの内容を取得する技術がある。この技術の代表的なものとしては、例えば、非特許文献１〜３に記載されている、オープンソースソフトウェアであるｂｌａｎｃｏ  ＦｒａｍｅｗｏｒｋのｂｌａｎｃｏＲｅｓｏｕｒｃｅＢｕｎｄｌｅがある。
【０００７】
しかしながら、アプリケーション（プログラム）が大規模であったり、機能追加を繰り返すことにより、プロパティファイル中の設定項目が増える。このため、管理可能な単位に複数のプロパティファイルが定義される。このことにより、次の（Ａ）と（Ｂ）の問題点が指摘できる。
【０００８】
（Ａ）複数のプロパティファイルが定義された場合には、プロパティファイルの内容を読み込み、設定内容を取り込むプログラムも、各プロパティフィアル毎に複数必要になる。一般的には、設定ファイルの種類が増える毎に、 Java（登録商標）標準ＡＰＩを用いて当該設定ファイルの内容を取り込むプログラムが作成されることになる。
【０００９】
このように複数のプログラムが作成されてしまうことで、その後の保守の煩雑さや、アプリケーションの統一感の欠如といった問題を招くことになる。このような問題に対しては、人間の努力（人手）による手順のルール化・共通化が必要となる。
【００１０】
（Ｂ） Java（登録商標）標準ＡＰＩの欠陥は、汎用性がある為にルール化されないという点にある。この問題を解決する技術として、例えば、上述の非特許文献１〜３に挙げたプロパティファイルの設定内容を取り込むことができるソースコードを自動的に生成するという技術がある。
【００１１】
しかし、このようなソースコードの自動生成については問題点があり、代表的な問題点としては次の（Ｂ−１）、（Ｂ−２）の点が挙げられる。
【００１２】
（Ｂ−１）自動生成されたソースプログラムに修正を加えると、再度、自動生成が必要になった時に、修正した箇所についての見直しが必要となる。
【００１３】
（Ｂ−２）上記の（Ｂ−１）問題を解決するには、ソースコードの自動生成に対してアプリケーション固有の機能を実装する必要があり、ソースコードの自動生成を行う機能を追加するコストが必要である。さらに、機能追加や機能変更に関しては、再度、ソースコードの自動生成が必要となる。
【００１４】
【非特許文献１】ｂｌａｎｃｏＲｅｓｏｕｒｃｅＢｕｎｃｌｅ  ［平成２０年９月９日検索］、インターネット＜ＵＲＬ  ：  ｈｔｔｐ：／／ｗｗｗ．ｉｇａｐｙｏｎ．ｊｐ／ｂｌａｎｃｏ／ｂｌａｎｃｏｒｅｓｏｕｒｃｅｂｕｎｄｌｅ．ｈｔｍｌ
【非特許文献２】株式会社ＮＴＴデータビジネスブレインズ  オープンソリューション  ［平成２０年９月９日検索］、インターネット＜ＵＲＬ  ：  ｈｔｔｐ：／／ｗｗｗ．ｎｔｔｄ−ｂｂ．ｃｏｍ／ｓｏｌｕｔｉｏｎ／ｏｐｅｎ−ｓｏｕｒｃｅ．ｈｔｍｌ
【非特許文献３】ＳｏｕｒｃｅＦｏｒｇｅ．ＪＰ  ｂｌａｎｃｏ  Ｆｒａｍｅｗｏｒｋ  ［平成２０年９月９日検索］、インターネット＜ＵＲＬ  ：  ｈｔｔｐ：／／ｓｏｕｒｃｅｆｏｒｇｅ．ｊｐ／ｐｒｏｊｅｃｔｓ／ｂｌａｎｃｏｆｗ／
【発明の開示】
【発明が解決しようとする課題】
【００１５】
解決しようとする問題点は、従来の技術では、複数のプロパティファイルが定義された場合には、各プロパティファイルの設定内容を取り込むための Java（登録商標）標準ＡＰＩを用いたプログラムも複数必要となり、その後の保守の煩雑さや、アプリケーションの統一感の欠如といった問題を招くことになり、このような問題に対しては、人間の努力（人手）による手順のルール化・共通化が必要となる点と、 Java（登録商標）標準ＡＰＩの欠陥（汎用性がある為にルール化されないという点）を解決するために、プロパティファイルの設定内容を取り込むことができるソースコードを自動的に生成する従来技術では、（Ｂ−１）自動生成されたソースプログラムに修正を加えると、再度、自動生成が必要になった時に、修正した箇所についての見直しが必要となると共に、（Ｂ−２）上記の（Ｂ−１）問題を解決するには、ソースコードの自動生成に対してアプリケーション固有の機能を実装する必要があり、ソースコードの自動生成を行う機能を追加するコストが必要であり、さらに、機能追加や機能変更に関しては、再度、ソースコードの自動生成が必要となる点である。
【００１６】
本発明の目的は、これら従来技術の課題を解決し、プロパティファイルの設定内容を JAVA（登録商標）アプリケーションプログラムで利用する場合において、手順を統一化する機能とアプリケーション固有の機能を独自に実装できるプログラムを提供することである。
【課題を解決するための手段】
【００１７】
上記目的を達成するため、本発明では、分析機能により、プロパティファイルを分析し、プロパティファイル中の設定値より、どの設定オブジェクトを生成するのかを決定し、この決定に基づき、設定オブジェクト生成機能により、当該設定オブジェクトを生成し、生成した設定オブジェクトに対して、プロパティファイル中の設定値を、ルールに則り格納する。この時点で、設定オブジェクトの内容は、プロパティファイルと同じ状態になる。本発明では、さらに、設定ファイル検証機能により、当該設定オブジェクトの内容に対して、アプリケーション固有の機能を実装する。このようにして、検証を終えて、固有機能を実装した設定オブジェクトは、業務ロジックを担当するモジュールに引き渡され、当該業務ロジックにおいて、プロパティファイルの設定内容が利用可能となる。
【発明の効果】
【００１８】
本発明をアプリケーションプログラム開発の初期工程から採用することにより次の効果が期待できる。
（１）設定ファイルオブジェクト生成プログラムは、共通部品的な性格を持つことから、プロパティファイルの読み込みロジックを統一でき、プログラマが Java（登録商標）標準ＡＰＩを利用せずに、簡単に、プロパティファイルの内容を取り込むことができるようになる。簡単に利用できるということは、ソースコード量を削減し、煩雑さを解消するという効果がある。
（２）生成される設定ファイルオブジェクトに対して検証を行う機能を有しており、拡張可能な形で提供する為に、アプリケーション固有の機能を実装することが可能である。これは、ソースコードの自動生成で問題となる自動生成後のソースコードに対する機能追加や、自動生成のロジック修正に関する問題点を解消する。
（３）副次的効果も得られる。すなわち、プロパティファイルと設定オブジェクトは１対１の関係になるので、プロパティファイルの設定内容が何処に利用されるかを追跡するのがたやすくなる。一般的に、オブジェクト化されたものを追跡するのは容易であるが、 Java（登録商標）標準ＡＰＩを利用してプロパティファイルの設定を取り込んだ場合には、何処のオブジェクトで管理されるのかは不定である。
【発明を実施するための最良の形態】
【００１９】
以下、図を用いて本発明を実施するための最良の形態例を説明する。図１は、本発明に係る設定ファイル取り込みシステムを具備したサーバコンピュータ装置の構成例を示すブロック図であり、図２は、本発明に係る設定ファイル取り込みシステムの構成例を示すブロック図、図３は、図２における設定ファイル分析機能と設定オブジェクト生成機能の処理動作例を示すフローチャート、図４は、図２における設定ファイル検証機能の処理動作例を示すフローチャート、図５は、図２におけるプロパティファイルの構成例を示す説明図、図６は、図２における設定オブジェクトのクラスの具体例を示す説明図、図７は、図２における設定オブジェクトのアクセサメソッドと設定内容の具体例を示す説明図である。
【００２０】
図１において、１０１は本発明に係る設定ファイル取り込みシステムを具備したサーバコンピュータ装置（図中「サーバ」と記載）、１０２はネットワークを介してサーバコンピュータ装置１０１にアクセスするクライアントコンピュータ装置（図中「クライアント」と記載）であり、サーバコンピュータ装置１０１とクライアントコンピュータ装置１０２のそれぞれは、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）や主メモリ、表示装置、入力装置、外部記憶装置を具備し、光ディスク駆動装置等を介してＣＤ−ＲＯＭ等の記憶媒体に記録されたプログラムやデータを外部記憶装置内にインストールした後、この外部記憶装置から主メモリに読み込みＣＰＵで処理することにより、業務プログラムＡ処理部１０３、業務プログラムＢ処理部１０４、業務プログラムＣ処理部１０５、設定ファイル取り込みプログラム処理部１０７等によるプログラムされたコンピュータ処理を実行する。
【００２１】
クライアントコンピュータ装置１０２は、サーバコンピュータ装置１０１上の業務プログラムＡ処理部１０３より何らかの実行結果を受け取るものである。本例では、このクライアントコンピュータ装置の形態は特定する必要がない。例えば、業務プログラムＡ処理部１０３がＷＥＢアプリケーションプログラムを実行する場合は、クライアントコンピュータ装置１０２はＷＥＢブラウザとなる。
【００２２】
サーバコンピュータ装置１０１における業務プログラムＡ処理部１０３は、処理内容のそれぞれ異なる業務プログラムＢ処理部１０４と業務プログラムＣ処理部１０５の設定ファイルであるプロパティファイル１０６を共有する別々のロジックが実装されたプログラムである。
【００２３】
これらは、設定ファイル取り込みプログラム処理部１０７を介して、プロパティファイル１０６の設定内容を利用する。
【００２４】
設定ファイル取り込みプログラム処理部１０７は、図２において、設定ファイル取り込みプログラム処理部２０１として示され、以下、この図２を用いて、設定ファイル取り込みプログラム処理部２０１（１０７）の処理動作について説明する。
【００２５】
図２においては、設定ファイル取り込みプログラム処理部２０１の内部構成と共に、この設定ファイル取り込みプログラム処理部２０１と、業務プログラムＡ処理部２０２およびプロパティファイル２０６間でのデータの流れを示している。
【００２６】
図２に示すように、設定ファイル取り込みプログラム処理部２０１は、設定ファイル分析機能２０３と、設定オブジェクト生成機能２０４、設定ファイル検証機能２０５を具備している。
【００２７】
設定ファイル分析機能２０３は、業務プログラムＡ処理部２０２が利用する設定オブジェクト２０７に必要な情報を、プロパティファイル２０６を解析して求めてメモリ２０８に展開する。
【００２８】
設定オブジェクト生成機能２０４は、設定オブジェクト２０７に必要な情報をメモリ２０８から取り込み、設定オブジェクト２０７を生成する。
【００２９】
設定ファイル検証機能２０５は、設定オブジェクト生成機能２０４が生成した設定オブジェクト２０７を読み込み、設定内容に対して業務プログラムＡ処理部２０２が実行するアプリケーションプログラムに固有の検証作業を行う。
【００３０】
この設定ファイル検証機能２０５による検証作業の結果に問題が無い場合、業務プログラムＡ処理部２０２は、設定オブジェクト２０７を利用できるようになる。
【００３１】
設定ファイル取り込みプログラム処理部２０１は、外部の業務プログラムＡ処理部２０２からの処理呼出（Ｓ１）があると、まず、設定ファイル分析機能２０３を起動して、プロパティファイル２０６からの情報の読み込み（Ｓ２）を実行し、読み込んだ情報を分析して結果をメモリ２０８に出力する（メモリ出力（Ｓ３））。
【００３２】
次に設定ファイル取り込みプログラム処理部２０１は、設定オブジェクト生成機能を起動して、メモリ２０８からの情報の読み込み（Ｓ４）を実行し、当該情報を用いて設定オブジェクト２０７の生成（Ｓ５）を行い、その後、設定ファイル検証機能２０５を起動して、設定オブジェクト２０７に対する検証（Ｓ６）を実行する。
【００３３】
以下、このような設定ファイル取り込みプログラム処理部２０１における設定ファイル分析機能２０３と設定オブジェクト生成機能２０４の処理動作例を、図３を用いて説明する。
【００３４】
図３において、設定ファイル分析機能２０３と設定オブジェクト生成機能２０４からなる設定ファイル取り込みプログラム処理部２０１の処理起動契機は、外部の業務プログラムＡ処理部２０２からの処理呼出（Ｓ１）であり、この業務プログラムＡ処理部２０２から呼び出されることにより設定ファイル取り込みプログラム処理部２０１は処理を開始する（ステップＳ３０１）。
【００３５】
設定ファイル分析機能２０３は、まず、業務プログラムＡ処理部２０２が必要とするプロパティファイル２０６を読み込む（ステップＳ３０２）。
【００３６】
プロパティファイル２０６自身は、図５におけるファイルイメージ５０１として示すように、単純なテキストファイルであり、行の先頭が「＃」である場合と、何も記述が無い行に関しては無視される為、処理には影響はない。尚、図５におけるファイルイメージ５０１のプロパティファイルのサンプル設定内容を、表形式に表現したのが図５における表形式５０２である。
【００３７】
次に、設定ファイル分析機能２０３は、読み込んだプロパティファイル２０６の解析を行い、設定一覧を作成してメモリ２０８に格納する（ステップＳ３０３）。この処理は、プロパティファイル２０６の状態を、設定項目と設定値の対応表としてメモリ２０８上に展開することであり、対応表を可視化すると図５における表形式５０２に示す内容と同等である。
【００３８】
図５の表形式５０２における設定項目の「ｃｏｎｆｉｇ．ｂｅａｎ」は、利用する設定オブジェクトのＦＱＣＮ（Ｆｕｌｌｙ  Ｑｕａｌｉｆｉｅｄ  Ｃｌａｓｓ  Ｎａｍｅ）を指し、本例ではオブジェクト「ｓａｍｐｌｅ．ＣｏｎｆｉｇＢｅａｎ」を利用することになる。
【００３９】
尚、ＦＱＣＮとは、完全修飾クラス名のことであり、 Java（登録商標）の世界で唯一のオブジェクト名を指すことが可能な記述方法のことである。本来、ＦＱＣＮはドメイン名を指定する必要があるが、ここでは簡易表現の為に省略している。
【００４０】
次に、設定オブジェクト生成機能２０４の処理に移り、この設定オブジェクト生成機能２０４は、まず、図５の表形式５０２において設定項目「ｃｏｎｆｉｇ．ｂｅａｎ」に対する設定値として指定されているオブジェクト「ｓａｍｐｌｅ．ＣｏｎｆｉｇＢｅａｎ」から、設定オブジェクト２０７に格納できる入力用アクセサメソッド（Ａｃｃｅｓｓｏｒ  Ｍｅｔｈｏｄ）一覧を構築する（ステップＳ３０４）。
【００４１】
尚、アクセサメソッドとは、設定オブジェクト２０７の外部（本例では、業務プログラムＡ処理部１０３，２０２、業務プログラムＢ処理部１０４、業務プログラムＣ処理部１０５など）から、当該設定オブジェクト２０７の属性（データ）に対してアクセス（入力と出力）する為に用意されたメソッド（操作）のことである。
【００４２】
ここで、入力用アクセサメソッド一覧および出力用アクセサメソッド一覧の構築手順について説明する。結論から述べると、入力用アクセサメソッド一覧および出力用アクセサメソッド一覧の構築とは、図７に示すアクセサメソッド一覧７０１を作成することである。
【００４３】
アクセサメソッド一覧７０１における入力用アクセサメソッド名および出力用アクセサメソッド名の作成ルールは、アプリケーションにより独自に定義すれば良いが、ここでは、もっとも一般的と思われるルールに従ってアクセサメソッド名を決定している。このルールについて下記のように定義する。
【００４４】
入力用アクセサメソッド名の生成ルールとして「ｓｅｔ＋設定項目（図５の表形式５０２に示すプロパティファイルにおける設定項目）」、出力用アクセサメソッド名の生成ルールとして「ｇｅｔ＋設定項目（図５の表形式５０２に示すプロパティファイルにおける設定項目）」と定義する。ただし、設定項目中にドット（「．」）が含まれる場合は、このドット（「．」）を削除し、次の文字を大文字に置換する。
【００４５】
続いて、設定オブジェクト生成機能２０４は、プロパティファイル２０６の設定値（／ｕａｐ／ｉｎｐｕｔ／ｄａｔａ、／ｕａｐ／ｏｕｔｐｕｔ／ｄａｔａなど）を格納する為の設定オブジェクト２０７を生成する（ステップＳ３０５）。
【００４６】
このステップＳ３０５の処理で生成する設定オブジェクト２０７を決定するのが、先に述べたプロパティファイル２０６の図５に示す表形式５０２中に定義されている「ｃｏｎｆｉｇ．ｂｅａｎ」の設定値である。この図５の表形式５０２の例では、「ｓａｍｐｌｅ．ＣｏｎｆｉｇＢｅａｎ」という名前の設定オブジェクトを生成する（図６の設定オブジェクトのクラス図を参照）。
【００４７】
尚、このｓａｍｐｌｅ．ＣｏｎｆｉｇＢｅａｎは事前に用意されたものであり、図６において示すように、「ｆｉｌｅＩｎｐｕｔ：Ｆｉｌｅ」、「ｆｉｌｅＯｕｔｐｕｔ：Ｆｉｌｅ」、「ｓｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００１：Ｓｔｒｉｎｇ」、「ｓｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００２：Ｓｔｒｉｎｇ」、「ｓｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００３：Ｓｔｒｉｎｇ」等の属性（データ）６０２と、「ｇｅｔＦｉｌｅＩｎｐｕｔ（）：Ｆｉｌｅ」、「ｓｅｔＦｉｌｅＩｎｐｕｔ（Ｆｉｌｅ）：ｖｏｉｄ」、「ｇｅｔＦｉｌｅＯｕｔｐｕｔ（）：Ｆｉｌｅ」、「ｓｅｔＦｉｌｅＯｕｔｐｕｔ（Ｆｉｌｅ）：ｖｏｉｄ」、「ｇｅｔＳｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００１（）：Ｓｔｒｉｎｇ」、「ｓｅｔＳｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００１（Ｓｔｒｉｎｇ）：ｖｏｉｄ」、「ｇｅｔＳｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００２（）：Ｓｔｒｉｎｇ」、「ｓｅｔＳｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００２（Ｓｔｒｉｎｇ）：ｖｏｉｄ」、「ｇｅｔＳｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００３（）：Ｓｔｒｉｎｇ」、「ｓｅｔＳｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００３（Ｓｔｒｉｎｇ）：ｖｏｉｄ」等の操作（アクセサメソッド）６０３からなる。例えば、ｆｉｌｅＩｎｐｕｔのアクセサメソッド６０１において示すように、出力用アクセサメソッドとして「ｇｅｔＦｉｌｅＩｎｐｕｔ（）」、入力用アクセサメソッドとして「ｓｅｔＦｉｌｅＩｎｐｕｔ（Ｆｉｌｅ）」が定義されている。
【００４８】
より詳細には、図７（ａ）のアクセサメソッド一覧７０１に示すように、入力用アクセサメソッド名として、「ｓｅｔＦｉｌｅＩｎｐｕｔ」、「ｓｅｔＦｉｌｅＯｕｔｐｕｔ」、「ｓｅｔＳｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００１」、「ｓｅｔＳｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００２」、「ｓｅｔＳｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００３」があり、
出力用アクセサメソッド名として、「ｇｅｔＦｉｌｅＩｎｐｕｔ」、「ｇｅｔＦｉｌｅＯｕｔｐｕｔ」、「ｇｅｔＳｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００１」、「ｇｅｔＳｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００２」、「ｇｅｔＳｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００３」がある。
【００４９】
尚、図７（ｂ）における「設定フィアルの内容を反映した設定オブジェクトの状態７０２」は、設定オブジェクト生成機能２０４が最終的に生成する設定オブジェクトの内容を示しており、各属性（データの名前）の設定値が示されている。例えば、属性「ｆｉｌｅＩｎｐｕｔ」に対しては設定値「／ｕａｐ／ｉｎｐｕｔ．ｄａｔａ」が対応付けられ、同様に、属性「ｆｉｌｅＯｕｔｐｕｔ」に対しては設定値「／ｕａｐ／ｏｕｔｐｕｔ．ｄａｔａ」が、属性「ｓｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００１」に対しては設定値「入力ファイルがありません」、属性「ｓｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００２」に対しては設定値「出力ファイルの生成に失敗しました」、属性「ｓｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００３」に対しては設定値「ｎｕｌｌ」が対応付けられている。
【００５０】
設定オブジェクト生成機能２０４は、上述の図７（ａ）におけるアクセサメソッド一覧７０１に示す入力用アクセサメソッド名の一覧作成のためのループ処理を開始する（ステップＳ３０６）。
【００５１】
このループ処理では、まず、図７（ａ）のアクセサメソッド一覧７０１における入力用アクセサメソッド名と、図５の表形式５０２に示す内容のプロパティファイルの設定項目から割り出したアクセサメソッド名とを比較し（ステップＳ３０７）、同じ設定項目がある場合には、設定オブジェクト２０７に、プロパティファイルにおける設定値（図５の表形式５０２における設定値）を格納する（ステップＳ３０８）。
【００５２】
このループ処理を、図７（ａ）のアクセサメソッド一覧７０１における入力用アクセサメソッド名の全てに対して実行することで（ステップＳ３０９）、図７（ｂ）における「設定ファイルの内容を反映した設定オブジェクトの状態７０２」に示すようにして、設定オブジェクト２０７の属性（データ）にプロパティファイルの設定内容が格納できることになる。
【００５３】
以上の処理により、図７の「設定ファイルの内容を反映した設定オブジェクトの状態７０２」に示す設定オブジェクト２０７が生成される。尚、図７の「設定ファイルの内容を反映した設定オブジェクトの状態７０２」における属性「ｓｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００３」の設定値である「ｎｕｌｌ」とは、初期値のことであり、ここでは、この項目（属性）には設定値が何も設定されなかったことを示している。
【００５４】
次に、図４を用いて、設定ファイル取り込みプログラム処理部２０１における設定ファイル検証機能２０５の処理動作を説明する。
【００５５】
設定ファイルの検証機能２０５は、アプリケーション毎に要件の異なる固有の機能であることから、ここでは、検証内容については、「設定オブジェクトには項目値が設定されなくてはならない」いう検証を例に説明する。
【００５６】
まず、設定ファイルの検証機能２０５は、設定ファイル生成機能２０４で生成された設定オブジェクト２０７を取り込み（ステップＳ４０１）、図７のアクセサメソッド一覧７０１における出力用アクセサメソッド一覧を用いて、取り込んだ設定オブジェクト２０７に設定されている設定値を取得する（ステップＳ４０２）。
【００５７】
次に、設定ファイルの検証機能２０５は、アプリケーション固有で実装可能な検証処理を実行する。今回の検証では、「設定オブジェクトには項目値が設定されなくてはならない」という前提であるために、まず、「設定値がｎｕｌｌ」であるか否かを判定する（ステップＳ４０３）。
【００５８】
ここで、設定値が「ｎｕｌｌ」とは、初期値のまま値が変更されなかったことであり、項目値が設定されなかったということになる。このことから、図７の設定ファイルの内容を反映した設定オブジェクトの状態７０２に示す各データ（属性）において、「ｆｉｌｅＩｎｐｕｔ」と「ｆｉｌｅＯｕｔｐｕｔ」および「ｓｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００１」、「ｓｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００２」に関しての検証結果は合格となるが、「ｓｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００３」に関しては設定値が「ｎｕｌｌ」であるために不合格となる。
【００５９】
今回の例で言えば、「ｓｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００３」が不合格である為に、設定ファイル取り込みプログラム処理部２０１の呼び出し元である業務プログラムＡ処理部２０２に対しては不合格の通知を出す（ステップＳ４０５）。
【００６０】
もしも、図７の設定ファイルの内容を反映した設定オブジェクトの状態７０２においての定義で、「ｓｔｒｉｎｇＥｒｒＭｅｓｓａｇｅ００３」が無い場合を想定すると、ステップＳ４０３での検証結果は合格となり、業務プログラムＡ処理部２０２に対して、設定値が設定された設定オブジェクトを渡す（ステップＳ４０４）。
【００６１】
これにより、業務プログラムＡ処理部２０２は、プロパティファイル２０６を参照する必要もなく、設定オブジェクト２０７から、図７のアクセサメソッド一覧７０１における各アクセサメソッド（出力用アクセサメソッド）を利用して、プロパティファイル２０６の設定内容を利用することが可能となる。
【００６２】
以上、図１〜図７を用いて説明したように、本例の設定ファイル取り込みプログラム処理部１０７，２０１は、プログラムされたコンピュータ処理によって、呼び出し元の Java（登録商標）アプリケーションのプロパティファイルを読み込み、当該プロパティファイルの各設定項目とその設定値を呼び出し元の Java（登録商標）アプリケーションに引き渡すシステムとして機能し、プログラムされたコンピュータ処理を実行する機能として、図示していないファイル記憶処理機能と、設定ファイル分析機能２０３、設定オブジェクト生成機能２０４、設定ファイル検証機能２０５とを有し、ファイル記憶処理機能により、複数の Java（登録商標）アプリケーションが共通に利用する設定項目と設定値をテキストで記述したプロパティファイル２０６を記憶装置に記憶し、設定ファイル分析機能２０３により、呼び出し元の Java（登録商標）アプリケーション（業務プログラムＡ２０２）が利用するプロパティファイルを読み出し、このプロパティファイルにおける各設定項目と各設定項目の設定値を抽出し、設定オブジェクト生成機能２０４により、設定ファイル分析機能２０３が抽出した当該プロパティファイルの設定項目と設定値を格納する設定オブジェクト２０７を生成し、設定ファイル検証機能２０５により、設定オブジェクト生成機能２０４が生成した設定オブジェクト２０７を読み込み、設定オブジェクト２０７に格納された設定項目と設定値に対する呼び出し元の Java（登録商標）アプリケーション（業務プログラムＡ２０２）固有の検証を行い、この設定ファイル検証機能２０５での検証結果に応じて、設定オブジェクト２０７に格納された当該プロパティファイル２０６の設定項目と設定値の呼び出し元の Java（登録商標）アプリケーション（業務プログラムＡ２０２）への引き渡しを制御する。
【００６３】
尚、プロパティファイル２０６は、当該プロパティファイル２０６に対して生成される設定オブジェクト２０７の生成に用いる図６にしめす設定オブジェクト（６０２，６０３）を指定する設定項目と設定値（ｃｏｎｆｉｇ．ｂｅａｎ＝ｓａｍｐｌｅ．ＣｏｎｆｉｇＢｅａｎ）を含み、設定オブジェクト生成機能２０４は、プロパティファイル２０６に含まれる設定項目と設定値（ｃｏｎｆｉｇ．ｂｅａｎ＝ｓａｍｐｌｅ．ＣｏｎｆｉｇＢｅａｎ）で指定される設定オブジェクト（ｓａｍｐｌｅ．ＣｏｎｆｉｇＢｅａｎ）を利用して、設定オブジェクト２０７を生成する。
【００６４】
さらに、設定オブジェクト生成機能２０４は、設定ファイル分析機能２０３が抽出したプロパティファイル２０６の設定項目に対応する設定値の入出力に用いる入力用アクセサメソッドと出力用アクセサメソッド（７０１）を、設定オブジェクト（ｓａｍｐｌｅ．ＣｏｎｆｉｇＢｅａｎ）から抽出して設定オブジェクト２０７に格納すると共に、格納した入力用アクセサメソッドで入力される当該プロパティファイル２０６の設定値を設定オブジェクト２０７に格納する。
【００６５】
また、設定ファイル分析機能２０３が抽出したプロパティファイル２０６の設定項目と、設定オブジェクト（ｓａｍｐｌｅ．ＣｏｎｆｉｇＢｅａｎ）に格納される入力用アクセサメソッドと出力用アクセサメソッドのそれぞれの名称は、予め定められた変換ルールで対応付けられており、設定オブジェクト生成機能２０４は、設定ファイル分析機能２０３が抽出した当該プロパティファイル２０６の設定項目に予め定められた変換ルールで対応付けられた入力用アクセサメソッドと出力用アクセサメソッドを設定オブジェクト（ｓａｍｐｌｅ．ＣｏｎｆｉｇＢｅａｎ）から抽出する。
【００６６】
また、設定ファイル検証機能２０５は、設定オブジェクト生成機能２０４が生成した設定オブジェクト２０７を読み込み、この設定オブジェクト２０７に格納された出力用アクセサメソッドを用いて、当該設定オブジェクト２０７に格納されている設定値を取得し、取得した設定値を用いて、呼び出し元の Java（登録商標）アプリケーション（業務プログラムＡ２０２）固有の検証を行う。
【００６７】
このように、本例では、設定ファイル分析機能２０３により、プロパティファイル２０６を分析し、プロパティファイル２０６中の設定値より、どの設定オブジェクトを生成するのかを決定し、この決定に基づき、設定オブジェクト生成機能２０４により、当該設定オブジェクト２０７を生成し、生成した設定オブジェクト２０７に対して、プロパティファイル２０６中の設定値を、ルールに則り格納する。
【００６８】
この時点で、設定オブジェクト２０７の内容は、プロパティファイル２０６と同じ状態になり、さらに、設定ファイル検証機能２０５により、当該設定オブジェクト２０７の内容に対して、アプリケーション固有の機能を実装する。このようにして、設定ファイル検証機能２０５による検証を終えて、固有機能を実装した設定オブジェクト２０７は、業務ロジックを担当するモジュールに引き渡され、当該業務ロジックＡ２０２において、プロパティファイルの設定内容が利用可能となる。
【００６９】
以上のように、本例の技術を JAVA（登録商標）アプリケーション開発の初期工程から採用することにより次の効果が期待できる。
【００７０】
設定ファイルオブジェクト生成プログラムは、共通部品的な性格を持つことから、プロパティファイルの読み込みロジックを統一でき、プログラマが Java（登録商標）標準ＡＰＩを利用せずに、簡単に、プロパティファイルの内容を取り込むことができるようになる。簡単に利用できるということは、ソースコード量を削減し、煩雑さを解消するという効果がある。
【００７１】
生成される設定ファイルオブジェクトに対して検証を行う機能を有しており、拡張可能な形で提供する為に、アプリケーション固有の機能を実装することが可能である。これは、ソースコードの自動生成で問題となる自動生成後のソースコードに対する機能追加や、自動生成のロジック修正に関する問題点を解消する。
【００７２】
副次的効果も得られる。すなわち、プロパティファイルと設定オブジェクトは１対１の関係になるので、プロパティファイルの設定内容が何処に利用されるかを追跡するのがたやすくなる。一般的に、オブジェクト化されたものを追跡するのは容易であるが、 Java（登録商標）標準ＡＰＩを利用してプロパティファイルの設定を取り込んだ場合には、何処のオブジェクトで管理されるのかは不定である。
【００７３】
尚、本発明は、図１〜図７を用いて説明した例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能である。例えば、本例では、業務プログラムＡ処理部１０３のプログラムＡでプロパティフィル１０６，２０６を利用する例で説明しているが、業務プログラムＢ処理部１０４のプログラムＢもしくは業務プログラムＣ処理部１０５のプログラムＣでプロパティフィル１０６，２０６を利用する場合においても、図６に示す設定ファイル（ｓａｍｐｌｅ．ＣｏｎｆｉｇＢｅａｎ）を利用することで、図７（ｂ）の設定フィアルの内容を反映した設定オブジェクトの状態７０２に示す内容と同じ設定オブジェクトの状態が得られ、このような設定オブジェクトに対して、設定ファイル検証機能２０５により、業務プログラムＢ処理部１０４のプログラムＢもしくは業務プログラムＣ処理部１０５のプログラムＣに固有の検証を実装することとなる。
【００７４】
また、本例のコンピュータ構成に関しても、キーボードや光ディスクの駆動装置の無いコンピュータ構成としても良い。また、本例では、光ディスクを記録媒体として用いているが、ＦＤ（Ｆｌｅｘｉｂｌｅ  Ｄｉｓｋ）等を記録媒体として用いることでも良い。また、プログラムのインストールに関しても、通信装置を介してネットワーク経由でプログラムをダウンロードしてインストールすることでも良い。
【図面の簡単な説明】
【００７５】
【図１】本発明に係る設定ファイル取り込みシステムを具備したサーバコンピュータ装置の構成例を示すブロック図である。
【図２】本発明に係る設定ファイル取り込みシステムの構成例を示すブロック図である。
【図３】図２における設定ファイル分析機能と設定オブジェクト生成機能の処理動作例を示すフローチャートである。
【図４】図２における設定ファイル検証機能の処理動作例を示すフローチャートである。
【図５】図２におけるプロパティファイルの構成例を示す説明図である。
【図６】図２における設定オブジェクトのクラスの具体例を示す説明図である。
【図７】図２における設定オブジェクトのアクセサメソッドと設定内容の具体例を示す説明図である。
【符号の説明】
【００７６】
１０１：サーバコンピュータ装置（サーバ）、１０２：クライアントコンピュータ装置（クライアント）、１０３，２０２：業務プログラムＡ処理部、１０４：業務プログラムＢ処理部、１０５：業務プログラムＣ処理部、１０６，２０６：プロパティファイル、１０７，２０１：設定ファイル取り込みプログラム処理部、２０３：設定ファイル分析機能、２０４：設定オブジェクト生成機能、２０５：設定ファイル検証機能、２０７：設定オブジェクト、２０８：メモリ（情報）、５０１：ファイルイメージ、５０２：表形式、６０１：ｆｉｌｅＩｎｐｕｔのアクセサメソッド、６０２：属性（データ）、６０３：操作（アクセサメソッド）、７０１：アクセサメソッド一覧、７０２：設定フィアルの内容を反映した設定オブジェクトの状態。
【図１】
2010079400.tif 000003
【図２】
2010079400.tif 000004
【図３】
2010079400.tif 000005
【図４】
2010079400.tif 000006
【図５】
2010079400.tif 000007
【図６】
2010079400.tif 000008
【図７】
2010079400.tif 000009