(57)【要約】    【課題】  開発用のデータベースと実運用で使用するデータベースとの間の不整合が生じ単体テストが通らないという問題や、テストコードを書き直す必要があるという問題を解消する。    【解決手段】  ショッピングシステム101のWEBアプリケーションサーバ201のアプリケーション203は、ファクトリ、OrderTestクラス350、Orderクラス360等を備える。OrderTestクラス350を使用し注文機能を単体テストする際に、OrderTestクラス350のtest（）メソッド351は、ファクトリをインスタンス化して店舗ID411に対応するテストデータを取得する。また、店舗に固有の商品情報であるProductテーブル440に対応するテストデータを取得する。また、OrderRecordテーブル430に対応するテストデータを取得する。次に、単体テスト対象であるOrderクラス360のOrderRegist（）メソッド361で注文処理を行う。最後に、Orderクラス360を使用した注文処理が正常に行われたかをチェックする。【選択図】      図３
2005092590.tif 000002
【特許請求の範囲】
【請求項１】
データベースと連携して動作するアプリケーションプログラムの単体テストを行う際に、前記データベースに格納されているデータに対応するテストデータを生成するモジュールから、前記アプリケーションプログラムのテスト対象機能に関わるテストデータを取得し、前記テスト対象機能を前記テストデータに従い実行することで単体テストを行うことを特徴とする単体テスト方法。
【請求項２】
前記アプリケーションプログラムは、オブジェクト指向型のプログラミング言語を使用したものであることを特徴とする請求項１記載の単体テスト方法。
【請求項３】
前記単体テストを行う際に、前記モジュールをアブストラクトファクトリパターンを適用することでインスタンス化し、該インスタンス化した前記モジュールから前記テストデータを取得することを特徴とする請求項１又は２記載の単体テスト方法。
【請求項４】
前記テスト対象機能の実行時に前記テスト対象機能に関わるデータを前記データベースに格納し、前記テスト対象機能の実行終了後に前記データベースから取得した前記テスト対象機能に関わるデータと前記テストデータとを比較することで、前記単体テストの結果を判定することを特徴とする請求項１記載の単体テスト方法。
【請求項５】
前記単体テストの開始前に、前記テストデータを前記データベースに登録することを特徴とする請求項１記載の単体テスト方法。
【請求項６】
前記単体テストの終了後に、前記データベースから前記テストデータを削除することを特徴とする請求項１記載の単体テスト方法。
【請求項７】
前記データベースに対する前記テストデータの登録或いは削除を行う機能は、通信媒体を介したクライアントの要求に応じて実行可能であることを特徴とする請求項５又は６記載の単体テスト方法。
【請求項８】
データベースと連携して動作するアプリケーションプログラムの単体テストを行う単体テスト装置であって、
前記データベースに格納されているデータに対応するテストデータを生成する生成手段と、前記生成手段から前記アプリケーションプログラムのテスト対象機能に関わるテストデータを取得する取得手段と、前記テスト対象機能を前記テストデータに従い実行することで単体テストを行う実行手段とを備えることを特徴とする単体テスト装置。
【請求項９】
データベースと連携して動作するアプリケーションプログラムの単体テストを行う際に、前記データベースに格納されているデータに対応するテストデータを生成するモジュールから、前記アプリケーションプログラムのテスト対象機能に関わるテストデータを取得する機能と、前記テスト対象機能を前記テストデータに従い実行することで単体テストを行う機能を、コンピュータに実現させるためのプログラム。
【請求項１０】
前記請求項９記載のプログラムを格納することを特徴とするコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースと連携するアプリケーションプログラムの単体テスト方法、単体テスト装置、プログラム、及び記憶媒体に関する。
【背景技術】
【０００２】
近年、オブジェクト指向型のプログラミング言語であるJava（登録商標）言語を使用したアプリケーションプログラム（以下アプリケーションと略称）の開発においては、JUnit（Java（登録商標）言語プログラムをテストするツール）等の、単体テスト（各モジュールがプログラム仕様書で要求されている機能を満たしているかどうかを確認するテスト）のフレームワークを利用してテストコードを記述し、単体テストを行うのが一般的である。
【０００３】
データベースと連携するアプリケーションにおいて、よくある単体テストの一例としては、データベースからデータを取得してそのデータを加工して出力する機能をテストする例がある。これは、テストコード上で、該機能が出力した値と期待値とが等しいか否かを判別することで該機能のテストを行うものである。この場合、上記の期待値は定数値で直接テストコードに記述されることが一般的に行われている。
【０００４】
上記のデータベースの例として、例えば、インターネット上に構築されたショッピングシステムにおいて、複数の店舗を管理すると共に店舗固有の様々な情報を格納したデータベースを考える。複数の店舗を識別するためには、データベースに店舗毎に固有の値（店舗ＩＤ）を格納しておくことで対応することができる。この店舗ＩＤをキーにしてデータベースを検索すると、その店舗固有の様々な情報をデータベースから取得することが可能となる。
【０００５】
一般的に、開発用のデータベースと、実運用で使用するデータベースとは別であり、データも別のものを使用することが多い。つまり、直接テストコードに店舗ＩＤを記述していると、開発用のデータベースには該当する店舗ＩＤが格納されていて単体テストにパスしたとしても、実運用で使用するデータベースには該当する店舗ＩＤがないと単体テストにパスしないことが起こりうる。例えば、店舗ＩＤをキーに店舗名を取得する機能の単体テストの場合、実運用で使用するデータベースに店舗ＩＤがないと店舗名の取得に失敗し、単体テストにパスしない。
【０００６】
上述した単体テストに関しては、店舗ＩＤに限らず、他のデータにおいても同様のことが起こりうる。例えば、ショッピングシステムのある店舗でその店舗の利用者が注文を行うと、ショッピングシステムは注文者名・住所・代金・注文商品等の注文データをデータベースに格納する。注文データを識別する固有のＩＤ（注文ＩＤ）が開発用のデータベースには存在するが、実運用で使用するデータベースに存在しない場合、店舗ＩＤの場合と同様に、実運用環境では単体テストがパスしないことが起こりうる。例えば、注文ＩＤをキーにして代金や注文商品等の注文データをデータベースから取得する機能をテストする際に、実運用で使用するデータベースに存在しない注文ＩＤで検索すると失敗する。
【０００７】
他方、ソフトウエアやハードウエアが適切に作動するかを試験する際に、ソフトウエア等に対して入力するデータや指示を予め多数設定し保存しておき、それらのデータや指示を組み合わせることで多様な条件でのテストを人手により一度も行うことなく自動的に実行する技術が提案されている（例えば、特許文献１参照）。
【０００８】
また、プログラムのテストにおいて、事前に入手した、テストパターンとそれに対するテストデータを使用してテストを行うことで、テスト項目、テスト方法が標準化でき、また事前に入手したテスト結果イメージを実際のテスト結果と照合することで自動的に合否判定する技術が提案されている（例えば、特許文献２参照）。
【特許文献１】特開平７−９３１８７号公報
【特許文献２】特開平８−２３５０２５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、従来技術においては、ショッピングシステムのデータベースに関する２つの例で述べたように、店舗ＩＤや注文ＩＤ等の、単体テストで使用するテストデータを直接テストコードに記述していると、開発用のデータベースと実運用で使用するデータベースとの間の不整合が生じ、単体テストが通らないという問題がある。
【００１０】
また、従来技術においては、次のような問題もある。店舗毎に異なる処理を行う場合（例えば、注文時に配送料金を計算する場合で店舗毎に配送料金の計算方法が違う場合など）において、店舗毎に固有の機能をテストしたいときや、新規に店舗を開店した際にデータベースに新規に登録された商品データ等のデータに不整合がないかをテストしたいときに、店舗ＩＤを指定してテストしたい場合がある。このような場合、テストコードに直接店舗ＩＤ（テストデータ）を記述していると、テストコードを書き直す必要があるという問題がある。
【００１１】
本発明の目的は、開発用のデータベースと実運用で使用するデータベースとの間の不整合が生じ単体テストが通らないという問題や、テストコードを書き直す必要があるという問題を解消することを可能とした単体テスト方法、単体テスト装置、プログラム、及び記憶媒体を提供することにある。
【課題を解決するための手段】
【００１２】
上述の目的を達成するために、本発明は、データベースと連携して動作するアプリケーションプログラムの単体テストを行う際に、前記データベースに格納されているデータに対応するテストデータを生成するモジュールから、前記アプリケーションプログラムのテスト対象機能に関わるテストデータを取得し、前記テスト対象機能を前記テストデータに従い実行することで単体テストを行うことを特徴とする。
【００１３】
また、本発明は、前記アプリケーションプログラムは、オブジェクト指向型のプログラミング言語を使用したものであることを特徴とする。
【００１４】
また、本発明は、前記単体テストを行う際に、前記モジュールをアブストラクトファクトリパターンを適用することでインスタンス化し、該インスタンス化した前記モジュールから前記テストデータを取得することを特徴とする。
【００１５】
また、本発明は、前記テスト対象機能の実行時に前記テスト対象機能に関わるデータを前記データベースに格納し、前記テスト対象機能の実行終了後に前記データベースから取得した前記テスト対象機能に関わるデータと前記テストデータとを比較することで、前記単体テストの結果を判定することを特徴とする。
【００１６】
また、本発明は、前記単体テストの開始前に、前記テストデータを前記データベースに登録することを特徴とする。
【００１７】
また、本発明は、前記単体テストの終了後に、前記データベースから前記テストデータを削除することを特徴とする。
【００１８】
また、本発明は、前記データベースに対する前記テストデータの登録或いは削除を行う機能は、通信媒体を介したクライアントの要求に応じて実行可能であることを特徴とする。
【００１９】
尚、本発明は、データベースと連携して動作しオブジェクト指向型のプログラミング言語を使用したアプリケーションプログラムの単体テストを行う単体テスト装置において、前記データベースに格納されているデータに対応するテストデータを生成するモジュールを、アブストラクトファクトリパターンを適用することでインスタンス化し、該インスタンス化した前記モジュールから前記テストデータを取得する取得手段と、前記アプリケーションプログラムのテスト対象機能を前記テストデータに従い実行することで単体テストを行う実行手段と、前記テスト対象機能の実行時に前記テスト対象機能に関わるデータを前記データベースに格納し、前記テスト対象機能の実行終了後に前記データベースから取得した前記テスト対象機能データと前記テストデータとを比較することで、前記単体テストの結果を判定する判定手段とを備える、構成としてもよい。
【００２０】
また、本発明は、データベースと連携して動作しオブジェクト指向型のプログラミング言語を使用したアプリケーションプログラムの単体テスト方法において、前記単体テストに使用するテストデータを前記データベースに対し登録或いは削除する機能を駆動するモジュールを作成する、ようにしてもよい。
【発明の効果】
【００２１】
本発明によれば、データベースに格納されているデータに対応するテストデータを生成するモジュールから、アプリケーションプログラムのテスト対象機能に関わるテストデータを取得し、テスト対象機能をテストデータに従い実行することで単体テストを行うので、即ち、データベースや環境に依存するテストデータを、テストコードに直接記述せずにモジュールから取得するので、従来のような、開発用のデータベースと実運用で使用するデータベースとの間の不整合が生じ単体テストが通らないという問題や、テストコードを書き直す必要があるという問題を解消でき、複数のデータベース環境で同様に単体テストを行うことができる。
【００２２】
また、本発明によれば、アプリケーションプログラムは、オブジェクト指向型のプログラミング言語を使用したものであり、単体テストを行う際に、モジュールをアブストラクトファクトリパターンを適用することでインスタンス化し、インスタンス化したモジュールからテストデータを取得するので、テストデータを取得するモジュールを動的に切り替えることが可能となり、新しいテスト対象機能や特定のテスト対象機能を含む任意のテスト対象機能に対して単体テストを行うことができる。
【００２３】
また、本発明によれば、テスト対象機能の実行時にテスト対象機能に関わるデータをデータベースに格納し、テスト対象機能の実行終了後にデータベースから取得したテスト対象機能に関わるデータと、モジュールから取得したテストデータとを比較し、単体テストの結果を判定するので、単体テストの際にテストデータをテストコードに直接記述することが不要となり、従来のような、開発用のデータベースと実運用で使用するデータベースとの間の不整合が生じ単体テストが通らないという問題や、テストコードを書き直す必要があるという問題を解消でき、複数のデータベース環境で同様に単体テストを行うことができる。
【００２４】
また、本発明によれば、単体テストの開始前に、テストデータをデータベースに登録し、単体テストの終了後に、データベースからテストデータを削除するので、実運用環境でも全ての単体テストを行うことが可能となる。
【００２５】
また、本発明によれば、データベースに対するテストデータの登録或いは削除を行う機能は、通信媒体を介したクライアントの要求に応じて実行可能としているので、遠隔からでも単体テストを行うことが可能となる。
【発明を実施するための最良の形態】
【００２６】
以下、本発明の実施の形態を図面に基づき説明する。
【００２７】
＜システムの概要＞
図１は、本発明の実施の形態に係るショッピングシステムの概要を示す図である。
【００２８】
図１において、ショッピングシステム１０１は、インターネット１１０上に構築されており、インターネット１１０上で商品を販売する仮想店舗である複数の店舗１０２を備えている。顧客１０３は、Ｗｅｂブラウザを使用してインターネット１１０を介しショッピングシステム１０１内の任意の店舗１０２にアクセスすることで、所望の商品を購入することが可能となっている。
【００２９】
＜システムの構成＞
図２は、上記図１に示したショッピングシステム１０１の構成例を示すブロック図である。
【００３０】
図２において、ショッピングシステム１０１は、ＷＥＢアプリケーションサーバ２０１と、データベース２０２とを備えている。ＷＥＢアプリケーションサーバ２０１内では、アプリケーション２０３が動作可能である。
【００３１】
ＷＥＢアプリケーションサーバ２０１は、インターネット１１０を介し顧客１０３から商品注文のリクエストを受け付ける。これにより、ＷＥＢアプリケーションサーバ２０１内でアプリケーション２０３が任意の処理を行い、インターネット１１０を介し顧客１０３に商品注文に対するレスポンスを返す。データベース２０２は、ＷＥＢアプリケーションサーバ２０１と接続されており、店舗や商品に関する情報、注文を受け付けたときに作成する注文情報等を格納するデータベースである。
【００３２】
アプリケーション２０３は、ＷＥＢアプリケーションサーバ２０１内で動作し、顧客１０３からのリクエストに応じて任意の処理を行うものであり、例えば、顧客１０３からの商品を注文するリクエストに応じて、データベース２０２に注文商品や代金等の注文情報を格納する処理を行う。また、アプリケーション２０３は、任意の単体テストも行う。単体テストとしては、例えば、注文処理を行うアプリケーション２０３が出力する値と期待値とを比較し、両方の値が等しいか否かを判別することで当該機能をテストする例を挙げることができる。
【００３３】
アプリケーション２０３の詳細については、静的な側面からＵＭＬ（Ｕｎｉｆｉｅｄ  Ｍｏｄｅｌｉｎｇ  Ｌａｎｇｕａｇｅ）のクラス図である図３を用いて後述し、動的な側面から単体テスト実行時の処理を示すフローチャートである図５及び図６を用いて後述する。
【００３４】
＜データベースの構成＞
図４は、上記図２に示したデータベース２０２に格納されるテーブルの一部の構成を示すＥＲ（Ｅｎｔｉｔｙ−Ｒｅｌａｔｉｏｎｓｈｉｐ）図である。ＥＲ図はエンティティ（データ項目、実体）を結び付ける関係（リレーション）を表した図である。
【００３５】
図４において、ＰＫ４００は、Ｐｒｉｍａｒｙ  Ｋｅｙの略であり、主キーであることを示す略語である。ＦＫ４０１は、Ｆｏｒｅｉｇｎ  Ｋｅｙの略であり、外部キーであることを示す略語である。ＦＫ１、ＦＫ２の語尾の数字はテーブル内に複数のＦＫがあった場合に区別できるよう便宜上付したもので、無視してかまわない。
【００３６】
Ｓｈｏｐテーブル４１０は、ショッピングシステム１０１内の店舗１０２を管理するテーブルである。Ｓｈｏｐテーブル４１０、及び、後述する店舗ＩＤ４１１と関連するデータベース２０２内の各種テーブル（図示しないテーブルも含む）にデータを登録することにより、ショッピングシステム１０１は複数の店舗１０２を管理することが可能となっている。
【００３７】
店舗ＩＤ４１１は、ショッピングシステム１０１内の店舗を一意に特定するための符号であり、主キーである。店舗名４１２は、店舗の名前である。ＵＲＩ４１３は、インターネット上にある店舗のトップページのＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）を示すものである。配送料金計算方法ＩＤ４１４は、後述するＤｅｌｉｖｅｒｙＣａｌｃｕｌａｔｉｏｎＷａｙテーブル４５０中の配送料金計算方法ＩＤ４５１の外部キーである。
【００３８】
ＯｒｄｅｒＲｅｃｏｒｄテーブル４３０は、顧客１０３からの注文を管理するテーブルである。ＯｒｄｅｒＲｅｃｏｒｄテーブル４３０には、顧客１０３の一注文で１つのレコードを追加する。
【００３９】
注文ＩＤ４３１は、顧客１０３の一注文を一意に特定するための符号であり、主キーである。店舗ＩＤ４３２は、Ｓｈｏｐテーブル４１０中の店舗ＩＤ４１１の外部キーである。商品代金４３３は、顧客１０３が一注文で注文した商品の代金の合計を示す。配送料金４３４は、顧客１０３が一注文で支払う配送料金の合計を示す。消費税４３５は、商品代金４３３と配送料金４３４に含まれない消費税の合計を示す。つまり、商品代金４３３と配送料金４３４がともに税抜きの価格ならば、商品代金４３３と配送料金４３４の合計に消費税率を掛けたものが消費税４３５になる。合計代金４３６は、商品代金４３３と配送料金４３４と消費税４３５を合計したものであり、一注文で顧客１０３が支払う代金の合計を示す。
【００４０】
Ｐｒｏｄｕｃｔテーブル４４０は、顧客１０３がショッピングシステム１０１内の店舗１０２において購入することができる商品を管理するテーブルである。
【００４１】
商品ＩＤ４４１は、商品を一意に特定するための符号であり、主キーである。店舗ＩＤ４４２は、Ｓｈｏｐテーブル４１０中の店舗ＩＤ４１１の外部キーである。商品名４４３は、商品の名前である。単価４４４は、商品の単価である。
【００４２】
ＳｕｂｏｒｄｅｒＲｅｃｏｒｄテーブル４２０は、顧客１０３が注文した商品に関する情報を管理するテーブルであり、ＯｒｄｅｒＲｅｃｏｒｄテーブル４３０の１つのレコードに１つ以上紐付く。顧客１０３が一注文で注文した商品が例えば２種類ならば、ＯｒｄｅｒＲｅｃｏｒｄテーブル４３０の１レコードに対して、ＳｕｂｏｒｄｅｒＲｅｃｏｒｄテーブル４２０に２つのレコードを追加する。１つの注文を注文商品毎に分けたものを以下「サブ注文」と称する。つまり、１つの注文には１つ以上のサブ注文が紐付く。
【００４３】
サブ注文ＩＤ４２１は、１つのサブ注文を一意に特定するための符号であり、主キーである。注文ＩＤ４２２は、ＯｒｄｅｒＲｅｃｏｒｄテーブル４３０中の注文ＩＤ４３１の外部キーである。商品ＩＤ４２３は、Ｐｒｏｄｕｃｔテーブル４４０中の商品ＩＤ４４１の外部キーである。注文個数４２４は、顧客１０３が注文した商品の個数である。
【００４４】
ＤｅｌｉｖｅｒｙＣａｌｃｕｌａｔｉｏｎＷａｙテーブル４５０は、配送料金の計算方法を店舗ＩＤ毎に管理するテーブルである。
【００４５】
配送料金計算方法ＩＤ４５１は、配送料金計算方法を一意に特定するための符号であり、主キーである。配送料金計算方法クラスパス４５２は、実際の配送料金を計算する配送料金計算モジュールのパスである。配送料金を計算するときに動的に配送料金計算方法クラスパス４５２の配送料金計算モジュールを呼び出すことで、店舗毎に異なる配送料金計算方法に基づいて配送料金を算出することが可能となっている。配送料金計算モジュールは、本実施の形態を説明する上で直接的には関連しないので詳細な説明は省略する。
【００４６】
＜アプリケーションの構成＞
図３は、顧客１０３からのリクエストによりＷＥＢアプリケーションサーバ２０１内で動作するアプリケーション２０３の一部の構成を示すＵＭＬクラス図である。ＵＭＬクラス図はクラス（オブジェクトを抽象化した型）間の静的な関連を記述した図である。
【００４７】
図３において、ＡｂｓｔｒａｃｔＴｅｓｔＤａｔａＦａｃｔｏｒｙ（抽象テストデータファクトリ）クラス３１０は、ＧｏＦ（ｔｈｅ  Ｇａｎｇ  ｏｆ  Ｆｏｕｒ）のデザインパターン（オブジェクトの持つ機能の一部）の１つであるＡｂｓｔｒａｃｔ  ＦａｃｔｏｒｙパターンのＡｂｓｔｒａｃｔＦａｃｔｏｒｙに相当するクラスである。ＡｂｓｔｒａｃｔＴｅｓｔＤａｔａＦａｃｔｏｒｙクラス３１０は、抽象クラスであり、実際の処理は後述のサブクラスで実装する。
【００４８】
ｇｅｔＩｎｓｔａｎｃｅ（）メソッド３１１は、ｔｅｓｔ（）メソッド３５１が、ファクトリをインスタンス化する際に、単体テストで使用するファクトリの具体的なクラスの場所を引数で渡される。ｇｅｔＳｈｏｐＩｄ（）メソッド３１２は、店舗ＩＤ（ＳｈｏｐＩｄ）を取得する。ｇｅｔＰｒｏｄｕｃｔＬｉｓｔ（）メソッド３１３は、商品（Ｐｒｏｄｕｃｔ）のリストを取得する。ｇｅｔＳａｍｐｌｅＯｒｄｅｒ（）メソッド３１４は、ＯｒｄｅｒＲｅｃｏｒｄテーブル４３０に対応するテストデータをＯｒｄｅｒＤＴＯクラス３８０のインスタンス（クラスに属する個々の実体）の形で取得する。
【００４９】
ＰｅｔＳｈｏｐＴｅｓｔＤａｔａＦａｃｔｏｒｙクラス３２０、ＦｌｏｗｅｒＳｈｏｐＴｅｓｔＤａｔａＦａｃｔｏｒｙクラス３３０は、ＡｂｓｔｒａｃｔＴｅｓｔＤａｔａＦａｃｔｏｒｙクラス３１０のサブクラスであり、Ａｂｓｔｒａｃｔ  ＦａｃｔｏｒｙパターンのＣｏｎｃｒｅｔｅＦａｃｔｏｒｙクラスに相当するクラスである。
【００５０】
ＡｂｓｔｒａｃｔＴｅｓｔＤａｔａＦａｃｔｏｒｙクラス３１０、ＰｅｔＳｈｏｐＴｅｓｔＤａｔａＦａｃｔｏｒｙクラス３２０、ＦｌｏｗｅｒＳｈｏｐＴｅｓｔＤａｔａＦａｃｔｏｒｙクラス３３０のことを以下「ファクトリ」（モジュール）と称する。ファクトリは、データベース２０２の各テーブル中のレコードに対応するテストデータを生成する。
【００５１】
例えばペットショップの単体テストを行うときは、ペットショップ用のファクトリであるＰｅｔＳｈｏｐＴｅｓｔＤａｔａＦａｃｔｏｒｙクラス３２０が生成するテストデータを使用し、例えば花屋の単体テストを行うときは、花屋用のファクトリであるＦｌｏｗｅｒＳｈｏｐＴｅｓｔＤａｔａＦａｃｔｏｒｙクラス３３０が生成するテストデータを使用する。このように店舗毎にファクトリを用意することで、複数の店舗に対して単体テストを行うことが可能となる。
【００５２】
ＴｅｓｔＤａｔａＥｎｔｉｔｙＡｓｓｅｍｂｌｅｒクラス３４０は、ファクトリが生成するテストデータをデータベース２０２に格納したり、ファクトリが生成するテストデータに対応する同じデータをデータベース２０２から削除したりする機能を有する。これにより、新規にデータベース２０２にテストデータを追加したり、その逆にテストの終わったデータベース２０２からテストデータを削除したりすることが可能となる。このため、実運用環境であっても全ての単体テストが可能となる。このような動作を行うアプリケーション２０３をＷＥＢアプリケーションサーバ２０１に作成しておけば、ショッピングシステム１０１以外のシステムからリモートでも単体テストが可能となる。
【００５３】
ｃｒｅａｔｅＥｎｔｉｔｙ（）メソッド３４１は、ファクトリが生成するテストデータをデータベース２０２に格納する。ｒｅｍｏｖｅＥｎｔｉｔｙ（）メソッド３４２は、ファクトリが生成するテストデータに対応するデータをデータベース２０２から削除する。
【００５４】
ＯｒｄｅｒＴｅｓｔクラス３５０は、後述するＯｒｄｅｒクラス３６０が持つ注文機能の単体テストを行う専用のクラスである。
【００５５】
ｔｅｓｔ（）メソッド３５１は、実際の単体テストを行う。単体テストの詳細は図６を用いて後述する。
【００５６】
上述したＡｂｓｔｒａｃｔＴｅｓｔＤａｔａＦａｃｔｏｒｙクラス３１０、ＰｅｔＳｈｏｐＴｅｓｔＤａｔａＦａｃｔｏｒｙクラス３２０、ＦｌｏｗｅｒＳｈｏｐＴｅｓｔＤａｔａＦａｃｔｏｒｙクラス３３０、ＴｅｓｔＤａｔａＥｎｔｉｔｙＡｓｓｅｍｂｌｅｒクラス３４０、ＯｒｄｅｒＴｅｓｔクラス３５０は、単体テストを行うためにだけ使用するクラスである。
【００５７】
他方、後述するＯｒｄｅｒクラス３６０、ＰｒｏｄｕｃｔＤＴＯクラス３７０、ＯｒｄｅｒＤＴＯクラス３８０は、単体テストでも使用するクラスであるが、単体テストの対象となるクラスとして使用しているものであり、単体テストを行うためのクラスではなく、ショッピングシステム１０１の本来の機能（例えば商品を注文する等の機能）の一部を実現するクラスである。
【００５８】
Ｏｒｄｅｒクラス３６０は、顧客１０３がショッピングシステム１０１に注文を行うと、該注文に伴いアプリケーション２０３が使用するクラスである。
【００５９】
ｏｒｄｅｒＲｅｇｉｓｔ（）メソッド３６１は、商品代金４３３、配送料金４３４、消費税４３５、合計代金４３６等の計算を行い、ＯｒｄｅｒＲｅｃｏｒｄテーブル４３０やＳｕｂｏｒｄｅｒＲｅｃｏｒｄテーブル４２０へのレコードの追加を行う。ｃａｌｃｕｌａｔｅＤｅｌｉｖｅｒｙＣｈａｒｇｅ（）メソッド３６２は、配送料金の計算を行うものであり、商品注文を受けた店舗の店舗ＩＤ４１１とＳｈｏｐテーブル４１０とから、配送料金計算方法ＩＤ４１４を取得する。
【００６０】
ＰｒｏｄｕｃｔＤＴＯクラス３７０は、データベース２０２中のＰｒｏｄｕｃｔテーブル４４０に対応するＤａｔａ  Ｔｒａｎｓｆｅｒ  Ｏｂｊｅｃｔ（ＤＴＯ）であり、Ｐｒｏｄｕｃｔテーブル４４０のレコードと対応するクラスで、Ｐｒｏｄｕｃｔテーブル４４０のデータを格納するためにアプリケーション２０３が使用する。Ｐｒｏｄｕｃｔテーブル４４０から商品情報を取得してＰｒｏｄｕｃｔＤＴＯクラス３７０に格納することで、商品情報が管理しやすくなる効果がある。
【００６１】
ｐｒｏｄｕｃｔＩｄ３７１は、商品ＩＤ４４１に対応する。ｓｈｏｐＩｄ３７２は、店舗ＩＤ４４２に対応する。ｐｒｏｄｕｃｔＮａｍｅ３７３は、商品名４４３に対応する。ｐｒｉｃｅ３７４は、単価４４４に対応する。
【００６２】
ＯｒｄｅｒＤＴＯクラス３８０は、ＤＴＯであり、データベース２０２中のＯｒｄｅｒＲｅｃｏｒｄテーブル４３０のレコードと対応し、該テーブル４３０に対応するデータを管理するクラスで、ＯｒｄｅｒＲｅｃｏｒｄテーブル４３０のデータを格納するためにアプリケーション２０３が使用する。ＯｒｄｅｒＤＴＯクラス３８０は、ｏｒｄｅｒＲｅｇｉｓｔ（）メソッド３６１中で、ＯｒｄｅｒＲｅｃｏｒｄテーブル４３０にデータを登録する際に有効的に使用している。
【００６３】
ＯｒｄｅｒＩｄ３８１は、注文ＩＤ４３１に対応する。ｓｈｏｐＩｄ３８２は、店舗ＩＤ４３２に対応する。ｐｒｏｄｕｃｔＣｈａｒｇｅ３８３は、商品代金４３３に対応する。ｄｅｌｉｖｅｒｙＣｈａｒｇｅ３８４は、配送料金４３４に対応する。ｃｏｎｓｕｍｐｔｉｏｎＴａｘ３８５は、消費税４３５に対応する。ｔｏｔａｌＣｈａｒｇｅ３８６は、合計代金４３６に対応する。ｓｕｂｏｒｄｅｒＬｉｓｔ３８７は、ＳｕｂｏｒｄｅｒＲｅｃｏｒｄテーブル４２０に対応するＤＴＯ（不図示）のリスト（配列）であり、該当する注文に関連する１つ以上のサブ注文をリストにして格納する。
【００６４】
＜商品の注文＞
次に、顧客１０３がインターネット１１０を介しショッピングシステム１０１内の所望の店舗１０２にアクセスして、商品の注文を行う時のショッピングシステム１０１の動作について説明する。
【００６５】
顧客１０３は、ショッピングシステム１０１内の所望の店舗１０２にアクセスし、注文する商品を選択して商品の個数を入力したり個人情報等の必要な情報を入力したりすることで注文を行う。アプリケーション２０３は、商品注文のリクエストを受け付けると、Ｏｒｄｅｒクラス３６０のｏｒｄｅｒＲｅｇｉｓｔ（）メソッド３６１を呼び出す（メソッド：オブジェクトの実行する手続きを記述したプログラム）。このｏｒｄｅｒＲｅｇｉｓｔ（）メソッド３６１は、商品代金４３３、配送料金４３４、消費税４３５、合計代金４３６等の計算を行い、ＯｒｄｅｒＲｅｃｏｒｄテーブル４３０やＳｕｂｏｒｄｅｒＲｅｃｏｒｄテーブル４２０へのレコードの追加を行う。
【００６６】
配送料金の計算は、ｏｒｄｅｒＲｅｇｉｓｔ（）メソッド３６１から呼ばれるｃａｌｃｕｌａｔｅＤｅｌｉｖｅｒｙＣｈａｒｇｅ（）メソッド３６２で行う。ｃａｌｃｕｌａｔｅＤｅｌｉｖｅｒｙＣｈａｒｇｅ（）メソッド３６２は、顧客１０３から商品注文を受けた店舗の店舗ＩＤ４１１と、Ｓｈｏｐテーブル４１０とから、配送料金計算方法ＩＤ４１４を取得する。
【００６７】
次に、ｃａｌｃｕｌａｔｅＤｅｌｉｖｅｒｙＣｈａｒｇｅ（）メソッド３６２は、ＤｅｌｉｖｅｒｙＣａｌｃｕｌａｔｉｏｎＷａｙテーブル４５０と、先ほど取得した配送料金計算方法ＩＤ４１４とから、配送料金計算方法クラスパス４５２を取得する。この配送料金計算方法クラスパス４５２は、配送料金の計算を行う配送料金計算モジュールの場所である。
【００６８】
ｃａｌｃｕｌａｔｅＤｅｌｉｖｅｒｙＣｈａｒｇｅ（）メソッド３６２中で、この配送料金計算モジュールを使用して配送料金の計算を行う。配送料金計算モジュールとしては、例えば、配送先毎に配送料を計算する方法や、合計代金に対して配送料金を計算する方法等を実現するモジュールが考えられる。このようなアーキテクチャを使用すれば、複数の店舗に対して複数の異なる配送料金計算方法を適用することが可能となる。
【００６９】
＜単体テスト＞
図５は、上記図３に示したアプリケーション２０３の単体テスト専用クラスであるＯｒｄｅｒＴｅｓｔクラス３５０を使用して、Ｏｒｄｅｒクラス３６０が持つ注文を行う機能を単体テストする際の処理を示すフローチャートである。
【００７０】
図５において、注文機能の単体テストをする前に、必要ならば以下のステップＳ５０１及びステップＳ５０２に示す２つの準備を行う。先ず、ステップＳ５０１では、ＯｒｄｅｒＴｅｓｔクラス３５０は、ファクトリをデータに矛盾なく作成する。
【００７１】
次に、ステップ５０２では、ＯｒｄｅｒＴｅｓｔクラス３５０は、ＴｅｓｔＤａｔａＥｎｔｉｔｙＡｓｓｅｍｂｌｅｒクラス３４０のｃｒｅａｔｅＥｎｔｉｔｙ（）メソッド３４１を実行し、ファクトリが生成するテストデータと等しくなるようにデータベース２０２を更新することで、データに矛盾が生じないようにする。ｃｒｅａｔｅＥｎｔｉｔｙ（）メソッド３４１では、ファクトリが生成するテストデータをデータベース２０２に追加（登録）する。
【００７２】
ファクトリは、ＰｒｏｄｕｃｔＤＴＯクラス３７０やＯｒｄｅｒＤＴＯクラス３８０のインスタンスを生成する。これらのインスタンスがテストデータとなる。テストデータとしては、後述するｇｅｔＳｈｏｐＩｄ（）メソッド３１２（店舗ＩＤ４１１に対応するテストデータ）が生成するもの等もある。これらはテストデータの一部であり、その他のテストデータは本実施の形態を説明する上で直接的には関連しないので詳細な説明は省略する。
【００７３】
上記ステップＳ５０１及びステップＳ５０２で示した２つの準備を行えば、ステップＳ５０３の単体テストを正常に行うことが可能となる。ステップＳ５０３では、ＯｒｄｅｒＴｅｓｔクラス３５０中のｔｅｓｔ（）メソッド３５１が、実際の単体テストを行う。単体テストの詳細は図６を用いて後述する。
【００７４】
最後に、ステップＳ５０４では、ＯｒｄｅｒＴｅｓｔクラス３５０は、ＴｅｓｔＤａｔａＥｎｔｉｔｙＡｓｓｅｍｂｌｅｒクラス３４０中のｒｅｍｏｖｅＥｎｔｉｔｙ（）メソッド３４２を実行し、ファクトリが生成するテストデータに対応するデータをデータベース２０２から削除する。データベース２０２にテストデータに対応するデータが不要な場合、即ち、実運用で使用しないデータは、単体テストの終了時にｒｅｍｏｖｅＥｎｔｉｔｙ（）メソッド３４２を実行することで、データベース２０２から削除することが可能となる。
【００７５】
尚、上述したステップＳ５０１、ステップＳ５０２、ステップＳ５０４は必要であれば実行する。
【００７６】
図６は、上記図５に示したステップＳ５０３の詳細を示すフローチャートである。
【００７７】
図６において、ＯｒｄｅｒＴｅｓｔクラス３５０中のｔｅｓｔ（）メソッド３５１（取得手段、実行手段）では以下の３段階の流れでテストを行う。先ず、ステップＳ６０１では、ｔｅｓｔ（）メソッド３５１は、ファクトリをインスタンス化し（コード上で使えるようにし）、ファクトリ（生成手段）から単体テストに使用するテストデータを取得する。以下、詳細に説明する。
【００７８】
ｔｅｓｔ（）メソッド３５１は、ファクトリのｇｅｔＩｎｓｔａｎｃｅ（）メソッド３１１に単体テストで使用するファクトリの具体的なクラスの場所を引数で渡すことで、ファクトリをインスタンス化し、ファクトリを単体テストで使用できる状態にする。
【００７９】
ｔｅｓｔ（）メソッド３５１は、インスタンス化したファクトリから店舗ＩＤ４１１に対応するテストデータを、ｇｅｔＳｈｏｐＩＤ（）メソッド３１２を使用して取得する。また、ｔｅｓｔ（）メソッド３５１は、その店舗に固有の商品情報であるＰｒｏｄｕｃｔテーブル４４０に対応するテストデータを、ｇｅｔＰｒｏｄｕｃｔＬｉｓｔ（）メソッド３１３を使用してＰｒｏｄｕｃｔＤＴＯクラス３７０のインスタンスのリストで取得する。また、ｔｅｓｔ（）メソッド３５１は、ＯｒｄｅｒＲｅｃｏｒｄテーブル４３０に対応するテストデータを、ｇｅｔＳａｍｐｌｅＯｒｄｅｒ（）メソッド３１４を使用してＯｒｄｅｒＤＴＯクラス３８０のインスタンスの形で取得する。必要であれば、同様にその他のテストデータ（詳細な説明は省略する）も取得する。
【００８０】
補足すると、上記ｇｅｔＰｒｏｄｕｃｔＬｉｓｔ（）メソッド３１３を使用して取得したテストデータであるＰｒｏｄｕｃｔＤＴＯクラス３７０のインスタンスのリストは、単体テストの際に注文できる商品のリストであり、上記ｇｅｔＳａｍｐｌｅＯｒｄｅｒ（）メソッド３１４を使用して取得したテストデータであるＯｒｄｅｒＤＴＯクラス３８０のインスタンスは、注文機能の単体テスト後にＯｒｄｅｒＲｅｃｏｒｄテーブル４３０に作成されるレコードと等しくなるようなＤＴＯである。
【００８１】
つまり、ＯｒｄｅｒＲｅｃｏｒｄテーブル４３０のテストデータ（ＯｒｄｅｒＤＴＯクラス３８０のインスタンス）は、テスト対象となる注文機能の単体テスト後にＯｒｄｅｒＲｅｃｏｒｄテーブル４３０に格納されるべき値を予測して設定される。単体テスト前は、ＯｒｄｅｒＲｅｃｏｒｄテーブル４３０には、テストデータ（ＯｒｄｅｒＤＴＯクラス３８０のインスタンス）に対応するデータが格納されるが、単体テストでＯｒｄｅｒＲｅｃｏｒｄテーブル４３０に作成されるデータは、単体テストが正常に終了した場合でも注文ＩＤ４３１のみテストデータとは違う値となる。これは、注文ＩＤ４３１が主キーだからである。
【００８２】
上述したようなアーキテクチャでテストデータを生成するファクトリをインスタンス化する際に、ＧｏＦのデザインパターンであるＡｂｓｔｒａｃｔ  Ｆａｃｔｏｒｙパターンを適用することで、単体テストに使用するテストデータを取得するファクトリを容易に切り替えることができ、複数の店舗や複数のデータベース環境で同じ単体テストを容易に行うことが可能となる。
【００８３】
次に、ステップＳ６０２では、ｔｅｓｔ（）メソッド３５１は、単体テスト対象（注文機能）であるＯｒｄｅｒクラス３６０のｏｒｄｅｒＲｅｇｉｓｔ（）メソッド３６１で注文処理を行う。ｏｒｄｅｒＲｅｇｉｓｔ（）メソッド３６１は、上記ステップＳ６０１で取得したテストデータである、ｇｅｔＳｈｏｐＩｄ（）メソッド３１２で取得した値（店舗ＩＤ４１１に相当する値）、ＰｒｏｄｕｃｔＤＴＯクラス３８０のインスタンス等の店舗、商品等の注文に必要なデータを引数で渡されることで、はじめて注文処理を行うことが可能となる。
【００８４】
配送料金が発生する場合における配送料金の計算は、ｏｒｄｅｒＲｅｇｉｓｔ（）メソッド３６１内で使用されるｃａｌｃｕｌａｔｅＤｅｌｉｖｅｒｙＣｈａｒｇｅ（）メソッド３６２で行う。ｃａｌｃｕｌａｔｅＤｅｌｉｖｅｒｙＣｈａｒｇｅ（）メソッド３６２は、引数で渡されたテストデータである店舗ＩＤ４１１に相当する値とＳｈｏｐテーブル４１０とから、店舗ＩＤ４１１をキーにして配送料金計算方法ＩＤ４１４を取得する。また、ｃａｌｃｕｌａｔｅＤｅｌｉｖｅｒｙＣｈａｒｇｅ（）メソッド３６２は、取得した配送料金計算方法ＩＤ４１４とＤｅｌｉｖｅｒｙＣａｌｃｕｌａｔｉｏｎＷａｙテーブル４５０とから、配送料金計算方法クラスパス４５２を取得する。この配送料金計算方法クラスパス４５２は配送料金計算モジュールの場所であり、該配送料金計算モジュールを使用することで配送料金を計算することが可能となる。
【００８５】
詳細な説明は省略するが、配送料金の計算だけではなく、例えば商品代金の計算方法も同様に店舗毎に設定することが可能である。
【００８６】
このように、配送料金や商品代金等のＯｒｄｅｒＲｅｃｏｒｄテーブル４３０、ＳｕｂｏｒｄｅｒＲｅｃｏｒｄテーブル４２０等に格納するデータを揃えると、ｏｒｄｅｒＲｅｇｉｓｔ（）メソッド３６１は、該データをＯｒｄｅｒＲｅｃｏｒｄテーブル４３０、ＳｕｂｏｒｄｅｒＲｅｃｏｒｄテーブル４２０等に格納する。その他、必要ならば注文処理に必要な処理（例えば、顧客にサンキューメールを送信する等の処理）を行うが、本実施の形態を説明する上で直接的には関連しないので詳細な説明は省略する。
【００８７】
最後に、ステップＳ６０３では、ｔｅｓｔ（）メソッド３５１は、Ｏｒｄｅｒクラス３６０を使用した注文処理が正常に行われたかをチェックし、注文処理が正常に行われた場合に単体テストは終了となる。
【００８８】
例えば、Ｏｒｄｅｒクラス３６０を使用して、ＯｒｄｅｒＲｅｃｏｒｄテーブル４３０に格納された注文情報のうち、配送料金４３４が正しいか否かをチェックするには、データベース２０２から取得した配送料金４３４と、ｇｅｔＳａｍｐｌｅＯｒｄｅｒ（）メソッド３１４を使用して取得したテストデータ中のｄｅｌｉｖｅｒｙＣｈａｒｇｅ３８４に格納されている値とを比較することでチェックが可能となる。両者が等しい場合、Ｏｒｄｅｒクラス３６０のｃａｌｃｕｌａｔｅＤｅｌｉｖｅｒｙＣｈａｒｇｅ（）メソッド３６２が正しい値を算出したと言うことができる。つまり、単体テストにパスしたと言うことができる。
【００８９】
以上説明したように、本実施の形態によれば、アプリケーションの単体テストを行う際に、データベースや環境に依存するテストデータを、テストコードに直接記述せずにファクトリから取得するようにすることで、従来のような、開発用のデータベースと実運用で使用するデータベースとの間の不整合が生じ単体テストが通らないという問題や、テストコードを書き直す必要があるという問題を解消でき、複数のデータベース環境で同様に単体テストを行うことができる。
【００９０】
また、テストデータを取得するファクトリをインスタンス化する際に、ＧｏＦのデザインパターンであるＡｂｓｔｒａｃｔ  Ｆａｃｔｏｒｙパターンを適用することで、テストデータを取得するファクトリを動的に切り替えることが可能となり、ショッピングシステムにおける新しい店舗や特定の店舗を含む任意の店舗に対して単体テストを行うことができる。
【００９１】
また、単体テストの開始前にテストデータに対応するデータをデータベースに登録したり、単体テストの終了後に不要なデータ（実運用で使用しないデータ）をデータベースから削除したりすることで、実運用環境でも全ての単体テストを行うことが可能となる。
【００９２】
また、データベースに対するテストデータの登録／削除を行う機能（ＴｅｓｔＤａｔａＥｎｔｉｔｙＡｓｓｅｍｂｌｅｒクラス３４０のｃｒｅａｔｅＥｎｔｉｔｙ（）メソッド３４１、ｒｅｍｏｖｅＥｎｔｉｔｙ（）メソッド３４２の機能）を駆動するサーブレット（クライアントの要求に応じてＷＥＢサーバ側で実行されるJava（登録商標）プログラムのモジュール）／ＪＳＰ（Java（登録商標） Server Pages：ＷＥＢアプリケーションを構築するための規格）を作成することで、遠隔からでも単体テストを行うことが可能となる。
【００９３】
［他の実施の形態］
上記実施の形態では、ショッピングシステムにおけるアプリケーションの注文機能の単体テストを例に挙げたが、これに限定されるものではなく、他の機能（例えばログイン機能等）の単体テストに適用することも可能である。
【００９４】
上記実施の形態では、ショッピングシステムにおけるアプリケーションの単体テストを例に挙げたが、これに限定されるものではなく、他のシステムにおけるアプリケーションの単体テストに適用することも可能である。
【００９５】
上記実施の形態では、単体テストの実行のみについて説明したが、単体テストの結果を表示出力或いは印刷出力するように構成することも可能である。
【００９６】
本発明は、上述した実施の形態の機能を実現するソフトウェアのプログラム（図５、図６のフローチャート）をコンピュータ又はＣＰＵに供給し、そのコンピュータ又はＣＰＵが該供給されたプログラムを読出して実行することによって、達成することができる。
【００９７】
この場合、上記プログラムは、該プログラムを記録した記憶媒体から直接供給されるか、又はインターネット、商用ネットワーク、若しくはローカルエリアネットワーク等に接続される不図示の他のコンピュータやデータベース等からダウンロードすることにより供給される。
【００９８】
上記プログラムの形態は、オブジェクトコード、インタプリタにより実行されるプログラムコード、ＯＳ（オペレーティングシステム）に供給されるスクリプトデータ等の形態から成ってもよい。
【００９９】
また、本発明は、上述した実施の形態の機能を実現するソフトウェアのプログラムを記憶した記憶媒体をコンピュータ又はＣＰＵに供給し、そのコンピュータ又はＣＰＵが記憶媒体に記憶されたプログラムを読出して実行することによっても、達成することができる。
【０１００】
この場合、格納媒体から読出されたプログラムコード自体が上述した各実施の形態の機能を実現すると共に、そのプログラムコードを記憶した記憶媒体は本発明を構成する。
【０１０１】
プログラムコードを記憶する記憶媒体としては、例えば、ＲＯＭ、ＲＡＭ、ＮＶ−ＲＡＭ、フロッピー（登録商標）ディスク、ハードディスク、光ディスク（登録商標）、光磁気ディスク、ＣＤ−ＲＯＭ、ＭＯ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、磁気テープ、不揮発性のメモリカード等がある。
【０１０２】
上述した実施の形態の機能は、コンピュータから読出されたプログラムコードを実行することによるばかりでなく、コンピュータ上で稼動するＯＳ等がプログラムコードの指示に基づいて実際の処理の一部又は全部を行うことによっても実現することができる。
【図面の簡単な説明】
【０１０３】
【図１】本発明の実施の形態に係るショッピングシステムの概要を示す図である。
【図２】ショッピングシステムの構成例を示すブロック図である。
【図３】ショッピングシステムのＷＥＢアプリケーションサーバ内で動作するアプリケーションの一部の構成を示すＵＭＬクラス図である。
【図４】ショッピングシステムのデータベースに格納されるテーブルの一部の構成を示すＥＲ図である。
【図５】図３におけるＯｒｄｅｒＴｅｓｔクラスを使用して注文機能を単体テストする際の処理を示すフローチャートである。
【図６】図５におけるステップＳ５０３の処理の詳細を示すフローチャートである。
【符号の説明】
【０１０４】
１０１  ショッピングシステム
１１０  インターネット
２０１  ＷＥＢアプリケーションサーバ
２０２  データベース
２０３  アプリケーション
３１０  ＡｂｓｔｒａｃｔＴｅｓｔＤａｔａＦａｃｔｏｒｙクラス
３１１  ｇｅｔＩｎｓｔａｎｃｅ（）メソッド
３１２  ｇｅｔＳｈｏｐＩｄ（）メソッド
３１３  ｇｅｔＰｒｏｄｕｃｔＬｉｓｔ（）メソッド
３１４  ｇｅｔＳａｍｐｌｅＯｒｄｅｒ（）メソッド
３２０  ＰｅｔＳｈｏｐＴｅｓｔＤａｔａＦａｃｔｏｒｙクラス
３３０  ＦｌｏｗｅｒＳｈｏｐＴｅｓｔＤａｔａＦａｃｔｏｒｙクラス
３４１  ｃｒｅａｔｅＥｎｔｉｔｙ（）メソッド
３４２  ｒｅｍｏｖｅＥｎｔｉｔｙ（）メソッド
３５０  ＯｒｄｅｒＴｅｓｔクラス
３５１  ｔｅｓｔ（）メソッド
３６０  Ｏｒｄｅｒクラス
【図１】
2005092590.tif 000003
【図２】
2005092590.tif 000004
【図３】
2005092590.tif 000005
【図４】
2005092590.tif 000006
【図５】
2005092590.tif 000007
【図６】
2005092590.tif 000008