JP4159674B2 - オブジェクト指向業務システムおよび方法 - Google Patents
オブジェクト指向業務システムおよび方法 Download PDFInfo
- Publication number
- JP4159674B2 JP4159674B2 JP30069098A JP30069098A JP4159674B2 JP 4159674 B2 JP4159674 B2 JP 4159674B2 JP 30069098 A JP30069098 A JP 30069098A JP 30069098 A JP30069098 A JP 30069098A JP 4159674 B2 JP4159674 B2 JP 4159674B2
- Authority
- JP
- Japan
- Prior art keywords
- domain
- management
- order
- interface
- objects
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Entrepreneurship & Innovation (AREA)
- Human Resources & Organizations (AREA)
- Operations Research (AREA)
- Economics (AREA)
- Marketing (AREA)
- Data Mining & Analysis (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Stored Programmes (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、流通業等において、伝票、商品等の資源に関する情報を管理し、必要な業務を統合する業務システムおよびその方法に関する。
【０００２】
【従来の技術および発明が解決しようとする課題】
近年、主として流通業において、受注伝票の起票、商品在庫の管理、出荷伝票の作成、請求書の発行、入金の受付、受注伝票の発行等の処理業務を統合した伝票処理システムが導入されている。このような情報処理システムは、ＥＲＰ（enterprise resource planning）システムとも呼ばれている。
【０００３】
従来、このような伝票処理システムを始めとする種々のビジネスアプリケーションシステムの構築には、オブジェクト指向は不向きであるとされていた（日経コンピュータ，１９９８．６．２２，ｐｐ．２０９−２１７）。オブジェクトには、通常、データとそのデータに対する手続き（メソッド）がカプセル化されている。
【０００４】
ビジネスプロセスをオブジェクト指向により分析し、オブジェクト部品によりモデルを構築したとしても、従来のシステムでは、実際には純粋なオブジェクトは全体の一部分に過ぎず、他のオブジェクトはデータを持たない退化型オブジェクトである。このため、結果として、オブジェクト指向の長所が十分に活かされず、実問題のモデル化の容易さ、部品の再利用、データと手続きのカプセル化、カスタマイズ性の向上、保守性の向上、品質の向上、および生産性の向上が達成されていなかった。
【０００５】
例えば、伝票処理業務をオブジェクト指向分析する際に、オブジェクト間の境界をどこに設定して、各オブジェクトをどのような粒度で設計すればよいかが非常に曖昧である。ここで、オブジェクト間の境界とは、オブジェクトが保持するデータおよび手続きの境界に対応し、オブジェクトの粒度とは、データおよび手続きの大きさに対応する。
【０００６】
また、オブジェクトの再利用を容易にするための抽象化のレベルについても適当な指針がなく、オブジェクト間のインタラクションが単純にならない。このため、ビジネスプロセスに応じてオブジェクトを組み替えられる程の柔軟性が確保されていない。また、オブジェクトの抽象化がうまくできないため、実装言語の特徴である継承や多態を効果的に使えないという問題もある。
【０００７】
さらに、伝票処理業務に不可欠なリレーショナルデータベースシステムでは、レコードの一意性が保証されているのに対して、オブジェクトの世界では、同じデータを持つオブジェクトが複数存在することが許容されている。このため、リレーショナルデータベースシステムとオブジェクトの世界との境界の設計が難しく、データの整合性の保証や、複数のオブジェクトにまたがるトランザクション制御の実現が困難である。
【０００８】
本発明の課題は、オブジェクト指向部品を組み合わせて構築され、オブジェクト指向の特徴を活用する業務システムおよびその方法を提供することである。
【０００９】
【課題を解決するための手段】
図１は、本発明の業務システムの原理図である。図１の業務システムは、オブジェクト手段１と実行手段２を備える。オブジェクト手段１は、ビジネスルールを保持するドメインオブジェクト３と、ドメインオブジェクト３を管理し、データアクセスのインタフェースを実装するオブジェクト管理４とを有する。実行手段２は、ドメインオブジェクト３とオブジェクト管理４を用いて、ビジネスルールに対応する処理を実行する。
【００１０】
ドメインオブジェクト３が保持するビジネスルールは、業務処理手順に基づいて作成される手続きに対応し、ドメインオブジェクト３のデータの設定や演算ロジックに関するプリミティブな処理を記述している。また、オブジェクト管理４は、ドメインオブジェクト３とは別のオブジェクトであり、オブジェクト管理４が保持するデータアクセスのインタフェースは、補助記憶装置に格納されたデータベースやシーケンシャルファイル等へのアクセス手続きに対応する。
【００１１】
このように、データアクセスのインタフェースを保持するオブジェクトを、ビジネスルールを保持するオブジェクトから分離することにより、ビジネスルールとデータアクセスのインタフェースをそれぞれ独立に実装することができる。これにより、各オブジェクトの抽象度が高められ、その粒度も小さくなるため、オブジェクト間のインタラクションを単純化することが可能になる。また、ビジネスルールとデータアクセスのインタフェースが独立に部品化されるため、いずれか一方を取り替えることができ、システムの柔軟性が向上する。
【００１２】
さらに、オブジェクト管理４がデータアクセスに関する処理を担当するため、ドメインオブジェクト３は、データベース等のアクセス対象を区別した実装を行う必要がない。このように、オブジェクト管理４は、ドメインオブジェクト３からデータベース等を隠蔽しており、データベースとオブジェクトの世界との境界が明確になる。
【００１３】
オブジェクト管理４は、例えば、データアクセスの対象およびアクセス形態のうち少なくとも一方に適したインタフェースを実装し、ドメインオブジェクト３と組み合わせて用いられる。例えば、図１のオブジェクト手段１は、後述する図２８のメモリ８２に対応し、図１の実行手段２は、図２８のＣＰＵ（中央処理装置）８１に対応する。
また、本発明の別の業務システムは、伝票処理業務を含んだ処理業務を行うためのコンピュータシステムであって、第一、第二、および第三の記憶手段と実行手段を備える。第一の記憶手段は、属性データと、属性データの値の設定方法や演算ロジックに関するメソッドとを保持するドメインオブジェクトを記憶する。第二の記憶手段は、ドメインオブジェクトを生成または削除または保持するとともに、ドメインオブジェクトが保持する属性データに対するメソッドとしてデータアクセスのインタフェースを保持するオブジェクト管理を記憶する。第三の記憶手段は、ドメインオブジェクトおよびオブジェクト管理へのリンク関係と、ドメインオブジェクトおよびオブジェクト管理が保持するメソッドの実行手順とを保持する制御オブジェクトを記憶する。実行手段は、制御オブジェクトが保持するリンク関係と実行手順に基いて、ドメインオブジェクトおよびオブジェクト管理が保持するメソッドを実行する。第二の記憶手段は、第一の記憶手段が記憶しているドメインオブジェクトのうちの１つのドメインオブジェクトに対応して、データアクセスの対象およびアクセス形態のうち少なくとも一方に応じて複数のオブジェクト管理を記憶し、実行手段は、制御オブジェクトが、そのドメインオブジェクトに対応するオブジェクト管理のメソッドの実行を要求することにより、そのドメインオブジェクトに保持されている属性データを対応する複数のオブジェクト管理のうちの１つに保持されているインタフェースに従い補助記憶装置へ保存する。
【００１４】
【発明の実施の形態】
以下、図面を参照しながら、本発明の実施の形態を詳細に説明する。
本実施形態においては、組み合わせて使用する各オブジェクト部品の粒度や、ビジネスアプリケーションとクライアント画面、あるいはビジネスアプリケーションとデータベースシステムとの境界面に位置するオブジェクトの機能や仕組みを明確化し、伝票処理業務全体をオブジェクトの集合で表現する。その際、一定のパターンに当てはめて部品の抽出および設計を行うことで、オブジェクト間のリンクや会話のインタフェースを単純化する。
【００１５】
具体的には、ビジネスルールを実装する場所と、データアクセス等に関する性能を実現する仕組みを実装する場所と、トランザクションの範囲を定義する場所とを、オブジェクト部品として明確に分離し、オブジェクト部品間の標準的な関係と標準的な会話の手順を設定する。そして、各々の実装の変更を独立して行えるようにする。
【００１６】
個々のオブジェクト部品は、あらかじめ決められた分析パターンによって一定の抽象度や粒度で設計され、これらの部品の中味およびインタフェースはあらかじめ決められた設計パターンおよび実装パターンに基づいて構築される。このため、部品の組み替えによるアプリケーションの修正や、部品内部の変更によるアプリケーションの修正が容易である。
【００１７】
また、ビジネスルールの変更、トランザクションの範囲の変更、およびデータベースアクセスやキャッシュへの要件の変更が生じた際に、修正対象の部品を容易に特定でき、対象外の部品に影響を与えることなく、それを修正することが可能である。また、オブジェクトの継承による新たな部品開発が容易で、新規部品と既存部品の組み合わせが良好に行える。
【００１８】
図２は、本実施形態の業務システムの構成図である。図２の業務システムは、ワークステーション等のコンピュータを用いて構成され、クライアント１１、ビジネスオブジェクト１２、データベース１３、およびシーケンシャルファイル１４を備える。データベース１３とシーケンシャルファイル１４は、それぞれ、補助記憶装置に格納される。
【００１９】
クライアント１１は、ユーザインタフェースとなる入出力装置に対応し、ビジネスオブジェクト１２は、オブジェクト部品の集合に対応する。これらのオブジェクト部品は、システムのメモリ上に展開される。また、データベース１３としては、例えば、リレーショナルデータベースが用いられる。
【００２０】
ビジネスオブジェクト１２は、ディレクタ２１とモデル群２２を含む。ディレクタ２１は、通信層のミドルウェアであって、クライアント１１とモデル群２２の間の通信に関する制御を行う。モデル群２２のオブジェクトは、その役割によって、ドメインオブジェクト２３、オブジェクト管理（オブジェクトマネージャ）２４、制御オブジェクト２５、およびサービスオブジェクト２６に分類される。
【００２１】
ドメインオブジェクト２３は、業務分析の際に、伝票や商品等の“物品”として抽出されたクラスに対応する。ここで、クラスとはオブジェクトの構造の定義に対応する。クラスにより定義された構造を持つ具体的なオブジェクトは、インスタンスと呼ばれる。
【００２２】
また、ドメインオブジェクト２３は、保持するデータに関するビジネスルールと手続きの実行手順を保持する。このビジネスルールは、業務処理手順を表すビジネスロジックに基づいて作成される手続きであり、主として値の設定や演算ロジックに関するプリミティブな処理を記述している。また、ドメインオブジェクト２３は、例外通知の受信や状態遷移も行う。
【００２３】
オブジェクト管理２４は、データベース１３やシーケンシャルファイル１４等への永続化が必要なドメインオブジェクト２３を管理するために用意されたクラスであり、対応するドメインオブジェクト２３と組み合わせて用いられる。ここで、永続化とは、補助記憶装置にデータを保存することを表す。
【００２４】
オブジェクト管理２４は、ドメインオブジェクト２３の生成元でもあり、ドメインオブジェクト２３の生成、削除、集約、再利用を行い、ドメインオブジェクト２３と同じインタフェースを備える。
【００２５】
また、オブジェクト管理２４は、外部のデータにアクセスする際のプロキシ（代理）でもあり、入出力ロジックの手続きを保持する。この入出力ロジックは、アクセス対象の種類やアクセス形態に応じた処理を記述しており、ビジネスルールから分離されている。
【００２６】
アクセス対象としては、データキャッシュや様々な種類の補助記憶装置が考えられる。データキャッシュは、ドメインオブジェクトをメモリ上に保持し続け、そのオブジェクトが参照されたとき、補助記憶装置にアクセスせずに、そのオブジェクトの情報を直ちに返却するメカニズムを表す。
【００２７】
また、アクセス形態は、アクセス対象のデータ構造等によって変化する。オブジェクト管理２４は、例えば、データベース１３にはＳＱＬによりアクセスし、データの検索、追加、削除、更新等の処理を行う。また、シーケンシャルファイル１４にはシーケンシャルにアクセスし、リード／ライト処理を行う。
【００２８】
さらに、オブジェクト管理２４は、システムがオンライン処理、バッチ処理、およびマスタメンテナンス処理のうちのいずれを行うかに応じて、異なる性能向上アルゴリズムを用いた入出力処理を行う。ここで、マスタメンテナンス処理は、ドメインオブジェクトの静的なデータを更新する処理等に対応し、性能向上アルゴリズムとしては、データキャッシュやデータベースアクセスのアルゴリズムが用いられる。
【００２９】
様々な入出力ロジックの組み合わせは、通常、オブジェクト管理２４のサブクラスにより指定され、処理に応じて特定のサブクラスのオブジェクト管理２４が用いられる。
【００３０】
制御オブジェクト２５は、業務分析の際に、“人手”、“業務”、“アプリケーション”，“画面”等として抽出されたクラスに対応し、ドメインオブジェクト２３、オブジェクト管理２４、およびサービスオブジェクト２６へのリンク関係を保持する。また、ドメインオブジェクト２３間の協調関係に関するビジネスルールと手続きの実行手順を保持する。
【００３１】
また、ディレクタ２１を介して入力されるクライアント１１からの処理依頼を、保持しているリンク関係に基づいて処理する。このとき、ビジネスルールに基づいてオブジェクトの協調関係を制御し、処理結果をクライアント１１に通知する。
【００３２】
これにより、制御オブジェクト２５は、抽象度が高く粒度の小さい複数のオブジェクトを繋ぎ合わせて、アプリケーションとしての処理の流れを制御し、複数のデータベースにまたがるようなトランザクションのセッションの範囲を規定する。そして、処理中に生じたエラーの出口処理を集中的に行う。
【００３３】
さらに、トランザクションの管理、モデルの例外通知の受信、クライアント１１とモデル群２２の間の型変換およびプロトコル変換、データの組立／分解等も行う。
【００３４】
サービスオブジェクト２６は、ドメインオブジェクト２３と類似のクラスに対応するが、補助記憶装置への永続化を必要とせず、対応するオブジェクト管理２４を持たない。サービスオブジェクト２６は、主として、他のオブジェクトから依頼された特定の機能をサービスとして実行する。
【００３５】
また、ドメインオブジェクト２３が業種に共通するビジネスルールを保持する場合、ドメインオブジェクト２３から独立しているサービスオブジェクト２６を用いて、システムをカスタマイズすることができる。この場合、カスタマイズを前提としたインタフェースをサービスオブジェクト２６に持たせておき、個別のユーザがビジネスルールを後から組み込めるようにする。
【００３６】
ビジネスオブジェクト１２における破線の矢印は、オブジェクトの生成関係を表す。オブジェクト管理２４、制御オブジェクト２５、およびサービスオブジェクト２６は、ディレクタ２１により生成され、ドメインオブジェクト２３は、対応するオブジェクト管理２４により生成される。
【００３７】
また、ビジネスオブジェクト１２における実線の矢印は、オブジェクト間のメッセージの流れを表す。メッセージ▲１▼は、クライアント１１に対して公開されているメソッドに対応し、メッセージ▲２▼は、論理テーブルへの照会に対応し、メッセージ▲３▼は、ドメインオブジェクト２３のデータの設定に対応する。また、メッセージ▲４▼は、ドメインオブジェクト２３の生成、更新、削除等の依頼に対応し、メッセージ▲５▼は、サービスオブジェクト２６へのサービス依頼に対応する。
【００３８】
このように、ドメインオブジェクト２３は、ビジネスルールを実装し、オブジェクト管理２４は、そのビジネスルールに対応するデータの入出力ロジックを実装し、制御オブジェクト２５は、それらの協調関係をトランザクションとして制御するビジネスルールを実装する。したがって、入出力ロジックがビジネスルールから明確に分離され、オブジェクト管理２４を取り替えることで、１つのビジネスルールに対して多様な入出力ロジックを組み合わせることが可能になる。
【００３９】
これに対して、従来のシステムでは、ビジネスルールと入出力ロジックの境界が明確でなく、これらが１つのオブジェクトに埋め込まれていることが多い。このため、ビジネスルールおよび入出力ロジックの一方を追加／削除するような操作が難しいという問題があった。
【００４０】
次に、図３は、ディレクタ２１、ドメインオブジェクト２３、オブジェクト管理２４、および制御オブジェクト２５のクラスのアーキテクチャを示している。図３の階層関係において、デイレクタベースクラス３１は、ディレクタ２１の上位のクラス（スーパークラス）であり、モデルベースクラス３２は、コントローラベースクラス３３、ドメインモデルベースクラス３４、オブジェクトマネージャベースクラス３５の上位のクラスである。また、コントローラベースクラス３３、ドメインモデルベースクラス３４、およびオブジェクトマネージャベースクラス３５は、それぞれ、制御オブジェクト２５、ドメインオブジェクト２３、およびオブジェクト管理２４の上位のクラスである。
【００４１】
一般に、クラス間の階層関係においては、下位のクラスが上位のクラスの定義を継承するため、制御オブジェクト２５、ドメインオブジェクト２３、およびオブジェクト管理２４は、それぞれ、コントローラベースクラス３３、ドメインモデルベースクラス３４、オブジェクトマネージャベースクラス３５の定義に基づいて生成される。
【００４２】
ところで、伝票処理業務の場合、業務システムの基本機能として、図４に示すような機能が要求される。図４では、“受注”、“出荷”、“与信”、および“在庫”が基本機能として存在し、“受注”は他の３つの機能を起動し、“出荷”は“在庫”を起動する。これらの基本機能は、伝票または商品に対応して設けられており、オブジェクトのクラスとして利用することができる。
【００４３】
“受注”は、“ＥＤＩ（electronic data interchange ）受注”、“直送受注”、“見積受注”、および“一般受注”の各機能を含み、“出荷”は、“出荷予定”、“出荷確定”、“分納出荷”、および“ピッキング指示”の各機能を含む。また、“与信”は、“与信警告”および“与信更新”の各機能を含み、“在庫”は、“在庫引当（引落）”、“ロット管理”、“倉庫移動”、“棚卸”、“荷姿単位管理”、および“在庫評価”の各機能を含む。
【００４４】
このような基本機能を実現するために、例えば、図５に示すようなクラスが設けられる。ここでは、受注制御４１、出荷制御４２、受注明細管理４３、受注明細４４、出荷明細管理４５、出荷明細４６、在庫サービス４７、与信管理４８、与信４９、在庫管理５０、および在庫５１がクラスとして設けられている。
【００４５】
このうち、受注制御４１および出荷制御４２は、制御オブジェクトのクラスに対応し、受注明細管理４３、出荷明細管理４５、与信管理４８、および在庫管理５０は、オブジェクト管理のクラスに対応する。また、受注明細４４、出荷明細４６、与信４９、および在庫５１は、ドメインオブジェクトのクラスに対応し、在庫サービス４７は、サービスオブジェクトのクラスに対応する。
【００４６】
受注制御４１は、ＥＤＩ受注入力（）、見積受注入力（）、一般受注入力（）、および直送受注入力（）の各メソッドを保持し、出荷制御４２は、出荷予定入力（）、分納出荷指示（）、ピッキング指示（）、出荷確定（）の各メソッドを保持する。
【００４７】
また、在庫サービス４７は、在庫引当（）、倉庫移動（）、荷姿単位別照会（）、ロット別照会（）、棚卸入力（）、および在庫評価（）の各メソッドを保持し、与信４９は、与信残高更新（）および与信警告チェック（）の各メソッドを保持する。このうち、記号“＋”が付加されたメソッドは、ＯＭＴ（object modeling technique ）表記でパブリックなメソッドに対応する。
【００４８】
また、実線の矢印はリンク関係を表し、例えば、受注制御４１は受注明細管理４３へのリンクを保持している。破線の矢印は使用関係を表し、例えば、受注明細４４は与信４９および在庫サービス４７の機能を必要に応じて使用する。◇印の付加された実線は集約関係を表し、例えば、受注明細管理４３のクラスの１つのオブジェクトは、受注明細４４のクラスの１つまたは複数のオブジェクトと相互にリンク関係を持っている。
【００４９】
リンク関係は、例えば、リンク元のオブジェクトがリンク先のオブジェクトを指すポインタを保持することにより設定される。相互リンク関係の場合は、２つのオブジェクトが、互いに相手のオブジェクトを指すポインタを保持している。
【００５０】
実際には、これらのクラス以外にも、商品、商品管理、得意先、得意先管理等の多数のクラスが設けられ、それらが互いにリンク関係や使用関係で関係付けられて、業務システムが構築される。また、一部のクラスのみを組み合わせることにより、部分的な機能を実現する受注入力システム、出荷指示システム、売上計上システム等の伝票処理システムを構築することもできる。
【００５１】
次に、図６から図１９までを参照しながら、オブジェクトのリンク関係の例と、オブジェクトの設計に用いられた分析パターンの例について説明する。設計パターンおよび実装パターンは、分析パターンより具体的であるが、基本的な構造は分析パターンと同様である。
【００５２】
図６は、オブジェクト間メッセージを説明するためのオブジェクトのリンク関係を示している。一般に、オブジェクトが他のオブジェクトにメソッドの実行を要求する場合は、そのメソッドの名称を含むメッセージを要求先のオブジェクトに送信する。
【００５３】
図６において、受注明細４４は、データのリード／ライトを伴うジャーナル系のドメインオブジェクトに対応し、商品６１は、主としてデータのリードのみに用いられるマスタ系のドメインオブジェクトに対応する。また、商品管理６２は、商品６１を管理するオブジェクト管理である。受注明細４４は、商品６１と商品管理６２を指す単方向のリンクを保持しており、商品管理６２と商品６１は、上述したような集約関係を持つ。
【００５４】
ドメインオブジェクトは、“物品”として抽出さたクラスに対応するので、“物品”の属性データとメソッドを保持している。属性は、ＣＲＣ（class responsibility & collaboration）カード分析やデータベースの項目から導かれる。ＣＲＣカード分析は、システム化対象の業務をオブジェクト指向分析する方法の１つであり、クラス毎に責務とその協調クラスを書き込むＣＲＣカードを用いて、属性、メソッド、クラス間のリンク関係等を抽出することができる。また、ドメインオブジェクトのメソッドは、属性値の設定、参照、ビジネスルール、計算式等に対応する。
【００５５】
ここでは、受注明細４４は、“商品コード”を属性として保持し、“Ｓｅｔ商品コード”、“Ｓｅｔ数量”、および“Ｇｅｔ商品”をメソッドとして保持している。商品６１は、“商品名”、“メーカー”、および“荷姿”を属性として保持し、“Ｇｅｔ商品名”、“Ｇｅｔメーカー”、および“Ｇｅｔ荷姿”をメソッドとして保持している。商品管理６２は、“Ｇｅｔ商品”および“Ｇｅｔ商品名”をメソッドとして保持している。商品６１が保持する“Ｇｅｔ商品名”、“Ｇｅｔメーカー”、および“Ｇｅｔ荷姿”は、ドメインオブジェクトのビジネスルールに対応する。
【００５６】
図７は、これらのオブジェクトが行う動作のパターンを示している。ここでは、商品コードの設定、数量の設定、商品オブジェクトの取得、メーカー取得、荷姿取得、および商品名取得の６つのパターンが示されている。
【００５７】
まず、商品コードの設定において、制御オブジェクトがＳｅｔ商品コード（コード）のメッセージを受注明細４４に送信すると、受注明細４４は、Ｓｅｔ商品コード（コード）を実行し、与えられた商品コードを設定する。次に、受注明細４４は、Ｇｅｔ商品名（コード）のメッセージを商品管理６２に送信し、商品管理６２は、Ｇｅｔ商品名（コード）を実行して、商品コードに対応する商品名を受注明細４４に返送する。このように、受注明細４４は、商品コードを設定したとき、対応する商品名を商品管理６２から自動的に取得する。
【００５８】
次に、数量の設定において、制御オブジェクトがＳｅｔ数量（個数）のメッセージを受注明細４４に送信すると、受注明細４４は、Ｓｅｔ数量（個数）を実行し、与えられた個数を設定する。
【００５９】
次に、商品オブジェクトの取得において、制御オブジェクトがＧｅｔ商品（）のメッセージを受注明細４４に送信すると、受注明細４４は、Ｇｅｔ商品（コード）のメッセージを商品管理６２に送信する。商品管理６２は、Ｇｅｔ商品（コード）を実行して、対応する商品６１（インスタンス）の情報を受注明細４４に返送し、受注明細４４は、その情報を制御オブジェクトに返送する。以後、制御オブジェクトは、返送された情報に基づいて、商品６１にメッセージを送信することができる。
【００６０】
次に、メーカー取得において、制御オブジェクトがＧｅｔメーカー（）のメッセージを商品６１に送信すると、商品６１は、Ｇｅｔメーカー（）を実行し、メーカー名を制御オブジェクトに返送する。
【００６１】
次に、荷姿取得において、制御オブジェクトがＧｅｔ荷姿（）のメッセージを商品６１に送信すると、商品６１は、Ｇｅｔ荷姿（）を実行し、荷姿を制御オブジェクトに返送する。
【００６２】
次に、商品名取得において、制御オブジェクトがＧｅｔ商品名（）のメッセージを商品６１に送信すると、商品６１は、Ｇｅｔ商品名（）を実行し、商品名を制御オブジェクトに返送する。
【００６３】
このように、ジャーナル系のドメインオブジェクトは、マスタ系のドメインオブジェクトを自力で取得し、そのオブジェクトと会話することができる。また、制御オブジェクトは、ジャーナル系のドメインオブジェクトまたはオブジェクト管理を介してマスタ系のドメインオブジェクトを取得し、そのオブジェクトから必要な情報を取得することができる。
【００６４】
図７のパターンでは、商品管理６２によるデータのアクセス形態が規定されていないため、リレーショナルデータベースかシーケンシャルファイルかに依らず、また、オンライン処理かバッチ処理かに依らずに、このパターンを適用することができる。実際に用いられる入出力ロジックは、商品管理６２のサブクラスとしてコンパイル時に指定され、実行プログラムに反映される。
【００６５】
図８は、サービスオブジェクトを説明するためのオブジェクトのリンク関係を示している。サービスオブジェクトは、ドメインオブジェクトから手続き部分を分離独立させたクラスに相当し、単独でも部品となり得る。また、複数種類のドメインオブジェクトにサービスを提供できる汎用あるいは多数のインタフェースを持つ。また、ビジネスルールの実行時に必要なマスタ系のドメインオブジェクトを参照することができる。さらに、補助記憶装置への永続化が必要な属性を持たず、オブジェクト管理も必要としない。
【００６６】
図８において、売上単価６３は、サービスオブジェクトであり、季節単価６４は、マスタ系のドメインオブジェクトである。受注明細管理４３は、売上単価６３を指すリンクを保持し、売上単価６３は、季節単価６４および商品６１を指すリンクを保持している。また、受注明細管理４３と受注明細４４は集約関係を持っており、受注明細４４は、売上単価６３を使用する。このように、ドメインオブジェクトが使用するサービスオブジェクトは、対応するオブジェクト管理により保持されている。
【００６７】
ここでは、受注明細管理４３は、“Ｇｅｔ売上単価”をメソッドとして保持し、受注明細４４は、“商品コード”を属性として保持し、“単価決定”をメソッドとして保持している。
【００６８】
売上単価６３は、“Ｇｅｔ単価”、“Ｃｈｅｃｋ手入力”、“Ｇｅｔ季節単価”、および“Ｇｅｔ標準単価”をメソッドとして保持し、季節単価６４は、“商品コード”、“期間”、および“単価”を属性として保持し、“Ｇｅｔ単価”をメソッドとして保持している。商品６１は、“商品コード”および“標準単価”を属性として保持し、“Ｇｅｔ単価”をメソッドとして保持している。
【００６９】
図９は、これらのオブジェクトが行う動作のパターンを示している。ここでは、単価決定依頼のパターンが示されている。まず、制御オブジェクトが単価決定（）のメッセージを受注明細４４に送信すると、受注明細４４は、Ｇｅｔ売上単価（）のメッセージを受注明細管理４３に送信し、Ｇｅｔ単価（明細）のメッセージを売上単価６３に送信する。受注明細管理４３は、Ｇｅｔ売上単価（）を実行し、売上単価６３は、Ｇｅｔ単価（明細）を実行する。
【００７０】
このとき、売上単価６３は、Ｃｈｅｃｋ手入力（）を実行し、Ｇｅｔ単価（）のメッセージを季節単価６４および商品６１に送信する。季節単価６４および商品６１は、Ｇｅｔ単価（）を実行して、対応する単価を売上単価６３に返送し、売上単価６３は、それを受注明細４４に返送する。
【００７１】
図１０は、オブジェクト管理によるインスタンスの管理を説明するためのオブジェクトのリンク関係を示している。オブジェクト管理は、ドメインオブジェクトのインスタンスの生成（ＧｅｔＮｅｗ）、取得（ＧｅｔＯｎｅ）、追加（ＩｎｓｅｒｔＯｎｅ）、更新（ＵｐｄａｔｅＯｎｅ）の各インタフェースを有し、これらのインタフェースはすべてのオブジェクト管理で統一されている。
【００７２】
“ＧｅｔＯｎｅ”は、ドメインオブジェクトのキー属性を指定して、対応する１つのインスタンスをキャッシュまたは補助記憶装置から取得し、そのインスタンスの情報を返却する。“ＩｎｓｅｒｔＯｎｅ”は、新規に生成されたドメインオブジェクトのインスタンスを１つずつ登録する。“ＵｐｄａｔｅＯｎｅ”は、既存のドメインオブジェクトのインスタンスを１つずつ更新する。
【００７３】
オブジェクト管理は、メモリリーク対策、インスタンスの再利用、インスタンスの一意性保持、データキャッシュのメカニズムを隠蔽している。データキャッシュのメカニズムは、生成／取得されたドメインオブジェクトをメモリ上に保持し続け、そのオブジェクトと同じキー属性を指定する“ＧｅｔＯｎｅ”に対しては、補助記憶装置にアクセスせずに、そのオブジェクトの情報を返却する。また、オブジェクト管理は、固有の属性やビジネスルールを内部に持たないため、実装パターンの適用率は１００％である。
【００７４】
図１０において、得意先６５は、マスタ系のドメインオブジェクトであり、得意先管理６６は、得意先６５のオブジェクト管理であり、得意先マスタメンテ６７は、得意先６５のメンテナンスを行う制御オブジェクトである。得意先マスタメンテ６７は、得意先６５および得意先管理６６を指すリンクを保持し、得意先管理６６と得意先６５は集約関係を持っている。
【００７５】
ここでは、得意先管理６６は、“ＧｅｔＮｅｗ”、“ＩｎｓｅｒｔＯｎｅ”、“ＧｅｔＯｎｅ”、および“ＵｐｄａｔｅＯｎｅ”をメソッドとして保持し、得意先６５は、“得意先コード”を属性として保持し、“Ｓｅｔ得意先コード”および“Ｓｅｔ得意先名”をメソッドとして保持している。得意先マスタメンテ６７は、“新規作成”、“Ｓｅｔ項目”、“登録”、および“更新”をメソッドとして保持している。
【００７６】
図１１は、これらのオブジェクトが行う動作のパターンを示している。ここでは、得意先追加と得意先修正の各パターンが示されている。これらのパターンは、必要な回数だけループ処理として繰り返される。
【００７７】
得意先追加において、まず、得意先マスタメンテ６７は、新規作成（）のメッセージを受け取ると、新規作成（）を実行し、ＧｅｔＮｅｗ（）のメッセージを得意先管理６６に送信する。得意先管理６６は、ＧｅｔＮｅｗ（）を実行して、得意先６５のインスタンスを生成し、その情報を得意先マスタメンテ６７に返送する。
【００７８】
次に、得意先マスタメンテ６７は、Ｓｅｔ項目（“得意先コード”，ｃｏｄｅ）のメッセージを受け取ると、Ｓｅｔ項目（“得意先コード”，ｃｏｄｅ）を実行し、Ｓｅｔ得意先コード（ｃｏｄｅ）のメッセージを得意先６５に送信する。そして、得意先６５は、Ｓｅｔ得意先コード（ｃｏｄｅ）を実行して、得意先コードを設定する。
【００７９】
次に、得意先マスタメンテ６７は、登録（）のメッセージを受け取ると、登録（）を実行し、ＩｎｓｅｒｔＯｎｅ（得意先インスタンス）のメッセージを得意先管理６６に送信する。そして、得意先管理６６は、ＩｎｓｅｒｔＯｎｅ（得意先インスタンス）を実行し、データベースに得意先６５を追加する。
【００８０】
また、得意先修正において、まず、得意先マスタメンテ６７は、検索（得意先コード）のメッセージを受け取ると、検索（得意先コード）を実行し、ＧｅｔＯｎｅ（得意先コード）のメッセージを得意先管理６６に送信する。得意先管理６６は、ＧｅｔＯｎｅ（得意先コード）を実行して、得意先６５のインスタンスをデータベースから取得し、その情報を得意先マスタメンテ６７に返送する。
【００８１】
次に、得意先マスタメンテ６７は、Ｓｅｔ項目（“得意先名”，ｎａｍｅ）のメッセージを受け取ると、Ｓｅｔ項目（“得意先名”，ｎａｍｅ）を実行し、Ｓｅｔ得意先名（ｎａｍｅ）のメッセージを得意先６５に送信する。そして、得意先６５は、Ｓｅｔ得意先名（ｎａｍｅ）を実行して、得意先名を設定する。
次に、得意先マスタメンテ６７は、更新（）のメッセージを受け取ると、更新（）を実行し、ＵｐｄａｔｅＯｎｅ（得意先インスタンス）のメッセージを得意先管理６６に送信する。そして、得意先管理６６は、ＵｐｄａｔｅＯｎｅ（得意先インスタンス）を実行し、データベースに登録されている得意先６５を更新する。
図１２は、オブジェクト管理による永続化先の隠蔽を説明するためのオブジェクトのリンク関係を示している。永続化先の補助記憶装置におけるデータ構造によってオブジェクト管理の実装（実行プログラム）は異なるが、ドメインオブジェクトのインスタンスの生成、取得、および追加のインタフェースは、異なるデータ構造の間で統一されている。
【００８２】
データ構造としては、上述のリレーショナルデータベースとシーケンシャルファイルのほかに、ＣＳＶ（comma separated value ）形式のファイルも用いられる。ドメインオブジェクト側のインタフェースは永続化先のデータ構造に依存しないため、制御オブジェクトではそれらを区別した実装を行う必要がない。
【００８３】
図１２において、ＥＤＩ受注明細６８は、回線を介した受注の受注明細に対応するＣＳＶ系のドメインオブジェクトであり、ＥＤＩ受注明細管理６９は、ＥＤＩ受注明細６８のオブジェクト管理である。ＥＤＩ受注制御７０は、ＥＤＩ受注明細管理６９および受注明細管理４３を指すリンクを保持し、ＥＤＩ受注明細管理６９とＥＤＩ受注明細６８は集約関係を持っている。また、ＥＤＩ受注制御７０は、ＥＤＩ受注明細６８と受注明細４４を使用し、受注明細４４は、ＥＤＩ受注明細６８を使用する。
【００８４】
ここでは、ＥＤＩ受注明細管理６９は、“Ｇｅｔ”をメソッドとして保持し、ＥＤＩ受注制御７０は、“受注開始”をメソッドとして保持し、ＥＤＩ受注明細６８は、“Ｇｅｔ商品コード”、“Ｇｅｔ数量”、および“Ｇｅｔ受注番号”をメソッドとして保持している。受注明細管理４３は、“ＧｅｔＮｅｗ”および“ＩｎｓｅｒｔＯｎｅ”をメソッドとして保持し、受注明細４４は、“伝票番号”および“明細番号”を属性として保持し、“Ｓｅｔ商品コード”、“Ｓｅｔ数量”、および“Ｓｅｔ受注番号”をメソッドとして保持している。
【００８５】
図１３は、これらのオブジェクトが行う動作のパターンを示している。ここでは、シーケンシャルファイルの受注情報からリレーショナルデータベースの受注ジャーナルを作成するパターンが示されている。このパターンは、必要な回数だけループ処理として繰り返される。このパターンは、単なるデータ移行ではなく、ＥＤＩ受注明細６８および受注明細４４のクラスのビジネスルールに対応する。
【００８６】
まず、ＥＤＩ受注制御７０は、受注開始（）のメッセージを受け取ると、受注開始（）を実行し、Ｇｅｔ（）のメッセージをＥＤＩ受注明細管理６９に送信する。ＥＤＩ受注明細管理６９は、Ｇｅｔ（）を実行して、シーケンシャルファイルからＥＤＩ受注明細６８のインスタンスを取得し、その情報をＥＤＩ受注制御７０に返送する。
【００８７】
次に、ＥＤＩ受注制御７０は、ＧｅｔＮｅｗ（）のメッセージを受注明細管理４３に送信し、受注明細管理４３は、ＧｅｔＮｅｗ（）を実行して、受注明細４４のインスタンスを生成し、その情報をＥＤＩ受注制御７０に返送する。
【００８８】
次に、ＥＤＩ受注制御７０は、Ｓｅｔ（ＥＤＩ受注明細）のメッセージを受注明細４４に送信し、受注明細４４は、Ｓｅｔ（ＥＤＩ受注明細）を実行する。そして、Ｇｅｔ商品コード（）、Ｇｅｔ数量（）、およびＧｅｔ受注番号（）のメッセージをＥＤＩ受注明細６８に送信し、ＥＤＩ受注明細６８は、商品コード、数量、および受注番号を受注明細４４に返送する。受注明細４４は、Ｓｅｔ商品コード（）、Ｓｅｔ数量（）、およびＳｅｔ受注番号（）を実行して、返送された情報を設定する。
【００８９】
次に、ＥＤＩ受注制御７０は、ＩｎｓｅｒｔＯｎｅ（受注明細）のメッセージを受注明細管理４３に送信し、受注明細管理４３は、ＩｎｓｅｒｔＯｎｅ（受注明細）を実行して、受注明細４４をデータベースに追加する。
【００９０】
図１４は、オブジェクト管理によるインスタンスの一意性の保証とライフサイクル制御を説明するためのオブジェクトのリンク関係を示している。オブジェクト管理は、生成したドメインオブジェクトのインスタンスを集約して保持しており、同じキーを持つマスタ系のドメインオブジェクトのインスタンスが二重生成されることを防止している。これにより、ドメインオブジェクトのデータの整合性が保証される。
【００９１】
これに対して、従来のシステムでは、インスタンスの一意性が必ずしも保証されておらず、同じキーを持つインスタンスが二重生成されることを許していた。このため、データ更新の際の整合性が保証されないという問題があった。
【００９２】
また、各ドメインオブジェクトは、上述したドメインモデルベースクラスから継承したリファレンスカウンタを保持しており、このリファレンスカウンタはオブジェクト管理により制御される。リファレンスカウンタは、オブジェクトの正しいライフサイクルを実現するために広く用いられており、そのオブジェクトをリンク関係で保持している他のオブジェクトの数を保持します。
【００９３】
ドメインオブジェクトをリンク関係で保持する制御オブジェクト等が、そのドメインオブジェクトの解放をオブジェクト管理に依頼したとき、リファレンスカウンタの値が１であれば、オブジェクト管理は、ドメインオブジェクトを直ちにメモリ上から解放する。しかし、リファレンスカウンタの値が２以上であれば、オブジェクト管理は、その値を１だけ減算し、ドメインオブジェクトをメモリ上に残す。
【００９４】
このようなオブジェクト管理と設計パターンの徹底によって、インスタンスの生成、削除に起因するメモリリークとメモリエラーが防止される。また、インスタンスの一意性の保証とリファレンスカウンタによって、データベースとの通信回数が削減される。
【００９５】
図１４において、受注伝票７１は、ジャーナル系のドメインオブジェクトであり、受注伝票管理７２は、受注伝票７１のオブジェクト管理である。また、納入先７３は、マスタ系のドメインオブジェクトであり、納入先管理７４は、納入先７３のオブジェクト管理である。
【００９６】
受注伝票管理７２は、納入先管理７４を指すリンクを保持し、受注制御４１は、受注伝票管理７２を指すリンクを保持している。受注伝票管理７２と受注伝票７１は集約関係を持っており、納入先管理７４と納入先７３も集約関係を持っている。さらに、受注伝票７１と受注明細４４も集約関係を持っており、１つの受注伝票７１のインスタンスは、１つ以上の受注明細４４のインスタンスとリンクされている。また、受注制御４１は、受注伝票７１および受注明細４４を使用し、受注明細４４は、受注伝票管理７２および納入先７３を使用する。
【００９７】
ここでは、受注伝票管理７２は、“ＧｅｔＮｅｗ”をメソッドとして保持し、受注伝票７１は、“Ｇｅｔ”をメソッドとして保持し、受注制御４１は、“新規起票”および“項目設定”をメソッドとして保持する。受注明細４４は、“明細番号”を属性として保持し、“Ｓｅｔ商品コード”、“Ｓｅｔ数量”、および“Ｓｅｔ納入先”をメソッドとして保持している。納入先管理７４は、“ＧｅｔＯｎｅ”をメソッドとして保持し、納入先７３は、“納入先コード”を属性として保持し、“Ｇｅｔ納入先名”をメソッドとして保持している。
【００９８】
図１５は、これらのオブジェクトが行う動作のパターンを示している。ここでは、受注伝票７１を起票し、受注明細４４の項目を設定するパターンが示されている。
【００９９】
まず、受注制御４１は、新規起票（）のメッセージを受け取ると、新規起票（）を実行し、ＧｅｔＮｅｗ（）のメッセージを受注伝票管理７２に送信する。受注伝票管理７２は、ＧｅｔＮｅｗ（）を実行して、受注伝票７１のインスタンスを生成し、その情報を受注制御４１に返送する。
【０１００】
次に、受注制御４１は、Ｇｅｔ（）のメッセージを受注伝票７１に送信し、受注伝票７１は、Ｇｅｔ（）を実行して、受注明細４４の１件目のインスタンスを取得し、その情報を受注制御４１に返送する。
【０１０１】
次に、受注制御４１は、項目設定（）のメッセージを受け取ると、項目設定（）を実行し、Ｓｅｔ商品コード（ｃｏｄｅ）のメッセージを受注明細４４に送信する。そして、受注明細４４は、Ｓｅｔ商品コード（ｃｏｄｅ）を実行して、商品コードを設定する。
【０１０２】
次に、受注制御４１は、項目設定（）のメッセージを受け取ると、項目設定（）を実行し、Ｓｅｔ数量（ｃｏｕｎｔ）のメッセージを受注明細４４に送信する。そして、受注明細４４は、Ｓｅｔ数量（ｃｏｕｎｔ）を実行して、数量を設定する。
【０１０３】
次に、受注制御４１は、項目設定（）のメッセージを受け取ると、項目設定（）を実行し、Ｓｅｔ納入先（００１）のメッセージを受注明細４４に送信する。そして、受注明細４４は、Ｓｅｔ納入先（００１）を実行して、納入先を設定する。
【０１０４】
このとき、受注明細４４は、ＧｅｔＯｎｅ（００１）のメッセージを納入先管理７４に送信する。そして、納入先管理７４は、ＧｅｔＯｎｅ（００１）を実行して、納入先コード“００１”に対応する納入先７３のインスタンスをデータベースから取得し、その情報を受注明細４４に返送する。次に、受注明細４４は、Ｇｅｔ納入先名（）のメッセージを納入先７３に送信する。そして、納入先７３は、Ｇｅｔ納入先名（）を実行して、納入先名を取得し、それを受注明細４４に返送する。
【０１０５】
次に、受注制御４１は、Ｇｅｔ（）のメッセージを受注伝票７１に送信し、受注伝票７１は、Ｇｅｔ（）を実行して、受注明細４４の２件目のインスタンスを取得し、その情報を受注制御４１に返送する。そして、１件目と同様のパターンで、商品コード、数量、および納入先を受注明細４４に設定する。
【０１０６】
このようなパターンは、受注明細４４のインスタンスの数だけ繰り返される。その間、納入先７３のインスタンスの一意性は納入先管理７４によって保証され、１つの受注伝票７１に関する受注明細４４の設定が終了するまで、納入先７３は繰り返し再利用される。
【０１０７】
図１６は、オブジェクト管理によるインスタンス間リンクの制御を説明するためのオブジェクトのリンク関係を示している。図１６において、端数調整情報７５は、マスタ系のドメインオブジェクトであり、端数調整情報管理７６は、端数調整情報７５のオブジェクト管理である。
【０１０８】
受注伝票管理７２は、得意先管理６６を指すリンク▲１▼を保持し、得意先管理６６は、端数調整情報管理７６を指すリンク▲２▼を保持し、受注伝票７１は、得意先６５を指すリンク▲３▼を保持し、得意先６５は、端数調整情報７５を指すリンク▲４▼を保持している。受注伝票管理７２と受注伝票７１は集約関係を持っており、得意先管理６６と得意先６５も集約関係を持っている。さらに、端数調整情報管理７６と端数調整情報７５も集約関係を持っている。
【０１０９】
一般に、オブジェクト管理は、上述したディレクタによって生成、保持されるが、その際、ディレクタにより、リンク▲１▼、▲２▼のようなオブジェクト管理間のリンクが確立される。ジャーナル系のオブジェクト管理は、リンク▲１▼のような、関連するマスタ系のオブジェクト管理へのリンクを保持している。また、リンク▲２▼のような、同じキーを持つマスタ系のオブジェクト管理間のリンクは、必要に応じて定義される。
【０１１０】
ドメインオブジェクトは、通常、他のドメインオブジェクトを生成することはないが、オブジェクト管理を通じて、リンク▲３▼、▲４▼のような、他のドメインオブジェクトとのリンクを動的に保持することができる。
【０１１１】
図１６では、受注伝票管理７２は、“Ｇｅｔ得意先管理”をメソッドとして保持し、受注伝票７１は、“伝票番号”を属性として保持し、“Ｓｅｔ得意先コード”、“Ｇｅｔ得意先”、および“金額計算”をメソッドとして保持している。得意先管理６６は、“ＧｅｔＯｎｅ”および“Ｇｅｔ端数調整情報管理”をメソッドとして保持し、得意先６５は、“得意先コード”を属性として保持し、“Ｇｅｔ得意先名”、“Ｇｅｔ住所”、“Ｇｅｔ電話番号”、および“端数調整依頼”をメソッドとして保持している。
【０１１２】
また、端数調整情報管理７６は、“ＧｅｔＯｎｅ”をメソッドとして保持し、端数調整情報７５は、“得意先コード”および“端数調整区分”を属性として保持し、“端数調整”をメソッドとして保持している。
【０１１３】
図１７は、これらのオブジェクトが行う動作のパターンを示している。ここでは、図１６に示したリンクを確立するパターンが示されている。まず、受注伝票７１は、Ｓｅｔ得意先コード（ｃｏｄｅ）のメッセージを受け取ると、Ｓｅｔ得意先コード（ｃｏｄｅ）を実行し、Ｇｅｔ得意先（）のメッセージを受け取ると、Ｇｅｔ得意先（）を実行する。
【０１１４】
このとき、受注伝票７１は、Ｇｅｔ得意先管理（）のメッセージを受注伝票管理７２に送信し、受注伝票管理７２は、Ｇｅｔ得意先管理（）を実行して、リンク▲１▼により得意先管理６６のインスタンスを取得し、その情報を受注伝票７１に返送する。
【０１１５】
次に、受注伝票７１は、ＧｅｔＯｎｅ（）のメッセージを得意先管理６６に送信し、得意先管理６６は、ＧｅｔＯｎｅ（）を実行して、得意先６５のインスタンスを取得し、その情報を受注伝票７１に返送する。この得意先６５のインスタンスへのリンクは、受注伝票７１の処理が終了するまで、受注伝票７１のインスタンスにリンク▲３▼として保持される。
【０１１６】
次に、得意先６５は、Ｇｅｔ得意先名（）、Ｇｅｔ住所（）、およびＧｅｔ電話番号（）のメッセージを受け取ると、Ｇｅｔ得意先名（）、Ｇｅｔ住所（）、およびＧｅｔ電話番号（）を実行する。
【０１１７】
次に、受注伝票７１は、金額計算（）のメッセージを受け取ると、金額計算（）を実行し、端数調整依頼（明細金額）のメッセージを得意先６５に送信する。得意先６５は、端数調整依頼（明細金額）を実行し、Ｇｅｔ端数調整情報管理（）のメッセージを得意先管理６６に送信する。そして、得意先管理６６は、Ｇｅｔ端数調整情報管理（）を実行し、リンク▲２▼により、端数調整情報管理７６のインスタンスを取得し、その情報を得意先６５に返送する。
【０１１８】
次に、得意先６５は、ＧｅｔＯｎｅ（得意先ｃｏｄｅ）のメッセージを端数調整情報管理７６に送信する。端数調整情報管理７６は、ＧｅｔＯｎｅ（得意先ｃｏｄｅ）を実行して、端数調整情報７５のインスタンスを取得し、その情報を得意先６５に返送する。この端数調整情報７５のインスタンスへのリンクは、受注伝票７１の金額計算が終了するまで、得意先６５のインスタンスにリンク▲４▼として保持される。
【０１１９】
次に、得意先６５は、端数調整（金額）のメッセージを端数調整情報７５に送信し、端数調整情報７５は、端数調整（金額）を実行して、調整された金額を得意先６５に返送する。そして、得意先６５は、返送された金額を端数調整済金額として受注伝票７１に送信する。これにより、１件の受注明細４４に関する金額計算が終了する。
【０１２０】
このような金額計算は、受注明細４４の件数だけ繰り返され、すべての受注明細４４について処理が終了すると、受注伝票７１の金額計算が終了する。端数調整情報７５のインスタンスへのリンク▲４▼は、受注伝票７１の金額計算が終了するまで得意先６５により保持されるため、端数調整情報管理７６への参照は、初回のみ行われる。
【０１２１】
オブジェクト管理は、以上説明したパターンに記述されたメソッドのほかにも、次のようなメソッド群をインタフェースとして持つことができる。
（１）ドメインオブジェクトの検索条件を指定し、対応するインスタンスを順番に１つずつ返却するメソッド群（Ｓｅｌｅｃｔ／Ｇｅｔ）。
【０１２２】
Ｓｅｌｅｃｔ（）は、検索条件を引数として含み、データベースとの１回の通信（ＳＱＬ実行）で複数のレコードを検索し、検索結果をオブジェクト管理のメモリ領域に格納する。また、Ｇｅｔ（）は、Ｓｅｌｅｃｔ（）とペアで使用され、Ｇｅｔ（）を実行すると、１つのドメインオブジェクトが返却される。このとき、オブジェクト管理は、Ｓｅｌｅｃｔ（）の実行時にプールしたデータの中から１つのドメインオブジェクトに相当するデータを抜き出して、ドメインオブジェクトを生成する。
【０１２３】
オブジェクト管理がデータベースを隠蔽している場合、一定の検索条件で処理対象のレコードをまとめて抽出可能ならば、これらのメソッドを用いた方がＧｅｔＯｎｅ（）によりドメインオブジェクトを個別に取得するよりも効率的である。
（２）ドメインオブジェクトの検索条件を指定し、対応するインスタンスのすべての属性情報を文字列として一括返却するメソッド群（Ｓｅｌｅｃｔ／ＧｅｔＡｌｌＡｔｔｒｉｂｕｔｅｓ）。
（３）ドメインオブジェクトの検索条件を指定し、対応するインスタンスを順番に１つずつ返却し、それらの属性情報を変更した後にデータベースを一括更新するメソッド群（Ｓｅｌｅｃｔ／Ｇｅｔ／Ｕｐｄａｔｅ）。
（４）新規に生成された複数のドメインオブジェクトのインスタンスをまとめて一括登録するメソッド群（Ａｌｌｏｃ／Ｉｎｓｅｒｔ／Ｆｌｕｓｈ）。
【０１２４】
図１８は、制御オブジェクトによるハイレベルな手続きを説明するためのオブジェクトのリンク関係を示している。制御オブジェクトは、特定のドメインオブジェクトに属さないハイレベルな手続きを保持している。ハイレベルな手続きとしては、次のようなものが考えられる。
（１）受注時に発注を行う。
（２）受注時に在庫の引き当てを行う。
（３）修正時に赤伝票を登録する。
（４）受注と同時に売上計上を行う。
【０１２５】
オンライン業務においては、制御オブジェクトは、クライアントからの処理依頼を、保持しているリンクを元に解決し、処理結果をクライアントに通知する。このとき、クライアントからのメッセージをオブジェクトへの複数のメッセージに展開して、送信する。また、同じクラスに属する複数のインスタンスを同時に扱うことができ、バッチ処理を記述することもできる。
【０１２６】
受注制御４１は、受注伝票管理７２、受注伝票７１、および受注明細４４を指すリンクを保持している。受注伝票管理７２と受注伝票７１は集約関係を持っており、受注伝票７１と受注明細４４も集約関係を持っている。受注明細４４は、受注伝票管理７２を使用する。
【０１２７】
ここでは、受注伝票管理７２は、“ＧｅｔＮｅｗ”および“ＧｅｔＯｎｅ”をメソッドとして保持し、受注伝票７１は、“伝票番号”を属性として保持し、“赤Ｃｏｐｙ”、“黒Ｃｏｐｙ”、“Ｓｅｔ元伝票フラグ”、“Ｇｅｔ”、および“Ｒｅｍｏｖｅ”をメソッドとして保持している。受注制御４１は、“修正開始”、“明細修正”、“明細追加”、および“明細削除”をメソッドとして保持し、受注明細４４は、“明細番号”を属性として保持し、“Ｓｅｔ商品コード”および“Ｓｅｔ数量”をメソッドとして保持している。
【０１２８】
図１９は、これらのオブジェクトが行う動作のパターンを示している。ここでは、赤黒修正を行うパターンが示されている。まず、受注制御４１は、修正開始（）のメッセージを受け取ると、修正開始（）を実行し、ＧｅｔＯｎｅ（伝票番号）のメッセージを受注伝票管理７２に送信する。受注伝票管理７２は、ＧｅｔＯｎｅ（伝票番号）を実行して、受注伝票７１のインスタンス（元伝票）を取得し、その情報を受注制御４１に返送する。
【０１２９】
次に、受注制御４１は、ＧｅｔＮｅｗ（）のメッセージを受注伝票管理７２に送信し、受注伝票管理７２は、ＧｅｔＮｅｗ（）を実行して、受注伝票７１のインスタンス（赤伝票）を生成し、その情報を受注制御４１に返送する。そして、受注制御４１は、赤Ｃｏｐｙ（元伝票インスタンス）のメッセージを赤伝票インスタンスに送信し、赤伝票インスタンスは、赤Ｃｏｐｙ（元伝票インスタンス）を実行する。
【０１３０】
次に、受注制御４１は、ＧｅｔＮｅｗ（）のメッセージを受注伝票管理７２に送信し、受注伝票管理７２は、ＧｅｔＮｅｗ（）を実行して、受注伝票７１のインスタンス（黒伝票）を生成し、その情報を受注制御４１に返送する。そして、受注制御４１は、黒Ｃｏｐｙ（元伝票インスタンス）のメッセージを黒伝票インスタンスに送信し、黒伝票インスタンスは、黒Ｃｏｐｙ（元伝票インスタンス）を実行する。
【０１３１】
次に、受注制御４１は、Ｓｅｔ元伝票フラグ（）のメッセージを元伝票インスタンスに送信し、元伝票インスタンスは、Ｓｅｔ元伝票フラグ（）を実行する。次に、受注制御４１は、明細修正（行情報）のメッセージを受け取ると、明細修正（行情報）を実行し、Ｇｅｔ（行番号）のメッセージを黒伝票インスタンスに送信する。黒伝票インスタンスは、Ｇｅｔ（行番号）を実行して、対応する受注明細４４のインスタンスを取得し、その情報を受注制御４１に返送する。そして、受注制御４１は、Ｓｅｔ商品コード（）およびＳｅｔ数量（）のメッセージを受注明細４４に送信し、受注明細４４は、Ｓｅｔ商品コード（）およびＳｅｔ数量（）を実行して、商品コードおよび数量を修正する。
【０１３２】
また、受注制御４１は、明細追加（行情報）のメッセージを受け取ると、明細追加（行情報）を実行し、Ｇｅｔ（）のメッセージを黒伝票インスタンスに送信する。黒伝票インスタンスは、Ｇｅｔ（）を実行して、受注明細４４のインスタンスを生成し、その情報を受注制御４１に返送する。そして、受注制御４１は、Ｓｅｔ商品コード（）およびＳｅｔ数量（）のメッセージを受注明細４４に送信し、受注明細４４は、Ｓｅｔ商品コード（）およびＳｅｔ数量（）を実行して、商品コードおよび数量を設定する。
【０１３３】
また、受注制御４１は、明細削除（行番号）のメッセージを受け取ると、明細削除（行番号）を実行し、Ｒｅｍｏｖｅ（行番号）のメッセージを黒伝票インスタンスに送信する。黒伝票インスタンスは、Ｒｅｍｏｖｅ（行番号）を実行して、対応する行を削除する。
【０１３４】
図２０は、制御オブジェクトによるインスタンス間リンクの制御を説明するためのオブジェクトのリンク関係を示している。制御オブジェクトは、ディレクタによって生成、保持されるが、その際、必要なジャーナル系およびマスタ系のオブジェクト管理へのリンクが確立される。また、制御オブジェクトは、クライアントからの処理依頼を解決するためのビジネスルールと、解決に必要なインスタンス間リンクを保持している。
【０１３５】
受注伝票管理７２は、商品管理６２を指すリンクを保持し、受注制御４１は、受注伝票管理７２を指すリンクを保持している。受注伝票管理７２と受注伝票７１は集約関係を持っており、商品管理６２と商品６１も集約関係を持っている。さらに、受注伝票７１と受注明細４４も集約関係を持っている。受注制御４１は、受注伝票７１、受注明細４４、および商品６１を使用し、受注明細４４は、受注伝票管理７２および商品６１を使用する。
【０１３６】
ここでは、受注伝票管理７２は、“ＧｅｔＮｅｗ”をメソッドとして保持し、受注伝票７１は、“伝票番号”を属性として保持し、“Ｓｅｔ得意先コード”および“Ｇｅｔ得意先”をメソッドとして保持している。受注制御４１は、“新規起票”、“ヘッダ項目設定”、“明細項目設定”、および“手入力単価設定”をメソッドとして保持し、受注明細４４は、“明細番号”を属性として保持し、“Ｓｅｔ商品コード”、“Ｓｅｔ数量”、“Ｓｅｔ単価”、および“Ｇｅｔ商品”をメソッドとして保持している。
【０１３７】
また、商品管理６２は、“ＧｅｔＯｎｅ”をメソッドとして保持し、商品６１は、“商品コード”を属性として保持し、“Ｇｅｔ商品名”をメソッドとして保持している。
【０１３８】
図２１は、これらのオブジェクトが行う動作のパターンを示している。ここでは、受注伝票７１を起票し、受注明細４４の項目を設定するパターンが示されている。
【０１３９】
まず、受注制御４１は、新規起票（）のメッセージを受け取ると、新規起票（）を実行し、ＧｅｔＮｅｗ（）のメッセージを受注伝票管理７２に送信する。受注伝票管理７２は、ＧｅｔＮｅｗ（）を実行して、受注伝票７１のインスタンスを生成し、その情報を受注制御４１に返送する。これにより、受注制御４１は、受注伝票７１へのリンクを取得する。
【０１４０】
次に、受注制御４１は、ヘッダ項目設定（）のメッセージを受け取ると、ヘッダ項目設定（）を実行し、Ｓｅｔ得意先コード（ｃｏｄｅ）のメッセージを受注伝票７１に送信する。そして、受注伝票７１は、Ｓｅｔ得意先コード（ｃｏｄｅ）を実行して、得意先コードを設定する。
【０１４１】
次に、受注制御４１は、Ｇｅｔ得意先（）のメッセージを受注伝票７１に送信する。受注伝票７１は、Ｇｅｔ得意先（）を実行し、ＧｅｔＯｎｅ（ｃｏｄｅ）のメッセージを図１６の得意先管理６６に送信する。得意先管理６６は、ＧｅｔＯｎｅ（ｃｏｄｅ）を実行し、図１６の得意先６５のインスタンスを取得して、その情報を受注伝票７１に返送する。そして、受注伝票７１は、返送された得意先６５のインスタンスの情報を受注制御４１に送信する。これにより、受注制御４１は、得意先６５へのリンクを取得する。
【０１４２】
次に、受注制御４１は、Ｇｅｔ得意先名（）のメッセージを得意先６５に送信する。得意先６５は、Ｇｅｔ得意先名（）を実行して、得意先名を取得し、それを受注制御４１に返送する。そして、受注制御４１は、返送された得意先名をクライアントに通知する。
【０１４３】
次に、受注制御４１は、明細項目設定（）のメッセージを受け取ると、明細項目設定（）を実行し、Ｓｅｔ商品コード（ｃｏｄｅ）のメッセージを受注明細４４に送信する。そして、受注明細４４は、Ｓｅｔ商品コード（ｃｏｄｅ）を実行して、商品コードを設定する。
【０１４４】
次に、受注制御４１は、Ｇｅｔ商品（）のメッセージを受注明細４４に送信する。受注明細４４は、Ｇｅｔ商品（）を実行し、ＧｅｔＯｎｅ（ｃｏｄｅ）のメッセージを商品管理６２に送信する。商品管理６２は、ＧｅｔＯｎｅ（ｃｏｄｅ）を実行し、商品６１のインスタンスを取得して、その情報を受注明細４４に返送する。そして、受注明細４４は、返送された商品６１のインスタンスの情報を受注制御４１に送信する。これにより、受注制御４１は、商品６１へのリンクを取得する。
【０１４５】
次に、受注制御４１は、Ｇｅｔ商品名（）のメッセージを商品６１に送信する。商品６１は、Ｇｅｔ商品名（）を実行して、商品名を取得し、それを受注制御４１に返送する。そして、受注制御４１は、返送された商品名をクライアントに通知する。
【０１４６】
次に、受注制御４１は、明細項目設定（）のメッセージを受け取ると、明細項目設定（）を実行し、Ｓｅｔ数量（ｃｏｕｎｔ）のメッセージを受注明細４４に送信する。そして、受注明細４４は、Ｓｅｔ数量（ｃｏｕｎｔ）を実行して、数量を設定する。
【０１４７】
次に、受注制御４１は、手入力単価設定（）のメッセージを受け取ると、手入力単価設定（）を実行し、Ｓｅｔ単価（ｐｒｉｃｅ）のメッセージを受注明細４４に送信する。そして、受注明細４４は、Ｓｅｔ単価（ｐｒｉｃｅ）を実行して、単価を設定する。
【０１４８】
なお、各項目の設定にはあらかじめ決められたルールが適用され、設定値に誤りがあると、設定を実行したオブジェクトから受注制御４１にエラーコードが返送される。そして、受注制御４１は、エラー処理を集中的に行う。
【０１４９】
図２２は、伝票処理の業務システムにおける受注入力時の実行画面を示しており、図２３は、対応するインスタンス間のリンク関係を示している。図２２の画面に表示された受注番号、得意先、納入先等の各項目の情報は、図２３のような複数のインスタンスに分散して保持される。
【０１５０】
図２３において、担当者７７は、ドメインオブジェクトであり、担当者管理７８は、担当者７７のオブジェクト管理である。受注制御４１は、受注伝票７１へのリンクを保持し、受注伝票７１は、得意先６５、納入先７３、および担当者７７へのリンクを保持し、受注明細４４は、商品６１へのリンクを保持している。
【０１５１】
また、受注伝票管理７２と受注伝票７１は集約関係を持ち、受注伝票７１と受注明細４４も集約関係を持ち、商品管理６２と商品６１も集約関係を持っている。さらに、得意先管理６６と得意先６５も集約関係を持ち、納入先管理７４と納入先７３も集約関係を持ち、担当者管理７８と担当者７７も集約関係を持っている。
【０１５２】
受注伝票７１は、受注番号、得意先コード、納入先コード、担当者コード等の属性を保持し、得意先６５は、得意先のコードおよび名前の属性を保持し、納入先７３は、納入先のコードおよび名前の属性を保持し、担当者７７は、担当者のコードおよび名前の属性を保持している。また、受注明細４４は、明細番号、取引区分、商品コード等の属性を保持し、商品６１は、商品のコードおよび名前の属性を保持している。
【０１５３】
図２４は、オブジェクト管理のクラスの作成手順を示している。業務システムは、まず、ドメインオブジェクトの属性を抽出し（ステップＳ１）、ドメインオブジェクトのキー項目を決定し（ステップＳ２）、キー項目別のデータベースアクセスのＳＱＬパターンを決定する（ステップＳ３）。キー項目としては、例えば、ドメインオブジェクトのコードや名前が用いられる。
【０１５４】
また、ビジネスルールやシステムの運用形態により、データのキャッシュ種別を選択する（ステップＳ４）。キャッシュは、例えば、業務システムのメモリ上に設けられ、１つまたは複数のキャッシュ種別を選択することができる。キャッシュ種別としては、例えば、次のようなものが用いられる。
（１）１トランザクション内での短期キャッシュ：１トランザクションの処理が終了するまで、ドメインオブジェクトをキャッシュ上に保持する。
（２）１スレッド内でのＬＲＵ（least recently used ）キャッシュ：１スレッドの処理が終了するまで、ドメインオブジェクトをキャッシュ上に保持し、ＬＲＵ法により、キャシュ上で置き換えるべきドメインオブジェクトを決定する。ここで、スレッドは、プロセス（タスク）を構成する処理単位である。また、ＬＲＵ法は、最近使用されたデータをキャッシュ上に残し、最も長く使われていないデータを置き換えの対象として選ぶアルゴリズムである。したがって、キャッシュ上には、最近アクセス時刻の新しい順に、キャッシュが一杯になるまで選ばれたオブジェクト群が保持され、メモリの利用効率が向上する。
（３）１スレッド内での順検索先読み式キャッシュ：最初にＧｅｔＯｎｅ（）で指定されたキーを属性として持つドメインオブジェクトから順番に、昇順または降順で一定数のドメインオブジェクトを、補助記憶装置からキャッシュに先読みしておく。キャッシュから読み込まれたドメインオブジェクトは処理が終了すると、キャッシュより解放される。そして、キャッシュが空になると、次の一定数のドメインオブジェクトをキャッシュに先読みする。
（４）１プロセス内での全件先読み式キャッシュ：プロセスの起動時に、処理対象とするすべてのドメインオブジェクトを補助記憶装置からキャッシュに先読みしておく。そして、１プロセスの処理が終了するまで、それらのドメインオブジェクトをキャッシュ上に保持する。
【０１５５】
次に、業務システムは、キャッシュ種別毎のオブジェクト管理の実装パターンを選択する（ステップＳ５）。ステップＳ６では、１トランザクション内での短期キャッシュの実装パターンが選択され、ステップＳ７では、１スレッド内でのＬＲＵキャッシュの実装パターンが選択され、ステップＳ８では、１スレッド内での順検索先読み式キャッシュの実装パターンが選択され、ステップＳ９では、１プロセス内での全件先読み式キャッシュの実装パターンが選択される。
【０１５６】
そして、業務システムは、実装パターンに基づいた各オブジェクト管理のクラスをコーディングして（ステップＳ１０）、作成処理を終了する。
図２５から図２７までは、業務システムで用いられるメソッドの実装パターンの例を示している。図２５は、ドメインオブジェクトを取得するＧｅｔＯｎｅ（）の実装パターンを示している。この実装パターンは、短期キャッシュおよびＬＲＵキャッシュに共通のパターンである。
【０１５７】
また、図２６および図２７は、オブジェクトを解放するｒｅｌｅａｓｅ ｏｎｅの実装パターンを示している。図２６は、短期キャッシュのためのパターンであり、図２７は、ＬＲＵキャッシュのためのパターンである。ｒｅｌｅａｓｅ ｏｎｅは、例えば、オブジェクト管理が保持しているドメインオブジェクトをメモリ上から解放する際に用いられる。
【０１５８】
ところで、上述した図２の業務システムは、図２８に示すような情報処理装置（コンピュータ）を用いて構成することができる。図２８の情報処理装置は、ＣＰＵ（中央処理装置）８１、メモリ８２、入力装置８３、出力装置８４、外部記憶装置８５、媒体駆動装置８６、およびネットワーク接続装置８７を備え、それらはバス８８により互いに接続されている。
【０１５９】
メモリ８２は、例えば、ＲＯＭ（read only memory）、ＲＡＭ（random access memory）等を含み、処理に用いられるオブジェクトのプログラムとデータを格納する。ＣＰＵ８１は、メモリ８２を利用してプログラムを実行することにより、必要な処理を行う。
【０１６０】
入力装置８３は、例えば、キーボード、ポインティングデバイス、タッチパネル等であり、ユーザからの指示や情報の入力に用いられる。出力装置８４は、例えば、ディスプレイ、プリンタ、スピーカ等であり、ユーザへの問い合わせや情報の出力に用いられる。
【０１６１】
外部記憶装置８５は、例えば、磁気ディスク装置、光ディスク装置、光磁気ディスク（magneto-optical disk）装置等の補助記憶装置であり、図２のデータベース１３やシーケンシャルファイル１４を格納する。この外部記憶装置８５に、上述のプログラムとデータを保存しておき、必要に応じて、それらをメモリ８２にロードして使用することもできる。
【０１６２】
媒体駆動装置８６は、可搬記録媒体８９を駆動し、その記録内容にアクセスする。可搬記録媒体８９としては、メモリカード、フロッピーディスク、ＣＤ−ＲＯＭ（compact disk read only memory ）、光ディスク、光磁気ディスク等、任意のコンピュータ読み取り可能な記録媒体が用いられる。この可搬記録媒体８９に上述のプログラムとデータを格納しておき、必要に応じて、それらをメモリ８２にロードして使用することもできる。
【０１６３】
ネットワーク接続装置８７は、ＬＡＮ（local area network）等の任意のネットワーク（回線）を介して外部の装置と通信し、通信に伴うデータ変換を行う。また、必要に応じて、上述のプログラムとデータを外部の装置から受け取り、それらをメモリ８２にロードして使用することもできる。
【０１６４】
図２９は、図２８の情報処理装置にプログラムとデータを供給することのできるコンピュータ読み取り可能な記録媒体を示している。可搬記録媒体８９や外部のデータベース９０に保存されたプログラムとデータは、メモリ８２にロードされる。そして、ＣＰＵ８１は、そのデータを用いてそのプログラムを実行し、必要な処理を行う。
【０１６５】
【発明の効果】
本発明によれば、オブジェクト指向の特徴を活用した業務システムを構築することが可能になる。本システムでは、オブジェクト指向部品の再利用や組み合わせが容易であり、本システムをベースにユーザの業務形態にマッチした様々なシステムを構築することができる。
【０１６６】
また、ユーザからのカストマイズの要件に応じて、修正の対象となる部品を容易に絞り込むことができ、修正する部品数も少なくて済む。また、オブジェクト指向部品を用いているため、データ操作やビジネスルールの実装が外部から隠蔽されており、すべての部品がパターンに基づいて設計／実装されているので、システム全体の保守性が良い。
【０１６７】
また、各部品はパターンと継承に基づいて実装されているので、部品の開発コストが従来のシステムより低く押さえられる。また、部品に対する実装パターンの適用率が高いので、部品の修正時の品質や部品の生産性が良い。
【図面の簡単な説明】
【図１】本発明の業務システムの原理図である。
【図２】業務システムの構成図である。
【図３】ビジネスオブジェクトのクラスを示す図である。
【図４】伝票処理業務の機能を示す図である。
【図５】クラスの例を示す図である。
【図６】第１のリンク関係を示す図である。
【図７】第１のパターンを示す図である。
【図８】第２のリンク関係を示す図である。
【図９】第２のパターンを示す図である。
【図１０】第３のリンク関係を示す図である。
【図１１】第３のパターンを示す図である。
【図１２】第４のリンク関係を示す図である。
【図１３】第４のパターンを示す図である。
【図１４】第５のリンク関係を示す図である。
【図１５】第５のパターンを示す図である。
【図１６】第６のリンク関係を示す図である。
【図１７】第６のパターンを示す図である。
【図１８】第７のリンク関係を示す図である。
【図１９】第７のパターンを示す図である。
【図２０】第８のリンク関係を示す図である。
【図２１】第８のパターンを示す図である。
【図２２】受注入力の画面を示す図である。
【図２３】インスタンスの例を示す図である。
【図２４】オブジェクト管理の作成手順を示す図である。
【図２５】オブジェクトの取得の実装パターンを示す図である。
【図２６】オブジェクトの解放の第１の実装パターンを示す図である。
【図２７】オブジェクトの解放の第２の実装パターンを示す図である。
【図２８】情報処理装置の構成図である。
【図２９】記録媒体を示す図である。
【符号の説明】
１ オブジェクト手段
２ 実行手段
３、２３、４４、４６、４９、５１、６１、６４、６５、６８、７１、７３、７５、７７ ドメインオブジェクト
４、２４、４３、４５、４８、５０、６２、６６、６９、７２、７４、７６、７８ オブジェクト管理
１１ クライアント
１２ ビジネスオブジェクト
１３、９０ データベース
１４ シーケンシャルファイル
２１ ディレクタ
２２ モデル群
２５、４１、４２、６７、７０ 制御オブジェクト
２６、４７、６３ サービスオブジェクト
３１ ディレクタベースクラス
３２ モデルベースクラス
３３ コントローラベースクラス
３４ ドメインモデルベースクラス
３５ オブジェクトマネージャベースクラス
８１ ＣＰＵ
８３ 入力装置
８４ 出力装置
８５ 外部記憶装置
８６ 媒体駆動装置
８７ ネットワーク接続装置
８８ バス
８９ 可搬記録媒体
【発明の属する技術分野】
本発明は、流通業等において、伝票、商品等の資源に関する情報を管理し、必要な業務を統合する業務システムおよびその方法に関する。
【０００２】
【従来の技術および発明が解決しようとする課題】
近年、主として流通業において、受注伝票の起票、商品在庫の管理、出荷伝票の作成、請求書の発行、入金の受付、受注伝票の発行等の処理業務を統合した伝票処理システムが導入されている。このような情報処理システムは、ＥＲＰ（enterprise resource planning）システムとも呼ばれている。
【０００３】
従来、このような伝票処理システムを始めとする種々のビジネスアプリケーションシステムの構築には、オブジェクト指向は不向きであるとされていた（日経コンピュータ，１９９８．６．２２，ｐｐ．２０９−２１７）。オブジェクトには、通常、データとそのデータに対する手続き（メソッド）がカプセル化されている。
【０００４】
ビジネスプロセスをオブジェクト指向により分析し、オブジェクト部品によりモデルを構築したとしても、従来のシステムでは、実際には純粋なオブジェクトは全体の一部分に過ぎず、他のオブジェクトはデータを持たない退化型オブジェクトである。このため、結果として、オブジェクト指向の長所が十分に活かされず、実問題のモデル化の容易さ、部品の再利用、データと手続きのカプセル化、カスタマイズ性の向上、保守性の向上、品質の向上、および生産性の向上が達成されていなかった。
【０００５】
例えば、伝票処理業務をオブジェクト指向分析する際に、オブジェクト間の境界をどこに設定して、各オブジェクトをどのような粒度で設計すればよいかが非常に曖昧である。ここで、オブジェクト間の境界とは、オブジェクトが保持するデータおよび手続きの境界に対応し、オブジェクトの粒度とは、データおよび手続きの大きさに対応する。
【０００６】
また、オブジェクトの再利用を容易にするための抽象化のレベルについても適当な指針がなく、オブジェクト間のインタラクションが単純にならない。このため、ビジネスプロセスに応じてオブジェクトを組み替えられる程の柔軟性が確保されていない。また、オブジェクトの抽象化がうまくできないため、実装言語の特徴である継承や多態を効果的に使えないという問題もある。
【０００７】
さらに、伝票処理業務に不可欠なリレーショナルデータベースシステムでは、レコードの一意性が保証されているのに対して、オブジェクトの世界では、同じデータを持つオブジェクトが複数存在することが許容されている。このため、リレーショナルデータベースシステムとオブジェクトの世界との境界の設計が難しく、データの整合性の保証や、複数のオブジェクトにまたがるトランザクション制御の実現が困難である。
【０００８】
本発明の課題は、オブジェクト指向部品を組み合わせて構築され、オブジェクト指向の特徴を活用する業務システムおよびその方法を提供することである。
【０００９】
【課題を解決するための手段】
図１は、本発明の業務システムの原理図である。図１の業務システムは、オブジェクト手段１と実行手段２を備える。オブジェクト手段１は、ビジネスルールを保持するドメインオブジェクト３と、ドメインオブジェクト３を管理し、データアクセスのインタフェースを実装するオブジェクト管理４とを有する。実行手段２は、ドメインオブジェクト３とオブジェクト管理４を用いて、ビジネスルールに対応する処理を実行する。
【００１０】
ドメインオブジェクト３が保持するビジネスルールは、業務処理手順に基づいて作成される手続きに対応し、ドメインオブジェクト３のデータの設定や演算ロジックに関するプリミティブな処理を記述している。また、オブジェクト管理４は、ドメインオブジェクト３とは別のオブジェクトであり、オブジェクト管理４が保持するデータアクセスのインタフェースは、補助記憶装置に格納されたデータベースやシーケンシャルファイル等へのアクセス手続きに対応する。
【００１１】
このように、データアクセスのインタフェースを保持するオブジェクトを、ビジネスルールを保持するオブジェクトから分離することにより、ビジネスルールとデータアクセスのインタフェースをそれぞれ独立に実装することができる。これにより、各オブジェクトの抽象度が高められ、その粒度も小さくなるため、オブジェクト間のインタラクションを単純化することが可能になる。また、ビジネスルールとデータアクセスのインタフェースが独立に部品化されるため、いずれか一方を取り替えることができ、システムの柔軟性が向上する。
【００１２】
さらに、オブジェクト管理４がデータアクセスに関する処理を担当するため、ドメインオブジェクト３は、データベース等のアクセス対象を区別した実装を行う必要がない。このように、オブジェクト管理４は、ドメインオブジェクト３からデータベース等を隠蔽しており、データベースとオブジェクトの世界との境界が明確になる。
【００１３】
オブジェクト管理４は、例えば、データアクセスの対象およびアクセス形態のうち少なくとも一方に適したインタフェースを実装し、ドメインオブジェクト３と組み合わせて用いられる。例えば、図１のオブジェクト手段１は、後述する図２８のメモリ８２に対応し、図１の実行手段２は、図２８のＣＰＵ（中央処理装置）８１に対応する。
また、本発明の別の業務システムは、伝票処理業務を含んだ処理業務を行うためのコンピュータシステムであって、第一、第二、および第三の記憶手段と実行手段を備える。第一の記憶手段は、属性データと、属性データの値の設定方法や演算ロジックに関するメソッドとを保持するドメインオブジェクトを記憶する。第二の記憶手段は、ドメインオブジェクトを生成または削除または保持するとともに、ドメインオブジェクトが保持する属性データに対するメソッドとしてデータアクセスのインタフェースを保持するオブジェクト管理を記憶する。第三の記憶手段は、ドメインオブジェクトおよびオブジェクト管理へのリンク関係と、ドメインオブジェクトおよびオブジェクト管理が保持するメソッドの実行手順とを保持する制御オブジェクトを記憶する。実行手段は、制御オブジェクトが保持するリンク関係と実行手順に基いて、ドメインオブジェクトおよびオブジェクト管理が保持するメソッドを実行する。第二の記憶手段は、第一の記憶手段が記憶しているドメインオブジェクトのうちの１つのドメインオブジェクトに対応して、データアクセスの対象およびアクセス形態のうち少なくとも一方に応じて複数のオブジェクト管理を記憶し、実行手段は、制御オブジェクトが、そのドメインオブジェクトに対応するオブジェクト管理のメソッドの実行を要求することにより、そのドメインオブジェクトに保持されている属性データを対応する複数のオブジェクト管理のうちの１つに保持されているインタフェースに従い補助記憶装置へ保存する。
【００１４】
【発明の実施の形態】
以下、図面を参照しながら、本発明の実施の形態を詳細に説明する。
本実施形態においては、組み合わせて使用する各オブジェクト部品の粒度や、ビジネスアプリケーションとクライアント画面、あるいはビジネスアプリケーションとデータベースシステムとの境界面に位置するオブジェクトの機能や仕組みを明確化し、伝票処理業務全体をオブジェクトの集合で表現する。その際、一定のパターンに当てはめて部品の抽出および設計を行うことで、オブジェクト間のリンクや会話のインタフェースを単純化する。
【００１５】
具体的には、ビジネスルールを実装する場所と、データアクセス等に関する性能を実現する仕組みを実装する場所と、トランザクションの範囲を定義する場所とを、オブジェクト部品として明確に分離し、オブジェクト部品間の標準的な関係と標準的な会話の手順を設定する。そして、各々の実装の変更を独立して行えるようにする。
【００１６】
個々のオブジェクト部品は、あらかじめ決められた分析パターンによって一定の抽象度や粒度で設計され、これらの部品の中味およびインタフェースはあらかじめ決められた設計パターンおよび実装パターンに基づいて構築される。このため、部品の組み替えによるアプリケーションの修正や、部品内部の変更によるアプリケーションの修正が容易である。
【００１７】
また、ビジネスルールの変更、トランザクションの範囲の変更、およびデータベースアクセスやキャッシュへの要件の変更が生じた際に、修正対象の部品を容易に特定でき、対象外の部品に影響を与えることなく、それを修正することが可能である。また、オブジェクトの継承による新たな部品開発が容易で、新規部品と既存部品の組み合わせが良好に行える。
【００１８】
図２は、本実施形態の業務システムの構成図である。図２の業務システムは、ワークステーション等のコンピュータを用いて構成され、クライアント１１、ビジネスオブジェクト１２、データベース１３、およびシーケンシャルファイル１４を備える。データベース１３とシーケンシャルファイル１４は、それぞれ、補助記憶装置に格納される。
【００１９】
クライアント１１は、ユーザインタフェースとなる入出力装置に対応し、ビジネスオブジェクト１２は、オブジェクト部品の集合に対応する。これらのオブジェクト部品は、システムのメモリ上に展開される。また、データベース１３としては、例えば、リレーショナルデータベースが用いられる。
【００２０】
ビジネスオブジェクト１２は、ディレクタ２１とモデル群２２を含む。ディレクタ２１は、通信層のミドルウェアであって、クライアント１１とモデル群２２の間の通信に関する制御を行う。モデル群２２のオブジェクトは、その役割によって、ドメインオブジェクト２３、オブジェクト管理（オブジェクトマネージャ）２４、制御オブジェクト２５、およびサービスオブジェクト２６に分類される。
【００２１】
ドメインオブジェクト２３は、業務分析の際に、伝票や商品等の“物品”として抽出されたクラスに対応する。ここで、クラスとはオブジェクトの構造の定義に対応する。クラスにより定義された構造を持つ具体的なオブジェクトは、インスタンスと呼ばれる。
【００２２】
また、ドメインオブジェクト２３は、保持するデータに関するビジネスルールと手続きの実行手順を保持する。このビジネスルールは、業務処理手順を表すビジネスロジックに基づいて作成される手続きであり、主として値の設定や演算ロジックに関するプリミティブな処理を記述している。また、ドメインオブジェクト２３は、例外通知の受信や状態遷移も行う。
【００２３】
オブジェクト管理２４は、データベース１３やシーケンシャルファイル１４等への永続化が必要なドメインオブジェクト２３を管理するために用意されたクラスであり、対応するドメインオブジェクト２３と組み合わせて用いられる。ここで、永続化とは、補助記憶装置にデータを保存することを表す。
【００２４】
オブジェクト管理２４は、ドメインオブジェクト２３の生成元でもあり、ドメインオブジェクト２３の生成、削除、集約、再利用を行い、ドメインオブジェクト２３と同じインタフェースを備える。
【００２５】
また、オブジェクト管理２４は、外部のデータにアクセスする際のプロキシ（代理）でもあり、入出力ロジックの手続きを保持する。この入出力ロジックは、アクセス対象の種類やアクセス形態に応じた処理を記述しており、ビジネスルールから分離されている。
【００２６】
アクセス対象としては、データキャッシュや様々な種類の補助記憶装置が考えられる。データキャッシュは、ドメインオブジェクトをメモリ上に保持し続け、そのオブジェクトが参照されたとき、補助記憶装置にアクセスせずに、そのオブジェクトの情報を直ちに返却するメカニズムを表す。
【００２７】
また、アクセス形態は、アクセス対象のデータ構造等によって変化する。オブジェクト管理２４は、例えば、データベース１３にはＳＱＬによりアクセスし、データの検索、追加、削除、更新等の処理を行う。また、シーケンシャルファイル１４にはシーケンシャルにアクセスし、リード／ライト処理を行う。
【００２８】
さらに、オブジェクト管理２４は、システムがオンライン処理、バッチ処理、およびマスタメンテナンス処理のうちのいずれを行うかに応じて、異なる性能向上アルゴリズムを用いた入出力処理を行う。ここで、マスタメンテナンス処理は、ドメインオブジェクトの静的なデータを更新する処理等に対応し、性能向上アルゴリズムとしては、データキャッシュやデータベースアクセスのアルゴリズムが用いられる。
【００２９】
様々な入出力ロジックの組み合わせは、通常、オブジェクト管理２４のサブクラスにより指定され、処理に応じて特定のサブクラスのオブジェクト管理２４が用いられる。
【００３０】
制御オブジェクト２５は、業務分析の際に、“人手”、“業務”、“アプリケーション”，“画面”等として抽出されたクラスに対応し、ドメインオブジェクト２３、オブジェクト管理２４、およびサービスオブジェクト２６へのリンク関係を保持する。また、ドメインオブジェクト２３間の協調関係に関するビジネスルールと手続きの実行手順を保持する。
【００３１】
また、ディレクタ２１を介して入力されるクライアント１１からの処理依頼を、保持しているリンク関係に基づいて処理する。このとき、ビジネスルールに基づいてオブジェクトの協調関係を制御し、処理結果をクライアント１１に通知する。
【００３２】
これにより、制御オブジェクト２５は、抽象度が高く粒度の小さい複数のオブジェクトを繋ぎ合わせて、アプリケーションとしての処理の流れを制御し、複数のデータベースにまたがるようなトランザクションのセッションの範囲を規定する。そして、処理中に生じたエラーの出口処理を集中的に行う。
【００３３】
さらに、トランザクションの管理、モデルの例外通知の受信、クライアント１１とモデル群２２の間の型変換およびプロトコル変換、データの組立／分解等も行う。
【００３４】
サービスオブジェクト２６は、ドメインオブジェクト２３と類似のクラスに対応するが、補助記憶装置への永続化を必要とせず、対応するオブジェクト管理２４を持たない。サービスオブジェクト２６は、主として、他のオブジェクトから依頼された特定の機能をサービスとして実行する。
【００３５】
また、ドメインオブジェクト２３が業種に共通するビジネスルールを保持する場合、ドメインオブジェクト２３から独立しているサービスオブジェクト２６を用いて、システムをカスタマイズすることができる。この場合、カスタマイズを前提としたインタフェースをサービスオブジェクト２６に持たせておき、個別のユーザがビジネスルールを後から組み込めるようにする。
【００３６】
ビジネスオブジェクト１２における破線の矢印は、オブジェクトの生成関係を表す。オブジェクト管理２４、制御オブジェクト２５、およびサービスオブジェクト２６は、ディレクタ２１により生成され、ドメインオブジェクト２３は、対応するオブジェクト管理２４により生成される。
【００３７】
また、ビジネスオブジェクト１２における実線の矢印は、オブジェクト間のメッセージの流れを表す。メッセージ▲１▼は、クライアント１１に対して公開されているメソッドに対応し、メッセージ▲２▼は、論理テーブルへの照会に対応し、メッセージ▲３▼は、ドメインオブジェクト２３のデータの設定に対応する。また、メッセージ▲４▼は、ドメインオブジェクト２３の生成、更新、削除等の依頼に対応し、メッセージ▲５▼は、サービスオブジェクト２６へのサービス依頼に対応する。
【００３８】
このように、ドメインオブジェクト２３は、ビジネスルールを実装し、オブジェクト管理２４は、そのビジネスルールに対応するデータの入出力ロジックを実装し、制御オブジェクト２５は、それらの協調関係をトランザクションとして制御するビジネスルールを実装する。したがって、入出力ロジックがビジネスルールから明確に分離され、オブジェクト管理２４を取り替えることで、１つのビジネスルールに対して多様な入出力ロジックを組み合わせることが可能になる。
【００３９】
これに対して、従来のシステムでは、ビジネスルールと入出力ロジックの境界が明確でなく、これらが１つのオブジェクトに埋め込まれていることが多い。このため、ビジネスルールおよび入出力ロジックの一方を追加／削除するような操作が難しいという問題があった。
【００４０】
次に、図３は、ディレクタ２１、ドメインオブジェクト２３、オブジェクト管理２４、および制御オブジェクト２５のクラスのアーキテクチャを示している。図３の階層関係において、デイレクタベースクラス３１は、ディレクタ２１の上位のクラス（スーパークラス）であり、モデルベースクラス３２は、コントローラベースクラス３３、ドメインモデルベースクラス３４、オブジェクトマネージャベースクラス３５の上位のクラスである。また、コントローラベースクラス３３、ドメインモデルベースクラス３４、およびオブジェクトマネージャベースクラス３５は、それぞれ、制御オブジェクト２５、ドメインオブジェクト２３、およびオブジェクト管理２４の上位のクラスである。
【００４１】
一般に、クラス間の階層関係においては、下位のクラスが上位のクラスの定義を継承するため、制御オブジェクト２５、ドメインオブジェクト２３、およびオブジェクト管理２４は、それぞれ、コントローラベースクラス３３、ドメインモデルベースクラス３４、オブジェクトマネージャベースクラス３５の定義に基づいて生成される。
【００４２】
ところで、伝票処理業務の場合、業務システムの基本機能として、図４に示すような機能が要求される。図４では、“受注”、“出荷”、“与信”、および“在庫”が基本機能として存在し、“受注”は他の３つの機能を起動し、“出荷”は“在庫”を起動する。これらの基本機能は、伝票または商品に対応して設けられており、オブジェクトのクラスとして利用することができる。
【００４３】
“受注”は、“ＥＤＩ（electronic data interchange ）受注”、“直送受注”、“見積受注”、および“一般受注”の各機能を含み、“出荷”は、“出荷予定”、“出荷確定”、“分納出荷”、および“ピッキング指示”の各機能を含む。また、“与信”は、“与信警告”および“与信更新”の各機能を含み、“在庫”は、“在庫引当（引落）”、“ロット管理”、“倉庫移動”、“棚卸”、“荷姿単位管理”、および“在庫評価”の各機能を含む。
【００４４】
このような基本機能を実現するために、例えば、図５に示すようなクラスが設けられる。ここでは、受注制御４１、出荷制御４２、受注明細管理４３、受注明細４４、出荷明細管理４５、出荷明細４６、在庫サービス４７、与信管理４８、与信４９、在庫管理５０、および在庫５１がクラスとして設けられている。
【００４５】
このうち、受注制御４１および出荷制御４２は、制御オブジェクトのクラスに対応し、受注明細管理４３、出荷明細管理４５、与信管理４８、および在庫管理５０は、オブジェクト管理のクラスに対応する。また、受注明細４４、出荷明細４６、与信４９、および在庫５１は、ドメインオブジェクトのクラスに対応し、在庫サービス４７は、サービスオブジェクトのクラスに対応する。
【００４６】
受注制御４１は、ＥＤＩ受注入力（）、見積受注入力（）、一般受注入力（）、および直送受注入力（）の各メソッドを保持し、出荷制御４２は、出荷予定入力（）、分納出荷指示（）、ピッキング指示（）、出荷確定（）の各メソッドを保持する。
【００４７】
また、在庫サービス４７は、在庫引当（）、倉庫移動（）、荷姿単位別照会（）、ロット別照会（）、棚卸入力（）、および在庫評価（）の各メソッドを保持し、与信４９は、与信残高更新（）および与信警告チェック（）の各メソッドを保持する。このうち、記号“＋”が付加されたメソッドは、ＯＭＴ（object modeling technique ）表記でパブリックなメソッドに対応する。
【００４８】
また、実線の矢印はリンク関係を表し、例えば、受注制御４１は受注明細管理４３へのリンクを保持している。破線の矢印は使用関係を表し、例えば、受注明細４４は与信４９および在庫サービス４７の機能を必要に応じて使用する。◇印の付加された実線は集約関係を表し、例えば、受注明細管理４３のクラスの１つのオブジェクトは、受注明細４４のクラスの１つまたは複数のオブジェクトと相互にリンク関係を持っている。
【００４９】
リンク関係は、例えば、リンク元のオブジェクトがリンク先のオブジェクトを指すポインタを保持することにより設定される。相互リンク関係の場合は、２つのオブジェクトが、互いに相手のオブジェクトを指すポインタを保持している。
【００５０】
実際には、これらのクラス以外にも、商品、商品管理、得意先、得意先管理等の多数のクラスが設けられ、それらが互いにリンク関係や使用関係で関係付けられて、業務システムが構築される。また、一部のクラスのみを組み合わせることにより、部分的な機能を実現する受注入力システム、出荷指示システム、売上計上システム等の伝票処理システムを構築することもできる。
【００５１】
次に、図６から図１９までを参照しながら、オブジェクトのリンク関係の例と、オブジェクトの設計に用いられた分析パターンの例について説明する。設計パターンおよび実装パターンは、分析パターンより具体的であるが、基本的な構造は分析パターンと同様である。
【００５２】
図６は、オブジェクト間メッセージを説明するためのオブジェクトのリンク関係を示している。一般に、オブジェクトが他のオブジェクトにメソッドの実行を要求する場合は、そのメソッドの名称を含むメッセージを要求先のオブジェクトに送信する。
【００５３】
図６において、受注明細４４は、データのリード／ライトを伴うジャーナル系のドメインオブジェクトに対応し、商品６１は、主としてデータのリードのみに用いられるマスタ系のドメインオブジェクトに対応する。また、商品管理６２は、商品６１を管理するオブジェクト管理である。受注明細４４は、商品６１と商品管理６２を指す単方向のリンクを保持しており、商品管理６２と商品６１は、上述したような集約関係を持つ。
【００５４】
ドメインオブジェクトは、“物品”として抽出さたクラスに対応するので、“物品”の属性データとメソッドを保持している。属性は、ＣＲＣ（class responsibility & collaboration）カード分析やデータベースの項目から導かれる。ＣＲＣカード分析は、システム化対象の業務をオブジェクト指向分析する方法の１つであり、クラス毎に責務とその協調クラスを書き込むＣＲＣカードを用いて、属性、メソッド、クラス間のリンク関係等を抽出することができる。また、ドメインオブジェクトのメソッドは、属性値の設定、参照、ビジネスルール、計算式等に対応する。
【００５５】
ここでは、受注明細４４は、“商品コード”を属性として保持し、“Ｓｅｔ商品コード”、“Ｓｅｔ数量”、および“Ｇｅｔ商品”をメソッドとして保持している。商品６１は、“商品名”、“メーカー”、および“荷姿”を属性として保持し、“Ｇｅｔ商品名”、“Ｇｅｔメーカー”、および“Ｇｅｔ荷姿”をメソッドとして保持している。商品管理６２は、“Ｇｅｔ商品”および“Ｇｅｔ商品名”をメソッドとして保持している。商品６１が保持する“Ｇｅｔ商品名”、“Ｇｅｔメーカー”、および“Ｇｅｔ荷姿”は、ドメインオブジェクトのビジネスルールに対応する。
【００５６】
図７は、これらのオブジェクトが行う動作のパターンを示している。ここでは、商品コードの設定、数量の設定、商品オブジェクトの取得、メーカー取得、荷姿取得、および商品名取得の６つのパターンが示されている。
【００５７】
まず、商品コードの設定において、制御オブジェクトがＳｅｔ商品コード（コード）のメッセージを受注明細４４に送信すると、受注明細４４は、Ｓｅｔ商品コード（コード）を実行し、与えられた商品コードを設定する。次に、受注明細４４は、Ｇｅｔ商品名（コード）のメッセージを商品管理６２に送信し、商品管理６２は、Ｇｅｔ商品名（コード）を実行して、商品コードに対応する商品名を受注明細４４に返送する。このように、受注明細４４は、商品コードを設定したとき、対応する商品名を商品管理６２から自動的に取得する。
【００５８】
次に、数量の設定において、制御オブジェクトがＳｅｔ数量（個数）のメッセージを受注明細４４に送信すると、受注明細４４は、Ｓｅｔ数量（個数）を実行し、与えられた個数を設定する。
【００５９】
次に、商品オブジェクトの取得において、制御オブジェクトがＧｅｔ商品（）のメッセージを受注明細４４に送信すると、受注明細４４は、Ｇｅｔ商品（コード）のメッセージを商品管理６２に送信する。商品管理６２は、Ｇｅｔ商品（コード）を実行して、対応する商品６１（インスタンス）の情報を受注明細４４に返送し、受注明細４４は、その情報を制御オブジェクトに返送する。以後、制御オブジェクトは、返送された情報に基づいて、商品６１にメッセージを送信することができる。
【００６０】
次に、メーカー取得において、制御オブジェクトがＧｅｔメーカー（）のメッセージを商品６１に送信すると、商品６１は、Ｇｅｔメーカー（）を実行し、メーカー名を制御オブジェクトに返送する。
【００６１】
次に、荷姿取得において、制御オブジェクトがＧｅｔ荷姿（）のメッセージを商品６１に送信すると、商品６１は、Ｇｅｔ荷姿（）を実行し、荷姿を制御オブジェクトに返送する。
【００６２】
次に、商品名取得において、制御オブジェクトがＧｅｔ商品名（）のメッセージを商品６１に送信すると、商品６１は、Ｇｅｔ商品名（）を実行し、商品名を制御オブジェクトに返送する。
【００６３】
このように、ジャーナル系のドメインオブジェクトは、マスタ系のドメインオブジェクトを自力で取得し、そのオブジェクトと会話することができる。また、制御オブジェクトは、ジャーナル系のドメインオブジェクトまたはオブジェクト管理を介してマスタ系のドメインオブジェクトを取得し、そのオブジェクトから必要な情報を取得することができる。
【００６４】
図７のパターンでは、商品管理６２によるデータのアクセス形態が規定されていないため、リレーショナルデータベースかシーケンシャルファイルかに依らず、また、オンライン処理かバッチ処理かに依らずに、このパターンを適用することができる。実際に用いられる入出力ロジックは、商品管理６２のサブクラスとしてコンパイル時に指定され、実行プログラムに反映される。
【００６５】
図８は、サービスオブジェクトを説明するためのオブジェクトのリンク関係を示している。サービスオブジェクトは、ドメインオブジェクトから手続き部分を分離独立させたクラスに相当し、単独でも部品となり得る。また、複数種類のドメインオブジェクトにサービスを提供できる汎用あるいは多数のインタフェースを持つ。また、ビジネスルールの実行時に必要なマスタ系のドメインオブジェクトを参照することができる。さらに、補助記憶装置への永続化が必要な属性を持たず、オブジェクト管理も必要としない。
【００６６】
図８において、売上単価６３は、サービスオブジェクトであり、季節単価６４は、マスタ系のドメインオブジェクトである。受注明細管理４３は、売上単価６３を指すリンクを保持し、売上単価６３は、季節単価６４および商品６１を指すリンクを保持している。また、受注明細管理４３と受注明細４４は集約関係を持っており、受注明細４４は、売上単価６３を使用する。このように、ドメインオブジェクトが使用するサービスオブジェクトは、対応するオブジェクト管理により保持されている。
【００６７】
ここでは、受注明細管理４３は、“Ｇｅｔ売上単価”をメソッドとして保持し、受注明細４４は、“商品コード”を属性として保持し、“単価決定”をメソッドとして保持している。
【００６８】
売上単価６３は、“Ｇｅｔ単価”、“Ｃｈｅｃｋ手入力”、“Ｇｅｔ季節単価”、および“Ｇｅｔ標準単価”をメソッドとして保持し、季節単価６４は、“商品コード”、“期間”、および“単価”を属性として保持し、“Ｇｅｔ単価”をメソッドとして保持している。商品６１は、“商品コード”および“標準単価”を属性として保持し、“Ｇｅｔ単価”をメソッドとして保持している。
【００６９】
図９は、これらのオブジェクトが行う動作のパターンを示している。ここでは、単価決定依頼のパターンが示されている。まず、制御オブジェクトが単価決定（）のメッセージを受注明細４４に送信すると、受注明細４４は、Ｇｅｔ売上単価（）のメッセージを受注明細管理４３に送信し、Ｇｅｔ単価（明細）のメッセージを売上単価６３に送信する。受注明細管理４３は、Ｇｅｔ売上単価（）を実行し、売上単価６３は、Ｇｅｔ単価（明細）を実行する。
【００７０】
このとき、売上単価６３は、Ｃｈｅｃｋ手入力（）を実行し、Ｇｅｔ単価（）のメッセージを季節単価６４および商品６１に送信する。季節単価６４および商品６１は、Ｇｅｔ単価（）を実行して、対応する単価を売上単価６３に返送し、売上単価６３は、それを受注明細４４に返送する。
【００７１】
図１０は、オブジェクト管理によるインスタンスの管理を説明するためのオブジェクトのリンク関係を示している。オブジェクト管理は、ドメインオブジェクトのインスタンスの生成（ＧｅｔＮｅｗ）、取得（ＧｅｔＯｎｅ）、追加（ＩｎｓｅｒｔＯｎｅ）、更新（ＵｐｄａｔｅＯｎｅ）の各インタフェースを有し、これらのインタフェースはすべてのオブジェクト管理で統一されている。
【００７２】
“ＧｅｔＯｎｅ”は、ドメインオブジェクトのキー属性を指定して、対応する１つのインスタンスをキャッシュまたは補助記憶装置から取得し、そのインスタンスの情報を返却する。“ＩｎｓｅｒｔＯｎｅ”は、新規に生成されたドメインオブジェクトのインスタンスを１つずつ登録する。“ＵｐｄａｔｅＯｎｅ”は、既存のドメインオブジェクトのインスタンスを１つずつ更新する。
【００７３】
オブジェクト管理は、メモリリーク対策、インスタンスの再利用、インスタンスの一意性保持、データキャッシュのメカニズムを隠蔽している。データキャッシュのメカニズムは、生成／取得されたドメインオブジェクトをメモリ上に保持し続け、そのオブジェクトと同じキー属性を指定する“ＧｅｔＯｎｅ”に対しては、補助記憶装置にアクセスせずに、そのオブジェクトの情報を返却する。また、オブジェクト管理は、固有の属性やビジネスルールを内部に持たないため、実装パターンの適用率は１００％である。
【００７４】
図１０において、得意先６５は、マスタ系のドメインオブジェクトであり、得意先管理６６は、得意先６５のオブジェクト管理であり、得意先マスタメンテ６７は、得意先６５のメンテナンスを行う制御オブジェクトである。得意先マスタメンテ６７は、得意先６５および得意先管理６６を指すリンクを保持し、得意先管理６６と得意先６５は集約関係を持っている。
【００７５】
ここでは、得意先管理６６は、“ＧｅｔＮｅｗ”、“ＩｎｓｅｒｔＯｎｅ”、“ＧｅｔＯｎｅ”、および“ＵｐｄａｔｅＯｎｅ”をメソッドとして保持し、得意先６５は、“得意先コード”を属性として保持し、“Ｓｅｔ得意先コード”および“Ｓｅｔ得意先名”をメソッドとして保持している。得意先マスタメンテ６７は、“新規作成”、“Ｓｅｔ項目”、“登録”、および“更新”をメソッドとして保持している。
【００７６】
図１１は、これらのオブジェクトが行う動作のパターンを示している。ここでは、得意先追加と得意先修正の各パターンが示されている。これらのパターンは、必要な回数だけループ処理として繰り返される。
【００７７】
得意先追加において、まず、得意先マスタメンテ６７は、新規作成（）のメッセージを受け取ると、新規作成（）を実行し、ＧｅｔＮｅｗ（）のメッセージを得意先管理６６に送信する。得意先管理６６は、ＧｅｔＮｅｗ（）を実行して、得意先６５のインスタンスを生成し、その情報を得意先マスタメンテ６７に返送する。
【００７８】
次に、得意先マスタメンテ６７は、Ｓｅｔ項目（“得意先コード”，ｃｏｄｅ）のメッセージを受け取ると、Ｓｅｔ項目（“得意先コード”，ｃｏｄｅ）を実行し、Ｓｅｔ得意先コード（ｃｏｄｅ）のメッセージを得意先６５に送信する。そして、得意先６５は、Ｓｅｔ得意先コード（ｃｏｄｅ）を実行して、得意先コードを設定する。
【００７９】
次に、得意先マスタメンテ６７は、登録（）のメッセージを受け取ると、登録（）を実行し、ＩｎｓｅｒｔＯｎｅ（得意先インスタンス）のメッセージを得意先管理６６に送信する。そして、得意先管理６６は、ＩｎｓｅｒｔＯｎｅ（得意先インスタンス）を実行し、データベースに得意先６５を追加する。
【００８０】
また、得意先修正において、まず、得意先マスタメンテ６７は、検索（得意先コード）のメッセージを受け取ると、検索（得意先コード）を実行し、ＧｅｔＯｎｅ（得意先コード）のメッセージを得意先管理６６に送信する。得意先管理６６は、ＧｅｔＯｎｅ（得意先コード）を実行して、得意先６５のインスタンスをデータベースから取得し、その情報を得意先マスタメンテ６７に返送する。
【００８１】
次に、得意先マスタメンテ６７は、Ｓｅｔ項目（“得意先名”，ｎａｍｅ）のメッセージを受け取ると、Ｓｅｔ項目（“得意先名”，ｎａｍｅ）を実行し、Ｓｅｔ得意先名（ｎａｍｅ）のメッセージを得意先６５に送信する。そして、得意先６５は、Ｓｅｔ得意先名（ｎａｍｅ）を実行して、得意先名を設定する。
次に、得意先マスタメンテ６７は、更新（）のメッセージを受け取ると、更新（）を実行し、ＵｐｄａｔｅＯｎｅ（得意先インスタンス）のメッセージを得意先管理６６に送信する。そして、得意先管理６６は、ＵｐｄａｔｅＯｎｅ（得意先インスタンス）を実行し、データベースに登録されている得意先６５を更新する。
図１２は、オブジェクト管理による永続化先の隠蔽を説明するためのオブジェクトのリンク関係を示している。永続化先の補助記憶装置におけるデータ構造によってオブジェクト管理の実装（実行プログラム）は異なるが、ドメインオブジェクトのインスタンスの生成、取得、および追加のインタフェースは、異なるデータ構造の間で統一されている。
【００８２】
データ構造としては、上述のリレーショナルデータベースとシーケンシャルファイルのほかに、ＣＳＶ（comma separated value ）形式のファイルも用いられる。ドメインオブジェクト側のインタフェースは永続化先のデータ構造に依存しないため、制御オブジェクトではそれらを区別した実装を行う必要がない。
【００８３】
図１２において、ＥＤＩ受注明細６８は、回線を介した受注の受注明細に対応するＣＳＶ系のドメインオブジェクトであり、ＥＤＩ受注明細管理６９は、ＥＤＩ受注明細６８のオブジェクト管理である。ＥＤＩ受注制御７０は、ＥＤＩ受注明細管理６９および受注明細管理４３を指すリンクを保持し、ＥＤＩ受注明細管理６９とＥＤＩ受注明細６８は集約関係を持っている。また、ＥＤＩ受注制御７０は、ＥＤＩ受注明細６８と受注明細４４を使用し、受注明細４４は、ＥＤＩ受注明細６８を使用する。
【００８４】
ここでは、ＥＤＩ受注明細管理６９は、“Ｇｅｔ”をメソッドとして保持し、ＥＤＩ受注制御７０は、“受注開始”をメソッドとして保持し、ＥＤＩ受注明細６８は、“Ｇｅｔ商品コード”、“Ｇｅｔ数量”、および“Ｇｅｔ受注番号”をメソッドとして保持している。受注明細管理４３は、“ＧｅｔＮｅｗ”および“ＩｎｓｅｒｔＯｎｅ”をメソッドとして保持し、受注明細４４は、“伝票番号”および“明細番号”を属性として保持し、“Ｓｅｔ商品コード”、“Ｓｅｔ数量”、および“Ｓｅｔ受注番号”をメソッドとして保持している。
【００８５】
図１３は、これらのオブジェクトが行う動作のパターンを示している。ここでは、シーケンシャルファイルの受注情報からリレーショナルデータベースの受注ジャーナルを作成するパターンが示されている。このパターンは、必要な回数だけループ処理として繰り返される。このパターンは、単なるデータ移行ではなく、ＥＤＩ受注明細６８および受注明細４４のクラスのビジネスルールに対応する。
【００８６】
まず、ＥＤＩ受注制御７０は、受注開始（）のメッセージを受け取ると、受注開始（）を実行し、Ｇｅｔ（）のメッセージをＥＤＩ受注明細管理６９に送信する。ＥＤＩ受注明細管理６９は、Ｇｅｔ（）を実行して、シーケンシャルファイルからＥＤＩ受注明細６８のインスタンスを取得し、その情報をＥＤＩ受注制御７０に返送する。
【００８７】
次に、ＥＤＩ受注制御７０は、ＧｅｔＮｅｗ（）のメッセージを受注明細管理４３に送信し、受注明細管理４３は、ＧｅｔＮｅｗ（）を実行して、受注明細４４のインスタンスを生成し、その情報をＥＤＩ受注制御７０に返送する。
【００８８】
次に、ＥＤＩ受注制御７０は、Ｓｅｔ（ＥＤＩ受注明細）のメッセージを受注明細４４に送信し、受注明細４４は、Ｓｅｔ（ＥＤＩ受注明細）を実行する。そして、Ｇｅｔ商品コード（）、Ｇｅｔ数量（）、およびＧｅｔ受注番号（）のメッセージをＥＤＩ受注明細６８に送信し、ＥＤＩ受注明細６８は、商品コード、数量、および受注番号を受注明細４４に返送する。受注明細４４は、Ｓｅｔ商品コード（）、Ｓｅｔ数量（）、およびＳｅｔ受注番号（）を実行して、返送された情報を設定する。
【００８９】
次に、ＥＤＩ受注制御７０は、ＩｎｓｅｒｔＯｎｅ（受注明細）のメッセージを受注明細管理４３に送信し、受注明細管理４３は、ＩｎｓｅｒｔＯｎｅ（受注明細）を実行して、受注明細４４をデータベースに追加する。
【００９０】
図１４は、オブジェクト管理によるインスタンスの一意性の保証とライフサイクル制御を説明するためのオブジェクトのリンク関係を示している。オブジェクト管理は、生成したドメインオブジェクトのインスタンスを集約して保持しており、同じキーを持つマスタ系のドメインオブジェクトのインスタンスが二重生成されることを防止している。これにより、ドメインオブジェクトのデータの整合性が保証される。
【００９１】
これに対して、従来のシステムでは、インスタンスの一意性が必ずしも保証されておらず、同じキーを持つインスタンスが二重生成されることを許していた。このため、データ更新の際の整合性が保証されないという問題があった。
【００９２】
また、各ドメインオブジェクトは、上述したドメインモデルベースクラスから継承したリファレンスカウンタを保持しており、このリファレンスカウンタはオブジェクト管理により制御される。リファレンスカウンタは、オブジェクトの正しいライフサイクルを実現するために広く用いられており、そのオブジェクトをリンク関係で保持している他のオブジェクトの数を保持します。
【００９３】
ドメインオブジェクトをリンク関係で保持する制御オブジェクト等が、そのドメインオブジェクトの解放をオブジェクト管理に依頼したとき、リファレンスカウンタの値が１であれば、オブジェクト管理は、ドメインオブジェクトを直ちにメモリ上から解放する。しかし、リファレンスカウンタの値が２以上であれば、オブジェクト管理は、その値を１だけ減算し、ドメインオブジェクトをメモリ上に残す。
【００９４】
このようなオブジェクト管理と設計パターンの徹底によって、インスタンスの生成、削除に起因するメモリリークとメモリエラーが防止される。また、インスタンスの一意性の保証とリファレンスカウンタによって、データベースとの通信回数が削減される。
【００９５】
図１４において、受注伝票７１は、ジャーナル系のドメインオブジェクトであり、受注伝票管理７２は、受注伝票７１のオブジェクト管理である。また、納入先７３は、マスタ系のドメインオブジェクトであり、納入先管理７４は、納入先７３のオブジェクト管理である。
【００９６】
受注伝票管理７２は、納入先管理７４を指すリンクを保持し、受注制御４１は、受注伝票管理７２を指すリンクを保持している。受注伝票管理７２と受注伝票７１は集約関係を持っており、納入先管理７４と納入先７３も集約関係を持っている。さらに、受注伝票７１と受注明細４４も集約関係を持っており、１つの受注伝票７１のインスタンスは、１つ以上の受注明細４４のインスタンスとリンクされている。また、受注制御４１は、受注伝票７１および受注明細４４を使用し、受注明細４４は、受注伝票管理７２および納入先７３を使用する。
【００９７】
ここでは、受注伝票管理７２は、“ＧｅｔＮｅｗ”をメソッドとして保持し、受注伝票７１は、“Ｇｅｔ”をメソッドとして保持し、受注制御４１は、“新規起票”および“項目設定”をメソッドとして保持する。受注明細４４は、“明細番号”を属性として保持し、“Ｓｅｔ商品コード”、“Ｓｅｔ数量”、および“Ｓｅｔ納入先”をメソッドとして保持している。納入先管理７４は、“ＧｅｔＯｎｅ”をメソッドとして保持し、納入先７３は、“納入先コード”を属性として保持し、“Ｇｅｔ納入先名”をメソッドとして保持している。
【００９８】
図１５は、これらのオブジェクトが行う動作のパターンを示している。ここでは、受注伝票７１を起票し、受注明細４４の項目を設定するパターンが示されている。
【００９９】
まず、受注制御４１は、新規起票（）のメッセージを受け取ると、新規起票（）を実行し、ＧｅｔＮｅｗ（）のメッセージを受注伝票管理７２に送信する。受注伝票管理７２は、ＧｅｔＮｅｗ（）を実行して、受注伝票７１のインスタンスを生成し、その情報を受注制御４１に返送する。
【０１００】
次に、受注制御４１は、Ｇｅｔ（）のメッセージを受注伝票７１に送信し、受注伝票７１は、Ｇｅｔ（）を実行して、受注明細４４の１件目のインスタンスを取得し、その情報を受注制御４１に返送する。
【０１０１】
次に、受注制御４１は、項目設定（）のメッセージを受け取ると、項目設定（）を実行し、Ｓｅｔ商品コード（ｃｏｄｅ）のメッセージを受注明細４４に送信する。そして、受注明細４４は、Ｓｅｔ商品コード（ｃｏｄｅ）を実行して、商品コードを設定する。
【０１０２】
次に、受注制御４１は、項目設定（）のメッセージを受け取ると、項目設定（）を実行し、Ｓｅｔ数量（ｃｏｕｎｔ）のメッセージを受注明細４４に送信する。そして、受注明細４４は、Ｓｅｔ数量（ｃｏｕｎｔ）を実行して、数量を設定する。
【０１０３】
次に、受注制御４１は、項目設定（）のメッセージを受け取ると、項目設定（）を実行し、Ｓｅｔ納入先（００１）のメッセージを受注明細４４に送信する。そして、受注明細４４は、Ｓｅｔ納入先（００１）を実行して、納入先を設定する。
【０１０４】
このとき、受注明細４４は、ＧｅｔＯｎｅ（００１）のメッセージを納入先管理７４に送信する。そして、納入先管理７４は、ＧｅｔＯｎｅ（００１）を実行して、納入先コード“００１”に対応する納入先７３のインスタンスをデータベースから取得し、その情報を受注明細４４に返送する。次に、受注明細４４は、Ｇｅｔ納入先名（）のメッセージを納入先７３に送信する。そして、納入先７３は、Ｇｅｔ納入先名（）を実行して、納入先名を取得し、それを受注明細４４に返送する。
【０１０５】
次に、受注制御４１は、Ｇｅｔ（）のメッセージを受注伝票７１に送信し、受注伝票７１は、Ｇｅｔ（）を実行して、受注明細４４の２件目のインスタンスを取得し、その情報を受注制御４１に返送する。そして、１件目と同様のパターンで、商品コード、数量、および納入先を受注明細４４に設定する。
【０１０６】
このようなパターンは、受注明細４４のインスタンスの数だけ繰り返される。その間、納入先７３のインスタンスの一意性は納入先管理７４によって保証され、１つの受注伝票７１に関する受注明細４４の設定が終了するまで、納入先７３は繰り返し再利用される。
【０１０７】
図１６は、オブジェクト管理によるインスタンス間リンクの制御を説明するためのオブジェクトのリンク関係を示している。図１６において、端数調整情報７５は、マスタ系のドメインオブジェクトであり、端数調整情報管理７６は、端数調整情報７５のオブジェクト管理である。
【０１０８】
受注伝票管理７２は、得意先管理６６を指すリンク▲１▼を保持し、得意先管理６６は、端数調整情報管理７６を指すリンク▲２▼を保持し、受注伝票７１は、得意先６５を指すリンク▲３▼を保持し、得意先６５は、端数調整情報７５を指すリンク▲４▼を保持している。受注伝票管理７２と受注伝票７１は集約関係を持っており、得意先管理６６と得意先６５も集約関係を持っている。さらに、端数調整情報管理７６と端数調整情報７５も集約関係を持っている。
【０１０９】
一般に、オブジェクト管理は、上述したディレクタによって生成、保持されるが、その際、ディレクタにより、リンク▲１▼、▲２▼のようなオブジェクト管理間のリンクが確立される。ジャーナル系のオブジェクト管理は、リンク▲１▼のような、関連するマスタ系のオブジェクト管理へのリンクを保持している。また、リンク▲２▼のような、同じキーを持つマスタ系のオブジェクト管理間のリンクは、必要に応じて定義される。
【０１１０】
ドメインオブジェクトは、通常、他のドメインオブジェクトを生成することはないが、オブジェクト管理を通じて、リンク▲３▼、▲４▼のような、他のドメインオブジェクトとのリンクを動的に保持することができる。
【０１１１】
図１６では、受注伝票管理７２は、“Ｇｅｔ得意先管理”をメソッドとして保持し、受注伝票７１は、“伝票番号”を属性として保持し、“Ｓｅｔ得意先コード”、“Ｇｅｔ得意先”、および“金額計算”をメソッドとして保持している。得意先管理６６は、“ＧｅｔＯｎｅ”および“Ｇｅｔ端数調整情報管理”をメソッドとして保持し、得意先６５は、“得意先コード”を属性として保持し、“Ｇｅｔ得意先名”、“Ｇｅｔ住所”、“Ｇｅｔ電話番号”、および“端数調整依頼”をメソッドとして保持している。
【０１１２】
また、端数調整情報管理７６は、“ＧｅｔＯｎｅ”をメソッドとして保持し、端数調整情報７５は、“得意先コード”および“端数調整区分”を属性として保持し、“端数調整”をメソッドとして保持している。
【０１１３】
図１７は、これらのオブジェクトが行う動作のパターンを示している。ここでは、図１６に示したリンクを確立するパターンが示されている。まず、受注伝票７１は、Ｓｅｔ得意先コード（ｃｏｄｅ）のメッセージを受け取ると、Ｓｅｔ得意先コード（ｃｏｄｅ）を実行し、Ｇｅｔ得意先（）のメッセージを受け取ると、Ｇｅｔ得意先（）を実行する。
【０１１４】
このとき、受注伝票７１は、Ｇｅｔ得意先管理（）のメッセージを受注伝票管理７２に送信し、受注伝票管理７２は、Ｇｅｔ得意先管理（）を実行して、リンク▲１▼により得意先管理６６のインスタンスを取得し、その情報を受注伝票７１に返送する。
【０１１５】
次に、受注伝票７１は、ＧｅｔＯｎｅ（）のメッセージを得意先管理６６に送信し、得意先管理６６は、ＧｅｔＯｎｅ（）を実行して、得意先６５のインスタンスを取得し、その情報を受注伝票７１に返送する。この得意先６５のインスタンスへのリンクは、受注伝票７１の処理が終了するまで、受注伝票７１のインスタンスにリンク▲３▼として保持される。
【０１１６】
次に、得意先６５は、Ｇｅｔ得意先名（）、Ｇｅｔ住所（）、およびＧｅｔ電話番号（）のメッセージを受け取ると、Ｇｅｔ得意先名（）、Ｇｅｔ住所（）、およびＧｅｔ電話番号（）を実行する。
【０１１７】
次に、受注伝票７１は、金額計算（）のメッセージを受け取ると、金額計算（）を実行し、端数調整依頼（明細金額）のメッセージを得意先６５に送信する。得意先６５は、端数調整依頼（明細金額）を実行し、Ｇｅｔ端数調整情報管理（）のメッセージを得意先管理６６に送信する。そして、得意先管理６６は、Ｇｅｔ端数調整情報管理（）を実行し、リンク▲２▼により、端数調整情報管理７６のインスタンスを取得し、その情報を得意先６５に返送する。
【０１１８】
次に、得意先６５は、ＧｅｔＯｎｅ（得意先ｃｏｄｅ）のメッセージを端数調整情報管理７６に送信する。端数調整情報管理７６は、ＧｅｔＯｎｅ（得意先ｃｏｄｅ）を実行して、端数調整情報７５のインスタンスを取得し、その情報を得意先６５に返送する。この端数調整情報７５のインスタンスへのリンクは、受注伝票７１の金額計算が終了するまで、得意先６５のインスタンスにリンク▲４▼として保持される。
【０１１９】
次に、得意先６５は、端数調整（金額）のメッセージを端数調整情報７５に送信し、端数調整情報７５は、端数調整（金額）を実行して、調整された金額を得意先６５に返送する。そして、得意先６５は、返送された金額を端数調整済金額として受注伝票７１に送信する。これにより、１件の受注明細４４に関する金額計算が終了する。
【０１２０】
このような金額計算は、受注明細４４の件数だけ繰り返され、すべての受注明細４４について処理が終了すると、受注伝票７１の金額計算が終了する。端数調整情報７５のインスタンスへのリンク▲４▼は、受注伝票７１の金額計算が終了するまで得意先６５により保持されるため、端数調整情報管理７６への参照は、初回のみ行われる。
【０１２１】
オブジェクト管理は、以上説明したパターンに記述されたメソッドのほかにも、次のようなメソッド群をインタフェースとして持つことができる。
（１）ドメインオブジェクトの検索条件を指定し、対応するインスタンスを順番に１つずつ返却するメソッド群（Ｓｅｌｅｃｔ／Ｇｅｔ）。
【０１２２】
Ｓｅｌｅｃｔ（）は、検索条件を引数として含み、データベースとの１回の通信（ＳＱＬ実行）で複数のレコードを検索し、検索結果をオブジェクト管理のメモリ領域に格納する。また、Ｇｅｔ（）は、Ｓｅｌｅｃｔ（）とペアで使用され、Ｇｅｔ（）を実行すると、１つのドメインオブジェクトが返却される。このとき、オブジェクト管理は、Ｓｅｌｅｃｔ（）の実行時にプールしたデータの中から１つのドメインオブジェクトに相当するデータを抜き出して、ドメインオブジェクトを生成する。
【０１２３】
オブジェクト管理がデータベースを隠蔽している場合、一定の検索条件で処理対象のレコードをまとめて抽出可能ならば、これらのメソッドを用いた方がＧｅｔＯｎｅ（）によりドメインオブジェクトを個別に取得するよりも効率的である。
（２）ドメインオブジェクトの検索条件を指定し、対応するインスタンスのすべての属性情報を文字列として一括返却するメソッド群（Ｓｅｌｅｃｔ／ＧｅｔＡｌｌＡｔｔｒｉｂｕｔｅｓ）。
（３）ドメインオブジェクトの検索条件を指定し、対応するインスタンスを順番に１つずつ返却し、それらの属性情報を変更した後にデータベースを一括更新するメソッド群（Ｓｅｌｅｃｔ／Ｇｅｔ／Ｕｐｄａｔｅ）。
（４）新規に生成された複数のドメインオブジェクトのインスタンスをまとめて一括登録するメソッド群（Ａｌｌｏｃ／Ｉｎｓｅｒｔ／Ｆｌｕｓｈ）。
【０１２４】
図１８は、制御オブジェクトによるハイレベルな手続きを説明するためのオブジェクトのリンク関係を示している。制御オブジェクトは、特定のドメインオブジェクトに属さないハイレベルな手続きを保持している。ハイレベルな手続きとしては、次のようなものが考えられる。
（１）受注時に発注を行う。
（２）受注時に在庫の引き当てを行う。
（３）修正時に赤伝票を登録する。
（４）受注と同時に売上計上を行う。
【０１２５】
オンライン業務においては、制御オブジェクトは、クライアントからの処理依頼を、保持しているリンクを元に解決し、処理結果をクライアントに通知する。このとき、クライアントからのメッセージをオブジェクトへの複数のメッセージに展開して、送信する。また、同じクラスに属する複数のインスタンスを同時に扱うことができ、バッチ処理を記述することもできる。
【０１２６】
受注制御４１は、受注伝票管理７２、受注伝票７１、および受注明細４４を指すリンクを保持している。受注伝票管理７２と受注伝票７１は集約関係を持っており、受注伝票７１と受注明細４４も集約関係を持っている。受注明細４４は、受注伝票管理７２を使用する。
【０１２７】
ここでは、受注伝票管理７２は、“ＧｅｔＮｅｗ”および“ＧｅｔＯｎｅ”をメソッドとして保持し、受注伝票７１は、“伝票番号”を属性として保持し、“赤Ｃｏｐｙ”、“黒Ｃｏｐｙ”、“Ｓｅｔ元伝票フラグ”、“Ｇｅｔ”、および“Ｒｅｍｏｖｅ”をメソッドとして保持している。受注制御４１は、“修正開始”、“明細修正”、“明細追加”、および“明細削除”をメソッドとして保持し、受注明細４４は、“明細番号”を属性として保持し、“Ｓｅｔ商品コード”および“Ｓｅｔ数量”をメソッドとして保持している。
【０１２８】
図１９は、これらのオブジェクトが行う動作のパターンを示している。ここでは、赤黒修正を行うパターンが示されている。まず、受注制御４１は、修正開始（）のメッセージを受け取ると、修正開始（）を実行し、ＧｅｔＯｎｅ（伝票番号）のメッセージを受注伝票管理７２に送信する。受注伝票管理７２は、ＧｅｔＯｎｅ（伝票番号）を実行して、受注伝票７１のインスタンス（元伝票）を取得し、その情報を受注制御４１に返送する。
【０１２９】
次に、受注制御４１は、ＧｅｔＮｅｗ（）のメッセージを受注伝票管理７２に送信し、受注伝票管理７２は、ＧｅｔＮｅｗ（）を実行して、受注伝票７１のインスタンス（赤伝票）を生成し、その情報を受注制御４１に返送する。そして、受注制御４１は、赤Ｃｏｐｙ（元伝票インスタンス）のメッセージを赤伝票インスタンスに送信し、赤伝票インスタンスは、赤Ｃｏｐｙ（元伝票インスタンス）を実行する。
【０１３０】
次に、受注制御４１は、ＧｅｔＮｅｗ（）のメッセージを受注伝票管理７２に送信し、受注伝票管理７２は、ＧｅｔＮｅｗ（）を実行して、受注伝票７１のインスタンス（黒伝票）を生成し、その情報を受注制御４１に返送する。そして、受注制御４１は、黒Ｃｏｐｙ（元伝票インスタンス）のメッセージを黒伝票インスタンスに送信し、黒伝票インスタンスは、黒Ｃｏｐｙ（元伝票インスタンス）を実行する。
【０１３１】
次に、受注制御４１は、Ｓｅｔ元伝票フラグ（）のメッセージを元伝票インスタンスに送信し、元伝票インスタンスは、Ｓｅｔ元伝票フラグ（）を実行する。次に、受注制御４１は、明細修正（行情報）のメッセージを受け取ると、明細修正（行情報）を実行し、Ｇｅｔ（行番号）のメッセージを黒伝票インスタンスに送信する。黒伝票インスタンスは、Ｇｅｔ（行番号）を実行して、対応する受注明細４４のインスタンスを取得し、その情報を受注制御４１に返送する。そして、受注制御４１は、Ｓｅｔ商品コード（）およびＳｅｔ数量（）のメッセージを受注明細４４に送信し、受注明細４４は、Ｓｅｔ商品コード（）およびＳｅｔ数量（）を実行して、商品コードおよび数量を修正する。
【０１３２】
また、受注制御４１は、明細追加（行情報）のメッセージを受け取ると、明細追加（行情報）を実行し、Ｇｅｔ（）のメッセージを黒伝票インスタンスに送信する。黒伝票インスタンスは、Ｇｅｔ（）を実行して、受注明細４４のインスタンスを生成し、その情報を受注制御４１に返送する。そして、受注制御４１は、Ｓｅｔ商品コード（）およびＳｅｔ数量（）のメッセージを受注明細４４に送信し、受注明細４４は、Ｓｅｔ商品コード（）およびＳｅｔ数量（）を実行して、商品コードおよび数量を設定する。
【０１３３】
また、受注制御４１は、明細削除（行番号）のメッセージを受け取ると、明細削除（行番号）を実行し、Ｒｅｍｏｖｅ（行番号）のメッセージを黒伝票インスタンスに送信する。黒伝票インスタンスは、Ｒｅｍｏｖｅ（行番号）を実行して、対応する行を削除する。
【０１３４】
図２０は、制御オブジェクトによるインスタンス間リンクの制御を説明するためのオブジェクトのリンク関係を示している。制御オブジェクトは、ディレクタによって生成、保持されるが、その際、必要なジャーナル系およびマスタ系のオブジェクト管理へのリンクが確立される。また、制御オブジェクトは、クライアントからの処理依頼を解決するためのビジネスルールと、解決に必要なインスタンス間リンクを保持している。
【０１３５】
受注伝票管理７２は、商品管理６２を指すリンクを保持し、受注制御４１は、受注伝票管理７２を指すリンクを保持している。受注伝票管理７２と受注伝票７１は集約関係を持っており、商品管理６２と商品６１も集約関係を持っている。さらに、受注伝票７１と受注明細４４も集約関係を持っている。受注制御４１は、受注伝票７１、受注明細４４、および商品６１を使用し、受注明細４４は、受注伝票管理７２および商品６１を使用する。
【０１３６】
ここでは、受注伝票管理７２は、“ＧｅｔＮｅｗ”をメソッドとして保持し、受注伝票７１は、“伝票番号”を属性として保持し、“Ｓｅｔ得意先コード”および“Ｇｅｔ得意先”をメソッドとして保持している。受注制御４１は、“新規起票”、“ヘッダ項目設定”、“明細項目設定”、および“手入力単価設定”をメソッドとして保持し、受注明細４４は、“明細番号”を属性として保持し、“Ｓｅｔ商品コード”、“Ｓｅｔ数量”、“Ｓｅｔ単価”、および“Ｇｅｔ商品”をメソッドとして保持している。
【０１３７】
また、商品管理６２は、“ＧｅｔＯｎｅ”をメソッドとして保持し、商品６１は、“商品コード”を属性として保持し、“Ｇｅｔ商品名”をメソッドとして保持している。
【０１３８】
図２１は、これらのオブジェクトが行う動作のパターンを示している。ここでは、受注伝票７１を起票し、受注明細４４の項目を設定するパターンが示されている。
【０１３９】
まず、受注制御４１は、新規起票（）のメッセージを受け取ると、新規起票（）を実行し、ＧｅｔＮｅｗ（）のメッセージを受注伝票管理７２に送信する。受注伝票管理７２は、ＧｅｔＮｅｗ（）を実行して、受注伝票７１のインスタンスを生成し、その情報を受注制御４１に返送する。これにより、受注制御４１は、受注伝票７１へのリンクを取得する。
【０１４０】
次に、受注制御４１は、ヘッダ項目設定（）のメッセージを受け取ると、ヘッダ項目設定（）を実行し、Ｓｅｔ得意先コード（ｃｏｄｅ）のメッセージを受注伝票７１に送信する。そして、受注伝票７１は、Ｓｅｔ得意先コード（ｃｏｄｅ）を実行して、得意先コードを設定する。
【０１４１】
次に、受注制御４１は、Ｇｅｔ得意先（）のメッセージを受注伝票７１に送信する。受注伝票７１は、Ｇｅｔ得意先（）を実行し、ＧｅｔＯｎｅ（ｃｏｄｅ）のメッセージを図１６の得意先管理６６に送信する。得意先管理６６は、ＧｅｔＯｎｅ（ｃｏｄｅ）を実行し、図１６の得意先６５のインスタンスを取得して、その情報を受注伝票７１に返送する。そして、受注伝票７１は、返送された得意先６５のインスタンスの情報を受注制御４１に送信する。これにより、受注制御４１は、得意先６５へのリンクを取得する。
【０１４２】
次に、受注制御４１は、Ｇｅｔ得意先名（）のメッセージを得意先６５に送信する。得意先６５は、Ｇｅｔ得意先名（）を実行して、得意先名を取得し、それを受注制御４１に返送する。そして、受注制御４１は、返送された得意先名をクライアントに通知する。
【０１４３】
次に、受注制御４１は、明細項目設定（）のメッセージを受け取ると、明細項目設定（）を実行し、Ｓｅｔ商品コード（ｃｏｄｅ）のメッセージを受注明細４４に送信する。そして、受注明細４４は、Ｓｅｔ商品コード（ｃｏｄｅ）を実行して、商品コードを設定する。
【０１４４】
次に、受注制御４１は、Ｇｅｔ商品（）のメッセージを受注明細４４に送信する。受注明細４４は、Ｇｅｔ商品（）を実行し、ＧｅｔＯｎｅ（ｃｏｄｅ）のメッセージを商品管理６２に送信する。商品管理６２は、ＧｅｔＯｎｅ（ｃｏｄｅ）を実行し、商品６１のインスタンスを取得して、その情報を受注明細４４に返送する。そして、受注明細４４は、返送された商品６１のインスタンスの情報を受注制御４１に送信する。これにより、受注制御４１は、商品６１へのリンクを取得する。
【０１４５】
次に、受注制御４１は、Ｇｅｔ商品名（）のメッセージを商品６１に送信する。商品６１は、Ｇｅｔ商品名（）を実行して、商品名を取得し、それを受注制御４１に返送する。そして、受注制御４１は、返送された商品名をクライアントに通知する。
【０１４６】
次に、受注制御４１は、明細項目設定（）のメッセージを受け取ると、明細項目設定（）を実行し、Ｓｅｔ数量（ｃｏｕｎｔ）のメッセージを受注明細４４に送信する。そして、受注明細４４は、Ｓｅｔ数量（ｃｏｕｎｔ）を実行して、数量を設定する。
【０１４７】
次に、受注制御４１は、手入力単価設定（）のメッセージを受け取ると、手入力単価設定（）を実行し、Ｓｅｔ単価（ｐｒｉｃｅ）のメッセージを受注明細４４に送信する。そして、受注明細４４は、Ｓｅｔ単価（ｐｒｉｃｅ）を実行して、単価を設定する。
【０１４８】
なお、各項目の設定にはあらかじめ決められたルールが適用され、設定値に誤りがあると、設定を実行したオブジェクトから受注制御４１にエラーコードが返送される。そして、受注制御４１は、エラー処理を集中的に行う。
【０１４９】
図２２は、伝票処理の業務システムにおける受注入力時の実行画面を示しており、図２３は、対応するインスタンス間のリンク関係を示している。図２２の画面に表示された受注番号、得意先、納入先等の各項目の情報は、図２３のような複数のインスタンスに分散して保持される。
【０１５０】
図２３において、担当者７７は、ドメインオブジェクトであり、担当者管理７８は、担当者７７のオブジェクト管理である。受注制御４１は、受注伝票７１へのリンクを保持し、受注伝票７１は、得意先６５、納入先７３、および担当者７７へのリンクを保持し、受注明細４４は、商品６１へのリンクを保持している。
【０１５１】
また、受注伝票管理７２と受注伝票７１は集約関係を持ち、受注伝票７１と受注明細４４も集約関係を持ち、商品管理６２と商品６１も集約関係を持っている。さらに、得意先管理６６と得意先６５も集約関係を持ち、納入先管理７４と納入先７３も集約関係を持ち、担当者管理７８と担当者７７も集約関係を持っている。
【０１５２】
受注伝票７１は、受注番号、得意先コード、納入先コード、担当者コード等の属性を保持し、得意先６５は、得意先のコードおよび名前の属性を保持し、納入先７３は、納入先のコードおよび名前の属性を保持し、担当者７７は、担当者のコードおよび名前の属性を保持している。また、受注明細４４は、明細番号、取引区分、商品コード等の属性を保持し、商品６１は、商品のコードおよび名前の属性を保持している。
【０１５３】
図２４は、オブジェクト管理のクラスの作成手順を示している。業務システムは、まず、ドメインオブジェクトの属性を抽出し（ステップＳ１）、ドメインオブジェクトのキー項目を決定し（ステップＳ２）、キー項目別のデータベースアクセスのＳＱＬパターンを決定する（ステップＳ３）。キー項目としては、例えば、ドメインオブジェクトのコードや名前が用いられる。
【０１５４】
また、ビジネスルールやシステムの運用形態により、データのキャッシュ種別を選択する（ステップＳ４）。キャッシュは、例えば、業務システムのメモリ上に設けられ、１つまたは複数のキャッシュ種別を選択することができる。キャッシュ種別としては、例えば、次のようなものが用いられる。
（１）１トランザクション内での短期キャッシュ：１トランザクションの処理が終了するまで、ドメインオブジェクトをキャッシュ上に保持する。
（２）１スレッド内でのＬＲＵ（least recently used ）キャッシュ：１スレッドの処理が終了するまで、ドメインオブジェクトをキャッシュ上に保持し、ＬＲＵ法により、キャシュ上で置き換えるべきドメインオブジェクトを決定する。ここで、スレッドは、プロセス（タスク）を構成する処理単位である。また、ＬＲＵ法は、最近使用されたデータをキャッシュ上に残し、最も長く使われていないデータを置き換えの対象として選ぶアルゴリズムである。したがって、キャッシュ上には、最近アクセス時刻の新しい順に、キャッシュが一杯になるまで選ばれたオブジェクト群が保持され、メモリの利用効率が向上する。
（３）１スレッド内での順検索先読み式キャッシュ：最初にＧｅｔＯｎｅ（）で指定されたキーを属性として持つドメインオブジェクトから順番に、昇順または降順で一定数のドメインオブジェクトを、補助記憶装置からキャッシュに先読みしておく。キャッシュから読み込まれたドメインオブジェクトは処理が終了すると、キャッシュより解放される。そして、キャッシュが空になると、次の一定数のドメインオブジェクトをキャッシュに先読みする。
（４）１プロセス内での全件先読み式キャッシュ：プロセスの起動時に、処理対象とするすべてのドメインオブジェクトを補助記憶装置からキャッシュに先読みしておく。そして、１プロセスの処理が終了するまで、それらのドメインオブジェクトをキャッシュ上に保持する。
【０１５５】
次に、業務システムは、キャッシュ種別毎のオブジェクト管理の実装パターンを選択する（ステップＳ５）。ステップＳ６では、１トランザクション内での短期キャッシュの実装パターンが選択され、ステップＳ７では、１スレッド内でのＬＲＵキャッシュの実装パターンが選択され、ステップＳ８では、１スレッド内での順検索先読み式キャッシュの実装パターンが選択され、ステップＳ９では、１プロセス内での全件先読み式キャッシュの実装パターンが選択される。
【０１５６】
そして、業務システムは、実装パターンに基づいた各オブジェクト管理のクラスをコーディングして（ステップＳ１０）、作成処理を終了する。
図２５から図２７までは、業務システムで用いられるメソッドの実装パターンの例を示している。図２５は、ドメインオブジェクトを取得するＧｅｔＯｎｅ（）の実装パターンを示している。この実装パターンは、短期キャッシュおよびＬＲＵキャッシュに共通のパターンである。
【０１５７】
また、図２６および図２７は、オブジェクトを解放するｒｅｌｅａｓｅ ｏｎｅの実装パターンを示している。図２６は、短期キャッシュのためのパターンであり、図２７は、ＬＲＵキャッシュのためのパターンである。ｒｅｌｅａｓｅ ｏｎｅは、例えば、オブジェクト管理が保持しているドメインオブジェクトをメモリ上から解放する際に用いられる。
【０１５８】
ところで、上述した図２の業務システムは、図２８に示すような情報処理装置（コンピュータ）を用いて構成することができる。図２８の情報処理装置は、ＣＰＵ（中央処理装置）８１、メモリ８２、入力装置８３、出力装置８４、外部記憶装置８５、媒体駆動装置８６、およびネットワーク接続装置８７を備え、それらはバス８８により互いに接続されている。
【０１５９】
メモリ８２は、例えば、ＲＯＭ（read only memory）、ＲＡＭ（random access memory）等を含み、処理に用いられるオブジェクトのプログラムとデータを格納する。ＣＰＵ８１は、メモリ８２を利用してプログラムを実行することにより、必要な処理を行う。
【０１６０】
入力装置８３は、例えば、キーボード、ポインティングデバイス、タッチパネル等であり、ユーザからの指示や情報の入力に用いられる。出力装置８４は、例えば、ディスプレイ、プリンタ、スピーカ等であり、ユーザへの問い合わせや情報の出力に用いられる。
【０１６１】
外部記憶装置８５は、例えば、磁気ディスク装置、光ディスク装置、光磁気ディスク（magneto-optical disk）装置等の補助記憶装置であり、図２のデータベース１３やシーケンシャルファイル１４を格納する。この外部記憶装置８５に、上述のプログラムとデータを保存しておき、必要に応じて、それらをメモリ８２にロードして使用することもできる。
【０１６２】
媒体駆動装置８６は、可搬記録媒体８９を駆動し、その記録内容にアクセスする。可搬記録媒体８９としては、メモリカード、フロッピーディスク、ＣＤ−ＲＯＭ（compact disk read only memory ）、光ディスク、光磁気ディスク等、任意のコンピュータ読み取り可能な記録媒体が用いられる。この可搬記録媒体８９に上述のプログラムとデータを格納しておき、必要に応じて、それらをメモリ８２にロードして使用することもできる。
【０１６３】
ネットワーク接続装置８７は、ＬＡＮ（local area network）等の任意のネットワーク（回線）を介して外部の装置と通信し、通信に伴うデータ変換を行う。また、必要に応じて、上述のプログラムとデータを外部の装置から受け取り、それらをメモリ８２にロードして使用することもできる。
【０１６４】
図２９は、図２８の情報処理装置にプログラムとデータを供給することのできるコンピュータ読み取り可能な記録媒体を示している。可搬記録媒体８９や外部のデータベース９０に保存されたプログラムとデータは、メモリ８２にロードされる。そして、ＣＰＵ８１は、そのデータを用いてそのプログラムを実行し、必要な処理を行う。
【０１６５】
【発明の効果】
本発明によれば、オブジェクト指向の特徴を活用した業務システムを構築することが可能になる。本システムでは、オブジェクト指向部品の再利用や組み合わせが容易であり、本システムをベースにユーザの業務形態にマッチした様々なシステムを構築することができる。
【０１６６】
また、ユーザからのカストマイズの要件に応じて、修正の対象となる部品を容易に絞り込むことができ、修正する部品数も少なくて済む。また、オブジェクト指向部品を用いているため、データ操作やビジネスルールの実装が外部から隠蔽されており、すべての部品がパターンに基づいて設計／実装されているので、システム全体の保守性が良い。
【０１６７】
また、各部品はパターンと継承に基づいて実装されているので、部品の開発コストが従来のシステムより低く押さえられる。また、部品に対する実装パターンの適用率が高いので、部品の修正時の品質や部品の生産性が良い。
【図面の簡単な説明】
【図１】本発明の業務システムの原理図である。
【図２】業務システムの構成図である。
【図３】ビジネスオブジェクトのクラスを示す図である。
【図４】伝票処理業務の機能を示す図である。
【図５】クラスの例を示す図である。
【図６】第１のリンク関係を示す図である。
【図７】第１のパターンを示す図である。
【図８】第２のリンク関係を示す図である。
【図９】第２のパターンを示す図である。
【図１０】第３のリンク関係を示す図である。
【図１１】第３のパターンを示す図である。
【図１２】第４のリンク関係を示す図である。
【図１３】第４のパターンを示す図である。
【図１４】第５のリンク関係を示す図である。
【図１５】第５のパターンを示す図である。
【図１６】第６のリンク関係を示す図である。
【図１７】第６のパターンを示す図である。
【図１８】第７のリンク関係を示す図である。
【図１９】第７のパターンを示す図である。
【図２０】第８のリンク関係を示す図である。
【図２１】第８のパターンを示す図である。
【図２２】受注入力の画面を示す図である。
【図２３】インスタンスの例を示す図である。
【図２４】オブジェクト管理の作成手順を示す図である。
【図２５】オブジェクトの取得の実装パターンを示す図である。
【図２６】オブジェクトの解放の第１の実装パターンを示す図である。
【図２７】オブジェクトの解放の第２の実装パターンを示す図である。
【図２８】情報処理装置の構成図である。
【図２９】記録媒体を示す図である。
【符号の説明】
１ オブジェクト手段
２ 実行手段
３、２３、４４、４６、４９、５１、６１、６４、６５、６８、７１、７３、７５、７７ ドメインオブジェクト
４、２４、４３、４５、４８、５０、６２、６６、６９、７２、７４、７６、７８ オブジェクト管理
１１ クライアント
１２ ビジネスオブジェクト
１３、９０ データベース
１４ シーケンシャルファイル
２１ ディレクタ
２２ モデル群
２５、４１、４２、６７、７０ 制御オブジェクト
２６、４７、６３ サービスオブジェクト
３１ ディレクタベースクラス
３２ モデルベースクラス
３３ コントローラベースクラス
３４ ドメインモデルベースクラス
３５ オブジェクトマネージャベースクラス
８１ ＣＰＵ
８３ 入力装置
８４ 出力装置
８５ 外部記憶装置
８６ 媒体駆動装置
８７ ネットワーク接続装置
８８ バス
８９ 可搬記録媒体
Claims (19)
- 伝票処理業務を含んだ処理業務を行うためのコンピュータシステムであって、
属性データと、該属性データの値の設定方法や演算ロジックに関するメソッドとを保持するドメインオブジェクトを記憶する第一の記憶手段と、
前記ドメインオブジェクトを生成または削除または保持するとともに、前記ドメインオブジェクトが保持する属性データに対するメソッドとしてデータアクセスのインタフェースを保持するオブジェクト管理を記憶する第二の記憶手段と、
前記ドメインオブジェクトおよび前記オブジェクト管理へのリンク関係と、前記ドメインオブジェクトおよび前記オブジェクト管理が保持するメソッドの実行手順とを保持する制御オブジェクトを記憶する第三の記憶手段と、
前記制御オブジェクトが保持するリンク関係と実行手順に基いて、前記ドメインオブジェクトおよび前記オブジェクト管理が保持するメソッドを実行する実行手段とを備え、
前記第二の記憶手段は、前記第一の記憶手段が記憶している前記ドメインオブジェクトのうちの１つのドメインオブジェクトに対応して、データアクセスの対象およびアクセス形態のうち少なくとも一方に応じて複数のオブジェクト管理を記憶し、前記実行手段は、前記制御オブジェクトが、前記ドメインオブジェクトに対応する前記オブジェクト管理の前記メソッドの実行を要求することにより、該ドメインオブジェクトに保持されている属性データを該対応する複数のオブジェクト管理のうちの１つに保持されているインタフェースに従い補助記憶装置へ保存することを特徴とする業務システム。 - 前記オブジェクト管理は、キャッシュおよび補助記憶装置のうち少なくとも一方に適したインタフェースを保持することを特徴とする請求項１記載の業務システム。
- 前記オブジェクト管理は、オンライン処理、バッチ処理、およびマスタメンテナンス処理のうち少なくとも１つに適したインタフェースを保持することを特徴とする請求項１記載の業務システム。
- 前記オブジェクト管理は、前記ドメインオブジェクトのキー属性の値を指定し、対応するドメインオブジェクトを返却するインタフェースを有することを特徴とする請求項１記載の業務システム。
- 前記オブジェクト管理は、前記ドメインオブジェクトの検索条件を指定し、対応するドメインオブジェクトを順番に１つずつ返却するインタフェースを有することを特徴とする請求項１記載の業務システム。
- 前記オブジェクト管理は、前記ドメインオブジェクトの検索条件を指定し、対応するドメインオブジェクトのすべての情報を一括返却するインタフェースを有することを特徴とする請求項１記載の業務システム。
- 前記オブジェクト管理は、新規のドメインオブジェクトを１つずつ登録するインタフェースを有することを特徴とする請求項１記載の業務システム。
- 前記オブジェクト管理は、新規のドメインオブジェクトをまとめて一括登録するインタフェースを有することを特徴とする請求項１記載の業務システム。
- 前記オブジェクト管理は、前記ドメインオブジェクトを１つずつ更新するインタフェースを有することを特徴とする請求項１記載の業務システム。
- 前記オブジェクト管理は、前記ドメインオブジェクトの検索条件を指定し、対応するドメインオブジェクトを順番に１つずつ返却し、返却されたドメインオブジェクトの変更後に、データベースを一括更新するインタフェースを有することを特徴とする請求項１記載の業務システム。
- 前記実行手段は、前記オブジェクト管理を用いて、前記ドメインオブジェクトを保持し続け、該ドメインオブジェクトの取得要求を受け取ったとき、該ドメインオブジェクトを返却することを特徴とする請求項１記載の業務システム。
- 前記実行手段は、前記オブジェクト管理を用いて、複数のドメインオブジェクトを保持し続け、メモリ効率に関する特定のアルゴリズムに従って、該複数のドメインオブジェクトを管理することを特徴とする請求項１記載の業務システム。
- 前記実行手段は、前記オブジェクト管理を用いて、処理対象となるすべてのドメインオブジェクトをあらかじめ取得しておき、ドメインオブジェクトの取得要求を受け取ったとき、要求されたドメインオブジェクトを返却することを特徴とする請求項１記載の業務システム。
- 前記実行手段は、前記オブジェクト管理を用いて、最初に指定されたキー属性の値を持つドメインオブジェクトから昇順または降順で一定数のドメインオブジェクトを先読みしておき、該一定数のドメインオブジェクトのうちの１つの取得要求を受け取ったとき、要求されたドメインオブジェクトを返却することを特徴とする請求項１記載の業務システム。
- 前記ドメインオブジェクトに他のオブジェクトから依頼された特定の機能を実行するサービスオブジェクトをさらに有することを特徴とする請求項１記載の業務システム。
- 前記サービスオブジェクトは、ユーザが指定したビジネスルールを組み込むためのインタフェースを有することを特徴とする請求項１５記載の業務システム。
- 前記第二の記憶手段は、少なくとも、前記ドメインオブジェクトの検索条件を指定し、対応するドメインオブジェクトを順番に１つずつ返却するメソッド群をインタフェースとして保持する第一のオブジェクト管理、前記ドメインオブジェクトの検索条件を指定し、対応するドメインオブジェクトのすべての情報を一括返却するメソッド群をインタフェースとして保持する第二のオブジェクト管理、前記ドメインオブジェクトの検索条件を指定し、対応するドメインオブジェクトを順番に１つずつ返却し、返却されたドメインオブジェクトの変更後に、データベースを一括更新するメソッド群をインタフェースとして保持する第三のオブジェクト管理、および新規のドメインオブジェクトをまとめて一括登録するメソッド群をインタフェースとして保持する第四のオブジェクト管理を記憶することを特徴とする請求項１記載の業務システム。
- 伝票処理業務を含んだ処理業務を行うコンピュータのためのオブジェクト指向プログラムを記録した記録媒体であって、
属性データと、該属性データの値の設定方法や演算ロジックに関するメソッドとを保持するドメインオブジェクトを記憶する第一の記憶手段と、
前記ドメインオブジェクトを生成または削除または保持するとともに、前記ドメインオブジェクトが保持する属性データに対するメソッドとしてデータアクセスのインタフェースを保持するオブジェクト管理を記憶する第二の記憶手段と、
前記ドメインオブジェクトおよび前記オブジェクト管理へのリンク関係と、前記ドメインオブジェクトおよび前記オブジェクト管理が保持するメソッドの実行手順とを保持する制御オブジェクトを記憶する第三の記憶手段と、
前記制御オブジェクトが保持するリンク関係と実行手順に基いて、前記ドメインオブジェクトおよび前記オブジェクト管理が保持するメソッドを実行する実行手段として、前記コンピュータを機能させ、
前記第二の記憶手段は、前記第一の記憶手段が記憶している前記ドメインオブジェクトのうちの１つのドメインオブジェクトに対応して、データアクセスの対象およびアクセス形態のうち少なくとも一方に応じて複数のオブジェクト管理を記憶し、前記実行手段は、前記制御オブジェクトが、前記ドメインオブジェクトに対応する前記オブジェクト管理の前記メソッドの実行を要求することにより、該ドメインオブジェクトに保持されている属性データを該対応する複数のオブジェクト管理のうちの１つに保持されているインタフェースに従い補助記憶装置へ保存するように、前記コンピュータを機能させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。 - 前記第二の記憶手段は、少なくとも、前記ドメインオブジェクトの検索条件を指定し、対応するドメインオブジェクトを順番に１つずつ返却するメソッド群をインタフェースとして保持する第一のオブジェクト管理、前記ドメインオブジェクトの検索条件を指定し、対応するドメインオブジェクトのすべての情報を一括返却するメソッド群をインタフェースとして保持する第二のオブジェクト管理、前記ドメインオブジェクトの検索条件を指定し、対応するドメインオブジェクトを順番に１つずつ返却し、返却されたドメインオブジェクトの変更後に、データベースを一括更新するメソッド群をインタフェースとして保持する第三のオブジェクト管理、および新規のドメインオブジェクトをまとめて一括登録するメソッド群をインタフェースとして保持する第四のオブジェクト管理を記憶することを特徴とする請求項１８記載の記録媒体。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP30069098A JP4159674B2 (ja) | 1998-10-22 | 1998-10-22 | オブジェクト指向業務システムおよび方法 |
| US09/791,917 US20010009033A1 (en) | 1998-10-22 | 2001-02-26 | Object-oriented business system and method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP30069098A JP4159674B2 (ja) | 1998-10-22 | 1998-10-22 | オブジェクト指向業務システムおよび方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000132394A JP2000132394A (ja) | 2000-05-12 |
| JP4159674B2 true JP4159674B2 (ja) | 2008-10-01 |
Family
ID=17887914
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP30069098A Expired - Lifetime JP4159674B2 (ja) | 1998-10-22 | 1998-10-22 | オブジェクト指向業務システムおよび方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20010009033A1 (ja) |
| JP (1) | JP4159674B2 (ja) |
Families Citing this family (35)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7571107B1 (en) * | 2000-06-23 | 2009-08-04 | Computer Sciences Corporation | System and method for externalization of rules for assessing damages |
| US7353494B2 (en) * | 2000-10-26 | 2008-04-01 | Microsoft Corporation | System and method supporting configurable object definitions |
| WO2002039255A2 (en) * | 2000-11-09 | 2002-05-16 | Navision A/S | An auto-generated task sequence |
| JP4907775B2 (ja) * | 2001-03-14 | 2012-04-04 | 富士通株式会社 | 分析装置及びプログラム及び分析方法 |
| JP2002298067A (ja) * | 2001-03-30 | 2002-10-11 | Tsubasa System Co Ltd | 伝票発行自動処理方法 |
| GB2382169A (en) * | 2001-11-16 | 2003-05-21 | Inventec Corp | XML in electronic data interchange systems |
| DE10161140A1 (de) * | 2001-12-12 | 2003-07-03 | Siemens Ag | System und Verfahren zum Verfolgen und/oder Auswerten des Informationsaustausches |
| US7676387B2 (en) | 2002-10-31 | 2010-03-09 | Computer Sciences Corporation | Graphical display of business rules |
| US7689442B2 (en) | 2002-10-31 | 2010-03-30 | Computer Science Corporation | Method of generating a graphical display of a business rule with a translation |
| US7457815B2 (en) * | 2003-03-27 | 2008-11-25 | Apple Inc. | Method and apparatus for automatically providing network services |
| US7895064B2 (en) | 2003-09-02 | 2011-02-22 | Computer Sciences Corporation | Graphical input display in an insurance processing system |
| US8341536B2 (en) * | 2005-07-08 | 2012-12-25 | International Business Machines Corporation | Dynamic interface component control support |
| US7872652B2 (en) * | 2007-01-07 | 2011-01-18 | Apple Inc. | Application programming interfaces for synchronization |
| US20080168402A1 (en) | 2007-01-07 | 2008-07-10 | Christopher Blumenberg | Application Programming Interfaces for Gesture Operations |
| US20080168478A1 (en) | 2007-01-07 | 2008-07-10 | Andrew Platzer | Application Programming Interfaces for Scrolling |
| US8813100B1 (en) * | 2007-01-07 | 2014-08-19 | Apple Inc. | Memory management |
| US7903115B2 (en) | 2007-01-07 | 2011-03-08 | Apple Inc. | Animations |
| US7844915B2 (en) | 2007-01-07 | 2010-11-30 | Apple Inc. | Application programming interfaces for scrolling operations |
| US8656311B1 (en) | 2007-01-07 | 2014-02-18 | Apple Inc. | Method and apparatus for compositing various types of content |
| US8010390B2 (en) * | 2007-06-04 | 2011-08-30 | Computer Sciences Corporation | Claims processing of information requirements |
| US8010391B2 (en) | 2007-06-29 | 2011-08-30 | Computer Sciences Corporation | Claims processing hierarchy for insured |
| US8000986B2 (en) | 2007-06-04 | 2011-08-16 | Computer Sciences Corporation | Claims processing hierarchy for designee |
| US8244558B2 (en) | 2008-01-18 | 2012-08-14 | Computer Sciences Corporation | Determining recommended settlement amounts by adjusting values derived from matching similar claims |
| US8416196B2 (en) | 2008-03-04 | 2013-04-09 | Apple Inc. | Touch event model programming interface |
| US8645827B2 (en) | 2008-03-04 | 2014-02-04 | Apple Inc. | Touch event model |
| US8717305B2 (en) | 2008-03-04 | 2014-05-06 | Apple Inc. | Touch event model for web pages |
| US9684521B2 (en) | 2010-01-26 | 2017-06-20 | Apple Inc. | Systems having discrete and continuous gesture recognizers |
| US8285499B2 (en) | 2009-03-16 | 2012-10-09 | Apple Inc. | Event recognition |
| US9311112B2 (en) | 2009-03-16 | 2016-04-12 | Apple Inc. | Event recognition |
| US8566045B2 (en) | 2009-03-16 | 2013-10-22 | Apple Inc. | Event recognition |
| US10216408B2 (en) | 2010-06-14 | 2019-02-26 | Apple Inc. | Devices and methods for identifying user interface objects based on view hierarchy |
| US9298363B2 (en) | 2011-04-11 | 2016-03-29 | Apple Inc. | Region activation for touch sensitive surface |
| US20140236857A1 (en) * | 2013-02-21 | 2014-08-21 | Bank Of America Corporation | Data Communication and Analytics Platform |
| US9733716B2 (en) | 2013-06-09 | 2017-08-15 | Apple Inc. | Proxy gesture recognizer |
| CN107818512B (zh) * | 2017-10-23 | 2021-01-26 | 平安科技（深圳）有限公司 | 产生保单批文的方法、装置、设备及计算机可读存储介质 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5535389A (en) * | 1993-01-26 | 1996-07-09 | International Business Machines Corporation | Business process objects with associated attributes such as version identifier |
| US5873067A (en) * | 1995-02-14 | 1999-02-16 | Kabushiki Kaisha Toshiba | Work flow system |
| US6094688A (en) * | 1997-01-08 | 2000-07-25 | Crossworlds Software, Inc. | Modular application collaboration including filtering at the source and proxy execution of compensating transactions to conserve server resources |
-
1998
- 1998-10-22 JP JP30069098A patent/JP4159674B2/ja not_active Expired - Lifetime
-
2001
- 2001-02-26 US US09/791,917 patent/US20010009033A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| US20010009033A1 (en) | 2001-07-19 |
| JP2000132394A (ja) | 2000-05-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4159674B2 (ja) | オブジェクト指向業務システムおよび方法 | |
| US10482022B2 (en) | Custom caching | |
| US6920456B2 (en) | Method, system, and program for maintaining information in database tables and performing operations on data in the database tables | |
| US9256655B2 (en) | Dynamic access of data | |
| US6484180B1 (en) | Accessing domain object data stored in a relational database system | |
| US6061689A (en) | Object aggregation representation of relational database rows having nontraditional datatypes | |
| US7698348B2 (en) | Extended database engine providing versioning and embedded analytics | |
| JP4594306B2 (ja) | 自己記述型ビジネスオブジェクト | |
| US7577934B2 (en) | Framework for modeling and providing runtime behavior for business software applications | |
| JP5065056B2 (ja) | ワークフローを処理するための方法、コンピュータ・プログラム、およびシステム（ワークフロー・システムへのデータ管理動作の統合） | |
| US7313575B2 (en) | Data services handler | |
| US6738975B1 (en) | Extensible distributed enterprise application integration system | |
| US7373633B2 (en) | Analytical application framework | |
| JP4571636B2 (ja) | サービス指向ビジネスフレームワークのサービス管理 | |
| US20040249867A1 (en) | Mining model versioning | |
| US10509632B2 (en) | Model augmentation in a model-driven application development environment | |
| US5890160A (en) | Object representation of relational database cells having nontraditional large object datatypes | |
| US7908290B2 (en) | Application development performed independent of system landscape | |
| US8140594B2 (en) | Advanced message mapping with sub-object key mapping | |
| CN111625548B (zh) | 查询方法、系统、装置和计算机可读介质 | |
| JP2002157386A (ja) | ワークフロー管理方法および装置並びにその処理プログラム並びにその処理プログラムを格納した記録媒体 | |
| US20050060309A1 (en) | Query objects | |
| Rosenthal et al. | Bringing Objects to the Enterprise without Losing Data Management | |
| JP2000148688A (ja) | 複数種類の情報処理が可能な環境下で統一的なユーザー権限管理を行うクライアントサーバーシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040511 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040611 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20050125 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050224 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20050328 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20050603 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080527 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080620 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080716 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110725 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110725 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120725 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120725 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130725 Year of fee payment: 5 |
|
| EXPY | Cancellation because of completion of term |