図面 (/)

技術 オブジェクト指向業務システムおよび方法

出願人 富士通株式会社
発明者 森崎雅稔吉田裕之
出願日 1998年10月22日 (20年1ヶ月経過) 出願番号 1998-300690
公開日 2000年5月12日 (18年7ヶ月経過) 公開番号 2000-132394
状態 特許登録済
技術分野 ストアードプログラム制御 特殊なプログラム実行装置 ストアードプログラム ストアードプログラム
主要キーワード 生成関係 コントローラベース 使用関係 向上アルゴリズム 既存部品 デイレクタ カスタマイズ性 シーケンシャルファイル
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2000年5月12日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

オブジェクト指向部品を組み合わせ、オブジェクト指向の特徴を活用して業務処理を行うことが課題である。

解決手段

ビジネスオブジェクト12のモデル群22を、ドメインオブジェクト23、オブジェクト管理24、制御オブジェクト25、およびサービスオブジェクト26に分類する。制御オブジェクト25は、クライアント11からの処理依頼受け取り、ドメインオブジェクト23、オブジェクト管理24、およびサービスオブジェクト26の協調関係を制御する。ドメインオブジェクト23は、ビジネスルールを保持し、オブジェクト管理24は、データベース13やシーケンシャルファイル14へのアクセスインタフェース実装する。

概要

背景

概要

オブジェクト指向部品を組み合わせ、オブジェクト指向の特徴を活用して業務処理を行うことが課題である。

ビジネスオブジェクト12のモデル群22を、ドメインオブジェクト23、オブジェクト管理24、制御オブジェクト25、およびサービスオブジェクト26に分類する。制御オブジェクト25は、クライアント11からの処理依頼受け取り、ドメインオブジェクト23、オブジェクト管理24、およびサービスオブジェクト26の協調関係を制御する。ドメインオブジェクト23は、ビジネスルールを保持し、オブジェクト管理24は、データベース13やシーケンシャルファイル14へのアクセスインタフェース実装する。

目的

効果

実績

技術文献被引用数
1件
牽制数
2件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

ビジネスルールを保持するドメインオブジェクトと、該ドメインオブジェクトを管理し、データアクセスインタフェース実装するオブジェクト管理とを有するオブジェクト手段と、前記ドメインオブジェクトとオブジェクト管理を用いて、前記ビジネスルールに対応する処理を実行する実行手段とを備えることを特徴とする業務システム

請求項2

前記オブジェクト管理は、前記ドメインオブジェクトの生成、削除、および保持のうち少なくとも1つの動作を行うことを特徴とする請求項1記載の業務システム。

請求項3

前記オブジェクト管理は、前記データアクセスの対象およびアクセス形態のうち少なくとも一方に適したインタフェースを実装し、前記ドメインオブジェクトと組み合わせて用いられることを特徴とする請求項1記載の業務システム。

請求項4

前記オブジェクト管理は、キャッシュおよび補助記憶装置のうち少なくとも一方に適したインタフェースを実装することを特徴とする請求項3記載の業務システム。

請求項5

前記オブジェクト管理は、オンライン処理バッチ処理、およびマスタメンテナンス処理のうち少なくとも1つに適したインタフェースを実装することを特徴とする請求項3記載の業務システム。

請求項6

前記オブジェクト手段は、データアクセスの対象およびアクセス形態のうち少なくとも一方に応じて複数のオブジェクト管理を有し、該複数のオブジェクト管理のうちの1つを前記ドメインオブジェクトと組み合わせることを特徴とする請求項1記載の業務システム。

請求項7

前記オブジェクト管理は、前記ドメインオブジェクトのキー属性の値を指定し、対応するドメインオブジェクトを返却するインタフェースを有することを特徴とする請求項1記載の業務システム。

請求項8

前記オブジェクト管理は、前記ドメインオブジェクトの検索条件を指定し、対応するドメインオブジェクトを順番に1つずつ返却するインタフェースを有することを特徴とする請求項1記載の業務システム。

請求項9

前記オブジェクト管理は、前記ドメインオブジェクトの検索条件を指定し、対応するドメインオブジェクトのすべての情報を一括返却するインタフェースを有することを特徴とする請求項1記載の業務システム。

請求項10

前記オブジェクト管理は、新規のドメインオブジェクトを1つずつ登録するインタフェースを有することを特徴とする請求項1記載の業務システム。

請求項11

前記オブジェクト管理は、新規のドメインオブジェクトをまとめて一括登録するインタフェースを有することを特徴とする請求項1記載の業務システム。

請求項12

前記オブジェクト管理は、前記ドメインオブジェクトを1つずつ更新するインタフェースを有することを特徴とする請求項1記載の業務システム。

請求項13

前記オブジェクト管理は、前記ドメインオブジェクトの検索条件を指定し、対応するドメインオブジェクトを順番に1つずつ返却し、返却されたドメインオブジェクトの変更後に、データベース一括更新するインタフェースを有することを特徴とする請求項1記載の業務システム。

請求項14

前記オブジェクト管理は、前記ドメインオブジェクトを保持し続け、該ドメインオブジェクトの取得要求を受け取ったとき、該ドメインオブジェクトを直ちに返却することを特徴とする請求項1記載の業務システム。

請求項15

前記オブジェクト管理は、複数のドメインオブジェクトを保持し続けるとき、メモリ効率に関する特定のアルゴリズムに従って、該複数のドメインオブジェクトを管理することを特徴とする請求項1記載の業務システム。

請求項16

前記オブジェクト管理は、処理対象となるすべてのドメインオブジェクトをあらかじめ取得しておき、ドメインオブジェクトの取得要求を受け取ったとき、要求されたドメインオブジェクトを直ちに返却することを特徴とする請求項1記載の業務システム。

請求項17

前記オブジェクト管理は、最初に指定されたキー属性の値を持つドメインオブジェクトから特定の順序で一定数のドメインオブジェクトをあらかじめ取得しておき、該一定数のドメインオブジェクトのうちの1つの取得要求を受け取ったとき、要求されたドメインオブジェクトを直ちに返却することを特徴とする請求項1記載の業務システム。

請求項18

前記オブジェクト手段は、前記ドメインオブジェクトとオブジェクト管理の協調関係を制御する制御オブジェクトをさらに有することを特徴とする請求項1記載の業務システム。

請求項19

前記オブジェクト手段は、前記ドメインオブジェクトにサービスを提供するサービスオブジェクトをさらに有することを特徴とする請求項1記載の業務システム。

請求項20

前記サービスオブジェクトは、ユーザが指定したビジネスルールを組み込むためのインタフェースを有することを特徴とする請求項19記載の業務システム。

請求項21

抽象度が高く粒度の小さい複数のオブジェクトを繋ぎ合わせて、アプリケーションに対応する処理を制御する制御オブジェクトを有するオブジェクト手段と、前記制御オブジェクトを用いて、前記アプリケーションに対応する処理を実行する実行手段とを備えることを特徴とする業務システム。

請求項22

コンピュータのためのオブジェクト指向プログラムを記録した記録媒体であって、ビジネスルールの手続きを有するドメインオブジェクトと、前記ドメインオブジェクトを管理し、前記ビジネスルールを実行する際のデータアクセスの手続きを有するオブジェクト管理とを含むプログラムを記録したコンピュータ読み取り可能な記録媒体。

請求項23

ビジネスルールを保持するドメインオブジェクトと、該ドメインオブジェクトを管理し、データアクセスのインタフェースを実装するオブジェクト管理とを分離し、前記ドメインオブジェクトとオブジェクト管理を用いて、前記ビジネスルールに対応する処理を実行し、処理結果を通知することを特徴とする業務処理方法。

技術分野

0001

本発明は、流通業等において、伝票商品等の資源に関する情報を管理し、必要な業務を統合する業務システムおよびその方法に関する。

0002

近年、主として流通業において、受注伝票の起票、商品在庫の管理、出荷伝票の作成、請求書発行入金の受付、受注伝票の発行等の処理業務を統合した伝票処理システムが導入されている。このような情報処理システムは、ERP(enterprise resource planning)システムとも呼ばれている。

0003

従来、このような伝票処理システムを始めとする種々のビジネスアプリケーションシステムの構築には、オブジェクト指向は不向きであるとされていた(日経コンピュータ,1998.6.22,pp.209−217)。オブジェクトには、通常、データとそのデータに対する手続き(メソッド)がカプセル化されている。

0004

ビジネスプロセスをオブジェクト指向により分析し、オブジェクト部品によりモデルを構築したとしても、従来のシステムでは、実際には純粋なオブジェクトは全体の一部分に過ぎず、他のオブジェクトはデータを持たない退化型オブジェクトである。このため、結果として、オブジェクト指向の長所が十分に活かされず、実問題のモデル化の容易さ、部品の再利用、データと手続きのカプセル化、カスタマイズ性の向上、保守性の向上、品質の向上、および生産性の向上が達成されていなかった。

