(57)【特許請求の範囲】
【請求項１】
コンピュータが複数のカテゴリに属するアイテムを表示して操作を受け付けるアイテム表示ギャラリーシステムを実現するための統括プログラムであって、
前記統括プログラムは、処理順序が特定される複数の処理を前記コンピュータに実行させるためのプログラムであって、
前記統括プログラムは、処理順序が特定される前記複数の処理の各々についてクラスがマッピングされ、当該マッピングされたクラスはその処理順序が先のクラスがその処理順序が後のクラスを包含して定義することにより後のクラスが先のクラスによって生成される関係を有することにより、
前記コンピュータに、第２処理を規定するクラスを包含するクラスにより規定される第１処理を実行させた後に、前記第１処理を規定するクラスに包含されるクラスにより規定される第２処理を実行させる統括プログラム。
【請求項２】
前記統括プログラムは、前記統括プログラムに含まれる全クラスを包含するプラットフォームクラスと、
アイテムクラスと条件クラスを包含するサービスコネクタクラスと、
取得するアイテムの条件を管理する条件クラスと、
前記アイテムに関する情報を管理するアイテムクラスと、を含んで構成し、
前記プラットフォームクラスは、その処理順序が最も先のクラスであり、
前記サービスコネクタクラス及び前記条件クラスは、その処理順序が前記プラットフォームクラスより後のクラスであり、
前記アイテムクラスは、その処理順序が前記サービスコネクタクラスより後のクラスである、請求項１に記載の統括プログラム。
【請求項３】
前記アイテムの取得要求に応じて、前記プラットフォームクラスは前記条件クラス及び前記サービスコネクタクラスからの応答に基づいて前記アイテムに関する情報を返し、
前記プラットフォームクラスからの要求に応じて、前記条件クラスは、取得する前記アイテムの条件を設定し、
前記プラットフォームクラスからの要求に応じて、前記サービスコネクタクラスは、前記条件の内容に従って前記アイテムに関する情報を前記アイテムの実態を管理するギャラリーシステムから取得し、前記アイテムクラスに当該取得した当該アイテムに関する情報を管理させるとともに、当該取得したアイテムに関する情報を返し、
前記サービスコネクタクラスからの要求に応じて、前記アイテムクラスは、要求された前記アイテムに関する情報を編集する、請求項２に記載の統括プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータが複数のカテゴリに属するアイテムを表示して操作を受け付けるアイテム表示ギャラリーシステムを実現するための統括プログラムに関する。
【背景技術】
【０００２】
近年、相互にメッセージを送りあうオブジェクトの集まりとしてプログラムを構成するオブジェクト指向プログラムが知られている。オブジェクト指向プログラムは、ソフトウェアをオブジェクトと呼ばれる機能の部品により構成するため、他のオブジェクトの内部構造や動作原理の詳細を知ることなくプログラミングが可能であり、分割開発に適している。例えば、ユーザ端末に対してアイテムを表示し、当該アイテムに関するユーザの操作（選択・購入・投稿など）を受け付けるアイテム表示ギャラリーシステムでは、ユーザ端末にアイテムを表示する機能や、ユーザの操作を受け付ける機能などの多数の機能を有するため、オブジェクト指向プログラムに適している。
【０００３】
ところで、オブジェクト指向プログラムによるプログラミングを支援するための発明はこれまで多数知られており、例えば、特許文献１には、プログラムの構文解析を行い、構文解析結果とプログラム規約情報とを照合し、照合結果に基づいて修正したプログラムを出力するオブジェクト指向プログラム作成支援装置が開示され、特許文献２には、拡張性や再利用性の高いプログラムとなるための要件を満たしているかどうかを判断し、ユーザに指摘することができるプログラム作成支援装置が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平１１−８５４９６号公報
【特許文献２】特開２００５−９２５１９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記プログラム作成支援装置は、所定の規約を充足するプログラムであるか、拡張性や再利用性が高いプログラムであるかといった点を、「作成されたプログラム」について照合するものであり、プログラム作成時のプログラマを支援するものではなかった。
【０００６】
オブジェクト指向プログラムによるプログラミングを困難にさせる要因の一つに、クラス間の関係性が挙げられる。従来では、クラス間の呼び出し関係などの関係性をプログラマが任意に規定していたため、例えば、あるクラス内で関数又は変数のインスタンスを生成し、他のクラス内で同じ関数又は変数のインスタンスを別に生成してしまうことがあった。その結果、生成したインスタンスが錯綜してしまい、プログラムが全体として不要に複雑になってしまう問題があった。また、このようにクラス間の呼び出し関係が任意に規定できるため、プログラマは常にプログラム全体を把握しておく必要があり、プログラムの分割開発を困難なものとしていた。
【０００７】
本発明は、このような問題に鑑みてなされたものであり、プログラム全体として生成したインスタンスの錯綜を防止し、プログラマによる分割開発が容易な統括プログラム（特に、上記アイテム表示ギャラリーシステムのように多数の機能を有するシステムを実現するための統括プログラム）を提供することを目的とする。
【課題を解決するための手段】
【０００８】
（１）  コンピュータが複数のカテゴリに属するアイテムを表示して操作を受け付けるアイテム表示ギャラリーシステムを実現するための統括プログラムであって、前記統括プログラムは、処理順序が特定される複数の処理を前記コンピュータに実行させるためのプログラムであって、前記統括プログラムは、処理順序が特定される前記複数の処理の各々についてクラスがマッピングされ、当該マッピングされたクラスはその処理順序が先のクラスがその処理順序が後のクラスを包含して定義することにより後のクラスが先のクラスによって生成される関係を有することにより、前記コンピュータに、第２処理を規定するクラスを包含するクラスにより規定される第１処理を実行させた後に、前記第１処理を規定するクラスに包含されるクラスにより規定される第２処理を実行させる統括プログラム。
【０００９】
（１）の統括プログラムによれば、処理順序が特定される第１処理と第２処理との各々は、処理順序が先の第１処理が処理順序が後の第２処理を包含するようにクラスがマッピングされる。これにより、処理順序が後の第２処理を規定するクラスでは、第１処理で生成したインスタンスを新たに生成することがなく、プログラム全体として生成したインスタンスの錯綜を防止することができる。さらに、このようなクラスの包含関係により、プログラマは、当該包含関係の一つ下位のクラスのみを把握すればよいので、分割開発を容易に行うことができる。
【００１０】
（２）  前記統括プログラムは、前記統括プログラムに含まれる全クラスを包含するプラットフォームクラスと、アイテムクラスと条件クラスを包含するサービスコネクタクラスと、取得するアイテムの条件を管理する条件クラスと、前記アイテムに関する情報を管理するアイテムクラスと、を含んで構成し、前記プラットフォームクラスは、その処理順序が最も先のクラスであり、前記サービスコネクタクラス及び前記条件クラスは、その処理順序が前記プラットフォームクラスより後のクラスであり、前記アイテムクラスは、その処理順序が前記サービスコネクタクラスより後のクラスである、（１）に記載の統括プログラム。
【００１１】
（２）の統括プログラムによれば、アイテム表示ギャラリーシステムを実現するための各クラス（機能）を処理順序に沿ってマッピングしたため、アイテム表示ギャラリーシステムの分割開発が容易になる。
【００１２】
（３）  前記アイテムの取得要求に応じて、前記プラットフォームクラスは前記条件クラス及び前記サービスコネクタクラスからの応答に基づいて前記アイテムに関する情報を返し、前記プラットフォームクラスからの要求に応じて、前記条件クラスは、取得する前記アイテムの条件を設定し、前記プラットフォームクラスからの要求に応じて、前記サービスコネクタクラスは、前記条件の内容に従って前記アイテムに関する情報を前記アイテムの実態を管理するギャラリーシステムから取得し、前記アイテムクラスに当該取得した当該アイテムに関する情報を管理させるとともに、当該取得したアイテムに関する情報を返し、前記サービスコネクタクラスからの要求に応じて、前記アイテムクラスは、要求された前記アイテムに関する情報を編集する、（２）に記載の統括プログラム。
【００１３】
（３）の統括プログラムによれば、ユーザ端末に対してアイテムを表示し、当該アイテムに関するユーザの操作（選択・購入・投稿など）を受け付けるアイテム表示ギャラリーシステムを実現することができるとともに、プログラマが当該システムの分割開発を容易に行うことができる。
【発明の効果】
【００１４】
本発明によれば、プログラム全体として生成したインスタンスの錯綜を防止し、プログラマによる作成が容易な統括プログラムを提供することができる。さらに、プログラマが分割開発を容易に行うことができる統括プログラムを提供することができる。
【図面の簡単な説明】
【００１５】
【図１】本発明の概要を示す図である。
【図２】ギャラリーページの表示例を示す図である。
【図３】ギャラリー表示アプリケーションを示す図である。
【図４】ギャラリープラットフォームシステムを示す図である。
【図５】ギャラリープラットフォームシステムのクラスの包含関係を示す図である。
【図６】プラットフォームクラスのソースコードを示す図である。
【発明を実施するための形態】
【００１６】
以下、本発明の実施形態について図面を参照して説明する。
【００１７】
［プログラム１の概要］
本件発明に係るプログラム１の概要について、図１を参照して説明する。
プログラム１は、データとそれを操作する手続きとをオブジェクトと呼ばれるひとまとまりの単位として一体化し、オブジェクトの組み合わせとして作成されるオブジェクト指向プログラムである。オブジェクト指向プログラムでは、クラスを用いてオブジェクトを定義する。
図１では、オブジェクトＡ、オブジェクトＢ、オブジェクトＣ及びオブジェクトＤを含むアプリケーションを例にとり、本件発明に係るプログラム１のクラス構成について説明する。
【００１８】
初めに、図１（１）を参照して、オブジェクト指向プログラムにおける従来のクラス構成を説明する。従来、オブジェクトを定義するクラス間の関係（クラス構成）には何らの規定がなく、設計者により任意に構成されていた。例えば、図１（１）に示すように、夫々対等な関係に構成され、互いに相手クラスのインスタンスを生成し合うことが許可されていた。具体的には、クラスＡにおいてクラスＢ、クラスＣ及びクラスＤといった他のクラスのインスタンスを生成することが可能な一方で、クラスＢ、クラスＣ及びクラスＤにおいても他のクラスのインスタンスを生成することが可能となっていた。
【００１９】
このような従来のクラス構成では、相手クラスのインスタンスの生成が互いに許容されているため、各クラスを担当するプログラマの夫々は、自己の担当するクラスだけでなく他のクラスを含む全体を把握した上で、プログラムの作成を行う必要があった。
【００２０】
また、相手クラスのインスタンスの生成が互いに許容されているため、例えば、クラスＢのインスタンスを、クラスＡだけでなくクラスＣ及びクラスＤでも生成することが許容され、生成したインスタンスの錯綜が生じる原因となっていた。インスタンスの錯綜により、プログラムが全体として不要に複雑になってしまい、プログラムの確認作業に膨大な時間がかかってしまう問題もあった。また、このようにクラス間の呼び出し関係が任意に規定できるため、プログラマは常にプログラム全体を把握しておく必要があり、プログラムの分割開発が困難となる問題もあった。
【００２１】
そこで、本件発明のプログラム１では、各クラス間に包含関係を設けることで、他のクラスのインスタンスの生成に一定の制限を課したクラス構成からなるテンプレートクラスを提供する。具体的には、本件発明のプログラム１では、後述するように、コンピュータＸの実行時の処理順序を開発時のクラス包含関係にマッピングしたテンプレートクラスをプラットフォーム化している。
【００２２】
アプリケーションによっては図１（２）に示すようにコンピュータＸの処理順序が特定されるものがある。例えば、図１（２）では、オブジェクトＡの実行後にオブジェクトＢ及びオブジェクトＣが実行され、オブジェクトＢの実行後にオブジェクトＤが実行される。本実施形態では、このように処理順序が特定されるアプリケーションについて、コンピュータＸの実行時の処理順序をクラス包含関係にマッピングすることで、生成したインスタンスの錯綜が生じないクラス構成を実現している。また、このようなクラスの包含関係により、プログラマは、当該包含関係の一つ下位のクラスのみを把握すればよいので、分割開発を容易に行うことができる。
【００２３】
図１（３）に本件発明に係るプログラム１のクラス構成を示す。コンピュータＸの実行時の処理順序として、オブジェクトＡが、オブジェクトＢ及びオブジェクトＣの前に実行される場合、プログラム１は、処理順序が前のオブジェクトＡを定義するクラスＡに包含される形で、処理順序が後のオブジェクトＢ及びオブジェクトＣを定義するクラスＢ及びクラスＣをマッピングする。すなわち、クラスＡのメンバー変数としてクラスＢ及びクラスＣのインスタンスを持つこととしている。同様に、オブジェクトＢが、オブジェクトＤの前に実行される場合、プログラム１は、処理順序が前のオブジェクトＢを定義するクラスＢに包含される形で、処理順序が後のオブジェクトＤを定義するクラスＤをマッピングする。
【００２４】
コンピュータＸは、このようにマッピングされたクラスにより規定されるオブジェクトを順次処理する。具体的には、クラスＢ及びクラスＣを包含するクラスＡを初めに実行し、クラスＡに包含されるクラスＢ及びクラスＣを次に実行し、続いて、クラスＢに包含されるクラスＤを実行する。すなわち、コンピュータＸは、プログラム１のうち包含上位のクラスから順に実行する。
【００２５】
このようなクラス構成とすることにより、プログラム１では、包含関係にあるクラス間でのみインスタンスの生成が行われ、すなわち、包含上位のクラスで包含下位のクラスのインスタンスの生成が行われることになり、他のクラス間でのインスタンスの生成を不可能とした。具体的には、クラスＤのインスタンスは、クラスＤを包含するクラスＢでのみ生成され、包含関係にないクラスＡ及びクラスＣで生成されることを不可能とした。
【００２６】
これにより、各クラスを担当するプログラマの夫々は、他のクラスを含む全体を把握した上でプログラムの作成を行う必要がなく、プログラムの作成が容易となる。すなわち、クラスＡを担当するプログラマは、自己が担当するクラスＡと、クラスＡが包含するクラスＢ及びクラスＣの外側とのみを把握すれば足り、他のクラスとの関係を把握する必要がない。また、クラスＢを担当するプログラマは、自己が担当するクラスＢと、クラスＢが包含するクラスＤの外側とのみを把握すれば足り、他のクラスとの関係を把握する必要がない。同様に、クラスＣを担当するプログラマは、自己が担当するクラスＣのみを把握すれば足り、他のクラスとの関係を把握する必要がなく、クラスＤを担当するプログラマは、自己が担当するクラスＤのみを把握すれば足り、他のクラスとの関係を把握する必要がない。その結果、インスタンスの錯綜を防止できるとともに、このようにマッピングされたテンプレートクラスを包含クラスの内と外との夫々のプログラマが継承して開発することにより、分割開発が容易となる。
【００２７】
［プログラム１のクラス構成を用いた好適なアプリケーション］
次に、プログラム１のクラス構成を用いた好適なアプリケーションの一例である、ギャラリー表示アプリケーション１０について説明する。ギャラリー表示アプリケーション１０は、複数のアイテムを表示するギャラリーページ１００を表示するためのアプリケーションである。
【００２８】
図２に、ギャラリー表示アプリケーション１０により表示されるギャラリーページ１００を示す。ギャラリーページ１００は、表示されるアイテムの選択を受け付けるアイテム選択部１０１，１０２及び受け付けた選択に基づくアイテムを表示するアイテム表示部１０３を含むページである。
【００２９】
アイテム選択部１０１は、表示されるアイテムの順序を変更するために選択（クリック）される。アイテム選択部１０１が選択されると、選択された順序に従い、アイテム表示部１０３の表示が切り換わる。具体的には、アイテム選択部１０１において「名前順」が選択されると、アイテム表示部１０３には５０音順又はアルファベット順でアイテムが表示される。
【００３０】
アイテム選択部１０２は、表示されるアイテムの種別を変更するために選択（クリック）される。アイテム選択部１０２が選択されると、選択された種別のアイテムを表示するように、アイテム表示部１０３の表示が切り換わる。具体的には、アイテム選択部１０２において「おすすめ」が選択されると、ギャラリー表示アプリケーション１０が管理するアイテムのうち、ギャラリー表示アプリケーション１０の管理者のおすすめのアイテムが、アイテム表示部１０３に表示される。
【００３１】
このようなアイテム選択部１０１，１０２及びアイテム表示部１０３を備えるギャラリー表示アプリケーション１０は、コンピュータＸの処理順序が特定されるアプリケーションである。すなわち、ギャラリー表示アプリケーション１０では、アイテム選択部１０１，１０２から受け付けた情報に基づいて「ページ表示要求」を行い、ページ表示要求に基づいて表示される「表示データを取得し」、取得した表示データを表示するための「画面生成表示」を行うという順序でコンピュータＸの処理が行われる。
【００３２】
［ギャラリー表示アプリケーション１０の概要］
図３及び図４を用いて、ギャラリー表示アプリケーション１０の概要について説明する。図４は、ギャラリー表示アプリケーション１０の構成を示す機能ブロック図であり、図４は、ギャラリー表示アプリケーション１０のギャラリープラットフォームシステム２２の構成を示す機能ブロック図である。
【００３３】
図３を参照して、ギャラリー表示アプリケーション１０は、ギャラリー表示用システム２及びサービスギャラリーＡＰＩシステム３を含む。
【００３４】
ギャラリー表示用システム２は、アイテムを表示するギャラリーページを表示するためのシステムであり、ギャラリーページを表示するためのギャラリーページ表示ロジック２１と、プログラム１を用いて作成されるギャラリープラットフォームシステム２２と、を含む。
【００３５】
サービスギャラリーＡＰＩシステム３は、ギャラリーページに表示されるアイテムを管理するためのシステムであり、ギャラリー表示用システム２からのアイテム要求に基づいてアイテムを取得するためのギャラリーアイテム取得ロジック３１と、アイテムデータを管理するギャラリーデータＤＢ３２と、を含む。
【００３６】
ギャラリー表示用システム２のギャラリープラットフォームシステム２２は、図４に示すようにプラットフォームクラス２２１と、条件クラス２２２と、サービスコネクタクラス２２３と、アイテムクラス２２４と、カテゴリクラス２２５と、を含む。ここで、ギャラリー表示用システム２を構成するクラスの夫々は、コンピュータＸの実行時において処理順序が特定される関係にある。具体的には、コンピュータＸの実行時において、プラットフォームクラス２２１が初めに実行され、条件クラス２２２及びサービスコネクタクラス２２３がプラットフォームクラス２２１の後に実行される。そして、アイテムクラス２２４及びカテゴリクラス２２５などが、サービスコネクタクラス２２３の後に実行される。
【００３７】
プラットフォームクラス２２１は、他のクラス２２２〜２２６などをまとめるクラスであり、ギャラリーページ表示ロジック２１とのやり取りを唯一行うクラスである。すなわち、プラットフォームクラス２２１は、ギャラリーページ表示ロジック２１からの表示要求を受け付ける。表示要求を受け付けると、プラットフォームクラス２２１は、条件クラス２２２及びサービスコネクタクラス２２３からの応答に基づいて、アイテムに関する情報を返す。
【００３８】
条件クラス２２２は、取得するアイテムの条件を管理するクラスである。サービスコネクタクラス２２３は、条件に従って、サービスギャラリーＡＰＩシステム３から情報を取得するクラスである。具体的には、条件クラス２２２は、プラットフォームクラス２２１からの要求に応じて、取得するアイテムの条件を設定し、サービスコネクタクラス２２３は、当該条件の無いように従ってアイテムに関する情報を亜サービスギャラリーＡＰＩシステム３から取得し、アイテムクラス２２４及びカテゴリクラス２２５などに当該取得したアイテムに関する情報を管理させるとともにに、当該取得したアイテムに関する情報を返す。
【００３９】
そして、アイテムクラス２２４及びカテゴリクラス２２５などは、ギャラリー情報を管理するクラスである。具体的には、アイテムクラス２２４及びカテゴリクラス２２５などは、サービスコネクタクラス２２３からの要求に応じて、要求されたアイテムに関する情報を編集する。
【００４０】
このような各クラスを備えるギャラリープラットフォームシステム２２は、コンピュータＸの実行時の処理順序が特定されるものである。具体的には、プラットフォームクラス２２１によりページ表示要求を受けると、サービスコネクタクラス２２３により表示データの取得が行われ、その後、アイテムクラス２２４及びカテゴリクラス２２５などにより画面生成表示が行われる。
【００４１】
このような処理順序を本件発明のプログラム１が規定するクラス包含関係にマッピングしたクラスの包含関係を図５に示す。図５に示すように、プラットフォームクラス２２１は処理順序が後の条件クラス２２２及びサービスコネクタクラス２２３を包含し、サービスコネクタクラス２２３は処理順序が後のアイテムクラス２２４及びカテゴリクラス２２５などを包含する。
【００４２】
このようなクラスの包含関係とすることにより、包含上位のクラスでのみ包含下位のクラスのインスタンスの生成が行われることになり、他のクラス間でのインスタンスの生成が不可能になる。具体的には、サービスコネクタクラス２２３のインスタンスはサービスコネクタクラス２２３を包含するプラットフォームクラス２２１でのみ生成され、包含関係にない条件クラス２２２、アイテムクラス２２４及びカテゴリクラス２２５などでは生成されない。
【００４３】
これにより、各クラスを担当するプログラマの夫々は、他のクラスを含む全体を把握した上でプログラムの作成を行う必要がなく、プログラムの作成が容易となる。また、包含関係にあるクラスでのみインスタンスの生成を許容し、包含関係にないクラスではインスタンスの生成を不可能としたため、プログラマは、当該包含関係の一つ下位のクラスのみを把握すればよいので、分割開発を容易に行うことができる。
【００４４】
そして、このようにマッピングされたクラスを包含関係にあるクラスの内と外との夫々のプログラマが継承して開発することにより、一つの機能（例えば、画面設計）のプログラムのプログラマは、クラスの包含関係により当該包含するクラス（例えば、ＤＢ設計）の内側に包含する管理プロパティのクラスのみを用い、他の機能（例えば、システム設計）のプログラムのプログラマは、その外側のクラスのみを用いて夫々分割開発を行うことができる。
【００４５】
［プラットフォームクラス２２１のソースコードの例］
続いて、図６を参照して、条件クラス２２２及びサービスコネクタクラス２２３を包含するプラットフォームクラス２２１の具体的にソースコードについて説明する。図６は、プラットフォームクラス２２１のソースコードの一例を示す図である。
【００４６】
プラットフォームクラス２２１では、初めにコード３００において、「＄ｇｐｃｙ＝ｎｅｗ  ＣｐＣｏｎｎｅｃｔｏｒＥｘ（）；」と規定され、サービスコネクタクラス２２３のインスタンス「ｇｐｃｙ」が生成される。
【００４７】
続いて、プラットフォームクラス２２１では、コード３０１において、「＄ｃｏｎｄｉｔｉｏｎ＝ｎｅｗ  ＧｐＣｏｎｄｉｔｉｏｎＢａｓｅ（）；」と規定し、条件クラス２２２のインスタンスを生成するとともに、コード３０２において、「＄ｃｏｎｄｉｔｉｏｎ−＞ｍｏｄｅ＝ＧｐＣｏｎｄｉｔｉｏｎＢａｓｅ：：ＭＯＤＥ＿ＩＴＥＭ；」と規定することにより、生成した条件オブジェクトとして定数「アイテムモード」を取得する。
【００４８】
そして、プラットフォームクラス２２１では、コード３０３において、「＄ｇｐｃｙ−＞ｓｅｔＣｏｎｄｉｔｉｏｎ（＄ｃｏｎｄｉｔｉｏｎ）；」と規定し、取得した条件オブジェクト「アイテムモード」をサービスコネクタクラス２２３のインスタンス「ｇｐｃｙ」に反映する。その後、インスタンス「ｇｐｃｙ」を実行することで、「アイテムモード」に基づく処理が行われる。
【００４９】
また、プラットフォームクラス２２１では、コード３０４において、「＄ｃｏｎｄｉｔｉｏｎ−＞ｍｏｄｅ＝ＧｐＣｏｎｄｉｔｉｏｎＢａｓｅ：：ＭＯＤＥ＿ＣＡＴＥＧＯＲＹ；」と規定し、条件オブジェクトとして定数「カテゴリモード」を設定する。そして、プラットフォームクラス２２１では、コード３０５において、「＄ｇｐｃｙ−＞ｓｅｔＣｏｎｄｉｔｉｏｎ（＄ｃｏｎｄｉｔｉｏｎ）；」と規定し、取得した条件オブジェクト「カテゴリモード」をサービスコネクタクラス２２３のインスタンス「ｇｐｃｙ」に設定する。その後、インスタンス「ｇｐｃｙ」を実行することで、「カテゴリモード」に基づく処理が行われる。すなわち、プラットフォームクラス２２１では、条件オブジェクトに設定するモード（アイテムモード、カテゴリモード）を切り換えることで、インスタンスとして生成したサービスコネクタクラス２２３の処理を切り換えている。
【００５０】
このように、プラットフォームクラス２２１では、包含関係にある、より詳細には包含下位の条件クラス２２２及びサービスコネクタクラス２２３のインスタンスのみを生成し、包含関係にないアイテムクラス２２４やカテゴリクラス２２５などのインスタンスを生成することがない。そのため、プラットフォームクラス２２１のプログラマは、アイテムクラス２２４やカテゴリクラス２２５などを把握する必要がなく、プログラムの作成が容易になる。
【００５１】
以上、本発明の実施形態について説明したが、本発明は上述した実施形態に限るものではない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施形態に記載されたものに限定されるものではない。
【符号の説明】
【００５２】
１  プログラム
Ｘ  コンピュータ
【図１】
0005279767.tif 000002
【図２】
0005279767.tif 000003
【図３】
0005279767.tif 000004
【図４】
0005279767.tif 000005
【図５】
0005279767.tif 000006
【図６】
0005279767.tif 000007