(57)【要約】【課題】業務処理システムに関するアプリケーション開発の生産性、メンテナンスの容易性、再利用性、仕様変更等に対する柔軟性を向上させる。【解決手段】業務処理の標準プログラムをスーパークラス１１〜１３に実装させるとともに、業務処理の修正時に修正プログラムが実装される空のサブクラス２１〜２３を当初から用意しておき、スーパークラス１１〜１３が実装する標準プログラムのメソッドを受け継いだサブクラス２１〜２３を順次実行するようにすることにより、業務処理のカスタマイズによって実装される修正プログラムＰＧ２’が標準プログラムＰＧ２と混ざらないようにして、標準プログラムをカスタマイズする際の工数を大幅に削減できるようにするとともに、バージョンアップの容易性、管理の容易性を向上させることができるようにする。【選択図】        図３
2004310279.tif 000002
【特許請求の範囲】
【請求項１】
業務処理の標準プログラムを実装するスーパークラス群と、個々のスーパークラスを継承したサブクラスであって、上記業務処理の修正時に修正プログラムが実装される当初は空のサブクラス群とによりインスタンス化されたオブジェクトを記憶するオブジェクト記憶手段と、
上記スーパークラス群に実装された上記標準プログラムのメソッドを受け継いだ上記サブクラス群を順次実行するように制御する制御手段とを備えたことを特徴とする業務処理システム。
【請求項２】
業務処理のプログラムを実装する複数のクラスがインスタンス化されたオブジェクトを記憶するオブジェクト記憶手段と、
ＸＭＬ形式のバリューオブジェクトで定義されたデータを上記複数のクラス間で受け渡しするように制御する制御手段とを備えたことを特徴とする業務処理システム。
【請求項３】
上記オブジェクト記憶手段は、イベント単位の一連の業務処理を制御し正規化されたトランザクションを実行するドメインマネージャと、業務ロジック単位に存在し個々の業務処理そのものを実行するビジネスロジックとを記憶し、
上記制御手段は、上記ドメインマネージャと上記ビジネスロジックとの間で、上記ＸＭＬ形式のバリューオブジェクトで定義されたデータ受け渡しするように制御することを特徴とする請求項２に記載の業務処理システム。
【請求項４】
業務処理に関する画面のデザインを定義したＸＨＴＭＬ形式の画面デザイン情報と、上記画面上に埋め込まれるデータを定義した上記ＸＭＬ形式のバリューオブジェクトとを用いて、変換ルールを定義したＸＳＬ形式の変換情報に従ってＸＳＬ変換を行うことにより、ＨＴＭＬ形式の画面を生成する画面生成手段を備えたことを特徴とする請求項２に記載の業務処理システム。
【請求項５】
データベースにアクセスする際に使用する複数の検索項目に関して、全ての検索項目を含むデータアクセスオブジェクトを記憶するオブジェクト記憶手段と、
上記データアクセスオブジェクトが持つ全ての検索項目のうち、ユーザにより実際に指定された検索項目に検索条件を設定し、対応するパターンの条件文を動的に生成して上記データベースに対するアクセスを実行するように制御する制御手段とを備えたことを特徴とする業務処理システム。
【請求項６】
画面遷移を起動するイベントおよび、どのイベントが発生したときにイベント情報の書き込みあるいは読み出しを行うかの区別を表したメタ情報を記憶するメタ情報記憶手段と、
上記画面遷移を起動するイベントが発生したときに、上記メタ情報記憶手段に記憶されているメタ情報に従って、上記画面遷移を行うために必要なイベント情報をキャッシュメモリに書き込むあるいは読み出すように制御するキャッシュ制御手段と、
上記キャッシュ制御手段により上記イベント情報の書き込みが行われるときには、実際に発生したイベントに従って上記画面遷移に関する処理を実行し、上記キャッシュ制御手段により上記イベント情報の読み出しが行われるときには、当該読み出されたイベント情報に従って上記画面遷移に関する処理を実行する画面遷移実行手段とを備えたことを特徴とする業務処理システム。
【請求項７】
業務処理の標準プログラムを実装するためのクラスを生成する際に、当該標準プログラムを実装するためのクラスをスーパークラスとして生成するとともに、そのスーパークラスを継承したサブクラスであって、上記業務処理の修正時に修正プログラムが実装される当初は空のサブクラスを生成するクラス生成手段と、
上記修正プログラムを実装する際に、上記サブクラスに実装するように制御する修正プログラム実装手段とを備えたことを特徴とする業務処理システムの構築支援装置。
【請求項８】
様々なＧＵＩ部品をエディタ画面上に貼り付けることによって画面の作成および編集を行う画面設計手段からの入力情報に基づいて、業務処理のオブジェクト間でやり取りするデータの構造体に関する定義情報を生成するバリューオブジェクト定義手段と、
上記バリューオブジェクト定義手段により生成されたバリューオブジェクトの定義情報に基づいて、画面内に配置された項目のデータを保持するためのＸＭＬ形式のバリューオブジェクトを生成するバリューオブジェクト生成手段とを備えたことを特徴とする業務処理システムの構築支援装置。
【請求項９】
上記画面設計手段からの入力情報に基づいて、画面に含まれる１以上の項目、各項目の属性および画面レイアウトに関する定義情報を生成する画面定義手段と、
上記画面定義手段により生成された画面の定義情報に基づいて、ＸＨＴＭＬ形式の画面デザインを生成する画面生成手段と、
上記画面生成手段により生成されたＸＨＴＭＬ形式の画面デザイン情報と、上記バリューオブジェクト生成手段により生成されたＸＭＬ形式のバリューオブジェクトとを用いてＨＴＭＬ形式の画面を生成する際の変換ルールを定義したＸＳＬ形式の変換情報を生成する変換情報生成手段とを備えたことを特徴とする請求項８に記載の業務処理システムの構築支援装置。
【請求項１０】
データベースにアクセスする際のＳＱＬ形式の命令文に関する定義情報を生成するＳＱＬ定義手段と、
上記ＳＱＬ定義手段により生成された定義情報に基づいて、上記データベースにアクセスするためのデータアクセスオブジェクトであって、上記データベースにアクセスする際に使用する複数の検索項目に関して、全ての検索項目を含むデータアクセスオブジェクトを生成するデータアクセスオブジェクト生成手段とを備えたことを特徴とする業務処理システムの構築支援装置。
【請求項１１】
様々なＧＵＩ部品をエディタ画面上に貼り付けることによって画面の作成および編集を行う画面設計手段からの入力情報に基づいて、画面に含まれる１以上の項目、各項目の属性および画面レイアウトに関する定義情報を生成する画面定義手段と、
上記画面定義手段により定義される各項目の属性中に含まれるイベントの設計定義情報に基づいて、画面遷移を起動するイベントおよびどのイベントが発生したときにイベント情報の書き込みあるいは読み出しを行うかの区別を表したメタ情報を生成するメタ情報生成手段とを備え、
上記メタ情報は、上記画面遷移を起動するイベントが発生したときに、当該画面遷移を行うために必要なイベント情報をキャッシュメモリに書き込むか読み出すかを特定するために使用され、上記イベント情報の読み出しが行われるときには当該読み出されたイベント情報に従って上記画面遷移に関する処理を実行するように成された情報であることを特徴とする業務処理システムの構築支援装置。
【請求項１２】
請求項１〜６の何れか１項に記載の各手段としてコンピュータを機能させるための業務処理システム用プログラム。
【請求項１３】
請求項７〜１１の何れか１項に記載の各手段としてコンピュータを機能させるための業務処理システムの構築支援用プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、業務処理システムおよびその構築支援装置、業務処理システム用プログラム、業務処理システムの構築支援用プログラムに関するものである。
【０００２】
【従来の技術】
従来、例えばＣＯＢＯＬなどの高級言語を用いてアプリケーションプログラムの開発を行う際には、構造化プログラミングという手法が用いられてきた。この手法では、パターン化が可能な処理手順や処理方式などを規定した汎用部品のソースコードが生成され、これが既存のプログラム資産として有効に再利用されてきた。
【０００３】
一方、近年では、オブジェクト指向プログラミングという手法で開発することが一般的になりつつある。オブジェクト指向は、継承と呼ばれる機能を有している。この継承機能を活用してソースコードを生成することにより、生成されたソースコードは、より容易かつ柔軟に再利用可能なものとなる。そのため、構造化プログラミング手法で生成されるソースコードと比べて、既存のプログラム資産としての再利用性が向上している。
【０００４】
このオブジェクト指向プログラミングの手法は、クライアントとサーバとから成るクライアントサーバシステムを開発する際に良く用いられる。クライアントサーバシステムの１つの形態として、受注処理、伝票処理、商品の在庫管理処理、会計処理などの各種企業業務を統合した業務処理システム（ＥＲＰ（Ｅｎｔｅｒｐｒｉｓｅ  Ｒｅｓｏｕｒｃｅ  Ｐｌａｎｎｉｎｇ）システムとも呼ばれる）がある。
【０００５】
最近の業務処理システムの殆どは、Ｗｅｂアプリケーションとして実現されている。Ｗｅｂアプリケーションは、Ｗｅｂブラウザを利用したＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）を備えているのが通常である。このようなＧＵＩを持つＷｅｂアプリケーションの開発には様々な試みがなされているが、扱うデータ量や画面数などが膨大な業務処理システムの場合には、再利用性や仕様変更に対する柔軟性に優れたＭＶＣモデルが有効である。
【０００６】
このＭＶＣモデルは、Ｍｏｄｅｌ（データ）、Ｖｉｅｗ（ユーザインタフェース）、Ｃｏｎｔｒｏｌｌｅｒ（制御部）の３種類のモデル要素に機能分解し、これらの組み合わせによりアプリケーションを実現するものである。図１１は、ＭＶＣモデルにて構築された従来のＷｅｂアプリケーションの構成例を示す図である。
【０００７】
図１１に示す業務処理システムは、Ｗｅｂ層（プレゼンテーション層）、ビジネスロジック層、データベース層の３層構造を有する３層Ｗｅｂクライアントサーバシステムとなっている。各層は、それぞれ特化した処理を行う。
【０００８】
Ｗｅｂ層に属するＷｅｂサーバは、物理的な画面編集を行うＶｉｅｗと、１つの画面内でイベントの制御を行うとともに、画面間の遷移を行うＣｏｎｔｒｏｌｌｅｒとを備えており、クライアントのＷｅｂブラウザを制御する。また、ビジネスロジック層に属するアプリケーションサーバは、Ｃｏｎｔｒｏｌｌｅｒからの命令に従って必要なデータをデータベース（ＤＢ）から取り出してＶｉｅｗに渡すといった一連の業務処理を制御するＭｏｄｅｌを備えている。
【０００９】
【発明が解決しようとする課題】
最近の業務処理システムは、業務の複雑化に伴って複雑な仕様が求められるようになってきており、これを実現するアプリケーションは大規模なものとなっている。しかも、そのような大規模なシステムを短期間で構築することが望まれている。しかしながら、従来はアプリケーションの開発が殆ど手作りで行われていた。また、多人数の開発者によってプログラムを分割して作成する場合には、プログラム全体の一貫性を保つのも難しくなる。そのため、漏れや誤りなどの不良部分が多くなり、これを修正する作業も増えるため、システム開発の生産性が上がらないという問題があった。
【００１０】
また、業務処理システムが対象とする業務の中には、仕様変更が頻繁に発生する業務も多い。また、業務処理システムを顧客に標準パッケージとして提供する場合には、提供された業務処理システムを顧客の要求に応じてカスタマイズする必要がある。これらの場合には、仕様変更や顧客の要求に対応して、業務処理システムを柔軟かつ容易に変更できることが望まれる。しかしながら、手作りで生成されたアプリケーションは構造が非常に複雑になっていることが多く、１箇所変更した場合の影響範囲を探すだけでも多くの手間と時間を要する。そのため、メンテナンスの効率が極めて悪いという問題もあった。
【００１１】
さらに、業務処理システムの標準パッケージを顧客の要求に応じてカスタマイズすると、元の標準パッケージが機能の追加や変更等によりバージョンアップしても、それに合わせて顧客のシステムをバージョンアップすることができなくなってしまう。顧客のシステムをバージョンアップするためには、旧バージョンのカスタマイズ済みシステムを破棄して新バージョンの標準パッケージを導入し、これを顧客の要求に応じて再びカスタマイズする必要があった。このため、顧客には多大な出費を強いるとともに、再度システムをカスタマイズする手間がかかるという問題があった。
【００１２】
本発明は、このような問題を解決するために成されたものであり、業務処理システムに関するアプリケーション開発の生産性、メンテナンスの容易性、再利用性、仕様変更等に対する柔軟性を向上させることができるようにすることを目的とする。
【００１３】
【課題を解決するための手段】
本発明の業務処理システムは、業務処理の標準プログラムを実装するスーパークラス群と、個々のスーパークラスを継承したサブクラスであって、上記業務処理の修正時に修正プログラムが実装される当初は空のサブクラス群とによりインスタンス化されたオブジェクトを記憶するオブジェクト記憶手段と、上記スーパークラス群に実装された上記標準プログラムのメソッドを受け継いだ上記サブクラス群を順次実行するように制御する制御手段とを備えたことを特徴とする。
【００１４】
本発明の他の態様では、業務処理のプログラムを実装する複数のクラスがインスタンス化されたオブジェクトを記憶するオブジェクト記憶手段と、ＸＭＬ形式のバリューオブジェクトで定義されたデータを上記複数のクラス間で受け渡しするように制御する制御手段とを備えたことを特徴とする。
【００１５】
本発明の他の態様では、上記オブジェクト記憶手段は、イベント単位の一連の業務処理を制御し正規化されたトランザクションを実行するドメインマネージャと、業務ロジック単位に存在し個々の業務処理そのものを実行するビジネスロジックとを記憶し、上記制御手段は、上記ドメインマネージャと上記ビジネスロジックとの間で、上記ＸＭＬ形式のバリューオブジェクトで定義されたデータ受け渡しするように制御することを特徴とする。
【００１６】
本発明の他の態様では、業務処理に関する画面のデザインを定義したＸＨＴＭＬ形式の画面デザイン情報と、上記画面上に埋め込まれるデータを定義した上記ＸＭＬ形式のバリューオブジェクトとを用いて、変換ルールを定義したＸＳＬ形式の変換情報に従ってＸＳＬ変換を行うことにより、ＨＴＭＬ形式の画面を生成する画面生成手段を備えたことを特徴とする。
【００１７】
本発明の他の態様では、データベースにアクセスする際に使用する複数の検索項目に関して、全ての検索項目を含むデータアクセスオブジェクトを記憶するオブジェクト記憶手段と、上記データアクセスオブジェクトが持つ全ての検索項目のうち、ユーザにより実際に指定された検索項目に検索条件を設定し、対応するパターンの条件文を動的に生成して上記データベースに対するアクセスを実行するように制御する制御手段とを備えたことを特徴とする。
【００１８】
本発明の他の態様では、画面遷移を起動するイベントおよび、どのイベントが発生したときにイベント情報の書き込みあるいは読み出しを行うかの区別を表したメタ情報を記憶するメタ情報記憶手段と、上記画面遷移を起動するイベントが発生したときに、上記メタ情報記憶手段に記憶されているメタ情報に従って、上記画面遷移を行うために必要なイベント情報をキャッシュメモリに書き込むあるいは読み出すように制御するキャッシュ制御手段と、上記キャッシュ制御手段により上記イベント情報の書き込みが行われるときには、実際に発生したイベントに従って上記画面遷移に関する処理を実行し、上記キャッシュ制御手段により上記イベント情報の読み出しが行われるときには、当該読み出されたイベント情報に従って上記画面遷移に関する処理を実行する画面遷移実行手段とを備えたことを特徴とする。
【００１９】
また、本発明による業務処理システムの構築支援装置は、業務処理の標準プログラムを実装するためのクラスを生成する際に、当該標準プログラムを実装するためのクラスをスーパークラスとして生成するとともに、そのスーパークラスを継承したサブクラスであって、上記業務処理の修正時に修正プログラムが実装される当初は空のサブクラスを生成するクラス生成手段と、上記修正プログラムを実装する際に、上記サブクラスに実装するように制御する修正プログラム実装手段とを備えたことを特徴とする。
【００２０】
本発明の他の態様では、様々なＧＵＩ部品をエディタ画面上に貼り付けることによって画面の作成および編集を行う画面設計手段からの入力情報に基づいて、業務処理のオブジェクト間でやり取りするデータの構造体に関する定義情報を生成するバリューオブジェクト定義手段と、上記バリューオブジェクト定義手段により生成されたバリューオブジェクトの定義情報に基づいて、画面内に配置された項目のデータを保持するためのＸＭＬ形式のバリューオブジェクトを生成するバリューオブジェクト生成手段とを備えたことを特徴とする。
【００２１】
本発明の他の態様では、上記画面設計手段からの入力情報に基づいて、画面に含まれる１以上の項目、各項目の属性および画面レイアウトに関する定義情報を生成する画面定義手段と、上記画面定義手段により生成された画面の定義情報に基づいて、ＸＨＴＭＬ形式の画面デザインを生成する画面生成手段と、上記画面生成手段により生成されたＸＨＴＭＬ形式の画面デザイン情報と、上記バリューオブジェクト生成手段により生成されたＸＭＬ形式のバリューオブジェクトとを用いてＨＴＭＬ形式の画面を生成する際の変換ルールを定義したＸＳＬ形式の変換情報を生成する変換情報生成手段とを備えたことを特徴とする。
【００２２】
本発明の他の態様では、データベースにアクセスする際のＳＱＬ形式の命令文に関する定義情報を生成するＳＱＬ定義手段と、上記ＳＱＬ定義手段により生成された定義情報に基づいて、上記データベースにアクセスするためのデータアクセスオブジェクトであって、上記データベースにアクセスする際に使用する複数の検索項目に関して、全ての検索項目を含むデータアクセスオブジェクトを生成するデータアクセスオブジェクト生成手段とを備えたことを特徴とする。
【００２３】
本発明の他の態様では、様々なＧＵＩ部品をエディタ画面上に貼り付けることによって画面の作成および編集を行う画面設計手段からの入力情報に基づいて、画面に含まれる１以上の項目、各項目の属性および画面レイアウトに関する定義情報を生成する画面定義手段と、上記画面定義手段により定義される各項目の属性中に含まれるイベントの設計定義情報に基づいて、画面遷移を起動するイベントおよびどのイベントが発生したときにイベント情報の書き込みあるいは読み出しを行うかの区別を表したメタ情報を生成するメタ情報生成手段とを備え、上記メタ情報は、上記画面遷移を起動するイベントが発生したときに、当該画面遷移を行うために必要なイベント情報をキャッシュメモリに書き込むか読み出すかを特定するために使用され、上記イベント情報の読み出しが行われるときには当該読み出されたイベント情報に従って上記画面遷移に関する処理を実行するように成された情報であることを特徴とする。
【００２４】
また、本発明の業務処理システム用プログラムは、請求項１〜６の何れか１項に記載の各手段としてコンピュータを機能させるためのプログラムであることを特徴とする。
【００２５】
また、本発明の業務処理システムの構築支援用プログラムは、請求項７〜１１の何れか１項に記載の各手段としてコンピュータを機能させるためのプログラムであることを特徴とする。
【００２６】
【発明の実施の形態】
以下、本発明の一実施形態を図面に基づいて説明する。図１は、本実施形態による業務処理システムの概略構成を示す図である。図１に示すように、本実施形態の業務処理システムは、クライアント層に相当するクライアント１、プレゼンテーション層および制御層に相当するＷｅｂサーバ２、ドメインモデル層に相当するＷｅｂアプリケーションサーバ３、データベース層に相当するＤＢサーバ４を備えて構成されている。
【００２７】
クライアント１上ではブラウザ１ａが動作し、Ｗｅｂサーバ２を通じてＧＵＩを含む種々のＷｅｂページを取得して表示することが可能である。すなわち、クライアント１のブラウザ１ａは、Ｗｅｂサーバ２に対してＨＴＭＬ情報の送信を要求する。このＨＴＭＬ情報の送信要求を受けたＷｅｂサーバ２は、Ｗｅｂアプリケーションサーバ３を介してＤＢサーバ４に問い合わせを行い、要求に対応する必要なデータを取得する。そして、取得したデータを用いてＷｅｂページを構成し、ＨＴＭＬソースコードとしてブラウザ１ａに返送する。ブラウザ１ａは、Ｗｅｂサーバ２から受け取ったＨＴＭＬソースコードを解析し、そのソースコード中に含まれる情報を画面表示する。
【００２８】
Ｗｅｂサーバ２は、クライアント１からの要求に応じて、Ｗｅｂアプリケーションサーバ３およびＤＢサーバ４と共に動作し、要求元のクライアント１が持つブラウザ１ａに対して各種のＷｅｂページを提供する。このＷｅｂサーバ２には、物理的な画面編集を行うＶｉｅｗ（ユーザインタフェース）２ａと、１つの画面内でイベントの制御を行うとともに、画面間の遷移を行うＣｏｎｔｒｏｌｌｅｒ（制御部）２ｂとが含まれている。これらのユーザインタフェース２ａおよび制御部２ｂは、クライアント１から要求があったときに起動する。
【００２９】
Ｗｅｂアプリケーションサーバ３は、受注、伝票処理、商品の在庫管理、会計などの様々な業務に特化した処理を行う。具体的には、Ｗｅｂサーバ２からの要求を受けてデータベース検索を行い、その結果をＷｅｂサーバ２に通知する処理を行う。このように、Ｗｅｂサーバ２から業務部分を専門に行うＷｅｂアプリケーションサーバ３を独立させることにより、Ｗｅｂサーバ２がクライアント１の窓口処理に専念できる環境を作っている。
【００３０】
本実施形態では、Ｗｅｂアプリケーションサーバ３をドメインマネージャ３ａとビジネスロジック３ｂとの２層に機能分解しているところに特徴がある。ドメインマネージャ３ａは、イベント単位の一連の業務処理を制御するものであり、正規化されたトランザクションを実行する。正規化されたトランザクションとは、例えば要求に対応するビジネスロジック３ｂを起動する処理を言い、業務ロジックの内容によらず汎用化できるものである。
【００３１】
一方、ビジネスロジック３ｂは、オブジェクト設計にて抽出された業務ロジック単位に存在し、個々の業務処理そのものを実行する。このビジネスロジック３ｂは、顧客の実際の業務に合わせて作り込まれる部分であり、各顧客に特有の業務ロジックが実装される。これらのドメインマネージャ３ａおよびビジネスロジック３ｂは、複数のコンポーネント（部品）として存在する。
【００３２】
ＤＢサーバ４は、Ｗｅｂアプリケーションサーバ３からの要求に応じてデータベース４ａの検索を行い、その結果取り出したデータをＷｅｂアプリケーションサーバ３に提供する処理を行う。
【００３３】
以上のような構成において、ユーザインタフェース２ａ、制御部２ｂおよびドメインマネージャ３ａについては、これらの設計定義情報をもとにソースコードを自動的に生成する。従来はドメインマネージャ３ａとビジネスロジック３ｂとが一体となってＭｏｄｅｌが構成され（図１１参照）、そこには顧客特有の汎用化できない業務ロジックが含まれていたため、Ｍｏｄｅｌを自動生成することはできなかった。これに対して、本実施形態では、Ｍｏｄｅｌをドメインマネージャ３ａとビジネスロジック３ｂとに切り分けることにより、少なくともドメインマネージャ３ａについては自動生成ができるようにしている。
【００３４】
また、制御部２ｂとドメインマネージャ３ａとの間でやり取りするデータを保持するためのバリューオブジェクト（ＶＯ）や、ドメインマネージャ３ａとビジネスロジック３ｂとの間でやり取りするデータを保持するためのバリューオブジェクト（ＶＯ）、ビジネスロジック３ｂがデータベース４ａにアクセスする際に使用するデータアクセスオブジェクト（ＤＡＯ）も、それらの設計定義情報をもとに自動的に生成する。
【００３５】
以下に、これらの自動生成の仕組みについて説明する。図２は、本実施形態による業務処理システム１００およびその構築支援装置２００の構成例を示す図である。なお、この図２において、図１に示した機能ブロックと同一の機能を有する部分には同一の符号を付して示している。
【００３６】
図２において、画面エディタ３００は、キーボードやマウスなどを用いて、各種ボタン、チェックボックス、リストボックス、ラジオボタン、コンボボックス、テキストボックス等の様々なＧＵＩ部品をエディタ画面上に貼り付けることによって画面の作成および編集ができるようにした画面設計支援ツールである。画面定義部１１は、画面に含まれる１以上の項目や各項目の属性（長さ、タイプ、イベント等）、画面レイアウト等を定義する。この画面設計定義情報は、画面エディタ３００の入力情報に基づいてジェネレートする。
【００３７】
ここで、ジェネレートとは、入力情報を所定の変換規則に従って変換し、その結果を出力すること言う。入力情報には、出力情報を得るために必要なデータ項目の他に、変換規則中のどのパターンで変換を行うのかの変換パターン名も含まれる。変換規則には複数の変換パターンが含まれ、変換パターン毎に異なるフォーマット変換のルールが記述されている。ジェネレートの実行時は、入力情報によって指定される変換パターンを探索し、そこに記述されている変換規則に従って、あらかじめ定められたフォーマットに入力情報を変換する。このジェネレートの意味は、他の機能ブロックでも同様である。
【００３８】
画面生成部１２は、画面定義部１１より出力される画面レイアウトの設計定義情報に基づいて、ユーザインタフェース２ａに相当するＸＨＴＭＬ（ｅＸｔｅｎｓｉｂｌｅ  ＨｙｐｅｒＴｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）形式の画面や帳票等のデザイン（どの項目をどこに配置するか等のレイアウトだけを決めた雛形）をジェネレートする。ユーザは、ここでジェネレートされた画面デザイン２ａをＨＴＭＬエディタ（図示せず）によって手作業で編集することにより、完成版を作成する。
【００３９】
なお、ＸＨＴＭＬは、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）をＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）形式に合わせて修正したものであり、任意のタグ名称を使用できる、データの階層構造をそのまま定義できる、などのＸＭＬの利点を活かすことが可能である。
【００４０】
フレームワーク生成部１３は、画面定義部１１より出力されるイベント（画面に対する操作）等の設計定義情報に基づいて、イベントに応じて使用するバリューオブジェクト５ａとドメインマネージャ３ａとを決定するためのメタ情報をジェネレートする。ここでジェネレートされたメタ情報は、制御部２ｂを構成するフレームワークにおいて保持される。フレームワーク２ｂは、当該メタ情報に基づいて、１つの画面内で発生するイベントを検出し、発生したイベントに対応するバリューオブジェクト５ａとドメインマネージャ３ａとを起動して画面の遷移を行うこととなる。
【００４１】
ＶＯ定義部１４は、画面エディタ３００の入力情報に基づいて、Ｗｅｂサーバ２の制御部（フレームワーク）２ｂとＷｅｂアプリケーションサーバ３のドメインマネージャ３ａとの間でやり取りするデータの構造体に関する定義情報をジェネレートする。この構造体は、Ｊａｖａ（登録商標）の世界ではバリューオブジェクトと呼ばれる。ＶＯ生成部１５は、ＶＯ定義部１４より出力されるバリューオブジェクトの設計定義情報に基づいて、各画面内に配置された項目のデータを保持するためのＸＭＬ形式のバリューオブジェクト５ａ（データの入れ物）をジェネレートする。
【００４２】
ビジネスルール設計ツール４００は、キーボードやマウスなどを用いて様々なＧＵＩ部品をエディタ画面に貼り付けることによって、ビジネスフローダイアグラムやデータフローダイアグラム等を作成および編集するビジネスルール定義の支援ツールである。なお、ビジネスフローダイアグラムとは、組織と業務手順とを軸にして、処理の内容と入出力の流れとを記述した流れ図を言う。また、データフローダイアグラムとは、各業務で使用するデータとデータ処理（プロセス）とを記述した流れ図を言う。
【００４３】
ＤＭ定義部１６は、ビジネスルール設計ツール４００の入力情報に基づいて、ドメインマネージャ３ａが実行するビジネスロジック３ｂの呼び出しの順序、ビジネスロジック３ｂの呼び出しロジック（例えば、ｉｆ分岐やループ等）に関する設計定義情報をジェネレートする。ＤＭ生成部１７は、ＤＭ定義部１６より出力される設計定義情報に基づいて、トランザクション単位にビジネスロジック３ｂを起動するドメインマネージャ３ａをジェネレートする。
【００４４】
ＢＬ定義部１８は、ビジネスルール設計ツール４００の入力情報に基づいて、ビジネスロジック３ｂで使用するデータの項目とその属性に関する設計定義情報をジェネレートする。ＶＯ生成部１９は、ＢＬ定義部１８より出力される設計定義情報に基づいて、ビジネスロジック３ｂに入出力するデータを保持するためのＸＭＬ形式のバリューオブジェクト５ｂをジェネレートする。
【００４５】
ＤＢ設計ツール５００は、例えばＥＲ図からデータベース４ａのテーブルを設計するための支援ツールである。このＤＢ設計ツール５００は、データ項目単位で整合性を図るためにデータ分析をしたり、データベース４ａにアクセスする際のＳＱＬ文を設計したりする機能を備えている。
【００４６】
ＳＱＬ定義部２０は、ＤＢ設計ツール５００の入力情報に基づいて、データベース４ａにアクセスする際のＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）形式の命令文に関する設計定義情報をジェネレートする。ＤＡＯ生成部２１は、ＳＱＬ定義部２０より出力される設計定義情報に基づいて、ビジネスロジック３ｂからデータベース４ａにアクセスするためのＤＡＯ（Ｄａｔａ  Ａｃｃｅｓｓ  Ｏｂｊｅｃｔ）６をジェネレートする。
【００４７】
ＤＢ定義部２２は、ＤＢ設計ツール５００の入力情報に基づいて、データベース４ａのテーブルに関する設計定義情報をジェネレートする。ＤＤＬ等生成部２３は、ＤＢ定義部２２より出力される設計定義情報に基づいて、データベース４ａを構成するテーブル全体の作成・変更・削除などを行うためのＤＤＬ（Ｄａｔａ  Ｄｅｆｉｎｉｔｉｏｎ  Ｌａｎｇｕａｇｅ）や、テーブル内のレコードの追加・検索・更新・削除などを行うためのＤＭＬ（Ｄａｔａ  Ｍａｎｉｐｕｌａｔｉｏｎ  Ｌａｎｇｕａｇｅ）をジェネレートする。
【００４８】
変更管理部２４は、ビジネスロジック３ｂのソースコードの変更（修正）情報を登録し、当該ソースコードの変更を管理する。この変更管理の詳細を、図３を用いて説明する。ここでは図３（ａ）に示すように、あるビジネスロジック３ｂにおいて、入力したデータを処理して出力するのに３つのプログラム（オブジェクト）ＰＧ１，ＰＧ２，ＰＧ３を順に実行する場合を考える。
【００４９】
開発者がプログラムを書くと、変更管理部２４は、その書かれたプログラムをスーパークラスに定義するとともに、それから継承される空の容器であるサブクラスを自動生成する。すなわち、開発者が図３（ａ）のように３つのプログラムＰＧ１，ＰＧ２，ＰＧ３を書いた場合、それらは継承関係の親となる３つのスーパークラス１０１〜１０３として実装される。また、これらスーパークラス１０１〜１０３を継承してそれぞれの子となるサブクラス２０１〜２０３が自動的に生成される。
【００５０】
そして、変更管理部２４は、このように自動生成したサブクラス２０１〜２０３を順次実行することによって一連の処理を行うように定義しておく。このように変更管理部２４は、スーパークラス１０１〜１０３とサブクラス２０１〜２０３との親子関係を管理する。サブクラス２０１〜２０３は変更管理部２４によって自動生成されるので、開発者にとっては普通にプログラムを書くのと変わりがなく、手間は増えない。
【００５１】
以上のように実装した場合、実際には図３（ａ）の点線矢印で示すような動きで３つのプログラムＰＧ１，ＰＧ２，ＰＧ３が動作する。すなわち、最初にサブクラス２０１が参照されるが、ここは中身が空のままである。しかし、このサブクラス２０１では、その親であるスーパークラス１０１を参照して処理を実行する。これにより、スーパークラス１０１に実装されたプログラムＰＧ１が実行され、その処理結果がサブクラス２０１から次のサブクラス２０２に引き渡されることになる。
【００５２】
サブクラス２０２も中身が空であるが、ここではその親であるスーパークラス１０２を参照して処理を実行する。これにより、スーパークラス１０２に実装されたプログラムＰＧ２が実行され、その処理結果が次のサブクラス２０３に引き渡されることになる。サブクラス２０３でも同様に、その親であるスーパークラス１０３に実装されたプログラムＰＧ３を実行し、その処理結果を出力する。
【００５３】
このように、本実施形態では当初からサブクラス２０１〜２０３を生成してこれを実行するように定義するが、その中身は空にしておき、親であるスーパークラス１０１〜１０３にプログラムＰＧ１，ＰＧ２，ＰＧ３を実装する。これにより、スーパークラス１０１〜１０３に相当する部分しか持たない普通のオブジェクトと同様に処理を行うことができる。業務処理システムを顧客にパッケージとして提供する場合には、図３（ａ）のように実装した状態で提供する。
【００５４】
一方、このようなパッケージの提供を受けた顧客が、自分の業務内容に合わせてビジネスロジック３ｂをカスタマイズする場合や、仕様変更に応じてビジネスロジック３ｂを修正する場合には、その修正内容はサブクラス２０１〜２０３に実装する。例えば、図３（ｂ）に示すように、標準プログラムＰＧ２に修正を加える場合は、その修正プログラムＰＧ２’をサブクラス２０２に実装する。このとき変更管理部２４は、修正プログラムＰＧ２’をサブクラス２０２に実装するように制御するとともに、標準プログラムＰＧ２と修正プログラムＰＧ２’との差分内容を管理する。
【００５５】
この図３（ｂ）のようにカスタマイズした場合も、プログラム実行の動きは図３（ａ）の場合と変わらない。ただし、サブクラス２０２には修正プログラムＰＧ２’が書かれているので、スーパークラス１０２に実装されているプログラムＰＧ２を引き継ぎつつ、修正部分については修正プログラムＰＧ２’の処理を実行することになる。
【００５６】
図３（ｃ）のように、当初実装されていなかったプログラムＰＧ４を新規で実装することも可能である。この場合は、変更管理部２４によって新たにスーパークラス１０４とサブクラス２０４とが追加され、追加のプログラムＰＧ４はサブクラス２０４に実装される。スーパークラス１０４は空のままである。この場合、サブクラス２０４では自身に実装されているプログラムＰＧ４をそのまま実行し、その処理結果を次のサブクラス２０３に出力することになる。
【００５７】
図４は、従来のカスタマイズ法を示す図である。図４（ａ）に示すように、従来は、大元の標準プログラムＰＧ２を修正プログラムＰＧ２”に書き換えてしまうやり方が一般的であった。この場合は、修正したプログラムＰＧ２”に合わせて他のプログラムＰＧ１，ＰＧ３も多少の修正を加える必要がある。そのため、元の標準パッケージの状態が殆ど維持できなくなってしまう。顧客毎にこのようなカスタマイズを行うと、標準パッケージと異なるプログラムが多数出来上がることになる。この場合にパッケージ提供者は、これら全てのプログラムを管理する必要があり、プログラム管理が極めて煩雑になってしまう。
【００５８】
また、図４（ｂ）に示すように、修正しようとするプログラムＰＧ２についてのみサブクラスを新たに定義し、そのサブクラスに修正プログラムＰＧ２’を実装する方法もあった。しかし、この場合は、プログラムＰＧ１からの呼び先を標準プログラムＰＧ２から修正プログラムＰＧ２’に変更する必要がある。また、プログラムＰＧ３への呼び元も、標準プログラムＰＧ２から修正プログラムＰＧ２’に変更する必要がある。そのため、プログラムＰＧ１，ＰＧ３のインタフェース部分も合わせて修正しなければならなかった。
【００５９】
これに対して、図３に示す本実施形態によれば、標準パッケージとして提供したプログラムＰＧ１，ＰＧ２，ＰＧ３には一切手を加える必要がない。すなわち、例えばプログラムＰＧ２を修正したい場合でも、スーパークラス１０２の標準プログラムＰＧ２はそのままに、サブクラス２０２に修正プログラムＰＧ２’を書くだけで、その差分が活かされるようになる。また、サブクラス２０２に修正プログラムＰＧ２’が書かれた場合でも、そのサブクラス２０２が元々呼ばれるように設定されているので、スーパークラス１０１，１０３のプログラムＰＧ１，ＰＧ３についても何ら修正を加える必要がない。
【００６０】
これにより、標準パッケージのプログラムをカスタマイズする際の工数を大幅に削減することができる。また、パッケージ提供先の顧客が多数あって、それぞれの顧客で異なるカスタマイズをするような場合にも、パッケージ提供元では基本的に標準パッケージのプログラムのみを管理していれば良く、図４のような手法によって顧客毎に変えられたプログラムを１つ１つ管理する必要がなくなる。よって、プログラム管理が非常に容易になる。
【００６１】
さらに、標準パッケージそのものがバージョンアップされた場合、顧客では、サブクラス２０１〜２０３の修正プログラムはそのまま使い、スーパークラス１０１〜１０３の標準プログラムだけを入れ替えれば良い。この場合、バージョンアップされた標準プログラムのメソッドをサブクラス２０１〜２０３が引き継ぎながら、既存の修正プログラムを動かすことができる。よって、顧客毎に修正が加えられた後でもバージョンアップが容易にできるというメリットも有する。
【００６２】
次に、図２に示す制御部（フレームワーク）２ｂの一機能について説明する。図５に示すように、フレームワーク２ｂは、ＸＳＬＴ（ｅＸｔｅｎｓｉｂｌｅ  Ｓｔｙｌｅｓｈｅｅｔｓ  Ｌａｎｇｕａｇｅ  Ｔｒａｎｓｆｏｒｍａｔｉｏｎ）プロセッサ３２を備え、全ての画面のＩ／Ｏを行う。画面のＩ／Ｏには、画面上のどこに何の項目を配置するか等のレイアウトだけを決めたＸＨＴＭＬ形式の画面デザイン２ａと、その画面上に埋め込まれるＸＭＬ形式の画面データであるバリューオブジェクト５ａと、ＸＳＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｓｔｙｌｅｓｈｅｅｔｓ  Ｌａｎｇｕａｇｅ）で書かれた変換情報３１とを使用する。
【００６３】
すなわち、ＸＳＬＴプロセッサ３２は、画面で発生したイベントをトリガとして情報取得機能を起動し、空のバリューオブジェクト５ａに画面データを取り込む。このとき取り込む画面データは、ドメインマネージャ３ａでビジネスロジック３ｂのクラスによって集められたデータである。その後、マッピング機能が起動し、変換情報３１をもとに、画面デザイン２ａとバリューオブジェクト５ａの画面データとを用いてＸＳＬ変換を行うことにより、ブラウザ１ａで閲覧可能なＨＴＭＬ形式の画面３３を生成する。
【００６４】
図６は、本実施形態による画面生成の一例を示す図である。図６において、画面デザイン２ａは、コンボボックスのレイアウトだけを定義したものであり、コンボボックスの項目名が例えば“ｔｏｄｏｆｕｋｅｎ１”と付けられている。このコンボボックスに埋め込むデータは、バリューオブジェクト５ａに定義されている。ここで、＜ｔｏｄｏｆｕｋｅｎ１＞のタグで示された部分には、コンボボックスで実際に選択されたデータが入る。また、＜ｏｐｔｉｏｎ＞のタグで示された部分には、データベース４ａから取得してくるデータが属性として記述されている。
【００６５】
ＸＳＬＴプロセッサ３２は、コンボボックスが操作されたことをトリガとして情報取得機能を起動し、＜ｏｐｔｉｏｎ＞で示されるデータをデータベース４ａからバリューオブジェクト５ａに取り込む。そして、マッピング機能を起動し、データを取り込んだバリューオブジェクト５ａと画面デザイン２ａとを用いてＸＳＬ変換を行うことにより、コンボボックス内に実際に都道府県のデータが入力されたＨＴＭＬ形式の画面３３を生成する。
【００６６】
図７は、本実施形態による画面生成の他の例を示す図である。図７において、画面デザイン２ａは、一覧表のレイアウトだけを定義したものであり、一覧表の項目名が例えば“ｔｏｄｏｆｕｋｅｎ２”と付けられている。この一覧表に埋め込むデータは、バリューオブジェクト５ａに定義されている。ここで、＜ｔｏｄｏｆｕｋｅｎ２＞のタグで示された部分には、一覧表で実際に選択されたコードが入る。また、＜ｏｐｔｉｏｎ＞のタグで示された部分には、データベース４ａから取得してくるデータに対応するコードが属性として記述されている。
【００６７】
ＸＳＬＴプロセッサ３２は、一覧表の表示要求が成されたことをトリガとして情報取得機能を起動し、＜ｏｐｔｉｏｎ＞で示されるコードに対応するデータをデータベース４ａからバリューオブジェクト５ａに取り込む。そして、マッピング機能を起動し、データを取り込んだバリューオブジェクト５ａと画面デザイン２ａとを用いてＸＳＬ変換を行うことにより、コードと都道府県名とを対応付けた一覧表を有するＨＴＭＬ形式の画面３３を生成する。さらに、ＸＳＬＴプロセッサ３２は、この一覧表の中から何れかのコードが選択されると、次に遷移した画面３３’では、そのコードを対応する都道府県名のデータに置き換えて表示する。
【００６８】
ここで説明したように、本実施形態では、画面デザイン２ａをＸＨＴＭＬで作成し、その画面に貼り付ける画面データであるバリューオブジェクト５ａをＸＭＬで作成しておくことにより、ＸＳＬの簡単な変換情報３１によって画面表示を行うようにしている。これにより、画面デザイン２ａと、画面データ（バリューオブジェクト５ａ）と、画面コントロールを行うロジック（ＸＳＬＴプロセッサ３２）とを完全に切り分けることができる。
【００６９】
これに対して従来は、図８に示すように、Ｗｅｂサーバ４１上で実行されるモジュール化されたＪａｖａプログラムであるサーブレット４２において、画面デザイン４２ａと、画面データ４２ｂと、ロジック（画面へのデータ入力、入力データのチェック、データの加工、データベースに対するデータの伝達などを行うプログラム）４２ｃとが１つのモジュールとして記述されていた。
【００７０】
図８に示す従来のシステムでは、Ｗｅｂアプリケーションサーバ４５は、ソフトウェアをオブジェクト化して統合するＥＪＢ（Ｅｎｔｅｒｐｒｉｓｅ  ＪａｎａＢｅａｎｓ）コンテナ４６を備えている。この中に作成された数種類のビジネスロジックは、ＥＪＢコンポーネント４６ａとしてＥＪＢコンテナ４６上で動作する。ＷｅｂブラウザからＷｅｂサーバ４１に画面表示の要求が与えられると、Ｗｅｂサーバ２ではサーブレット４２が動作し、Ｗｅｂアプリケーションサーバ４５にアクセスして必要なＥＪＢコンポーネント４６ａを呼び出す。
【００７１】
呼び出されたＥＪＢコンポーネント４６ａは、必要に応じてデータベースにアクセスして所定の処理を行い、その結果をＷｅｂサーバ４１に返す。Ｗｅｂサーバ４１上のサーブレット４２は、この結果を利用してＷｅｂページを生成する。その後、ＪＳＰ（Ｊａｖａ  Ｓｅｒｖｅｒ  Ｐａｇｅｓ）４３が起動して、Ｗｅｂブラウザで閲覧可能なＨＴＭＬ形式の画面４４を生成する。
【００７２】
このように、従来は、画面デザインと画面データとが１つのモジュールとして記述されていたので、画面データの変更は画面デザインと一体として行う必要があった。これに対して、本実施形態では、画面デザインと画面データとが完全に分離されている。また、画面デザインの中に画面データを埋め込む処理を、ビジネスロジック３ｂの機能としてではなく、フレームワーク２ｂの機能としてＸＳＬＴプロセッサ３２が行うようにしている。
【００７３】
したがって、画面デザイン２ａやビジネスロジック３ｂには一切変更を加えることなく、画面データだけを動的に変更することができる。例えば、図６や図７の例で都道府県のデータを１つ増やしたい場合は、バリューオブジェクト５ａだけを変更すれば良い。これにより、画面、帳票、ＣＳＶ等のユーザインタフェース２ａのカスタマイズを容易に行うことができる。
【００７４】
また、従来は、画面デザインとロジックとが１つのモジュールとして記述されていたので、単に画面デザインを変えたい場合でも、プログラムの内容を知らないと画面デザインを適切に変更することができなかった。逆に、単にロジックを変えたい場合でも、画面デザインのことを知らないとプログラムを適切に変更することができなかった。これに対して、本実施形態では、画面デザインとロジックとが完全に分離されているので、画面デザインの修正やロジックの修正を独立して行うことができ、画面のカスタマイズが容易にできる。
【００７５】
また、本実施形態では、画面デザイン２ａと変換情報３１とも別に分けているので、業務処理システムに必要な複数の画面デザイン２ａについて共通に見せ方を少し変えたいというような場合には、個々の画面デザイン２ａを修正するのではなく、変換情報３１の変換ルールを変更するだけで対応することができる。しかも、画面デザイン２ａ自体は、その雛形が構築支援装置２００によって自動的に生成されるので、決められたルールに従ってパターン化されたものとなっている。そのため、作成される画面デザイン２ａが多数あっても、必要な変換情報３１の種類はわずかで済み、そのわずかな変換情報３１を変えるだけで数千枚もの画面デザイン２ａを簡単にカスタマイズすることができる。
【００７６】
さらに、本実施形態は、フレームワーク２ｂとドメインマネージャ３ａとの間、ドメインマネージャ３ａとビジネスロジック３ｂとの間における全てのクラス間のデータをＸＭＬ形式でやり取りしていることにも特徴がある。このようにすることにより、複雑なデータ形式を１つの同一のデータの集まりとして扱うことができる。
【００７７】
これにより、カスタマイズによって受け渡すデータの項目を増減したい場合にも、ＸＭＬの記述中において項目を単に増減するだけで変更が加えられる。しかもそのような変更は、図２の画面エディタ３００にて行えば良い。ここで必要な変更を加えれば、その変更内容が反映されたバリューオブジェクト５ａが自動的に生成される。したがって、本実施形態によれば、プログラム間でやり取りするデータのカスタマイズを容易に行うことができるというメリットも有する。
【００７８】
また、従来はデータの受け渡しをメモリを介して行っていたので、あるプログラムから他のプログラムに受け渡されたデータが正しいものであるかどうかを検証するためには、受け渡しに使ったメモリ内のデータを参照する必要がある。しかし、メモリ内のデータを見るのは楽ではない。これに対して、本実施形態では、ＸＭＬ形式でデータの受け渡しが行われるため、どういうデータがどのように渡されているのかをテキスト形式で簡単に参照することができる。よって、テストや障害発生時のデータ追跡なども容易に行うことができる。
【００７９】
次に、フレームワーク２ｂが行う画面遷移のイベントキャッシュ機能について説明する。図９は、本実施形態のイベントキャッシュ機能を説明するための図である。図９では、画面Ａの表示中に図示しない項目にデータを入力した後、「次へ」のボタンを操作すると画面Ｂに遷移する。また、画面Ｂの表示中に図示しない項目にデータを入力した後、「次へ」のボタンを操作すると画面Ｃに遷移する。さらに、画面Ｃの表示中に「戻る」のボタンを操作すると画面Ｂに戻る例について示している。
【００８０】
このような画面遷移の際には、図５で説明した仕組みが実行される。例えば、画面Ａから画面Ｂに遷移する際には、ボタン操作というイベントの発生に応じてプログラムＰＧ１が実行される。プログラムＰＧ１は、データベース４ａにアクセスして画面Ｂの表示に必要なデータを取得し、その取得したデータを用いてＨＴＭＬの画面Ｂを生成して表示する。
【００８１】
画面Ｂから画面Ｃに遷移する際も同様の手順を踏む。すなわち、画面Ｂ上でのボタン操作というイベントの発生に応じて、プログラムＰＧ２が起動する。プログラムＰＧ２は、データベース４ａにアクセスして画面Ｃの表示に必要なデータを取得し、その取得したデータを用いてＨＴＭＬの画面Ｃを生成して表示する。
【００８２】
画面Ｃから画面Ｂに戻る際にも、通常はそれ専用のプログラム（図示せず）が起動する。そして、データベース４ａから画面Ｂの表示に必要なデータを再取得し、そのデータを用いてＨＴＭＬの画面Ｂを生成して表示する。このように、画面Ｃから画面Ｂへ戻るような画面遷移を実装するためには、従来は、戻り用のプログラム（図示せず）を用意する必要があった。これに対して、本実施形態では以下に述べるイベントキャッシュ機能を備えることにより、このプログラムを全く不要とする。
【００８３】
すなわち、本実施形態では、何のイベントが発生したときにイベントキャッシュに書き込みを行い、何のイベントが発生したときにイベントキャッシュの内容を使用するかということを、図２の構築支援装置２００を用いてフレームワーク２ｂに上述のメタ情報として登録しておく。この登録は、図２の画面定義部１１およびフレームワーク生成部１３を用いて行う。図９に即して説明すると、画面Ａおよび画面Ｂの「次へ」ボタンが押されたときはイベントキャッシュメモリ５０に書き込みを行い、画面Ｃの「戻る」ボタンが押されたときはイベントキャッシュメモリ５０のキャッシュ内容を使用するということをメタ情報として定義する。
【００８４】
イベントキャッシュメモリ５０は、先入れ後出しのメモリである。このイベントキャッシュメモリ５０に記憶される情報は、指定されているイベントの名称およびそのイベントを実行するための入力データである。例えば、画面Ａ上で「次へ」ボタンが押されたときは、そのイベント名と入力データとが、画面Ｂを表示するイベントとしてイベントキャッシュメモリ５０に格納される。また、画面Ｂ上で「次へ」ボタンが押されたときは、そのイベント名と入力データとが、画面Ｃを表示するイベントとしてイベントキャッシュメモリ５０に格納される。
【００８５】
一方、画面Ｃ上で「戻る」ボタンが押されたときは、フレームワーク２ｂは、イベントキャッシュメモリ５０を参照して、キャッシュ情報を取り出す。このとき取り出す情報は、自身の画面を表示するイベントを除いて最新に格納された情報である。図９の例の場合、
イベントキャッシュメモリ５０に記憶されている最新のイベントは、画面Ｃを表示するイベントであるが、これは自身を表示するものであるので無視し、次に新しい画面Ｂを表示するイベントのキャッシュ情報を取り出す。
【００８６】
そして、フレームワーク２ｂは、この取り出したキャッシュ情報に従って処理を実行する。ここで取り出したキャッシュ情報には、画面Ａ上で「次へ」ボタンが押されたときのイベントの内容が記述されている。よって、この場合はプログラムＰＧ１が実行され、ＨＴＭＬの画面Ｂが生成されて表示されることになる。このように、本実施形態によれば、戻り専用のプログラムを用意しなくても、画面Ｃから画面Ｂに戻る画面遷移を実現することができる。よって、プログラム開発の工数を大幅に削減することができる。
【００８７】
次に、図２に示したＤＡＯ６の機能について説明する。ＤＡＯ６は、ビジネスロジック３ｂからデータベース４ａにアクセスする際の処理を行うものであり、例えばＳＱＬ文による検索実行機能も備えている。通常のＤＡＯでは、例えば検索項目が３つある場合、どの項目に検索条件が入力されたかによって、７個のプログラムに振り分けられて検索が実行される。
【００８８】
つまり、従来は、３つの検索項目に対して、何れか１個の検索項目だけが入力された場合の検索プログラムを３つ、何れか２個の検索項目が入力された場合の検索プログラムを３つ、全ての検索項目が入力された場合の検索プログラムを１つ、合計７個の検索プログラムを作成する必要があった。これに対して本実施形態は、データ検索のＳＱＬ文として最大パターンの検索条件を設定して検索プログラムを１つ登録しておき、それから各種パターンの条件文を動的に生成して実行するようにする。
【００８９】
図１０は、上記最大パターンの検索条件を表したＤＡＯ６の構成例を示す図である。図１０に示すように、本実施形態のＤＡＯ６には、検索によって取得するデータ項目６１と、検索対象のテーブル６２と、３つの検索項目α、β、γを備えた最大パターンの検索条件６３とを含むＳＱＬ文が記述されている。このようなＳＱＬ文による検索プログラムは、検索条件６３に関して実際に画面上で入力された検索項目の条件だけを使い、入力されていない検索項目は空のままで検索を実行する。
【００９０】
このようなＤＡＯ６は、上述したように図２の構築支援装置２００によって自動的に生成される。このとき図２のＤＡＯ生成部２１は、ＳＱＬ定義部２０より出力される設計定義情報に基づいて、指定されたデータベースベンダのフォーマットに合わせたＳＱＬ文のＤＡＯ６を自動生成する。ＤＡＯ生成部２１は、種々のベンダ用のＳＱＬ文に合わせたＤＡＯ６の生成ロジックを備えている。したがって、異なるベンダ用のＤＡＯ６が欲しいときは、ＤＡＯ生成部２１での生成ロジックを異なるベンダ用のものに切り替えるだけで良く、ＤＡＯ６自身を手作業で書き換える必要はない。
【００９１】
以上のように、本実施形態では、通常はビジネスロジック３ｂなどの業務アプリケーションに記述されるＳＱＬ文をＤＡＯ６として外出しにして、そのＤＡＯ６には最大パターンの検索条件だけを登録してそれから各種パターンの条件文を動的に生成するようにしたので、１個のＤＡＯ６を作るだけで複数パターンの検索プログラムの処理を実行することができ、ＳＱＬ文作成のプログラム製造が容易になる。また、異なるベンダ用のＤＡＯ６を作るときにも構築支援装置２００を使って簡単に生成できるので、ＤＡＯ６の生産性を向上させることができる。
【００９２】
以上に説明した本実施形態による業務処理システム１００およびその構築支援装置２００は、実際にはコンピュータのＣＰＵあるいはＭＰＵ、ＲＡＭ、ＲＯＭなどを備えて構成され、ＲＡＭやＲＯＭに記憶されたプログラムが動作することによって実現できる。
【００９３】
したがって、コンピュータが上記本実施形態の機能を果たすように動作させるプログラムを例えばＣＤ−ＲＯＭのような記録媒体に記録し、コンピュータに読み込ませることによって実現できるものである。上記プログラムを記録する記録媒体としては、ＣＤ−ＲＯＭ以外に、フレキシブルディスク、ハードディスク、磁気テープ、光ディスク、光磁気ディスク、ＤＶＤ、不揮発性メモリカード等を用いることができる。また、上記プログラムをインターネット等のネットワークを介してコンピュータにダウンロードすることによっても実現できる。
【００９４】
また、上記本実施形態による業務処理システム１００あるいはその構築支援装置２００の機能をネットワーク環境で実現するべく、全部あるいは一部のプログラムが他のコンピュータで実行されるようになっていても良い。
【００９５】
また、コンピュータが供給されたプログラムを実行することにより上述の実施形態の機能が実現されるだけでなく、そのプログラムがコンピュータにおいて稼働しているＯＳ（オペレーティングシステム）あるいは他のアプリケーションソフト等と共同して上述の実施形態の機能が実現される場合や、供給されたプログラムの処理の全てあるいは一部がコンピュータの機能拡張ボードや機能拡張ユニットにより行われて上述の実施形態の機能が実現される場合も、かかるプログラムは本発明の実施形態に含まれる。
【００９６】
なお、上記実施形態は、何れも本発明を実施するにあたっての具体化の一例を示したものに過ぎず、これによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその精神、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。
【００９７】
【発明の効果】
本発明は上述したように、業務処理の標準プログラムをスーパークラスに実装させ、そのスーパークラスを継承したサブクラスであって、業務処理の修正時に修正プログラムが実装される空のサブクラスを当初から用意しておくようにしたので、業務処理のカスタマイズによって実装される修正プログラムが標準プログラムと混ざらないようにすることができる。これにより、標準プログラムをカスタマイズする際の工数を大幅に削減することができるとともに、バージョンアップの容易性、管理の容易性を向上させることができる。
【００９８】
本発明の他の特徴によれば、クラス間のデータをＸＭＬ形式でやり取りするようにしたので、複雑なデータ形式を１つの同一のデータの集まりとして扱うことができる。また、受け渡しすべき項目が増減した際の変更が容易となるばかりでなく、受け渡しデータをＸＭＬ形式で参照できるため、テストや障害発生時のデータ追跡を容易に行うことができる。
【００９９】
本発明の他の特徴によれば、画面デザインをＸＨＴＭＬ形式で生成するとともに、その画面に貼り付けるデータ（バリューオブジェクト）をＸＭＬ形式で生成して、これらをＸＳＬ変換することによってＨＴＭＬの画面表示を行うようにしたので、画面デザインと画面データとを完全に切り分けることができ、カスタマイズが容易にできるようになる。
【０１００】
本発明の他の特徴によれば、データ検索のＳＱＬ文として最大の検索条件パターンのみを登録しておくことで、条件文を動的に生成して実行するようにしたので、ＳＱＬ文生成のプログラム作成が容易になり、データベースへのアクセスプログラムの生産性を向上させることができる。
【０１０１】
本発明の他の特徴によれば、指定されている画面遷移の処理を行うために必要なイベント情報をキャッシュメモリに記憶しておき、後続の処理でキャッシュメモリのイベント情報を読み出してそれに従って画面遷移の処理を実行するようにしたので、画面遷移が複雑な場合の前画面に戻る処理や再描画処理のプログラムを生成する必要がなくなる。また、後続の処理へ前処理の入力データを引き渡す必要もなくなるので、シンプルなプログラム生成を行うことが可能となる。よって、プログラムの生産性を向上させることができる。
【０１０２】
以上のように、本発明によれば、業務処理システムに関するアプリケーション開発の生産性、メンテナンスの容易性、再利用性、仕様変更等に対する柔軟性を向上させることができる。
【図面の簡単な説明】
【図１】本実施形態による業務処理システムの概略構成を示す図である。
【図２】本実施形態による業務処理システムおよびその構築支援装置の構成例を示す図である。
【図３】本実施形態によるビジネスロジックの変更管理について説明するための図である。
【図４】従来のカスタマイズ法について説明するための図である。
【図５】本実施形態のフレームワークによる画面生成機能を説明するための図である。
【図６】本実施形態による画面生成の一例を示す図である。
【図７】本実施形態による画面生成の他の例を示す図である。
【図８】従来の画面生成処理について説明するための図である。
【図９】本実施形態のイベントキャッシュ機能を説明するための図である。
【図１０】本実施形態による最大パターンの検索条件を表したＤＡＯの構成例を示す図である。
【図１１】従来の業務処理システムの概略構成を示す図である。
【符号の説明】
１  クライアント
１ａ  ブラウザ
２  Ｗｅｂサーバ
２ａ  ユーザインタフェース
２ｂ  制御部（フレームワーク）
３  Ｗｅｂアプリケーションサーバ
３ａ  ドメインマネージャ（ＤＭ）
３ｂ  ビジネスロジック（ＢＬ）
４  データベースサーバ
４ａ  データベース（ＤＢ）
５ａ，５ｂ  バリューオブジェクト（ＶＯ）
６  データアクセスオブジェクト（ＤＡＯ）
１１  画面定義部
１２  画面生成部
１３  フレームワーク生成部
１４  ＶＯ定義部
１５  ＶＯ生成部
１６  ＤＭ定義部
１７  ＤＭ生成部
１８  ＢＬ定義部
１９  ＶＯ生成部
２０  ＳＱＬ定義部
２１  ＤＡＯ生成部
２２  ＤＢ定義部
２３  ＤＤＬ等生成部
２４  変更管理部
１００  業務処理システム
２００  構築支援装置
３００  画面エディタ
４００  ビジネスルール設計ツール
５００  ＤＢ設計ツール
【図１】
2004310279.tif 000003
【図２】
2004310279.tif 000004
【図３】
2004310279.tif 000005
【図４】
2004310279.tif 000006
【図５】
2004310279.tif 000007
【図６】
2004310279.tif 000008
【図７】
2004310279.tif 000009
【図８】
2004310279.tif 000010
【図９】
2004310279.tif 000011
【図１０】
2004310279.tif 000012
【図１１】
2004310279.tif 000013