0005

例えば、伝票処理業務をオブジェクト指向分析する際に、オブジェクト間境界をどこに設定して、各オブジェクトをどのような粒度で設計すればよいかが非常に曖昧である。ここで、オブジェクト間の境界とは、オブジェクトが保持するデータおよび手続きの境界に対応し、オブジェクトの粒度とは、データおよび手続きの大きさに対応する。

0006

また、オブジェクトの再利用を容易にするための抽象化のレベルについても適当な指針がなく、オブジェクト間のインタラクションが単純にならない。このため、ビジネスプロセスに応じてオブジェクトを組み替えられる程の柔軟性が確保されていない。また、オブジェクトの抽象化がうまくできないため、実装言語の特徴である継承や多態を効果的に使えないという問題もある。

0007

さらに、伝票処理業務に不可欠なリレーショナルデータベースシステムでは、レコード一意性保証されているのに対して、オブジェクトの世界では、同じデータを持つオブジェクトが複数存在することが許容されている。このため、リレーショナルデータベースシステムとオブジェクトの世界との境界の設計が難しく、データの整合性の保証や、複数のオブジェクトにまたがるトランザクション制御の実現が困難である。

0008

本発明の課題は、オブジェクト指向部品を組み合わせて構築され、オブジェクト指向の特徴を活用する業務システムおよびその方法を提供することである。

課題を解決するための手段

0009

図1は、本発明の業務システムの原理図である。図1の業務システムは、オブジェクト手段1と実行手段2を備える。オブジェクト手段1は、ビジネスルールを保持するドメインオブジェクト3と、ドメインオブジェクト3を管理し、データアクセスインタフェースを実装するオブジェクト管理4とを有する。実行手段2は、ドメインオブジェクト3とオブジェクト管理4を用いて、ビジネスルールに対応する処理を実行する。

0010

ドメインオブジェクト3が保持するビジネスルールは、業務処理手順に基づいて作成される手続きに対応し、ドメインオブジェクト3のデータの設定や演算ロジックに関するプリミティブな処理を記述している。また、オブジェクト管理4は、ドメインオブジェクト3とは別のオブジェクトであり、オブジェクト管理4が保持するデータアクセスのインタフェースは、補助記憶装置に格納されたデータベースシーケンシャルファイル等へのアクセス手続きに対応する。

0011

このように、データアクセスのインタフェースを保持するオブジェクトを、ビジネスルールを保持するオブジェクトから分離することにより、ビジネスルールとデータアクセスのインタフェースをそれぞれ独立に実装することができる。これにより、各オブジェクトの抽象度が高められ、その粒度も小さくなるため、オブジェクト間のインタラクションを単純化することが可能になる。また、ビジネスルールとデータアクセスのインタフェースが独立に部品化されるため、いずれか一方を取り替えることができ、システムの柔軟性が向上する。

0012

さらに、オブジェクト管理4がデータアクセスに関する処理を担当するため、ドメインオブジェクト3は、データベース等のアクセス対象を区別した実装を行う必要がない。このように、オブジェクト管理4は、ドメインオブジェクト3からデータベース等を隠蔽しており、データベースとオブジェクトの世界との境界が明確になる。

0013

オブジェクト管理4は、例えば、データアクセスの対象およびアクセス形態のうち少なくとも一方に適したインタフェースを実装し、ドメインオブジェクト3と組み合わせて用いられる。例えば、図1のオブジェクト手段1は、後述する図28メモリ82に対応し、図1の実行手段2は、図28のCPU(中央処理装置)81に対応する。

発明を実施するための最良の形態

0014

以下、図面を参照しながら、本発明の実施の形態を詳細に説明する。本実施形態においては、組み合わせて使用する各オブジェクト部品の粒度や、ビジネスアプリケーションとクライアント画面、あるいはビジネスアプリケーションとデータベースシステムとの境界面に位置するオブジェクトの機能や仕組みを明確化し、伝票処理業務全体をオブジェクトの集合表現する。その際、一定のパターンに当てはめて部品の抽出および設計を行うことで、オブジェクト間のリンク会話のインタフェースを単純化する。

0015

具体的には、ビジネスルールを実装する場所と、データアクセス等に関する性能を実現する仕組みを実装する場所と、トランザクションの範囲を定義する場所とを、オブジェクト部品として明確に分離し、オブジェクト部品間の標準的な関係と標準的な会話の手順を設定する。そして、各々の実装の変更を独立して行えるようにする。

0016

個々のオブジェクト部品は、あらかじめ決められた分析パターンによって一定の抽象度や粒度で設計され、これらの部品の中味およびインタフェースはあらかじめ決められた設計パターンおよび実装パターンに基づいて構築される。このため、部品の組み替えによるアプリケーション修正や、部品内部の変更によるアプリケーションの修正が容易である。

0017

また、ビジネスルールの変更、トランザクションの範囲の変更、およびデータベースアクセスキャッシュへの要件の変更が生じた際に、修正対象の部品を容易に特定でき、対象外の部品に影響を与えることなく、それを修正することが可能である。また、オブジェクトの継承による新たな部品開発が容易で、新規部品と既存部品の組み合わせが良好に行える。

0018

図2は、本実施形態の業務システムの構成図である。図2の業務システムは、ワークステーション等のコンピュータを用いて構成され、クライアント11、ビジネスオブジェクト12、データベース13、およびシーケンシャルファイル14を備える。データベース13とシーケンシャルファイル14は、それぞれ、補助記憶装置に格納される。

0019

クライアント11は、ユーザインタフェースとなる入出力装置に対応し、ビジネスオブジェクト12は、オブジェクト部品の集合に対応する。これらのオブジェクト部品は、システムのメモリ上に展開される。また、データベース13としては、例えば、リレーショナルデータベースが用いられる。

0020

ビジネスオブジェクト12は、ディレクタ21とモデル群22を含む。ディレクタ21は、通信層ミドルウェアであって、クライアント11とモデル群22の間の通信に関する制御を行う。モデル群22のオブジェクトは、その役割によって、ドメインオブジェクト23、オブジェクト管理(オブジェクトマネージャ)24、制御オブジェクト25、およびサービスオブジェクト26に分類される。

0021

ドメインオブジェクト23は、業務分析の際に、伝票や商品等の“物品”として抽出されたクラスに対応する。ここで、クラスとはオブジェクトの構造の定義に対応する。クラスにより定義された構造を持つ具体的なオブジェクトは、インスタンスと呼ばれる。

0022

また、ドメインオブジェクト23は、保持するデータに関するビジネスルールと手続きの実行手順を保持する。このビジネスルールは、業務処理手順を表すビジネスロジックに基づいて作成される手続きであり、主として値の設定や演算ロジックに関するプリミティブな処理を記述している。また、ドメインオブジェクト23は、例外通知の受信や状態遷移も行う。

0023

オブジェクト管理24は、データベース13やシーケンシャルファイル14等への永続化が必要なドメインオブジェクト23を管理するために用意されたクラスであり、対応するドメインオブジェクト23と組み合わせて用いられる。ここで、永続化とは、補助記憶装置にデータを保存することを表す。

0024

オブジェクト管理24は、ドメインオブジェクト23の生成元でもあり、ドメインオブジェクト23の生成、削除、集約、再利用を行い、ドメインオブジェクト23と同じインタフェースを備える。

0025

また、オブジェクト管理24は、外部のデータにアクセスする際のプロキシ代理)でもあり、入出力ロジックの手続きを保持する。この入出力ロジックは、アクセス対象の種類やアクセス形態に応じた処理を記述しており、ビジネスルールから分離されている。

0026

アクセス対象としては、データキャッシュや様々な種類の補助記憶装置が考えられる。データキャッシュは、ドメインオブジェクトをメモリ上に保持し続け、そのオブジェクトが参照されたとき、補助記憶装置にアクセスせずに、そのオブジェクトの情報を直ちに返却するメカニズムを表す。

0027

また、アクセス形態は、アクセス対象のデータ構造等によって変化する。オブジェクト管理24は、例えば、データベース13にはSQLによりアクセスし、データの検索、追加、削除、更新等の処理を行う。また、シーケンシャルファイル14にはシーケンシャルにアクセスし、リードライト処理を行う。

0028

さらに、オブジェクト管理24は、システムがオンライン処理バッチ処理、およびマスタメンテナンス処理のうちのいずれを行うかに応じて、異なる性能向上アルゴリズムを用いた入出力処理を行う。ここで、マスタメンテナンス処理は、ドメインオブジェクトの静的なデータを更新する処理等に対応し、性能向上アルゴリズムとしては、データキャッシュやデータベースアクセスのアルゴリズムが用いられる。

0029

様々な入出力ロジックの組み合わせは、通常、オブジェクト管理24のサブクラスにより指定され、処理に応じて特定のサブクラスのオブジェクト管理24が用いられる。

