(57)【要約】      （修正有）【課題】バッチ処理に要する処理時間を極力短くできる処理条件を決定する仕組みを提供する。【解決手段】過去の更新処理の際に用いられたデータのデータ種と、その際に用いた１トランザクション単位のデータの数とを、過去情報として記憶して、これらの過去情報とこれから更新処理しようとする記憶手段のデータのデータ種とから、これから行う更新処理における１トランザクション単位のデータの数を決定する。これにより、更新処理（バッチ処理）に要する処理時間を極力短くできる処理条件を決定する。【選択図】図１４
2016051242.tif 000002
【特許請求の範囲】
【請求項１】
複数のデータを記憶する記憶手段を備えたサーバ装置通信可能に設けられ、前記記憶手段に記憶された複数のデータを区分けして得られた複数のユニットそれぞれを１つのトランザクション単位として、前記記憶手段のデータの更新処理を行う情報処理装置であって、
過去の更新処理の際に用いられたデータのデータ種と、その際に用いた１トランザクション単位のデータの数とを、過去情報として複数記憶する更新事例記憶手段と、
前記更新事例記憶手段に記憶された過去情報のデータ種と、当該データ種のデータに対応する１トランザクション単位のデータの数と、これから更新処理しようとする前記記憶手段のデータのデータ種とに基づいて、これから更新しようとする前記記憶手段に記憶されたデータのデータ種を区分けする際に用いる１トランザクション単位のデータの数を決定する決定手段と、を有することを特徴とする情報処理装置。
【請求項２】
前記決定手段は、前記複数の過去情報から、これから更新しようとする前記記憶手段に記憶されたデータのデータ種に最も近い過去情報を特定し、当該特定された過去情報で用いられた１トランザクション単位のデータの数を、これから更新しようとする前記記憶手段に記憶されたデータのデータ種を区分けする際に用いる１トランザクション単位のデータの数とすることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記決定手段による最も近い過去情報の特定は、データ種間の類似度を算出し、当該類似度の結果を用いて特定することを特徴とする請求項２に記載の情報処理装置。
【請求項４】
複数のデータを記憶する記憶手段を備えたサーバ装置と通信可能に設けられ、前記記憶手段に記憶された複数のデータを区分けして得られた複数のユニットそれぞれを１つのトランザクション単位として、前記記憶手段のデータの更新処理を行う情報処理装置の制御方法であって、
過去の更新処理の際に用いられたデータ種と、その際に用いた１トランザクション単位のデータの数と、これから更新処理しようとする前記記憶手段のデータのデータ種とに基づいて、これから更新しようとする前記記憶手段に記憶されたデータのデータ種を区分けする際に用いる１トランザクション単位のデータの数を決定する決定工程を有することを特徴とする制御方法。
【請求項５】
複数のデータを記憶する記憶手段を備えたサーバ装置と通信可能に設けられ、前記記憶手段に記憶された複数のデータを区分けして得られた複数のユニットそれぞれを１つのトランザクション単位として、前記記憶手段のデータの更新処理を行う情報処理装置で実行可能なプログラムであって、
前記情報処理装置を
過去の更新処理の際に用いられたデータ種と、その際に用いた１トランザクション単位のデータの数と、これから更新処理しようとする前記記憶手段のデータのデータ種とに基づいて、これから更新しようとする前記記憶手段に記憶されたデータのデータ種を区分けする際に用いる１トランザクション単位のデータの数を決定する決定手段として機能させることを特徴とするプログラム。
【請求項６】
複数のデータを記憶する記憶手段を備え、前記記憶手段に記憶された複数のデータを区分けして得られた複数のユニットそれぞれを１つのトランザクション単位として、前記記憶手段のデータの更新処理を行う情報処理装置であって、
過去の更新処理の際に用いられたデータのデータ種と、その際に用いた１トランザクション単位のデータの数とを、過去情報として複数記憶する更新事例記憶手段と、
前記更新事例記憶手段に記憶された過去情報のデータ種と、当該データ種のデータに対応する１トランザクション単位のデータの数と、これから更新処理しようとする前記記憶手段のデータのデータ種とに基づいて、これから更新しようとする前記記憶手段に記憶されたデータのデータ種を区分けする際に用いる１トランザクション単位のデータの数を決定する決定手段と、
を有することを特徴とする情報処理装置。
【請求項７】
複数のデータを記憶する記憶手段を備え、前記記憶手段に記憶された複数のデータを区分けして得られた複数のユニットそれぞれを１つのトランザクション単位として、前記記憶手段のデータの更新処理を行う情報処理装置の制御方法であって、
過去の更新処理の際に用いられたデータ種と、その際に用いた１トランザクション単位のデータの数と、これから更新処理しようとする前記記憶手段のデータのデータ種とに基づいて、これから更新しようとする前記記憶手段に記憶されたデータのデータ種を区分けする際に用いる１トランザクション単位のデータの数を決定する決定工程を有することを特徴とする制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理装置の制御方法、およびプログラムに関する。
【背景技術】
【０００２】
近年、企業内では、クライアント端末に特別なアプリケーションをインストールすることなく業務が行えるように、業務用アプリケーションのＷｅｂ化が急速に進んでいる。そしてこのような業務アプリケーションの開発現場においては、開発スキル不足や要員不足を解決するために、Ｗｅｂアプリケーションをプログラミングレスで容易に作成できる開発ツールが用いられている。このような開発ツールを用いると、プログラミング言語の知識を有していなくても、業務・設計ノウハウを活用して基本設計情報を定義するだけで、Ｗｅｂアプリケーションを自動生成することができる。
【０００３】
ところで、このようなＷｅｂアプリケーションを用いて入力されるデータベースでは、例えば、大量に発生するデータの更新や不要データの削除など、定期的なメンテナンスが必要となる場合がある。このような大量のデータメンテナンスを、１件ごとに行うとかなりの時間が掛かってしまうため、バッチプログラムを開発して複数のデータをまとめたトランザクション単位で処理されることが一般的である。
【０００４】
そしてＷｅｂアプリケーションの管理者は、このようなバッチプログラムも用いることで、夜間等のシステム停止時に定期的にデータのメンテナンスを行うことになる。しかし、このようなメンテナンスは、システム稼働の時間までにバッチ処理を完了させておかないと日常業務に影響が出てしまうため、Ｗｅｂアプリケーションの管理者は、バッチ処理に要する時間を予め予測して、開始時間を調整することが必要である。
【０００５】
特許文献１には、複数のジョブを含むバッチ処理に要する時間を予測する方法として、ジョブごとに１トランザクション分の処理を仮実行して仮処理時間を測定することで、想定される予測処理時間を算出する方法が開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１２−１５０７１１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、バッチ処理に要する時間は、１トランザクション内のデータの数等の処理内容に依存するところが大きく、特許文献１の方法を用いて予測される時間がかならずしも最短の処理時間であるとは限らない。
【０００８】
そこで本発明は、上記課題を鑑み、バッチ処理に要する処理時間を極力短くできる処理条件を決定できる仕組みを提供することを目的としている。
【課題を解決するための手段】
【０００９】
本発明の情報処理装置は、複数のデータを記憶する記憶手段を備えたサーバ装置通信可能に設けられ、前記記憶手段に記憶された複数のデータを区分けして得られた複数のユニットそれぞれを１つのトランザクション単位として、前記記憶手段のデータの更新処理を行う情報処理装置であって、過去の更新処理の際に用いられたデータのデータ種と、その際に用いた１トランザクション単位のデータの数とを、過去情報として複数記憶する更新事例記憶手段と、前記更新事例記憶手段に記憶された過去情報のデータ種と、当該データ種のデータに対応する１トランザクション単位のデータの数と、これから更新処理しようとする前記記憶手段のデータのデータ種とに基づいて、これから更新しようとする前記記憶手段に記憶されたデータのデータ種を区分けする際に用いる１トランザクション単位のデータの数を決定する決定手段と、を有することを特徴とする。
【発明の効果】
【００１０】
このように、最適な処理条件で処理されているであろう過去の更新処理条件を参照してこれから行う更新処理（バッチ処理）の１トランザクション単位のデータの数を決定することにより、これから行う更新処理に要する処理時間を極力短くすることができる。
【図面の簡単な説明】
【００１１】
【図１】Ｗｅｂアプリケーション自動生成システム（情報処理システム）のシステム構成の一例を示す図である。
【図２】開発用端末１０１、サーバ１０２、利用者用端末１０３、バッチ処理用端末１０４のハードウェア構成を示す図である。
【図３】Ｗｅｂアプリケーション自動生成システムの機能構成を説明するための図である。
【図４】データベース定義１１１の一例を説明するための図である。
【図５】データモデル定義１１２の一例を説明するための図である。
【図６】ビジネスプロセス定義１１３の一例を説明するための図である。
【図７】入出力定義１１４の一例を説明するための図である。
【図８】Ｗｅｂアプリケーションを自動生成する際の流れを説明するためのフローチャートである。
【図９】ユーザ登録画面９０１の一例を示す図である。
【図１０】ユーザ一覧画面１００１の一例を示す図である。
【図１１】バッチ入出力定義１５１の一例を説明するための図である。
【図１２】バッチアプリケーションを自動生成する際の流れを説明するためのフローチャートである。
【図１３】バッチアプリケーションを用いたバッチ処理の流れを説明するためのフローチャートである。
【図１４】バッチアプリケーションに用いられるｄａｔａＵｎｉｔ値を決定する際の流れを説明するためのフローチャートである。
【図１５】事例定義リポジトリ管理部１８２に管理されている過去情報の管理テーブルの一例を示す図である。
【図１６】類似計算情報管理部１８３に管理されている類似計算情報管理テーブル１６００の一例を示す図である。
【図１７】事例定義リポジトリ管理部１８２に管理されているバッチ入出力定義の一例を示す図である。
【図１８】事例定義リポジトリ管理部１８２に管理されているビジネスプロセス定義及びデータモデル定義の一例を示す図である。
【図１９】バッチアプリケーションの生成に用いられる、ｄａｔａＵｎｉｔ値が決定される前のバッチ入出力定義の一例を示す図である。
【図２０】バッチアプリケーションの生成に用いられる、ビジネスプロセス定義及びデータモデル定義の一例を示す図である。
【図２１】類似結果管理部１８５に管理される類似結果管理テーブル２１００の一例を示す図である。
【発明を実施するための形態】
【００１２】
以下、図面を参照して、本発明の実施形態を詳細に説明する。
【００１３】
図１は、本実施形態におけるＷｅｂアプリケーション自動生成システム（以下、情報処理システムとも称する）のシステム構成を示す図である。本発明のＷｅｂアプリケーション自動生成システムは、開発用端末１０１、サーバ１０２（サーバ装置）、利用者用端末１０３、バッチ処理用端末１０４が、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）やＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等のネットワーク１０５を介して相互にデータ通信可能に接続されている。
【００１４】
Ｗｅｂアプリケーションとは、企業内で用いられる業務用アプリケーションをＷｅｂ上で実施することができるアプリケーションのことであり、クライアント端末上に特別なアプリケーションをインストールすることなく業務を行うことができるため、近年広く用いられている。本発明のＷｅｂアプリケーションシステムは、このようなＷｅｂアプリケーションを指定した要件定義情報からプログラミングレスで自動生成することができるシステムである。このようなシステムを用いることにより、開発スキルが不足していたしても各企業内で容易にＷｅｂ上の業務アプリケーションを開発することができる。
【００１５】
図１に示す開発用端末１０１には、Ｗｅｂアプリケーション（プログラム）を自動生成する際に開発者が使用する端末でありプログラムを自動生成する開発ツールがインストールされている。この端末で予め要件定義を行い、開発ツールに読み込ませて自動生成処理を行うことでＷｅｂアプリケーション１３０（プログラム）が生成される。また、Ｗｅｂアプリケーションで生成されたデータの更新作業をバッチ処理として行う際に用いる要件定義行っておき、同様にこれを開発ツールに読み込ませて自動生成処理を行うことで、バッチアプリケーション１７０（プログラム）が生成される。
【００１６】
サーバ１０２は、開発用端末１０１で生成されたＷｅｂアプリケーション（プログラム）を保持運用し、業務アプリケーションを本番環境として提供するために用いられる。そして、利用者用端末１０３を介してＷｅｂアプリケーション１３０（プログラム）へのアクセスを受け付ける。そして、Ｗｅｂアプリケーションを用いて生成されたデータをデータベース１４０内に記憶している。
【００１７】
利用者用端末１０３は、一般に本番環境において業務アプリケーションを利用するユーザが利用する端末であり、本端末を用いてサーバ１０２に接続することで、Ｗｅｂ化されたアプリケーションを利用することができる。
【００１８】
バッチ処理用端末１０４は、Ｗｅｂアプリケーションを管理する管理者が使用する端末であり、バッチアプリケーション１７０を記憶しており、当該バッチアプリケーション１７０を用いてサーバ１０２に記憶されたデータの更新処理をバッチ処理として行う指示を出す際に用いられる。
【００１９】
図２は、開発用端末１０１、サーバ１０２、利用者用端末１０３、バッチ処理用端末１０４のハードウェア構成を示す図である。
【００２０】
ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。
【００２１】
また、ＲＯＭ２０２あるいは外部メモリ２１１（記憶手段）には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ／ＯｕｔｐｕｔＳｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、開発用端末１０１、サーバ１０２、利用者用端末１０３、バッチ処理用端末１０４の実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。
【００２２】
ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＡＭ２０３にロードして、プログラムを実行することで各種動作を実現するものである。
【００２３】
また、入力コントローラ（入力Ｃ）２０５は、キーボードや不図示のマウス等のポインティングデバイス等の入力デバイス２０９からの入力を制御する。
【００２４】
ビデオコントローラ（ＶＣ）２０６は、ディスプレイ２１０等の表示器への表示を制御する。表示器の種類はＣＲＴや、液晶ディスプレイを想定するが、これに限らない。
【００２５】
メモリコントローラ（ＭＣ）２０７は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶するハードディスク（ＨＤ）やフレキシブルディスク（ＦＤ）或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるカード型メモリ等の外部メモリ２１１へのアクセスを制御する。
【００２６】
通信Ｉ／Ｆコントローラ（通信Ｉ／ＦＣ）２０８は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。
【００２７】
尚、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ディスプレイ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。
【００２８】
本発明の開発用端末１０１、サーバ１０２、利用者用端末１０３、バッチ処理用端末１０４が後述する各種処理を実行するために用いられる各種プログラム等は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行可能となるものである。
【００２９】
さらに、本発明に係わるプログラムが用いる定義ファイルや各種情報テーブルは外部メモリ２１１に格納されている。
【００３０】
図３は、Ｗｅｂアプリケーション自動生成システムの構成図および生成されたアプリケーション等の機能構成を説明するための図である。
【００３１】
開発用端末１０１は、Ｗｅｂアプリケーション定義部１１０とバッチアプリケーション定義部１５０とｄａｔａ値導出部１８０とＷｅｂアプリケーション生成部１２０とソースコード保持部１２１とバッチアプリ生成部１６０を有している。
【００３２】
サーバ１０２は、開発用端末１０１のＷｅｂアプリ生成部１２０で生成されたＷｅｂアプリケーション１３０を保持し、利用者用端末１０３から入力データ等をデータベースに記憶している。
【００３３】
バッチ処理用端末１０４は、開発用端末１０１のバッチアプリ生成部１６０で生成されたバッチアプリケーション１７０と、バッチ処理のために用いるファイルの入力を受け付けるファイル入力部１９０、エラーファイル１９６が出力されるエラー出力部１９５とを有している。
【００３４】
（Ｗｅｂアプリケーションの自動生成処理）
次に、図３乃至図１０を用いて、開発者がＷｅｂアプリケーションを開発用端末１０１で自動生成する際の流れを説明する。図４乃至７は、図３のＷｅｂアプリケーション定義部１１０に記憶されるデータベース定義１１１、データモデル定義１１２、ビジネスプロセス定義１１３、入出力定義１１４等の開発者によって予め設定した定義の一例を示したものである。
【００３５】
図４はＷｅｂアプリケーションがアクセスするサーバの設定を記憶したデータベース定義１１１である。図４に示すように、データベース定義には、サーバ１０２のコード４０１、サーバの名前４０２、接続ＵＲＬ情報４０３、サーバの種類４０４、データベース名４０５、アプリケーションがデータベースにアクセスする際に必要となるユーザ名４０６及びパスワード４０７が定義されている。
【００３６】
図５は、スキーマ情報として定義されるデータモデル定義１１２である。図５（ａ）に示すように、各データモデル定義は、コード５０１と名前５０２を付与して管理されており、詳細定義もそれぞれ定義されている。例えば図５（ａ）のコード『Ｕｓｅｒ』では、図５（ｂ）に示す項目５１０と図５（ｃ）に示す操作コード５２０が詳細定義されている。
【００３７】
図５（ｂ）は、データベース上で受け付ける項目として、項目コード５１１、項目の名前５１２、ＮＵＬＬを許可するか否かを設定する項目５１３、桁数５１４、データタイプ５１５を定義している。この例では、データモデル「ＵＳＥＲＳ」に対して、「ＩＤ」から「ＰＨＯＮＥ」までのデータモデル項目を定義している。ここで定義する各項目はＷｅｂアプリケーションが接続するデータベースのテーブルのカラム名と一致する。
【００３８】
図５（ｃ）は、データモデルに対する操作をどのように受け付けるかを設定した操作コードであり、操作コード５２１、当該操作の名前５２２、操作タイプ５２３が定義されている。すなわち、データモデルが関連するテーブルに対して操作内容を定義するものである。ここでは、操作コード『ＲＥＧＩＳＴ』というコードを有するユーザ登録操作は、操作タイプ『ＩＮＳＥＲＴ』であると定義されており、つまりユーザ登録操作で入力されたデータがデータベースに挿入されるというように定義されている。
【００３９】
図６は、Ｗｅｂアプリケーションの業務フローを定義するためのビジネスプロセス定義１１３である。図６（ａ）に示すように、各ビジネスプロセス定義は、コード６０１と名前６０２を付与して管理されており、詳細なロジック定義もそれぞれ定義されている。なお、ビジネスプロセスのコード６０１は、後述する入出力定義からの呼び出し指定するコードとして用いられる。詳細なロジック定義としては、図６（ｂ）に示すように、制御コード６１１、データモデルコード６１２、機能コード６１３、パラメータ６１４、作業コード６１５が設定されている。
【００４０】
例えば図６（ａ）のコード『ＵＳＥＲ＿ＲＥＧＩＳＴ＿ＢＰ』のビジネスプロセス定義では、制御コード６１１の設定順に以下のような処理が行われる。この例ではＷｅｂ画面の入力内容を制御コード「ＩＮ」で受け取り、受け取ったデータを作業コード「ＩＮＰＵＴ」として定義している。次に制御コード「ＣＡＬＬ」でデータモデル「ＵＳＥＲ」に対する操作を定義している。つまり、まず（１）『ＩＮ』制御として、図５のＵＳＥＲ（ユーザマスタ）というデータモデルコード５０１から、入力データを取得する。その際に、当該作業コードに『ＩＮＰＵＴ』というコードを付与する。次に、（２）『ＣＡＬＬ』制御として、図５（ｃ）のデータモデル定義の操作コードとして設定されており『ＩＮＳＥＲＴ』処理を、『ＩＮ』制御で読み込んだ入力データ（作業コード『ＩＮＰＵＴ』）に対して行うビジネスロジックが定義している。
【００４１】
図７は、Ｗｅｂ画面に配置する各表示項目の入出力定義１１４である。ここで設定されている項目が、利用者用端末１０３の表示画面に表示され、本番環境時にユーザが用いる画面として用いられる。図７（ａ）に示すように、各入出力定義は、コード７０１と名前７０２を付与して管理されており、詳細な項目定義もそれぞれされている。例えば図７（ａ）のコード『ＵＳＥＲ＿ＲＥＧＩＳＴ』では、図７（ｂ）に示す項目タイプ７１１、項目コード７１２、名前７１３、表示７１４、加工式７１５、次入出力７１６、データモデルコード７１７、データモデル項目コード７１８が定義されている。
【００４２】
この例では、項目タイプ「ＩＯ入出力」と定義されている項目は入出力項目（データを入力およびデータを表示する「フィールド」）である。項目タイプ「Ａアクション」と定義されている項目はアクション項目（処理を呼び出し、画面を遷移する「ボタン」）である。この例における、項目コード「ＲＥＧＩＳＴ＿ＢＰ」はアクション項目である。アクション項目「ＲＥＧＩＳＴ＿ＢＰ」の加工式７１５には、「ＵＳＥＲ＿ＲＥＧＩＳＴ＿ＢＰ」が定義されている。「ＲＥＧＩＳＴ＿ＢＰ」のアクションでは、ビジネスプロセス「ＵＳＥＲ＿ＲＥＧＩＳＴ＿ＢＰ」が呼び出されることを示す定義である。そして、次入出力先として、「ＵＳＥＲ＿ＬＩＳＴ」のコードが定義されている。すなわち、「登録」アクションが行われると、「ＵＳＥＲ＿ＲＥＧＩＳＴ＿ＢＰ」の加工式で定義されたアクションが実行された後、「ＵＳＥＲ＿ＬＩＳＴ」に画面遷移することが定義されている。
【００４３】
図９が、入出力定義１１４で定義された「ＵＳＥＲ＿ＲＥＧＩＳＴ（ユーザ登録）」のＷｅｂ画面の一例である。この画面により利用者用端末１０３を介してユーザがユーザ登録処理を行うことができる。ユーザＩＤ９０２、ユーザ名９０３、ふりがな９０４、性別９０５、年齢９０６、誕生日９０７、電話番号９０８、登録ボタン９０９、戻るボタン９１０は、それぞれ図７（ｂ）の項目名前７１３に設定された項目に対応している。
【００４４】
図１０は、入出力定義１１４で定義された「ＵＳＥＲ＿ＬＩＳＴ（ユーザ一覧）」のＷｅｂ画面の一例である。つまりこの例では、図９の画面で各項目が入力され登録ボタン９０９が押下されると、「ＵＳＥＲ＿ＲＥＧＩＳＴ＿ＢＰ」の加工式で定義されたユーザ登録処理が行われ、その結果「ＵＳＥＲ＿ＬＩＳＴ」として表示されるように定義されている。
【００４５】
図８は、図４乃至７に示すようなＷｅｂアプリケーション定義部１１０に記憶されているデータベース定義１１１、データモデル定義１１２、ビジネスプロセス定義１１３、入出力定義１１４等の要件定義がされた後、Ｗｅｂアプリケーションを自動生成する際の流れを説明するためのフローチャートである。
【００４６】
このような処理は、開発用端末１０１のＣＰＵ２０１が記憶されている制御プログラムを読み出して実行することにより実現される。
【００４７】
まず、Ｓ８０１では、開発用端末１０１のＣＰＵ２０１が、データベース定義１１１をＷｅｂアプリケーション定義部１１０から読み込む。Ｓ８０２では、データモデル定義１１２をＷｅｂアプリケーション定義部１１０から読み込む。Ｓ８０３では、ビジネスプロセス定義１１３をＷｅｂアプリケーション定義部１１０から読み込む。Ｓ８０４では、入出力定義１１４をＷｅｂアプリケーション定義部１１０から読み込む。
【００４８】
このような定義はＸＭＬ形式で記述されているため、Ｓ８０５では、開発用端末１０１のＣＰＵ２０１が、ＸＭＬファイルを構造解析し、必要な定義内容をメモリ上にオブジェクトデータとして保存する。
【００４９】
次に、Ｓ８０６では、生成処理は開発用端末１０１のＣＰＵ２０１がＷｅｂアプリ生成部１２０として機能し、予め設定されているソースコードテンプレートを、ソースコード保持部１２１から読み込み、Ｓ８０７でメモリ上に保存した定義データをソースコードテンプレートに埋め込んだ、ソースコードファイル、すなわちＷｅｂアプリケーションを生成する。
【００５０】
以上のように、予め定義した要件定義とソースコードを用いることにより、Ｗｅｂアプリケーションが自動生成される。開発者は、このように生成したＷｅｂアプリケーションを、サーバ１０２に保存して業務アプリケーションの開発作業を終了する。
【００５１】
（バッチアプリケーションの自動生成処理）
次に、図３、図１１及び図１２を用いて、Ｗｅｂアプリケーションの管理者がデータベース１４０に記憶されたデータの更新をバッチ処理として行う際に用いる、バッチアプリケーションを、開発者が開発用端末１０１で自動生成する際の流れを説明する。
【００５２】
一般的にＷｅｂアプリケーションを運用していくためには適宜バッチ処理を行い、データのメンテナンスを行うということが必要となる。本実施形態ではＷｅｂアプリケーションを用いてユーザ登録をする例で説明しているが、このようなアプリケーションを用いた業務で１日に大量のユーザ登録がなされた場合や一度に大量のユーザデータの編集が行われる際には、処理を一括で進めることができるようにバッチ処理を行うことが通常である。このようなバッチ処理に用いるアプリケーションは、個別開発を行うことが一般的であるが、本実施形態におけるバッチアプリケーションは、Ｗｅｂアプリケーションで画面単位に行っていた処理をバッチ化するのみでよいため、多くの部分で共通な領域が存在する。このバッチアプリケーションの自動生成処理ではＷｅｂアプリケーション定義をそのまま用い、最小限の定義を追加するだけで、Ｗｅｂアプリケーションで行っていた操作の機能を有するバッチアプリケーションを容易に作成することができる。
【００５３】
図１１のバッチ入出力定義は、バッチアプリケーションへの入力データとなる項目一覧を定義したもので、図３のバッチアプリケーション定義部１５０に記憶されるバッチ入出力定義１５１の一例を示したものである。Ｗｅｂアプリケーションの入出力定義と異なり、バッチアプリケーションは利用者による入出力がＷｅｂ画面上で行われることはないため、画面定義としては不要であるが、このように、入出力定義１１４に対応する項目をバッチ入出力定義１５１として用意しておくことにより、Ｗｅｂアプリケーション定義部１１０に定義された、データベース定義１１１、データモデル定義１１２、ビジネスプロセス定義１１３、を再度バッチ処理用に用意することなくそのまま利用し、バッチアプリケーションを自動生成させることができる。
【００５４】
図１１（ａ）に示すように、バッチ入出力定義１５１は、コード１１０１と名前１１０２と、後述するｄａｔａ値導出処理によって導出されたｄａｔａＵｎｉｔ値１１０３とが管理されており、さらに詳細な項目定義もされている。例えば図１１（ａ）のコード『ＵＳＥＲ＿ＲＥＧＩＳＴ＿ＢＡＴＣＨ』では、図１１（ｂ）に示す項目タイプ１１１１、項目コード１１１２、名前１１１３、表示１１１４、加工式１１１５、次入出力１１１６、データモデルコード１１１７、データモデル項目コード１１１８が定義されている。
【００５５】
これらの図１１（ｂ）の項目は図７の入出力定義１１４の項目とほぼ同じであり、大きく異なるのはｄａｔａＵｎｉｔ値１１０３が定義されている点である。なお、バッチアプリケーションでは、アクション項目「Ｂ戻る」が定義されていないが、これは、バッチ処理においては、元の画面へ「戻る」処理が不要であるからである。
【００５６】
ｄａｔａＵｎｉｔ値１１０３とはバッチアプリケーションによる大量のデータ処理に対して、何件毎にコミット処理を行うかを設定する値である。例えば、１万件のユーザ登録に対して、ｄａｔａＵｎｉｔを１００に設定すると、１００回のトランザクション処理が発生し、１００回コミットするバッチ処理となる。ここで設定されるｄａｔａＵｎｉｔ値が小さすぎると、データベース接続、コミット処理、クローズ処理に係る処理時間が大きくなり、バッチ処理全体のパフォーマンスが悪くなる。一方、ｄａｔａＵｎｉｔ値が大きすぎると、トランザクション当たりのデータ量が多くなり、メモリエラーが発生する可能性が高くなる。そのため、バッチアプリケーションに合わせた最適なｄａｔａＵｎｉｔ値を決定する必要がある。このような後述するｄａｔａ値導出部１８０は、メモリエラーが発生することなく最短の時間で処理を行うことができる最適なｄａｔａＵｎｉｔ値を導出することができ、ここで導出されたｄａｔａｎｉｔ値がバッチ入出力定義１５１のｄａｔａＵｎｉｔ値として記憶されている。
【００５７】
バッチ入出力定義に定義されているアクション項目「ＥＸＥＣ＿ＡＣＴＩＯＮ登録」の加工式１１１５には、「ＵＳＥＲ＿ＲＥＧＩＳＴ＿ＢＰ」が定義されている。この「ＵＳＥＲ＿ＲＥＧＩＳＴ＿ＢＰ」は図６に示すＷｅｂアプリケーションで利用しているビジネスプロセス定義のコードである。すなわち、このように定義しておくことによりバッチアプリケーションからもＷｅｂアプリケーションと同様のビジネスプロセス定義を利用することが可能であり、バッチアプリケーション用にビジネスプロセスを作成する必要がない。Ｗｅｂアプリケーションのビジネスプロセス定義をバッチアプリケーションでも利用することにより、そしてビジネスプロセス定義で利用されているデータモデル定義、さらにはデータベース定義についても、Ｗｅｂアプリケーションで利用した定義をそのまま利用することができる。
【００５８】
図１２は、図４乃至６に示すようなＷｅｂアプリケーション定義部１１０に記憶されているデータベース定義１１１、データモデル定義１１２、ビジネスプロセス定義１１３、等の要件定義がされ、さらに図１１に示すバッチアプリケーション定義部１５０に記憶されているバッチ入出力定義１５１がされた後に、バッチアプリケーションを自動生成する際の流れを説明するためのフローチャートである。
【００５９】
このような処理は、開発用端末１０１のＣＰＵ２０１が記憶されている制御プログラムを読み出して実行することにより実現される。
【００６０】
まず、Ｓ１２０１では、開発用端末１０１のＣＰＵ２０１が、データベース定義１１１をＷｅｂアプリケーション定義部１１０から読み込む。Ｓ１２０２では、データモデル定義１１２をＷｅｂアプリケーション定義部１１０から読み込む。Ｓ１２０３では、ビジネスプロセス定義１１３をＷｅｂアプリケーション定義部１１０から読み込む。Ｓ１２０４では、バッチ入出力定義１５１をバッチアプリケーション定義部１５０から読み込む。
【００６１】
このような定義はＸＭＬ形式で記述されているため、Ｓ１２０５では、開発用端末１０１のＣＰＵ２０１が、ＸＭＬファイルを構造解析し、必要な定義内容をメモリ上にオブジェクトデータとして保存する。
【００６２】
次に、Ｓ１２０６では、開発用端末１０１のＣＰＵ２０１がバッチアプリ生成部１６０として機能し、予め設定されているソースコードテンプレートを、ソースコード保持部１２１から読み込み、Ｓ１２０７でメモリ上に保存した定義データをソースコードテンプレートに埋め込んだ、ソースコードファイル、すなわちバッチアプリケーションを生成する。
【００６３】
以上のように、予め定義した要件定義とソースコードを用いることにより、バッチアプリケーションが自動生成される。開発者は、このように生成したバッチアプリケーションを、バッチ処理用端末１０４に保存してバッチアプリケーションの生成作業を終了する。
【００６４】
（バッチアプリケーションによるバッチ処理）
次に、図３及び図１３を用いて、生成されたバッチアプリケーションを用いてバッチ処理用端末１０４で行われるバッチ処理を説明する。Ｗｅｂアプリケーションの管理者は、バッチ処理用端末１０４に記憶されたバッチアプリケーションを用いてバッチ処理を行う。このようなバッチ処理はサーバ１０２に負荷がかかるため、他の業務が行われない深夜等にまとめて行われるのが一般的である。
【００６５】
バッチ処理用端末１０４には、図３に示すようにバッチアプリケーション１７０と、バッチ処理に用いるファイル入力部１９０とが設けられている。
【００６６】
ファイル入力部１９０からは、例えばＣＳＶ形式のバッチ処理に用いるファイル入力を受け付けることができる。バッチアプリケーション１７０は、ファイル取得部１７２と、バッチ処理部１７１と、バッチエラー出力部１７３を有している。ファイル入力部１９０から入力された入力ファイルは、ファイル取得部１７２で取得される。そしてバッチ処理動作が実行されると、詳細は後述するがバッチ処理部１７１がデータベース１４０に対して１つのトランザクションごとに処理を行いコミットさせるか、エラーが発生したとしてトランザクションをロールバックさせる。
【００６７】
バッチエラー出力部１７３は、バッチ処理部１７１でエラーが発生したトランザクションについてのエラーファイル１９６をエラー出力部１９５に出力させる。
【００６８】
次に図１３のフローチャートを用いてバッチ処理の流れを説明する。このような処理は、バッチ処理用端末１０４のＣＰＵ２０１が記憶されている制御プログラムを読み出して実行することにより実現される。
【００６９】
Ｓ１３０１では、バッチ処理用端末１０４のＣＰＵ２０１のファイル取得部１７２が、ファイル入力部１９０から入力されたファイルを取得する。
【００７０】
Ｓ１３０２では、バッチ処理用端末１０４のＣＰＵ２０１がバッチアプリケーションとして定義されたｄａｔａＵｎｉｔ値１１０３を初期のｄａｔａＵｎｉｔ値として取得し、ｄａｔａＵｎｉｔ値管理部１７４に記憶する。
【００７１】
Ｓ１３０３では、バッチ処理用端末１０４のＣＰＵ２０１のバッチ処理部１７１が区分手段として機能し、ファイル取得部１７２で取得したファイルの入力データを、ｄａｔａＵｎｉｔ値管理部１７４に記憶されたｄａｔａＵｎｉｔ値を用いて複数に区分けする。ここでは、区分けされたデータ一覧の単位を１つのトランザクションとして更新処理されるユニットと呼ぶ。
【００７２】
Ｓ１３０４では、バッチ処理用端末１０４のＣＰＵ２０１がユニット分だけ繰り返してＳ１３１１〜Ｓ１３１６に示すバッチ処理を行う。
【００７３】
Ｓ１３１１では、バッチ処理用端末１０４のＣＰＵ２０１がデータベース１４０に対してデータをユニット単位で更新するトランザクション処理の実行を行う（更新処理）。
【００７４】
Ｓ１３１２では、バッチ処理用端末１０４のＣＰＵ２０１が、トランザクション処理中にエラーが発生したかを判断する。
【００７５】
トランザクション処理中にエラーが発生しなかったと判断した場合には、Ｓ１３１３では、バッチ処理用端末１０４のＣＰＵ２０１が、更新処理は無事に終了したとして、トランザクションのコミット待ち領域に当該処理結果を格納する。そして、Ｓ１３１４では、当該ユニットに関するトランザクションをコミットする。
【００７６】
一方、トランザクション処理が成功しなかった場合には、Ｓ１３１５に進み、当該ユニットに含まれるデータをすべてエラーファイル１９６に出力する。そしてエラーファイル１９６に出力後、Ｓ１３１６にて当該ユニットに関するトランザクションをロールバックする。
【００７７】
このようなバッチ処理を、Ｓ１３０３で区分けして生成されたユニット分繰り返し行う。そしてすべてのユニットに関する処理が完了すると、バッチ処理の繰り返しは終了する。
【００７８】
なお、本実施形態においてはトランザクション処理中にエラーが発生した場合には、エラーファイルとして出力して終了させたが、予め所定のリトライ回数を指定しておき、リトライ処理を行うように設定してもよい。
【００７９】
なお、実施形態では、バッチ処理を行う際に用いられる入力データはＣＳＶ形式の入力ファイルによるデータの場合を例に説明したが、データベース１４０にアクセスして抽出したデータを用いても同様に行うことができる。
【００８０】
（バッチアプリケーションで用いるｄａｔａ値の導出）
次に、バッチアプリケーションで用いられるｄａｔａＵｎｉｔ値１１０３（ｄａｔａ値とも称する）の導出について説明を行う。ｄａｔａＵｎｉｔ値１１０３とはバッチアプリケーションによる大量のデータ処理に対して、何件のデータ毎にコミット処理を行うかを設定する値である。例えば、１万件のユーザ登録に対して、ｄａｔａＵｎｉｔを１００に設定すると、１００回のトランザクション処理が発生し、１００回コミットするバッチ処理となる。ここで設定されるｄａｔａＵｎｉｔ値が小さすぎると、データベース接続、コミット処理、クローズ処理に係る処理時間が大きくなり、バッチ処理全体のパフォーマンスが悪くなる。一方、ｄａｔａＵｎｉｔ値が大きすぎると、トランザクション当たりのデータ量が多くなり、メモリエラーが発生する可能性が高くなる。そのため、バッチアプリケーションに合わせた最適なｄａｔａＵｎｉｔ値を決定する必要がある。
【００８１】
本実施形態では、過去のバッチ処理の際に対象となったデータのデータ種と、その際に用いた１トランザクション単位のｄａｔａ値とを、更新事例として蓄積して記憶しておく。そして、その中から、これからバッチ処理を行う対象となるデータのデータ種に最も類似している更新事例を特定し、その際に用いた１トランザクション単位のｄａｔａ値を、今回のバッチ処理の１トランザクション単位のｄａｔａ値とする。このように、最適なｄａｔａ値が用いられていると推察される過去の条件のうち最も近い条件と同じｄａｔａ値とすることで、今回のバッチ処理にかかる時間を削減することができる。
【００８２】
以下、図３、図１４乃至図２１用いて、ｄａｔａＵｎｉｔ値の導出処理について具体的に説明する。このようなｄａｔａＵｎｉｔ値の導出するタイミングとしては、Ｗｅｂアプリケーションの管理者が、バッチアプリを生成する前であればいつでも良い。
【００８３】
図１５は、事例定義リポジトリ管理部１８２に管理されている過去情報一覧を示す管理テーブルの一例である。図１６は、類似計算情報管理１８３に管理されている類似計算情報管理テーブル１６００の一例である。
【００８４】
図３に示すように開発用端末１０１には、ｄａｔａＵｎｉｔ値の導出部１８０が設けられており、ｄａｔａ値導出部１８０の事例定義リポジトリ管理部１８２には、これまでにバッチ処理として更新処理がなされた過去のバッチアプリケーションを作成した際の条件（バッチ入出力定義、データモデル定義、ビジネスプロセス定義）及び、その際に利用したｄａｔａＵｎｉｔ値が少なくとも記憶されている。すなわち、事例定義リポジトリ管理部１８２は、過去情報を複数記憶する更新事例記憶手段として用いられている。
【００８５】
過去情報は図１５に示すように過去の一覧がわかるように管理されており、本実施形態においては各管理テーブルを設けて管理している。例えば、本実施形態ではＩＤ１５１１とバッチ入出力コード１５１２、プロジェクトコード１５１３、ＸＭＬテキスト１５１４を管理する図１５（ａ）に示すようなバッチ入出力定義管理テーブル１５１０が設けられている。さらに、ＩＤ１５２１とデータモデルコード１５２２、プロジェクトコード１５２３、ＸＭＬテキスト１５２４を管理する図１５（ｂ）に示すようなデータモデル定義管理テーブル１５２０が設けられている。さらに、ＩＤ１５３１とビジネスプロセスコード１５３２、プロジェクトコード１５３３、ＸＭＬテキスト１５３４を管理する図１５（ｃ）に示すようなビジネスプロセス定義管理テーブルが設けられている。さらに、ＩＤ１５４１とバッチ入出力コード１５４２、ビジネスプロセスコード１５４３、プロジェクトコード１５４４とを管理する図１５（ｄ）に示すようなバッチ入出力定義−ビジネスプロセス定義関係テーブルが設けられている。さらに、ＩＤ１５５１とバッチ入出力コード１５５２、データモデルコード１５５３、プロジェクトコード１５５４とを管理する図１５（ｅ）に示すようなバッチ入出力定義−データモデル定義関係テーブルが設けられている。さらに、ＩＤ１５６１とビジネスプロセスコード１５６２、データモデルコード１５６３、プロジェクトコード１５６４とを管理する図１５（ｆ）に示すようなビジネスプロセス‐データモデル定義関係テーブルが設けられている。
【００８６】
図１７及び図１８は、過去情報として事例定義リポジトリ管理部１８２に管理されているバッチ入出力定義（図１７）、ビジネスプロセス定義（図１８（ａ））及びデータモデル定義（図１８（ｂ））の一例である。図１７及び図１８では、従業員登録のバッチアプリケーション『ＥＭＰＭＳＴ』生成処理時に用いられた、バッチ入出力定義、ビジネスプロセス定義及びデータモデル定義が示されている。
【００８７】
事例定義リポジトリ管理部１８２で実際に管理されている図１７（ａ）のバッチ入出力定義は、バッチアプリケーションの生成に用いられる図１１（ａ）に示すバッチ入出力定義とほぼ同じ内容であり、バッチ入出力定義は、コード１７０１と名前１７０２と、過去にバッチアプリケーション生成時に用いられたｄａｔａＵｎｉｔ値１７０３とが管理されており、さらに詳細な項目定義も管理されている。
【００８８】
さらに図１７（ｂ）のバッチ入出力定義‐項目は、図１１（ｂ）のバッチ入出力定義‐項目とほぼ同じ内容であり、項目タイプ１７１１、項目コード１７１２、名前１７１３、表示１７１４、加工式１７１５、次入出力１７１６、データモデルコード１７１７、データモデル項目コード１７１８が管理されている。
【００８９】
さらに、図１８（ａ）のビジネスプロセス‐ロジック一覧は、図６（ｂ）に示すＷｅｂアプリケーションの業務フローを定義するためのビジネスプロセス定義のビジネスプロセス‐ロジック一覧とほぼ同様であり、制御コード１８０１、データモデルコード１８０２、機能コード１８０３、パラメータ１８０４、作業コード１８０５が管理されている。
【００９０】
さらに、図１８（ｂ）のデータモデル定義‐項目は、図５（ｂ）のデータモデル定義‐項目とほぼ同様であり、項目コード１８１１、項目の名前１８１２、ＮＵＬＬを許可するか否かを設定する項目１８１３、桁数１８１４、データタイプ１８１５が管理されている。
【００９１】
以上のように、ｄａｔａ値導出部１８０の事例定義リポジトリ管理部１８２には、過去情報として、過去にバッチアプリケーション生成に使用した定義情報が蓄積されているといえる。このような過去情報の蓄積タイミングとしては、バッチアプリ生成部１６０でバッチアプリケーションが生成されたタイミングが好ましい。
【００９２】
そして、図３に示す類似計算情報管理部１８３には、これからバッチ処理を行う対象となるデータのデータ種に最も類似している更新事例を特定する際に用いる類似判定条件である類似計算情報が、図１６に示すような類似計算情報管理テーブル１６００として管理されている。
【００９３】
図１６の類似計算情報管理テーブル１６００には、ＩＤ１６０１、定義１６０２、条件１６０３、定義種別１６０４、類似対象１６０５、重み計数（Ｂ）１６０６、計算式１６０７からなる類似計算条件が、ＩＤごとに管理されている。ここで示す各計算式を類似計算項目と呼ぶ。重み計数（Ｂ）を設けて、計算式内に所定の重み変数を加えることで、類似計算項目の類似性について、差をつけることができる。この重み計数は任意に管理者が設定することができる。
【００９４】
そして、図３に示す類似計算部１８１では、蓄積された過去情報と、これから生成しようとするバッチアプリケーションのためのバッチアプリケーション定義部１５０で定義されているバッチ入出力定義１５１と、当該バッチアプリケーション生成時に用いるＷｅｂアプリケーション定義部で定義されているデータモデル定義１１２と、ビジネスプロセス定義１１３とを参照しつつ、類似計算情報管理テーブル１６００で管理される計算式を用いて、これから生成しようとするバッチアプリケーションの処理条件に最も類似する処理条件を特定する。
【００９５】
具体的には、図３の類似計算部１８１で、過去情報の処理条件とこれから生成するバッチアプリケーションの処理条件とを用いて、ＩＤごとに定義１６０２、条件１６０３、定義種別１６０４、類似対象１６０５を参照して特定された対象項目に対して、重み計数（Ｂ）１６０６及び計算式１６０７を用いて計算結果を算出する。その後全ＩＤ分（全計算式分）の計算結果を合算した合算値が、管理されている過去情報の処理条件とこれから生成するバッチアプリケーションの処理条件との類似度として用いられる。そして、このような類似度の算出を、過去情報の全てに対して行うことで、最も類似度が高い（もっとも類似性の高い）過去情報をとくていすることができる。
【００９６】
図１９は、類似計算部１８１によって取得されたこれからバッチアプリケーションの生成に用いられる、ｄａｔａＵｎｉｔ値の決定される前のバッチ入出力定義の一例である。ｄａｔａＵｎｉｔ値１１０３はまだ決定されていないため、空欄となっている。図２０は、これからバッチアプリケーションの生成に用いられる、ビジネスプロセス定義（図２０（ａ））及びデータモデル定義（図２０（ｂ））の一例を示す図である。
【００９７】
そして、図３に示す類似結果管理部１８５は、図２１のような類似結果管理テーブルとして情報類似結果を管理している。類似結果管理部１８５は、全ての過去情報のうち最も類似度の高い過去情報が特定された後に、当該過去情報のｄａｔａＵｎｉｔ値を、図１９に示すｄａｔａＵｎｉｔ値１１０３として設定する。
【００９８】
次に、上述した過去の実績から類似性の高い条件を特定しｄａｔａＵｎｉｔ値を設定までの流れを、図１４のフローチャートを用いてさらに詳細に説明する。
【００９９】
図１４は、バッチアプリケーションに用いられるｄａｔａＵｎｉｔ値を決定する際の流れを説明するためのフローチャートである。このような処理は、開発用端末１０１のＣＰＵ２０１が記憶されている制御プログラムを読み出して実行することにより実現される。具体的には、開発用端末１０１のＣＰＵ２０１が類似計算部１８１及び類似結果管理部１８５として機能して実行される。
【０１００】
まず、図１４のＳ１４０１では、開発用端末１０１のＣＰＵ２０１が類似計算情報管理部１８３の類似計算情報管理テーブル１６００（図１６）から類似計算情報を取得する。次に、Ｓ１４０２では、開発用端末１０１のＣＰＵ２０１が事例定義リポジトリ管理部１８２から、全事例定義リポジトリを取得する。具体的には、図１５に管理されている過去情報全ての、図１７及び図１８に示すようなバッチ入出力定義及びビジネスプロセス定義及びデータモデル定義を少なくとも取得する。
【０１０１】
次に、Ｓ１４０３では、開発用端末１０１のＣＰＵ２０１が、これからバッチアプリケーションを生成しようとしている件の定義である、バッチアプリケーション定義部１５０で定義されている図１９に示すようなバッチ入出力定義と、Ｗｅｂアプリケーション定義部１１０に定義されている図２０に示すようなデータモデル定義１１２及びビジネスプロセス定義を取得する。
【０１０２】
次に、Ｓ１４０４では、開発用端末１０１のＣＰＵ２０１が事例定義リポジトリ及びバッチ入出力定義ごとに対応した、これからバッチアプリケーションを生成する定義の条件（以下、アプリ未生成条件とも称する）と過去の定義条件との類似性を計算する。具体的には、類似計算情報管理テーブル１６００で管理された計算条件をもとに計算する。
【０１０３】
類似計算情報管理テーブル１６００の『ＩＤ１』の類似計算項目では、データモデル定義１６０２の『制御コードがＩＮ（入力データ処理）』のときの項目一覧がカラム数が一致するかを判断する計算条件であることを示している。ここでは、アプリ未生成条件のデータモデル定義のカラム数（Ｘ）と過去条件とのデータモデル定義のカラム数（Ｙ）が一致している場合には、重み計数Ｂを２倍し（すなわち５０×２＝１００）、一致していない場合には、Ｂ／｜Ｘ−Ｙ｜（すなわち５０／｜Ｘ−Ｙ｜）と計算することが定義されている。ここに示されている『ＩＤ１』〜『ＩＤ５』の類似計算項目について計算を行い、『ＩＤ１』〜『ＩＤ５』の計算結果を合算したものを類似度として算出する。
【０１０４】
ここで図１７及び１８に示す過去条件（ＥＭＰＭＳＴ＿ＤＭ：Ｙ）と、図１９及び２０に示すアプリ未生成条件（ＳＭＰＭＳＴ＿ＤＭ：Ｘ）と、図１６に示す計算式とを用い、類似度の算出方法を具体的に説明する。図１８（ｂ）のデータモデル定義からわかるようにＥＭＰＭＳＴ＿ＤＭのカラム数は６であり、レコード長は（２０＋２０＋２００＋２０＋１００）＊３＋２＝１０８２であるのに対し、図２０（ｂ）のデータモデル定義からわかるようにＳＭＰＭＳＴ＿ＤＭのカラム数は５であり、レコード長は（１０＋３０＋１００＋１００）＊３＋２＝７２２である。なお、ここでレコード長の計算はコード型、テキスト型は桁数ｘ３（バイト）である。また、ＢＯＯＬ型は桁数ｘ１（バイト）として計算する。つまり類似性計算結果は、５０＋１００００／（１０８２−７２２）＋２００＋４００００／（１０８２−７２２）＋１００＝４８９となる。すなわち、過去情報として記憶されたデータのデータ定義（すなわちデータ種）と、これからバッチアプリケーションを生成するデータ定義（すなわちデータ種）という２つのデータ種間の類似度は、４８９であると算出された。
【０１０５】
次に、Ｓ１４０５では、開発用端末１０１のＣＰＵ２０１が既に算出された類似性計算結果が記憶されている図２１に示す類似結果管理テーブル２１００を参照し、登録されている類似性計算結果を取得する。そして、Ｓ１４０６では、Ｓ１４０４で算出された類似性計算結果が、Ｓ１４０５で取得された類似性計算結果より大きいかを比較し、類似性が高いかどうかを判断する。
【０１０６】
Ｓ１４０６においてＳ１４０４で計算した過去情報の方が類似性が高いと判断した場合、すなわち類似性計算結果の値が計算値より大きい場合には、Ｓ１４０７に進み、Ｓ１４０４で計算した過去情報に対応するｄａｔａＵｎｉｔ値１７０３（図１７）を特定し、図２１に示す類似結果管理テーブル２１００で管理されるプロジェクトコード、バッチ入出力定義コード、類似性計算結果、ｄａｔａＵｎｉｔ値といった類似結果情報を更新する。
【０１０７】
一方、Ｓ１４０６においてＳ１４０４で計算した過去情報の方が類似性が高くないと判断した場合、すなわち類似性計算結果の値が計算値未満の場合には、Ｓ１４０７には進まずにＳ１４０４に戻る若しくはＳ１４０８に進む。
【０１０８】
このようなＳ１４０４乃至Ｓ１４０７の処理は、全ての事例定義リポジトリ及びバッチ入出力定義が完了するまで繰り返し行う。
【０１０９】
そして、全ての事例定義リポジトリ及びバッチ入出力定義に対する処理が終了した場合には、Ｓ１４０８に進み、開発用端末１０１のＣＰＵ２０１が類似結果管理部１８５として機能し、図２１に示す類似結果管理テーブル２１００に最終的に管理されているｄａｔａＵｎｉｔ値を、最も類似性の高い過去情報のｄａｔａＵｎｉｔ値として、これから生成しようとしているバッチアプリケーションのバッチ入出力定義のｄａｔａＵｎｉｔ値１１０３として入力し、設定を終了する。これにより、図１９（ａ）に示す定義の空欄が埋まるため、バッチアプリケーションを生成することができるようになる。
【０１１０】
つまり、このように設定されたｄａｔａＵｎｉｔ値は、これから生成しようとするバッチアプリケーションの処理条件に最も類似している、最適な処理条件で処理されているであろう過去条件のｄａｔａＵｎｉｔ値であるといえる。そのため、このｄａｔａＵｎｉｔ値を１トランザクション単位のデータの数として生成されたバッチアプリケーションは、更新処理に要する処理時間を削減できるバッチアプリケーションであるといえる。
【０１１１】
なお、本実施形態においては、Ｗｅｂアプリケーション及びバッチアプリケーションを自動生成するツールで生成されたバッチアプリケーションによるバッチ処理の際に、最適なｄａｔａＵｎｉｔ値を算出する仕組みを例に説明を行ったが、このような仕組みはアプリを自動生成するツールで生成されたバッチアプリケーション（プログラム）に限られず、バッチ処理するプログラムのいずれにも適用できることは言うまでもない。
【０１１２】
本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、１つの機器からなる装置に適用してもよい。
【０１１３】
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接、或いは遠隔から供給するものを含む。そして、そのシステム或いは装置の情報処理装置が前記供給されたプログラムコードを読み出して実行することによっても達成される場合も本発明に含まれる。
【０１１４】
したがって、本発明の機能処理を情報処理装置で実現する（実行可能とする）ために、前記情報処理装置にインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【０１１５】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。
【０１１６】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。
【０１１７】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。
【０１１８】
また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理を情報処理装置で実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【０１１９】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行して情報処理装置にインストールさせて実現することも可能である。
【０１２０】
また、情報処理装置が、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、情報処理装置上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
【０１２１】
さらに、記録媒体から読み出されたプログラムが、情報処理装置に挿入された機能拡張ボードや情報処理装置に接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。
【０１２２】
なお、前述した実施形態は、本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。即ち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
【符号の説明】
【０１２３】
１０１  開発用端末
１０２  サーバ
１０３  利用者用端末
１０４  バッチ処理端末
１３０  Ｗｅｂアプリケーション
１７０  バッチアプリケーション
１７１  バッチ処理部
１８０  ｄａｔａ値導出部
【図１】
2016051242.tif 000003
【図２】
2016051242.tif 000004
【図３】
2016051242.tif 000005
【図４】
2016051242.tif 000006
【図５】
2016051242.tif 000007
【図６】
2016051242.tif 000008
【図７】
2016051242.tif 000009
【図８】
2016051242.tif 000010
【図９】
2016051242.tif 000011
【図１０】
2016051242.tif 000012
【図１１】
2016051242.tif 000013
【図１２】
2016051242.tif 000014
【図１３】
2016051242.tif 000015
【図１４】
2016051242.tif 000016
【図１５】
2016051242.tif 000017
【図１６】
2016051242.tif 000018
【図１７】
2016051242.tif 000019
【図１８】
2016051242.tif 000020
【図１９】
2016051242.tif 000021
【図２０】
2016051242.tif 000022
【図２１】
2016051242.tif 000023