0030

制御オブジェクト25は、業務分析の際に、“人手”、“業務”、“アプリケーション”,“画面”等として抽出されたクラスに対応し、ドメインオブジェクト23、オブジェクト管理24、およびサービスオブジェクト26へのリンク関係を保持する。また、ドメインオブジェクト23間の協調関係に関するビジネスルールと手続きの実行手順を保持する。

0031

また、ディレクタ21を介して入力されるクライアント11からの処理依頼を、保持しているリンク関係に基づいて処理する。このとき、ビジネスルールに基づいてオブジェクトの協調関係を制御し、処理結果をクライアント11に通知する。

0032

これにより、制御オブジェクト25は、抽象度が高く粒度の小さい複数のオブジェクトを繋ぎ合わせて、アプリケーションとしての処理の流れを制御し、複数のデータベースにまたがるようなトランザクションのセッションの範囲を規定する。そして、処理中に生じたエラー出口処理を集中的に行う。

0033

さらに、トランザクションの管理、モデルの例外通知の受信、クライアント11とモデル群22の間の型変換およびプロトコル変換、データの組立/分解等も行う。

0034

サービスオブジェクト26は、ドメインオブジェクト23と類似のクラスに対応するが、補助記憶装置への永続化を必要とせず、対応するオブジェクト管理24を持たない。サービスオブジェクト26は、主として、他のオブジェクトから依頼された特定の機能をサービスとして実行する。

0035

また、ドメインオブジェクト23が業種に共通するビジネスルールを保持する場合、ドメインオブジェクト23から独立しているサービスオブジェクト26を用いて、システムをカスタマイズすることができる。この場合、カスタマイズを前提としたインタフェースをサービスオブジェクト26に持たせておき、個別のユーザがビジネスルールを後から組み込めるようにする。

0036

ビジネスオブジェクト12における破線の矢印は、オブジェクトの生成関係を表す。オブジェクト管理24、制御オブジェクト25、およびサービスオブジェクト26は、ディレクタ21により生成され、ドメインオブジェクト23は、対応するオブジェクト管理24により生成される。

0037

また、ビジネスオブジェクト12における実線の矢印は、オブジェクト間のメッセージの流れを表す。メッセージは、クライアント11に対して公開されているメソッドに対応し、メッセージは、論理テーブルへの照会に対応し、メッセージは、ドメインオブジェクト23のデータの設定に対応する。また、メッセージは、ドメインオブジェクト23の生成、更新、削除等の依頼に対応し、メッセージは、サービスオブジェクト26へのサービス依頼に対応する。

0038

このように、ドメインオブジェクト23は、ビジネスルールを実装し、オブジェクト管理24は、そのビジネスルールに対応するデータの入出力ロジックを実装し、制御オブジェクト25は、それらの協調関係をトランザクションとして制御するビジネスルールを実装する。したがって、入出力ロジックがビジネスルールから明確に分離され、オブジェクト管理24を取り替えることで、1つのビジネスルールに対して多様な入出力ロジックを組み合わせることが可能になる。

0039

これに対して、従来のシステムでは、ビジネスルールと入出力ロジックの境界が明確でなく、これらが1つのオブジェクトに埋め込まれていることが多い。このため、ビジネスルールおよび入出力ロジックの一方を追加/削除するような操作が難しいという問題があった。

0040

次に、図3は、ディレクタ21、ドメインオブジェクト23、オブジェクト管理24、および制御オブジェクト25のクラスのアーキテクチャを示している。図3階層関係において、デイレクタベースクラス31は、ディレクタ21の上位のクラス(スーパークラス)であり、モデルベースクラス32は、コントローラベースクラス33、ドメインモデルベースクラス34、オブジェクトマネージャベースクラス35の上位のクラスである。また、コントローラベースクラス33、ドメインモデルベースクラス34、およびオブジェクトマネージャベースクラス35は、それぞれ、制御オブジェクト25、ドメインオブジェクト23、およびオブジェクト管理24の上位のクラスである。

0041

一般に、クラス間の階層関係においては、下位のクラスが上位のクラスの定義を継承するため、制御オブジェクト25、ドメインオブジェクト23、およびオブジェクト管理24は、それぞれ、コントローラベースクラス33、ドメインモデルベースクラス34、オブジェクトマネージャベースクラス35の定義に基づいて生成される。

0042

ところで、伝票処理業務の場合、業務システムの基本機能として、図4に示すような機能が要求される。図4では、“受注”、“出荷”、“与信”、および“在庫”が基本機能として存在し、“受注”は他の3つの機能を起動し、“出荷”は“在庫”を起動する。これらの基本機能は、伝票または商品に対応して設けられており、オブジェクトのクラスとして利用することができる。

0043

“受注”は、“EDI(electronic data interchange )受注”、“直送受注”、“見積受注”、および“一般受注”の各機能を含み、“出荷”は、“出荷予定”、“出荷確定”、“分納出荷”、および“ピッキング指示”の各機能を含む。また、“与信”は、“与信警告”および“与信更新”の各機能を含み、“在庫”は、“在庫引当引落)”、“ロット管理”、“倉庫移動”、“棚卸”、“荷姿単位管理”、および“在庫評価”の各機能を含む。

0044

このような基本機能を実現するために、例えば、図5に示すようなクラスが設けられる。ここでは、受注制御41、出荷制御42、受注明細管理43、受注明細44、出荷明細管理45、出荷明細46、在庫サービス47、与信管理48、与信49、在庫管理50、および在庫51がクラスとして設けられている。

0045

このうち、受注制御41および出荷制御42は、制御オブジェクトのクラスに対応し、受注明細管理43、出荷明細管理45、与信管理48、および在庫管理50は、オブジェクト管理のクラスに対応する。また、受注明細44、出荷明細46、与信49、および在庫51は、ドメインオブジェクトのクラスに対応し、在庫サービス47は、サービスオブジェクトのクラスに対応する。

0046

受注制御41は、EDI受注入力()、見積受注入力()、一般受注入力()、および直送受注入力()の各メソッドを保持し、出荷制御42は、出荷予定入力()、分納出荷指示()、ピッキング指示()、出荷確定()の各メソッドを保持する。

0047

また、在庫サービス47は、在庫引当()、倉庫移動()、荷姿単位別照会()、ロット別照会()、棚卸入力()、および在庫評価()の各メソッドを保持し、与信49は、与信残高更新()および与信警告チェック()の各メソッドを保持する。このうち、記号“+”が付加されたメソッドは、OMT(object modeling technique )表記パブリックなメソッドに対応する。

0048

また、実線の矢印はリンク関係を表し、例えば、受注制御41は受注明細管理43へのリンクを保持している。破線の矢印は使用関係を表し、例えば、受注明細44は与信49および在庫サービス47の機能を必要に応じて使用する。◇印の付加された実線は集約関係を表し、例えば、受注明細管理43のクラスの1つのオブジェクトは、受注明細44のクラスの1つまたは複数のオブジェクトと相互にリンク関係を持っている。

0049

リンク関係は、例えば、リンク元のオブジェクトがリンク先のオブジェクトを指すポインタを保持することにより設定される。相互リンク関係の場合は、2つのオブジェクトが、互いに相手のオブジェクトを指すポインタを保持している。

0050

実際には、これらのクラス以外にも、商品、商品管理、得意先、得意先管理等の多数のクラスが設けられ、それらが互いにリンク関係や使用関係で関係付けられて、業務システムが構築される。また、一部のクラスのみを組み合わせることにより、部分的な機能を実現する受注入力システム、出荷指示システム、売上計上システム等の伝票処理システムを構築することもできる。

0051

次に、図6から図19までを参照しながら、オブジェクトのリンク関係の例と、オブジェクトの設計に用いられた分析パターンの例について説明する。設計パターンおよび実装パターンは、分析パターンより具体的であるが、基本的な構造は分析パターンと同様である。

0052

図6は、オブジェクト間メッセージを説明するためのオブジェクトのリンク関係を示している。一般に、オブジェクトが他のオブジェクトにメソッドの実行を要求する場合は、そのメソッドの名称を含むメッセージを要求先のオブジェクトに送信する。

0053

図6において、受注明細44は、データのリード/ライトを伴うジャーナル系のドメインオブジェクトに対応し、商品61は、主としてデータのリードのみに用いられるマスタ系のドメインオブジェクトに対応する。また、商品管理62は、商品61を管理するオブジェクト管理である。受注明細44は、商品61と商品管理62を指す単方向のリンクを保持しており、商品管理62と商品61は、上述したような集約関係を持つ。

0054

ドメインオブジェクトは、“物品”として抽出さたクラスに対応するので、“物品”の属性データとメソッドを保持している。属性は、CRC(class responsibility & collaboration)カード分析やデータベースの項目から導かれる。CRCカード分析は、システム化対象の業務をオブジェクト指向分析する方法の1つであり、クラス毎責務とその協調クラスを書き込むCRCカードを用いて、属性、メソッド、クラス間のリンク関係等を抽出することができる。また、ドメインオブジェクトのメソッドは、属性値の設定、参照、ビジネスルール、計算式等に対応する。

0055

ここでは、受注明細44は、“商品コード”を属性として保持し、“Set商品コード”、“Set数量”、および“Get商品”をメソッドとして保持している。商品61は、“商品名”、“メーカー”、および“荷姿”を属性として保持し、“Get商品名”、“Getメーカー”、および“Get荷姿”をメソッドとして保持している。商品管理62は、“Get商品”および“Get商品名”をメソッドとして保持している。商品61が保持する“Get商品名”、“Getメーカー”、および“Get荷姿”は、ドメインオブジェクトのビジネスルールに対応する。

0056

図7は、これらのオブジェクトが行う動作のパターンを示している。ここでは、商品コードの設定、数量の設定、商品オブジェクトの取得、メーカー取得、荷姿取得、および商品名取得の6つのパターンが示されている。

0057

まず、商品コードの設定において、制御オブジェクトがSet商品コード(コード)のメッセージを受注明細44に送信すると、受注明細44は、Set商品コード(コード)を実行し、与えられた商品コードを設定する。次に、受注明細44は、Get商品名(コード)のメッセージを商品管理62に送信し、商品管理62は、Get商品名(コード)を実行して、商品コードに対応する商品名を受注明細44に返送する。このように、受注明細44は、商品コードを設定したとき、対応する商品名を商品管理62から自動的に取得する。

0058

次に、数量の設定において、制御オブジェクトがSet数量(個数)のメッセージを受注明細44に送信すると、受注明細44は、Set数量(個数)を実行し、与えられた個数を設定する。

0059

次に、商品オブジェクトの取得において、制御オブジェクトがGet商品()のメッセージを受注明細44に送信すると、受注明細44は、Get商品(コード)のメッセージを商品管理62に送信する。商品管理62は、Get商品(コード)を実行して、対応する商品61(インスタンス)の情報を受注明細44に返送し、受注明細44は、その情報を制御オブジェクトに返送する。以後、制御オブジェクトは、返送された情報に基づいて、商品61にメッセージを送信することができる。

0060

次に、メーカー取得において、制御オブジェクトがGetメーカー()のメッセージを商品61に送信すると、商品61は、Getメーカー()を実行し、メーカー名を制御オブジェクトに返送する。

0061

次に、荷姿取得において、制御オブジェクトがGet荷姿()のメッセージを商品61に送信すると、商品61は、Get荷姿()を実行し、荷姿を制御オブジェクトに返送する。

0062

次に、商品名取得において、制御オブジェクトがGet商品名()のメッセージを商品61に送信すると、商品61は、Get商品名()を実行し、商品名を制御オブジェクトに返送する。

0063

このように、ジャーナル系のドメインオブジェクトは、マスタ系のドメインオブジェクトを自力で取得し、そのオブジェクトと会話することができる。また、制御オブジェクトは、ジャーナル系のドメインオブジェクトまたはオブジェクト管理を介してマスタ系のドメインオブジェクトを取得し、そのオブジェクトから必要な情報を取得することができる。

0064

図7のパターンでは、商品管理62によるデータのアクセス形態が規定されていないため、リレーショナルデータベースかシーケンシャルファイルかに依らず、また、オンライン処理かバッチ処理かに依らずに、このパターンを適用することができる。実際に用いられる入出力ロジックは、商品管理62のサブクラスとしてコンパイル時に指定され、実行プログラムに反映される。

0065

図8は、サービスオブジェクトを説明するためのオブジェクトのリンク関係を示している。サービスオブジェクトは、ドメインオブジェクトから手続き部分を分離独立させたクラスに相当し、単独でも部品となり得る。また、複数種類のドメインオブジェクトにサービスを提供できる汎用あるいは多数のインタフェースを持つ。また、ビジネスルールの実行時に必要なマスタ系のドメインオブジェクトを参照することができる。さらに、補助記憶装置への永続化が必要な属性を持たず、オブジェクト管理も必要としない。

0066

図8において、売上単価63は、サービスオブジェクトであり、季節単価64は、マスタ系のドメインオブジェクトである。受注明細管理43は、売上単価63を指すリンクを保持し、売上単価63は、季節単価64および商品61を指すリンクを保持している。また、受注明細管理43と受注明細44は集約関係を持っており、受注明細44は、売上単価63を使用する。このように、ドメインオブジェクトが使用するサービスオブジェクトは、対応するオブジェクト管理により保持されている。

0067

ここでは、受注明細管理43は、“Get売上単価”をメソッドとして保持し、受注明細44は、“商品コード”を属性として保持し、“単価決定”をメソッドとして保持している。

0068

売上単価63は、“Get単価”、“Check手入力”、“Get季節単価”、および“Get標準単価”をメソッドとして保持し、季節単価64は、“商品コード”、“期間”、および“単価”を属性として保持し、“Get単価”をメソッドとして保持している。商品61は、“商品コード”および“標準単価”を属性として保持し、“Get単価”をメソッドとして保持している。

0069

図9は、これらのオブジェクトが行う動作のパターンを示している。ここでは、単価決定依頼のパターンが示されている。まず、制御オブジェクトが単価決定()のメッセージを受注明細44に送信すると、受注明細44は、Get売上単価()のメッセージを受注明細管理43に送信し、Get単価(明細)のメッセージを売上単価63に送信する。受注明細管理43は、Get売上単価()を実行し、売上単価63は、Get単価(明細)を実行する。

0070

このとき、売上単価63は、Check手入力()を実行し、Get単価()のメッセージを季節単価64および商品61に送信する。季節単価64および商品61は、Get単価()を実行して、対応する単価を売上単価63に返送し、売上単価63は、それを受注明細44に返送する。

0071

図10は、オブジェクト管理によるインスタンスの管理を説明するためのオブジェクトのリンク関係を示している。オブジェクト管理は、ドメインオブジェクトのインスタンスの生成(GetNew)、取得(GetOne)、追加(InsertOne)、更新(UpdateOne)の各インタフェースを有し、これらのインタフェースはすべてのオブジェクト管理で統一されている。

0072

“GetOne”は、ドメインオブジェクトのキー属性を指定して、対応する1つのインスタンスをキャッシュまたは補助記憶装置から取得し、そのインスタンスの情報を返却する。“InsertOne”は、新規に生成されたドメインオブジェクトのインスタンスを1つずつ登録する。“UpdateOne”は、既存のドメインオブジェクトのインスタンスを1つずつ更新する。

0073

オブジェクト管理は、メモリリーク対策、インスタンスの再利用、インスタンスの一意性保持、データキャッシュのメカニズムを隠蔽している。データキャッシュのメカニズムは、生成/取得されたドメインオブジェクトをメモリ上に保持し続け、そのオブジェクトと同じキー属性を指定する“GetOne”に対しては、補助記憶装置にアクセスせずに、そのオブジェクトの情報を返却する。また、オブジェクト管理は、固有の属性やビジネスルールを内部に持たないため、実装パターンの適用率は100%である。

0074

図10において、得意先65は、マスタ系のドメインオブジェクトであり、得意先管理66は、得意先65のオブジェクト管理であり、得意先マスタメンテ67は、得意先65のメンテナンスを行う制御オブジェクトである。得意先マスタメンテ67は、得意先65および得意先管理66を指すリンクを保持し、得意先管理66と得意先65は集約関係を持っている。

0075

ここでは、得意先管理66は、“GetNew”、“InsertOne”、“GetOne”、および“UpdateOne”をメソッドとして保持し、得意先65は、“得意先コード”を属性として保持し、“Set得意先コード”および“Set得意先名”をメソッドとして保持している。得意先マスタメンテ67は、“新規作成”、“Set項目”、“登録”、および“更新”をメソッドとして保持している。

0076

図11は、これらのオブジェクトが行う動作のパターンを示している。ここでは、得意先追加と得意先修正の各パターンが示されている。これらのパターンは、必要な回数だけループ処理として繰り返される。

0077

得意先追加において、まず、得意先マスタメンテ67は、新規作成()のメッセージを受け取ると、新規作成()を実行し、GetNew()のメッセージを得意先管理66に送信する。得意先管理66は、GetNew()を実行して、得意先65のインスタンスを生成し、その情報を得意先マスタメンテ67に返送する。

0078

次に、得意先マスタメンテ67は、Set項目(“得意先コード”,code)のメッセージを受け取ると、Set項目(“得意先コード”,code)を実行し、Set得意先コード(code)のメッセージを得意先65に送信する。そして、得意先65は、Set得意先コード(code)を実行して、得意先コードを設定する。

0079

次に、得意先マスタメンテ67は、登録()のメッセージを受け取ると、登録()を実行し、InsertOne(得意先インスタンス)のメッセージを得意先管理66に送信する。そして、得意先管理66は、InsertOne(得意先インスタンス)を実行し、データベースに得意先65を追加する。

0080

また、得意先修正において、まず、得意先マスタメンテ67は、検索(得意先コード)のメッセージを受け取ると、検索(得意先コード)を実行し、GetOne(得意先コード)のメッセージを得意先管理66に送信する。得意先管理66は、GetOne(得意先コード)を実行して、得意先65のインスタンスをデータベースから取得し、その情報を得意先マスタメンテ67に返送する。

0081

次に、得意先マスタメンテ67は、Set項目(“得意先名”,name)のメッセージを受け取ると、Set項目(“得意先名”,name)を実行し、Set得意先名(name)のメッセージを得意先65に送信する。そして、得意先65は、Set得意先名(name)を実行して、得意先名を設定する。次に、得意先マスタメンテ67は、更新()のメッセージを受け取ると、更新()を実行し、UpdateOne(得意先インスタンス)のメッセージを得意先管理66に送信する。そして、得意先管理66は、UpdateOne(得意先インスタンス)を実行し、データベースに登録されている得意先65を更新する。図12は、オブジェクト管理による永続化先の隠蔽を説明するためのオブジェクトのリンク関係を示している。永続化先の補助記憶装置におけるデータ構造によってオブジェクト管理の実装(実行プログラム)は異なるが、ドメインオブジェクトのインスタンスの生成、取得、および追加のインタフェースは、異なるデータ構造の間で統一されている。

0082

データ構造としては、上述のリレーショナルデータベースとシーケンシャルファイルのほかに、CSV(comma separated value )形式ファイルも用いられる。ドメインオブジェクト側のインタフェースは永続化先のデータ構造に依存しないため、制御オブジェクトではそれらを区別した実装を行う必要がない。

0083

図12において、EDI受注明細68は、回線を介した受注の受注明細に対応するCSV系のドメインオブジェクトであり、EDI受注明細管理69は、EDI受注明細68のオブジェクト管理である。EDI受注制御70は、EDI受注明細管理69および受注明細管理43を指すリンクを保持し、EDI受注明細管理69とEDI受注明細68は集約関係を持っている。また、EDI受注制御70は、EDI受注明細68と受注明細44を使用し、受注明細44は、EDI受注明細68を使用する。

0084

ここでは、EDI受注明細管理69は、“Get”をメソッドとして保持し、EDI受注制御70は、“受注開始”をメソッドとして保持し、EDI受注明細68は、“Get商品コード”、“Get数量”、および“Get受注番号”をメソッドとして保持している。受注明細管理43は、“GetNew”および“InsertOne”をメソッドとして保持し、受注明細44は、“伝票番号”および“明細番号”を属性として保持し、“Set商品コード”、“Set数量”、および“Set受注番号”をメソッドとして保持している。

0085

図13は、これらのオブジェクトが行う動作のパターンを示している。ここでは、シーケンシャルファイルの受注情報からリレーショナルデータベースの受注ジャーナルを作成するパターンが示されている。このパターンは、必要な回数だけループ処理として繰り返される。このパターンは、単なるデータ移行ではなく、EDI受注明細68および受注明細44のクラスのビジネスルールに対応する。

0086

まず、EDI受注制御70は、受注開始()のメッセージを受け取ると、受注開始()を実行し、Get()のメッセージをEDI受注明細管理69に送信する。EDI受注明細管理69は、Get()を実行して、シーケンシャルファイルからEDI受注明細68のインスタンスを取得し、その情報をEDI受注制御70に返送する。

0087

次に、EDI受注制御70は、GetNew()のメッセージを受注明細管理43に送信し、受注明細管理43は、GetNew()を実行して、受注明細44のインスタンスを生成し、その情報をEDI受注制御70に返送する。

0088

次に、EDI受注制御70は、Set(EDI受注明細)のメッセージを受注明細44に送信し、受注明細44は、Set(EDI受注明細)を実行する。そして、Get商品コード()、Get数量()、およびGet受注番号()のメッセージをEDI受注明細68に送信し、EDI受注明細68は、商品コード、数量、および受注番号を受注明細44に返送する。受注明細44は、Set商品コード()、Set数量()、およびSet受注番号()を実行して、返送された情報を設定する。

0089

次に、EDI受注制御70は、InsertOne(受注明細)のメッセージを受注明細管理43に送信し、受注明細管理43は、InsertOne(受注明細)を実行して、受注明細44をデータベースに追加する。

0090

図14は、オブジェクト管理によるインスタンスの一意性の保証とライフサイクル制御を説明するためのオブジェクトのリンク関係を示している。オブジェクト管理は、生成したドメインオブジェクトのインスタンスを集約して保持しており、同じキーを持つマスタ系のドメインオブジェクトのインスタンスが二重生成されることを防止している。これにより、ドメインオブジェクトのデータの整合性が保証される。

0091

これに対して、従来のシステムでは、インスタンスの一意性が必ずしも保証されておらず、同じキーを持つインスタンスが二重生成されることを許していた。このため、データ更新の際の整合性が保証されないという問題があった。

0092

また、各ドメインオブジェクトは、上述したドメインモデルベースクラスから継承したリファレンスカウンタを保持しており、このリファレンスカウンタはオブジェクト管理により制御される。リファレンスカウンタは、オブジェクトの正しいライフサイクルを実現するために広く用いられており、そのオブジェクトをリンク関係で保持している他のオブジェクトの数を保持します。

0093

ドメインオブジェクトをリンク関係で保持する制御オブジェクト等が、そのドメインオブジェクトの解放をオブジェクト管理に依頼したとき、リファレンスカウンタの値が1であれば、オブジェクト管理は、ドメインオブジェクトを直ちにメモリ上から解放する。しかし、リファレンスカウンタの値が2以上であれば、オブジェクト管理は、その値を1だけ減算し、ドメインオブジェクトをメモリ上に残す。

0094

このようなオブジェクト管理と設計パターンの徹底によって、インスタンスの生成、削除に起因するメモリリークとメモリエラーが防止される。また、インスタンスの一意性の保証とリファレンスカウンタによって、データベースとの通信回数が削減される。

0095

図14において、受注伝票71は、ジャーナル系のドメインオブジェクトであり、受注伝票管理72は、受注伝票71のオブジェクト管理である。また、納入先73は、マスタ系のドメインオブジェクトであり、納入先管理74は、納入先73のオブジェクト管理である。

0096

受注伝票管理72は、納入先管理74を指すリンクを保持し、受注制御41は、受注伝票管理72を指すリンクを保持している。受注伝票管理72と受注伝票71は集約関係を持っており、納入先管理74と納入先73も集約関係を持っている。さらに、受注伝票71と受注明細44も集約関係を持っており、1つの受注伝票71のインスタンスは、1つ以上の受注明細44のインスタンスとリンクされている。また、受注制御41は、受注伝票71および受注明細44を使用し、受注明細44は、受注伝票管理72および納入先73を使用する。

0097

ここでは、受注伝票管理72は、“GetNew”をメソッドとして保持し、受注伝票71は、“Get”をメソッドとして保持し、受注制御41は、“新規起票”および“項目設定”をメソッドとして保持する。受注明細44は、“明細番号”を属性として保持し、“Set商品コード”、“Set数量”、および“Set納入先”をメソッドとして保持している。納入先管理74は、“GetOne”をメソッドとして保持し、納入先73は、“納入先コード”を属性として保持し、“Get納入先名”をメソッドとして保持している。

0098

図15は、これらのオブジェクトが行う動作のパターンを示している。ここでは、受注伝票71を起票し、受注明細44の項目を設定するパターンが示されている。

0099

まず、受注制御41は、新規起票()のメッセージを受け取ると、新規起票()を実行し、GetNew()のメッセージを受注伝票管理72に送信する。受注伝票管理72は、GetNew()を実行して、受注伝票71のインスタンスを生成し、その情報を受注制御41に返送する。

0100

次に、受注制御41は、Get()のメッセージを受注伝票71に送信し、受注伝票71は、Get()を実行して、受注明細44の1件目のインスタンスを取得し、その情報を受注制御41に返送する。

0101

次に、受注制御41は、項目設定()のメッセージを受け取ると、項目設定()を実行し、Set商品コード(code)のメッセージを受注明細44に送信する。そして、受注明細44は、Set商品コード(code)を実行して、商品コードを設定する。

0102

次に、受注制御41は、項目設定()のメッセージを受け取ると、項目設定()を実行し、Set数量(count)のメッセージを受注明細44に送信する。そして、受注明細44は、Set数量(count)を実行して、数量を設定する。

0103

次に、受注制御41は、項目設定()のメッセージを受け取ると、項目設定()を実行し、Set納入先(001)のメッセージを受注明細44に送信する。そして、受注明細44は、Set納入先(001)を実行して、納入先を設定する。

0104

このとき、受注明細44は、GetOne(001)のメッセージを納入先管理74に送信する。そして、納入先管理74は、GetOne(001)を実行して、納入先コード“001”に対応する納入先73のインスタンスをデータベースから取得し、その情報を受注明細44に返送する。次に、受注明細44は、Get納入先名()のメッセージを納入先73に送信する。そして、納入先73は、Get納入先名()を実行して、納入先名を取得し、それを受注明細44に返送する。

0105

次に、受注制御41は、Get()のメッセージを受注伝票71に送信し、受注伝票71は、Get()を実行して、受注明細44の2件目のインスタンスを取得し、その情報を受注制御41に返送する。そして、1件目と同様のパターンで、商品コード、数量、および納入先を受注明細44に設定する。

0106

このようなパターンは、受注明細44のインスタンスの数だけ繰り返される。その間、納入先73のインスタンスの一意性は納入先管理74によって保証され、1つの受注伝票71に関する受注明細44の設定が終了するまで、納入先73は繰り返し再利用される。

0107

図16は、オブジェクト管理によるインスタンス間リンクの制御を説明するためのオブジェクトのリンク関係を示している。図16において、端数調整情報75は、マスタ系のドメインオブジェクトであり、端数調整情報管理76は、端数調整情報75のオブジェクト管理である。

0108

受注伝票管理72は、得意先管理66を指すリンクを保持し、得意先管理66は、端数調整情報管理76を指すリンクを保持し、受注伝票71は、得意先65を指すリンクを保持し、得意先65は、端数調整情報75を指すリンクを保持している。受注伝票管理72と受注伝票71は集約関係を持っており、得意先管理66と得意先65も集約関係を持っている。さらに、端数調整情報管理76と端数調整情報75も集約関係を持っている。

0109

一般に、オブジェクト管理は、上述したディレクタによって生成、保持されるが、その際、ディレクタにより、リンク、のようなオブジェクト管理間のリンクが確立される。ジャーナル系のオブジェクト管理は、リンクのような、関連するマスタ系のオブジェクト管理へのリンクを保持している。また、リンクのような、同じキーを持つマスタ系のオブジェクト管理間のリンクは、必要に応じて定義される。

0110

ドメインオブジェクトは、通常、他のドメインオブジェクトを生成することはないが、オブジェクト管理を通じて、リンク、のような、他のドメインオブジェクトとのリンクを動的に保持することができる。

0111

図16では、受注伝票管理72は、“Get得意先管理”をメソッドとして保持し、受注伝票71は、“伝票番号”を属性として保持し、“Set得意先コード”、“Get得意先”、および“金額計算”をメソッドとして保持している。得意先管理66は、“GetOne”および“Get端数調整情報管理”をメソッドとして保持し、得意先65は、“得意先コード”を属性として保持し、“Get得意先名”、“Get住所”、“Get電話番号”、および“端数調整依頼”をメソッドとして保持している。

0112

また、端数調整情報管理76は、“GetOne”をメソッドとして保持し、端数調整情報75は、“得意先コード”および“端数調整区分”を属性として保持し、“端数調整”をメソッドとして保持している。

0113

図17は、これらのオブジェクトが行う動作のパターンを示している。ここでは、図16に示したリンクを確立するパターンが示されている。まず、受注伝票71は、Set得意先コード(code)のメッセージを受け取ると、Set得意先コード(code)を実行し、Get得意先()のメッセージを受け取ると、Get得意先()を実行する。

0114

このとき、受注伝票71は、Get得意先管理()のメッセージを受注伝票管理72に送信し、受注伝票管理72は、Get得意先管理()を実行して、リンクにより得意先管理66のインスタンスを取得し、その情報を受注伝票71に返送する。

0115

次に、受注伝票71は、GetOne()のメッセージを得意先管理66に送信し、得意先管理66は、GetOne()を実行して、得意先65のインスタンスを取得し、その情報を受注伝票71に返送する。この得意先65のインスタンスへのリンクは、受注伝票71の処理が終了するまで、受注伝票71のインスタンスにリンクとして保持される。

0116

次に、得意先65は、Get得意先名()、Get住所()、およびGet電話番号()のメッセージを受け取ると、Get得意先名()、Get住所()、およびGet電話番号()を実行する。

0117

次に、受注伝票71は、金額計算()のメッセージを受け取ると、金額計算()を実行し、端数調整依頼(明細金額)のメッセージを得意先65に送信する。得意先65は、端数調整依頼(明細金額)を実行し、Get端数調整情報管理()のメッセージを得意先管理66に送信する。そして、得意先管理66は、Get端数調整情報管理()を実行し、リンクにより、端数調整情報管理76のインスタンスを取得し、その情報を得意先65に返送する。

0118

次に、得意先65は、GetOne(得意先code)のメッセージを端数調整情報管理76に送信する。端数調整情報管理76は、GetOne(得意先code)を実行して、端数調整情報75のインスタンスを取得し、その情報を得意先65に返送する。この端数調整情報75のインスタンスへのリンクは、受注伝票71の金額計算が終了するまで、得意先65のインスタンスにリンクとして保持される。

0119

次に、得意先65は、端数調整(金額)のメッセージを端数調整情報75に送信し、端数調整情報75は、端数調整(金額)を実行して、調整された金額を得意先65に返送する。そして、得意先65は、返送された金額を端数調整済金額として受注伝票71に送信する。これにより、1件の受注明細44に関する金額計算が終了する。

0120

このような金額計算は、受注明細44の件数だけ繰り返され、すべての受注明細44について処理が終了すると、受注伝票71の金額計算が終了する。端数調整情報75のインスタンスへのリンクは、受注伝票71の金額計算が終了するまで得意先65により保持されるため、端数調整情報管理76への参照は、初回のみ行われる。

0121

オブジェクト管理は、以上説明したパターンに記述されたメソッドのほかにも、次のようなメソッド群をインタフェースとして持つことができる。
(1)ドメインオブジェクトの検索条件を指定し、対応するインスタンスを順番に1つずつ返却するメソッド群(Select/Get)。

0122

Select()は、検索条件を引数として含み、データベースとの1回の通信(SQL実行)で複数のレコードを検索し、検索結果をオブジェクト管理のメモリ領域に格納する。また、Get()は、Select()とペアで使用され、Get()を実行すると、1つのドメインオブジェクトが返却される。このとき、オブジェクト管理は、Select()の実行時にプールしたデータの中から1つのドメインオブジェクトに相当するデータを抜き出して、ドメインオブジェクトを生成する。

0123

オブジェクト管理がデータベースを隠蔽している場合、一定の検索条件で処理対象のレコードをまとめて抽出可能ならば、これらのメソッドを用いた方がGetOne()によりドメインオブジェクトを個別に取得するよりも効率的である。
(2)ドメインオブジェクトの検索条件を指定し、対応するインスタンスのすべての属性情報文字列として一括返却するメソッド群(Select/GetAllAttributes)。
(3)ドメインオブジェクトの検索条件を指定し、対応するインスタンスを順番に1つずつ返却し、それらの属性情報を変更した後にデータベースを一括更新するメソッド群(Select/Get/Update)。
(4)新規に生成された複数のドメインオブジェクトのインスタンスをまとめて一括登録するメソッド群(Alloc/Insert/Flush)。

0124

図18は、制御オブジェクトによるハイレベルな手続きを説明するためのオブジェクトのリンク関係を示している。制御オブジェクトは、特定のドメインオブジェクトに属さないハイレベルな手続きを保持している。ハイレベルな手続きとしては、次のようなものが考えられる。
(1)受注時に発注を行う。
(2)受注時に在庫の引き当てを行う。
(3)修正時に赤伝票を登録する。
(4)受注と同時に売上計上を行う。

0125

オンライン業務においては、制御オブジェクトは、クライアントからの処理依頼を、保持しているリンクを元に解決し、処理結果をクライアントに通知する。このとき、クライアントからのメッセージをオブジェクトへの複数のメッセージに展開して、送信する。また、同じクラスに属する複数のインスタンスを同時に扱うことができ、バッチ処理を記述することもできる。

0126

受注制御41は、受注伝票管理72、受注伝票71、および受注明細44を指すリンクを保持している。受注伝票管理72と受注伝票71は集約関係を持っており、受注伝票71と受注明細44も集約関係を持っている。受注明細44は、受注伝票管理72を使用する。

0127

ここでは、受注伝票管理72は、“GetNew”および“GetOne”をメソッドとして保持し、受注伝票71は、“伝票番号”を属性として保持し、“赤Copy”、“黒Copy”、“Set元伝票フラグ”、“Get”、および“Remove”をメソッドとして保持している。受注制御41は、“修正開始”、“明細修正”、“明細追加”、および“明細削除”をメソッドとして保持し、受注明細44は、“明細番号”を属性として保持し、“Set商品コード”および“Set数量”をメソッドとして保持している。

0128

図19は、これらのオブジェクトが行う動作のパターンを示している。ここでは、赤黒修正を行うパターンが示されている。まず、受注制御41は、修正開始()のメッセージを受け取ると、修正開始()を実行し、GetOne(伝票番号)のメッセージを受注伝票管理72に送信する。受注伝票管理72は、GetOne(伝票番号)を実行して、受注伝票71のインスタンス(元伝票)を取得し、その情報を受注制御41に返送する。

0129

次に、受注制御41は、GetNew()のメッセージを受注伝票管理72に送信し、受注伝票管理72は、GetNew()を実行して、受注伝票71のインスタンス(赤伝票)を生成し、その情報を受注制御41に返送する。そして、受注制御41は、赤Copy(元伝票インスタンス)のメッセージを赤伝票インスタンスに送信し、赤伝票インスタンスは、赤Copy(元伝票インスタンス)を実行する。

0130

次に、受注制御41は、GetNew()のメッセージを受注伝票管理72に送信し、受注伝票管理72は、GetNew()を実行して、受注伝票71のインスタンス(黒伝票)を生成し、その情報を受注制御41に返送する。そして、受注制御41は、黒Copy(元伝票インスタンス)のメッセージを黒伝票インスタンスに送信し、黒伝票インスタンスは、黒Copy(元伝票インスタンス)を実行する。

0131

次に、受注制御41は、Set元伝票フラグ()のメッセージを元伝票インスタンスに送信し、元伝票インスタンスは、Set元伝票フラグ()を実行する。次に、受注制御41は、明細修正(行情報)のメッセージを受け取ると、明細修正(行情報)を実行し、Get(行番号)のメッセージを黒伝票インスタンスに送信する。黒伝票インスタンスは、Get(行番号)を実行して、対応する受注明細44のインスタンスを取得し、その情報を受注制御41に返送する。そして、受注制御41は、Set商品コード()およびSet数量()のメッセージを受注明細44に送信し、受注明細44は、Set商品コード()およびSet数量()を実行して、商品コードおよび数量を修正する。

0132

また、受注制御41は、明細追加(行情報)のメッセージを受け取ると、明細追加(行情報)を実行し、Get()のメッセージを黒伝票インスタンスに送信する。黒伝票インスタンスは、Get()を実行して、受注明細44のインスタンスを生成し、その情報を受注制御41に返送する。そして、受注制御41は、Set商品コード()およびSet数量()のメッセージを受注明細44に送信し、受注明細44は、Set商品コード()およびSet数量()を実行して、商品コードおよび数量を設定する。

0133

また、受注制御41は、明細削除(行番号)のメッセージを受け取ると、明細削除(行番号)を実行し、Remove(行番号)のメッセージを黒伝票インスタンスに送信する。黒伝票インスタンスは、Remove(行番号)を実行して、対応する行を削除する。

0134

図20は、制御オブジェクトによるインスタンス間リンクの制御を説明するためのオブジェクトのリンク関係を示している。制御オブジェクトは、ディレクタによって生成、保持されるが、その際、必要なジャーナル系およびマスタ系のオブジェクト管理へのリンクが確立される。また、制御オブジェクトは、クライアントからの処理依頼を解決するためのビジネスルールと、解決に必要なインスタンス間リンクを保持している。

0135

受注伝票管理72は、商品管理62を指すリンクを保持し、受注制御41は、受注伝票管理72を指すリンクを保持している。受注伝票管理72と受注伝票71は集約関係を持っており、商品管理62と商品61も集約関係を持っている。さらに、受注伝票71と受注明細44も集約関係を持っている。受注制御41は、受注伝票71、受注明細44、および商品61を使用し、受注明細44は、受注伝票管理72および商品61を使用する。

0136

ここでは、受注伝票管理72は、“GetNew”をメソッドとして保持し、受注伝票71は、“伝票番号”を属性として保持し、“Set得意先コード”および“Get得意先”をメソッドとして保持している。受注制御41は、“新規起票”、“ヘッダ項目設定”、“明細項目設定”、および“手入力単価設定”をメソッドとして保持し、受注明細44は、“明細番号”を属性として保持し、“Set商品コード”、“Set数量”、“Set単価”、および“Get商品”をメソッドとして保持している。

0137

また、商品管理62は、“GetOne”をメソッドとして保持し、商品61は、“商品コード”を属性として保持し、“Get商品名”をメソッドとして保持している。

0138

図21は、これらのオブジェクトが行う動作のパターンを示している。ここでは、受注伝票71を起票し、受注明細44の項目を設定するパターンが示されている。

0139

まず、受注制御41は、新規起票()のメッセージを受け取ると、新規起票()を実行し、GetNew()のメッセージを受注伝票管理72に送信する。受注伝票管理72は、GetNew()を実行して、受注伝票71のインスタンスを生成し、その情報を受注制御41に返送する。これにより、受注制御41は、受注伝票71へのリンクを取得する。

0140

次に、受注制御41は、ヘッダ項目設定()のメッセージを受け取ると、ヘッダ項目設定()を実行し、Set得意先コード(code)のメッセージを受注伝票71に送信する。そして、受注伝票71は、Set得意先コード(code)を実行して、得意先コードを設定する。

0141

次に、受注制御41は、Get得意先()のメッセージを受注伝票71に送信する。受注伝票71は、Get得意先()を実行し、GetOne(code)のメッセージを図16の得意先管理66に送信する。得意先管理66は、GetOne(code)を実行し、図16の得意先65のインスタンスを取得して、その情報を受注伝票71に返送する。そして、受注伝票71は、返送された得意先65のインスタンスの情報を受注制御41に送信する。これにより、受注制御41は、得意先65へのリンクを取得する。

0142

次に、受注制御41は、Get得意先名()のメッセージを得意先65に送信する。得意先65は、Get得意先名()を実行して、得意先名を取得し、それを受注制御41に返送する。そして、受注制御41は、返送された得意先名をクライアントに通知する。

0143

次に、受注制御41は、明細項目設定()のメッセージを受け取ると、明細項目設定()を実行し、Set商品コード(code)のメッセージを受注明細44に送信する。そして、受注明細44は、Set商品コード(code)を実行して、商品コードを設定する。

0144

次に、受注制御41は、Get商品()のメッセージを受注明細44に送信する。受注明細44は、Get商品()を実行し、GetOne(code)のメッセージを商品管理62に送信する。商品管理62は、GetOne(code)を実行し、商品61のインスタンスを取得して、その情報を受注明細44に返送する。そして、受注明細44は、返送された商品61のインスタンスの情報を受注制御41に送信する。これにより、受注制御41は、商品61へのリンクを取得する。

0145

次に、受注制御41は、Get商品名()のメッセージを商品61に送信する。商品61は、Get商品名()を実行して、商品名を取得し、それを受注制御41に返送する。そして、受注制御41は、返送された商品名をクライアントに通知する。

0146

次に、受注制御41は、明細項目設定()のメッセージを受け取ると、明細項目設定()を実行し、Set数量(count)のメッセージを受注明細44に送信する。そして、受注明細44は、Set数量(count)を実行して、数量を設定する。

0147

次に、受注制御41は、手入力単価設定()のメッセージを受け取ると、手入力単価設定()を実行し、Set単価(price)のメッセージを受注明細44に送信する。そして、受注明細44は、Set単価(price)を実行して、単価を設定する。

0148

なお、各項目の設定にはあらかじめ決められたルールが適用され、設定値誤りがあると、設定を実行したオブジェクトから受注制御41にエラーコードが返送される。そして、受注制御41は、エラー処理を集中的に行う。

0149

図22は、伝票処理の業務システムにおける受注入力時の実行画面を示しており、図23は、対応するインスタンス間のリンク関係を示している。図22の画面に表示された受注番号、得意先、納入先等の各項目の情報は、図23のような複数のインスタンスに分散して保持される。

0150

図23において、担当者77は、ドメインオブジェクトであり、担当者管理78は、担当者77のオブジェクト管理である。受注制御41は、受注伝票71へのリンクを保持し、受注伝票71は、得意先65、納入先73、および担当者77へのリンクを保持し、受注明細44は、商品61へのリンクを保持している。

0151

また、受注伝票管理72と受注伝票71は集約関係を持ち、受注伝票71と受注明細44も集約関係を持ち、商品管理62と商品61も集約関係を持っている。さらに、得意先管理66と得意先65も集約関係を持ち、納入先管理74と納入先73も集約関係を持ち、担当者管理78と担当者77も集約関係を持っている。

0152

受注伝票71は、受注番号、得意先コード、納入先コード、担当者コード等の属性を保持し、得意先65は、得意先のコードおよび名前の属性を保持し、納入先73は、納入先のコードおよび名前の属性を保持し、担当者77は、担当者のコードおよび名前の属性を保持している。また、受注明細44は、明細番号、取引区分、商品コード等の属性を保持し、商品61は、商品のコードおよび名前の属性を保持している。

0153

図24は、オブジェクト管理のクラスの作成手順を示している。業務システムは、まず、ドメインオブジェクトの属性を抽出し(ステップS1)、ドメインオブジェクトのキー項目を決定し(ステップS2)、キー項目別のデータベースアクセスのSQLパターンを決定する(ステップS3)。キー項目としては、例えば、ドメインオブジェクトのコードや名前が用いられる。

0154

また、ビジネスルールやシステムの運用形態により、データのキャッシュ種別を選択する(ステップS4)。キャッシュは、例えば、業務システムのメモリ上に設けられ、1つまたは複数のキャッシュ種別を選択することができる。キャッシュ種別としては、例えば、次のようなものが用いられる。
(1)1トランザクション内での短期キャッシュ:1トランザクションの処理が終了するまで、ドメインオブジェクトをキャッシュ上に保持する。
(2)1スレッド内でのLRU(least recently used )キャッシュ:1スレッドの処理が終了するまで、ドメインオブジェクトをキャッシュ上に保持し、LRU法により、キャシュ上で置き換えるべきドメインオブジェクトを決定する。ここで、スレッドは、プロセス(タスク)を構成する処理単位である。また、LRU法は、最近使用されたデータをキャッシュ上に残し、最も長く使われていないデータを置き換えの対象として選ぶアルゴリズムである。したがって、キャッシュ上には、最近アクセス時刻の新しい順に、キャッシュが一杯になるまで選ばれたオブジェクト群が保持され、メモリの利用効率が向上する。
(3)1スレッド内での順検索先読み式キャッシュ:最初にGetOne()で指定されたキーを属性として持つドメインオブジェクトから順番に、昇順または降順で一定数のドメインオブジェクトを、補助記憶装置からキャッシュに先読みしておく。キャッシュから読み込まれたドメインオブジェクトは処理が終了すると、キャッシュより解放される。そして、キャッシュが空になると、次の一定数のドメインオブジェクトをキャッシュに先読みする。
(4)1プロセス内での全件先読み式キャッシュ:プロセスの起動時に、処理対象とするすべてのドメインオブジェクトを補助記憶装置からキャッシュに先読みしておく。そして、1プロセスの処理が終了するまで、それらのドメインオブジェクトをキャッシュ上に保持する。

0155

次に、業務システムは、キャッシュ種別毎のオブジェクト管理の実装パターンを選択する(ステップS5)。ステップS6では、1トランザクション内での短期キャッシュの実装パターンが選択され、ステップS7では、1スレッド内でのLRUキャッシュの実装パターンが選択され、ステップS8では、1スレッド内での順検索先読み式キャッシュの実装パターンが選択され、ステップS9では、1プロセス内での全件先読み式キャッシュの実装パターンが選択される。

0156

そして、業務システムは、実装パターンに基づいた各オブジェクト管理のクラスをコーディングして(ステップS10)、作成処理を終了する。図25から図27までは、業務システムで用いられるメソッドの実装パターンの例を示している。図25は、ドメインオブジェクトを取得するGetOne()の実装パターンを示している。この実装パターンは、短期キャッシュおよびLRUキャッシュに共通のパターンである。

0157

また、図26および図27は、オブジェクトを解放するrelease oneの実装パターンを示している。図26は、短期キャッシュのためのパターンであり、図27は、LRUキャッシュのためのパターンである。releaseoneは、例えば、オブジェクト管理が保持しているドメインオブジェクトをメモリ上から解放する際に用いられる。

0158

ところで、上述した図2の業務システムは、図28に示すような情報処理装置(コンピュータ)を用いて構成することができる。図28の情報処理装置は、CPU(中央処理装置)81、メモリ82、入力装置83、出力装置84、外部記憶装置85、媒体駆動装置86、およびネットワーク接続装置87を備え、それらはバス88により互いに接続されている。

0159

メモリ82は、例えば、ROM(read only memory)、RAM(random access memory)等を含み、処理に用いられるオブジェクトのプログラムとデータを格納する。CPU81は、メモリ82を利用してプログラムを実行することにより、必要な処理を行う。

0160

入力装置83は、例えば、キーボードポインティングデバイスタッチパネル等であり、ユーザからの指示や情報の入力に用いられる。出力装置84は、例えば、ディスプレイプリンタスピーカ等であり、ユーザへの問い合わせや情報の出力に用いられる。

0161

外部記憶装置85は、例えば、磁気ディスク装置光ディスク装置光磁気ディスク(magneto-optical disk)装置等の補助記憶装置であり、図2のデータベース13やシーケンシャルファイル14を格納する。この外部記憶装置85に、上述のプログラムとデータを保存しておき、必要に応じて、それらをメモリ82にロードして使用することもできる。

0162

媒体駆動装置86は、可搬記録媒体89を駆動し、その記録内容にアクセスする。可搬記録媒体89としては、メモリカードフロッピーディスクCD−ROM(compact disk read only memory )、光ディスク、光磁気ディスク等、任意のコンピュータ読み取り可能な記録媒体が用いられる。この可搬記録媒体89に上述のプログラムとデータを格納しておき、必要に応じて、それらをメモリ82にロードして使用することもできる。

0163

ネットワーク接続装置87は、LAN(local area network)等の任意のネットワーク(回線)を介して外部の装置と通信し、通信に伴うデータ変換を行う。また、必要に応じて、上述のプログラムとデータを外部の装置から受け取り、それらをメモリ82にロードして使用することもできる。

0164

図29は、図28の情報処理装置にプログラムとデータを供給することのできるコンピュータ読み取り可能な記録媒体を示している。可搬記録媒体89や外部のデータベース70に保存されたプログラムとデータは、メモリ82にロードされる。そして、CPU81は、そのデータを用いてそのプログラムを実行し、必要な処理を行う。

発明の効果

0165

本発明によれば、オブジェクト指向の特徴を活用した業務システムを構築することが可能になる。本システムでは、オブジェクト指向部品の再利用や組み合わせが容易であり、本システムをベースにユーザの業務形態マッチした様々なシステムを構築することができる。

0166

また、ユーザからのカストマイズの要件に応じて、修正の対象となる部品を容易に絞り込むことができ、修正する部品数も少なくて済む。また、オブジェクト指向部品を用いているため、データ操作やビジネスルールの実装が外部から隠蔽されており、すべての部品がパターンに基づいて設計/実装されているので、システム全体の保守性が良い。

0167

また、各部品はパターンと継承に基づいて実装されているので、部品の開発コストが従来のシステムより低く押さえられる。また、部品に対する実装パターンの適用率が高いので、部品の修正時の品質や部品の生産性が良い。

図面の簡単な説明

0168

図1本発明の業務システムの原理図である。
図2業務システムの構成図である。
図3ビジネスオブジェクトのクラスを示す図である。
図4伝票処理業務の機能を示す図である。
図5クラスの例を示す図である。
図6第1のリンク関係を示す図である。
図7第1のパターンを示す図である。
図8第2のリンク関係を示す図である。
図9第2のパターンを示す図である。
図10第3のリンク関係を示す図である。
図11第3のパターンを示す図である。
図12第4のリンク関係を示す図である。
図13第4のパターンを示す図である。
図14第5のリンク関係を示す図である。
図15第5のパターンを示す図である。
図16第6のリンク関係を示す図である。
図17第6のパターンを示す図である。
図18第7のリンク関係を示す図である。
図19第7のパターンを示す図である。
図20第8のリンク関係を示す図である。
図21第8のパターンを示す図である。
図22受注入力の画面を示す図である。
図23インスタンスの例を示す図である。
図24オブジェクト管理の作成手順を示す図である。
図25オブジェクトの取得の実装パターンを示す図である。
図26オブジェクトの解放の第1の実装パターンを示す図である。
図27オブジェクトの解放の第2の実装パターンを示す図である。
図28情報処理装置の構成図である。
図29記録媒体を示す図である。

--

0169

1オブジェクト手段
2 実行手段
3、23、44、46、49、51、61、64、65、68、71、73、75、77ドメインオブジェクト
4、24、43、45、48、50、62、66、69、72、74、76、78オブジェクト管理
11クライアント
12ビジネスオブジェクト
13、90データベース
14シーケンシャルファイル
21ディレクタ
22モデル群
25、41、42、67、70制御オブジェクト
26、47、63サービスオブジェクト
31 ディレクタベースクラス
32モデルベースクラス
33コントローラベースクラス
34ドメインモデルベースクラス
35オブジェクトマネージャベースクラス
81 CPU
83入力装置
84出力装置
85外部記憶装置
86媒体駆動装置
87ネットワーク接続装置
88バス
89 可搬記録媒体

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

新着 最近 公開された関連が強い 技術

この 技術と関連性が強い 技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する挑戦したい社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