(57)【要約】【課題】オブジェクト指向言語に基づいて、複数のジョブを実行制御するシステムを効率的に設計するための技術、を提供する。【解決手段】UriageProcessingModelクラス４４０は、各ジョブオブジェクトのデータの依存関係を定義する。UriageProcessingModelクラス４４０は、ジョブオブジェクトのクラス群４２０（以下「ジョブクラス」）と、各ジョブオブジェクトのデータの依存関係をリストとして管理するConnectionクラス４３０のオブジェクトを持つ。UriageProcessingModelクラス４４０は、ジョブとその依存関係をジョブオブジェクトのクラス群４２０とConnectionクラス４３０の機能を使って管理することになる。SingleThreadFlowControllerクラス４５０は、各ジョブオブジェクトの実行方法を定義するクラスである。【選択図】図５
2014021665.tif 000002
【特許請求の範囲】
【請求項１】
ユーザが作成したクラスから生成されたオブジェクトを保持するオブジェクト保持部であって、（Ａ）ジョブの処理内容が定義されたジョブクラスから生成された複数のジョブオブジェクトと、（Ｂ）あらかじめ定められた複数のコントロールクラスのうちのいずれかへの参照が設定され、かつ、各ジョブクラスのデータの依存関係が定義されたモデルクラスから生成されたモデルオブジェクトと、を保持するオブジェクト保持部と、
複数のジョブオブジェクトそれぞれのタイプに応じた複数の仲介オブジェクトであって、対応するジョブオブジェクトへの参照が設定される複数の仲介オブジェクトを生成するオブジェクト生成部と、
モデルオブジェクトに定義されたデータの依存関係に基づいて選択されたジョブオブジェクトに対応する仲介オブジェクトのメンバ関数を、モデルオブジェクトが参照するコントロールオブジェクトにおいて定められた対応で呼び出すことにより、当該仲介オブジェクトが参照するジョブオブジェクトに定義された処理を当該ジョブオブジェクトに実行させる実行制御部と、を備え、
前記実行制御部は、選択されたジョブオブジェクトが次にデータを渡すべきジョブオブジェクトをモデルオブジェクトに定義されたデータの依存関係に基づいて特定し、特定したジョブオブジェクトに対応する仲介オブジェクトのメンバ関数を、モデルオブジェクトが参照するコントロールオブジェクトにおいて定められた対応で呼び出すことを特徴とするジョブ管理装置。
【請求項２】
モデルオブジェクトには、各ジョブオブジェクトに定義された処理を時間的に並行して実行させるよう定義されたコントロールオブジェクトへの参照が設定され、
前記実行制御部は、複数の仲介オブジェクトに別々のスレッドを割り当てることにより、複数の仲介オブジェクトに対応する各ジョブオブジェクトに定義された処理を当該各ジョブオブジェクトに時間的に並行して実行させることを特徴とする請求項１に記載のジョブ管理装置。
【請求項３】
コントロールオブジェクトには、各ジョブオブジェクトが配置されるべき外部装置に関する情報を示す分散配置情報がさらに定義され、
前記オブジェクト生成部は、分散配置情報にしたがって、ネットワークを介して接続された複数の外部装置に対して複数の仲介オブジェクトを分散配置し、
前記実行制御部は、複数の外部装置に分散配置された各仲介オブジェクトの所定のメンバ関数を呼び出すことにより、複数の外部装置に分散配置されたジョブオブジェクトに処理を実行させることを特徴とする請求項１または２に記載のジョブ管理装置。
【請求項４】
ユーザが作成したクラスから生成されたオブジェクトを保持するオブジェクト機能であって、（Ａ）ジョブの処理内容が定義されたジョブクラスから生成された複数のジョブオブジェクトと、（Ｂ）あらかじめ定められた複数のコントロールクラスのうちのいずれかへの参照が設定され、かつ、各ジョブクラスのデータの依存関係が定義されたモデルクラスから生成されたモデルオブジェクトと、を保持する機能と、
複数のジョブオブジェクトそれぞれのタイプに応じた複数の仲介オブジェクトであって、対応するジョブオブジェクトへの参照が設定される複数の仲介オブジェクトを生成する機能と、
モデルオブジェクトに定義されたデータの依存関係に基づいて選択されたジョブオブジェクトに対応する仲介オブジェクトのメンバ関数を、モデルオブジェクトが参照するコントロールオブジェクトにおいて定められた対応で呼び出すことにより、当該仲介オブジェクトが参照するジョブオブジェクトに定義された処理を当該ジョブオブジェクトに実行させる機能と、をコンピュータに実現させ、
前記実行させる機能は、選択されたジョブオブジェクトが次にデータを渡すべきジョブオブジェクトをモデルオブジェクトに定義されたデータの依存関係に基づいて特定し、特定したジョブオブジェクトに対応する仲介オブジェクトのメンバ関数を、モデルオブジェクトが参照するコントロールオブジェクトにおいて定められた対応で呼び出すことを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ジョブの実行を制御するための技術、特に、依存関係を有する複数のジョブを実行制御するための技術、に関する。
【背景技術】
【０００２】
企業や公共施設などの運用を支えるエンタープライズシステム（Enterprise System）は、今や、大小さまざまな組織の基盤システムとして導入されている。エンタープライズシステムは、ノード端末やデータベースから得られるデータを集計、蓄積、解析、加工した上でより付加価値の高い情報を出力する。エンタープライズシステムは複雑化する組織マネジメントをより効率化するために発展を続けている。
【０００３】
このようなエンタープライズシステムは、ジョブの集合体としてモデリングされることが多い。ジョブとは、データベースの更新処理や、各ノード端末から得られたデータに対する演算処理など、システムにおいて基本的な実行単位となる処理である。これらのジョブは、前段にあたるジョブの実行結果に基づいて後段にあたるジョブが実行されるように互いに依存関係を有したかたちで設計される。
【０００４】
エンタープライズシステムの構築にあたっては、ＣＯＢＯＬ（Common Business Oriented Language）などの手続き型言語が広く採用されている。ＣＯＢＯＬは、その文法がシンプルであることから、エンタープライズシステムにおいてジョブを順次処理するという処理モデルにおいては実績のある言語である。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平７−１２９４１５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
その一方、ＪＡＶＡ（登録商標）やＣ＋＋などのオブジェクト指向言語が、ソフトウェア開発の現場において急速に普及しつつある。オブジェクト指向言語は、データとそのデータにアクセスするためのインタフェースをクラス（class）としてカプセル化する。クラスという一種の構造体によってデータが保護されるため、オブジェクト指向言語は、コードの再利用性・保守性・堅牢性などの諸点において手続き型言語よりも優れている。オブジェクト指向言語が普及するにつれて、開発現場でもＣＯＢＯＬプログラマよりもＪＡＶＡ（登録商標）プログラマの方が増加しつつある。とりわけ、中国・台湾・インドをはじめとする東アジア諸国では、ＣＯＢＯＬプログラマよりもＪＡＶＡ（登録商標）プログラマの方が確保しやすい。
このような背景から、ＪＡＶＡ（登録商標）によってエンタープライズシステムを開発する必要性が顕在化しつつあると本発明者は認識した。
【０００７】
ただし、大量のデータをバッチ処理する形態となることが多いエンタープライズシステムにおいてオブジェクト指向言語の優位性を発揮させるためには、手続き型言語による設計思想とは異なる設計思想に基づく必要がある。オブジェクト指向言語の特徴はソフトウェアの部品化であり、クラスの機能をいかに定義するかによってそのクラスの有用性が決まる。本発明者は、オブジェクト指向言語を前提としてエンタープライズシステムを設計するための新たなフレームワークを提供することにより、その優位性を好適に発揮させることができると想到した。
【０００８】
本発明はこうした状況に鑑みてなされたものであり、その目的は、オブジェクト指向言語に基づいて、複数のジョブを実行制御するシステムを効率的に設計するための技術、を提供することにある。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、本発明のある態様のジョブ管理装置は、ユーザが作成したクラスから生成されたオブジェクトを保持するオブジェクト保持部であって、（Ａ）ジョブの処理内容が定義されたジョブクラスから生成された複数のジョブオブジェクトと、（Ｂ）あらかじめ定められた複数のコントロールクラスのうちのいずれかへの参照が設定され、かつ、各ジョブクラスのデータの依存関係が定義されたモデルクラスから生成されたモデルオブジェクトと、を保持するオブジェクト保持部と、複数のジョブオブジェクトそれぞれのタイプに応じた複数の仲介オブジェクトであって、対応するジョブオブジェクトへの参照が設定される複数の仲介オブジェクトを生成するオブジェクト生成部と、モデルオブジェクトに定義されたデータの依存関係に基づいて選択されたジョブオブジェクトに対応する仲介オブジェクトのメンバ関数を、モデルオブジェクトが参照するコントロールオブジェクトにおいて定められた対応で呼び出すことにより、当該仲介オブジェクトが参照するジョブオブジェクトに定義された処理を当該ジョブオブジェクトに実行させる実行制御部と、を備える。実行制御部は、選択されたジョブオブジェクトが次にデータを渡すべきジョブオブジェクトをモデルオブジェクトに定義されたデータの依存関係に基づいて特定し、特定したジョブオブジェクトに対応する仲介オブジェクトのメンバ関数を、モデルオブジェクトが参照するコントロールオブジェクトにおいて定められた対応で呼び出す。
【００１０】
なお、以上の構成要素の任意の組合せ、本発明の表現を装置、方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１１】
本発明によれば、オブジェクト指向言語に基づくジョブの実行制御システムを効率的に設計する上で効果がある。
【図面の簡単な説明】
【００１２】
【図１】エンタープライズシステムのハードウェア構成を示す図である。
【図２】ジョブ管理装置の機能構成を示すブロック図である。
【図３】本実施例におけるデータフローダイアグラムを示す図である。
【図４】図３のＤＦＤに対応するジョブクラスの依存関係を示す図である。
【図５】ジョブ管理装置の基本的な機能を実現するためのクラスの関係を示す模式図である。
【図６】ジョブクラスとモデルクラスの関係を示すクラス図である。
【図７】処理クラスの継承に関するクラス図である。
【図８】エンタープライズシステムの実行開始にあたって、最初に実行される関数を示す図である。
【図９】モデルオブジェクト生成時に実行されるソースコードを示す図である。
【図１０】コントロールオブジェクト生成時とデータフローの実行開始に際して実行されるソースコードを示す図である。
【図１１】図１０のＳ３２０からＳ３４０までの処理に対応するソースコードを示す図である。
【図１２】仲介オブジェクトを介してジョブオブジェクトに処理を実行させる過程に対応したソースコードの一例を示す図である。
【発明を実施するための形態】
【００１３】
図１は、エンタープライズシステムのハードウェア構成図である。
エンタープライズシステム２０４は、企業や公共施設のような組織の業務管理のために導入されるシステムである。エンタープライズシステム２０４は、地理的に分散された複数の組織を統合するシステムとして構成されてもよい。
【００１４】
本実施例におけるエンタープライズシステム２０４は、ジョブ管理装置１００、ノード端末２００およびデータベース２０６を含む。これらは、インターネット２０２を介して互いに接続されている。
ジョブ管理装置１００は、各ジョブのデータの依存関係を定義したデータフローダイアグラム（DFD:Data Flow Diagram）にしたがって複数のジョブを順次実行する。データフローダイアグラム（以下、「ＤＦＤ」ともよぶ）については、後に図３等に関連して詳述する。また、ジョブ管理装置１００の機能については、次の図２以降に関連して詳述する。
【００１５】
ノード端末２００は、ユーザが業務遂行のために使用するコンピュータ端末である。ノード端末２００は業務上のさまざまなデータを取得する。ジョブ管理装置１００は、ジョブの実行に際して、ノード端末２００やデータベース２０６とデータを送受する。ジョブ管理装置１００は、ノード端末２００やデータベース２０６から取得したデータに基づいて各種のジョブを実行する。
【００１６】
まとめると、ノード端末２００やデータベース２０６から得られるデータを変数として、ジョブ管理装置１００はさまざまなジョブを実行する。また、ジョブ管理装置１００は、各ジョブの実行タイミングを統合的に制御する。このように、ノード端末２００やデータベース２０６から得られるデータに基づいて、あらかじめ処理内容が定義されたジョブが順次実行されることにより、エンタープライズシステム２０４全体としての運用がなされている。
【００１７】
図２は、ジョブ管理装置の機能ブロック図である。
これら各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
ここでは、主として各機能ブロックの発揮すべき機能について述べ、その具体的な作用については、図３以降に関連して説明する。
【００１８】
ジョブ管理装置１００は、ユーザインタフェース処理部１１０、通信部１２０、データ処理部１３０およびデータ保持部１６０を含む。
ユーザインタフェース処理部１１０は、ユーザからの入力処理やユーザに対する情報表示のようなユーザインタフェース全般に関する処理を担当する。通信部１２０は、ノード端末２００やデータベース２０６との通信処理を担当する。データ処理部１３０は、ユーザインタフェース処理部１１０や通信部１２０から取得されたデータを元にして各種のデータ処理を実行する。データ処理部１３０は、ユーザインタフェース処理部１１０および通信部１２０の間のインタフェースの役割も果たす。データ保持部１６０は、あらかじめ用意された各種の設定データや、データ処理部１３０から受け取ったデータを格納する。
【００１９】
データ処理部１３０は、モデル管理部１４０とフロー制御部１５０を含む。
モデル管理部１４０は、各ジョブの処理内容を管理するとともに、各ジョブのデータの依存関係を管理する。フロー制御部１５０は、各ジョブの実行方法を管理する。ここで注目すべきは、本実施例におけるジョブ管理装置１００においては、ジョブの処理内容を管理するモデル管理部１４０と、ジョブの実行方法を管理するフロー制御部１５０が機能上分離されていることである。そのため、ジョブの「処理内容の管理」と「実行方法の管理」について、一方の設計作業が他方の設計内容によって制約されない枠組み（フレームワーク）となっている。具体的には、ジョブの処理内容を設計する開発者は、たとえば、ジョブを逐次実行させるシングルスレッドモデルと各ジョブを時間的に並行して実行させるマルチスレッドモデルとのいずれのモデルとして実行させるか、各ジョブを１つの装置に配置して実行させるかそれとも複数の装置に分散配置して実行させるか、といったジョブの実行方法を意識することなく設計できる。
【００２０】
データ保持部１６０は、オブジェクト保持部１７０を含む。
オブジェクト保持部１７０は、モデル管理部１４０によって生成されたジョブオブジェクトを保持する。
以上をふまえて、より具体的なソフトウェア構造について説明する。
【００２１】
図３は、本実施例におけるデータフローダイアグラムを示す図である。
同図に示すデータフローダイアグラム３１２は、所定の期間における４つＣＤ（Compact Disc）店のＣＤの売上枚数を集計して、地域別および店別の売上枚数を計算する処理過程を示している。このデータフローダイアグラム３１２には、売上データ３００、売上集約処理３０２、地区別売上データ３０４、店マスタデータ３０６、店名追加処理３０８および店別売上データ３１０の６つの構成要素（Entity）が定義されている。
【００２２】
売上データ３００は、４つのＣＤ店におけるＣＤ売上枚数を示すデータである。ここで、ＣＤ店を識別するために、各ＣＤ店には「０１」〜「０４」の「店ＩＤ」が付与されている。また、各ＣＤ店が所属する地区を識別するために、各地区には「Ａ」または「Ｂ」の「地区ＩＤ」が付与されている。売上データ３００によれば、「０１」および「０２」のＣＤ店は、「Ａ」地区に属し、「０３」と「０４」のＣＤ店は「Ｂ」地区に属している。ここで「０１」のＣＤ店には、２つのノード端末２００が設置されており、それぞれのノード端末２００からは、ＣＤ売上枚数として「１枚」と「２枚」が入力されている。同様に「０２」や「０４」のＣＤ店にも、２つのノード端末２００が設置されている。すなわち、売上データ３００は、２つの地区、４つのＣＤ店、７つのノード端末２００から得られるデータである。
【００２３】
売上集約処理３０２は、各ＣＤ店に設置されるノード端末２００から得られた売上データ３００をまとめて、ＣＤ店ごとのＣＤ売上枚数を計算する。そして、このＣＤ店ごとのＣＤ売上枚数に関する情報（以下、「中間データ」とよぶ）を店名追加処理３０８に渡す。また、売上集約処理３０２は、地区ごとのＣＤ売上枚数を計算して地区別売上データ３０４を生成する。
【００２４】
店名追加処理３０８は、売上集約処理３０２から受け取った中間データと店マスタデータ３０６とに基づいて、店別売上データ３１０を生成する。店マスタデータ３０６は、店ＩＤと店名を対応づけるデータであり、データベース２０６から得られるデータである。店別売上データ３１０は、ＣＤ店ごとのＣＤ売上枚数を集計したデータであり、かつ、店ＩＤだけでなく対応する店名も含むデータである。
【００２５】
仮に、データフローダイアグラム３１２をＣＯＢＯＬによって実装するとする。ＣＯＢＯＬはマルチスレッド環境を想定して設計された言語ではない。そのため、売上集約処理３０２と店名追加処理３０８をマルチタスク処理として定義する場合、売上集約処理３０２のメモリ空間と、店名追加処理３０８のメモリ空間は別々に割り当てられることになる。したがって、売上集約処理３０２は、中間データをいったんファイル化し、店名追加処理３０８はこのファイルから中間データを読み出すという処理方法になる。
【００２６】
これに対し、本実施例において使用されるプログラミング言語であるＪＡＶＡ（登録商標）は、マルチスレッド環境にて使用されることを充分に想定して設計された言語である。そのため、売上集約処理３０２と店名追加処理３０８をマルチタスク処理として定義する場合でも、各処理は別々のスレッドにて実行可能である。同一プロセス空間に属するスレッド間でメモリを共有するのは簡単であることから、売上集約処理３０２は、中間データをファイル化しなくても、店名追加処理３０８に渡すことができる。このようなマルチスレッドに関する優位性と実現性については後述する。
【００２７】
本実施例においては、データフローダイアグラム３１２に含まれる６つの構成要素を「ジョブ」として定義し、ジョブごとにクラス（以下、「ジョブクラス」ともよぶ）を定義する。以下においては、「Ｘクラス（「Ｘ」は文字列）」をインスタンス化して生成されるオブジェクトのことを単に「Ｘオブジェクト」と表記するものとする。
【００２８】
図４は、図３のＤＦＤに対応するジョブクラスのデータの依存関係を示す図である。
UriageSourceクラス４００は、売上データ３００に対応するジョブクラスであり、売上データ３００を各ＣＤ店のノード端末２００から収集して保持するクラスである。UriageAggregatorクラス４０２は、売上集約処理３０２に対応するジョブクラスである。以下、同様に、AreaUriageTotalSinkクラス４０４は地区別売上データ３０４、MiseMaSourceクラス４０６は店マスタデータ３０６、MiseMaMatcherクラス４０８は店名追加処理３０８、MiseUriageTotalSinkクラス４１０は店別売上データ３１０にそれぞれ対応するジョブクラスである。
【００２９】
図５は、ジョブ管理装置の基本的な機能を実現するためのクラスの関係を示す模式図である。より詳細には、次の図６および図７に関連して説明するが、同図において、まず、クラスの関係の概要を示す。
UriageProcessingModelクラス４４０は、データフローダイアグラム３１２に示した各ジョブクラスのデータの依存関係を定義するクラスである。UriageProcessingModelクラス４４０は、図４に示した６つのジョブクラスを含むジョブクラス群４２０を持つ。同図に示す菱形記号は、ＵＭＬ（Unified Modeling Language）の表記法に基づき、「集約（aggregation）」を示す記号である。すなわち、UriageProcessingModelクラス４４０は、その一部としてジョブクラス群４２０を持つ。したがって、UriageProcessingModelクラス４４０がインスタンス化されるときには、その一部であるジョブクラス群４２０も付随してインスタンス化される。UriageProcessingModelオブジェクトは、各ジョブオブジェクトを持つことになる。
【００３０】
UriageProcessingModelクラス４４０は、Connectionクラス４３０も持つ。Connectionクラス４３０は、ジョブクラス群４２０における各ジョブクラスのデータの依存関係をリストとして管理するクラスである（以下、このようなタイプのクラスのことを「関係クラス」とよぶ）。UriageProcessingModelクラス４４０は、ジョブとそのデータの依存関係をジョブクラス群４２０とConnectionクラス４３０の機能を使って管理することになる。
UriageProcessingModelクラス４４０がインスタンス化されるときには、Connectionクラス４３０も付随してインスタンス化される。つまり、UriageProcessingModelクラス４４０がインスタンス化されるときには、ジョブクラス群４２０とConnectionクラス４３０とが連鎖的にインスタンス化されることになる。
【００３１】
SingleThreadFlowControllerクラス４５０は、ジョブの実行方法を定義するクラスである。SingleThreadFlowControllerクラス４５０の機能によって、エンタープライズシステム２０４が実際に稼働することになる。SingleThreadFlowControllerクラス４５０は、UriageProcessingModelクラス４４０を持っている。より厳密には、SingleThreadFlowControllerクラス４５０は、UriageProcessingModelクラス４４０への参照（reference）を設定されているが、本明細書では、参照も含めて「持つ」と定義する。
【００３２】
先の図２に示した機能ブロック図と対比すると、モデル管理部１４０の機能はUriageProcessingModelクラス４４０、ジョブクラス群４２０、Connectionクラス４３０の各機能によって実現され、フロー制御部１５０の機能はSingleThreadFlowControllerクラス４５０の機能によって実現されることになる。以下、UriageProcessingModelクラス４４０のようなジョブの処理内容が定義されたジョブクラスを持つとともに、ジョブのデータの依存関係を定義するクラスことを「モデルクラス」、SingleThreadFlowControllerクラス４５０のようなジョブの実行方法を定義するクラスのことを「コントロールクラス」とよぶ。
【００３３】
図６は、ジョブクラスとモデルクラスの関係を示すクラス図である。
前の図５に示したように、UriageProcessingModelクラス４４０は、UriageSourceクラス４００からMiseUriageTotalSinkクラス４１０までの６つのジョブクラスを持つ。UriageProcessingModelクラス４４０自体は、SingleThreadFlowControllerクラス４５０に持たれている。UriageProcessingModelクラス４４０は、ProcessingModelクラス４６０を継承するモデルクラスである。すなわちUriageProcessingModelクラス４４０は、ProcessingModelクラス４６０において定義された機能を受け継ぎつつ、ＣＤの売上処理を管理するために特有の機能が追加されたクラスとして定義される。UriageProcessingModelクラス４４０の作成にあたっては、ＣＤの売上処理を管理するために特有の機能のみを追加すればよいので、スクラッチでUriageProcessingModelクラス４４０を作成するのに比べて、開発や保守にともなう負担が軽減される。以下、ProcessingModelクラス４６０のように、モデルクラスの継承元となる、基本的なクラスのことを「モデルベースクラス」とよぶことにする。ProcessingModelクラス４６０は、Connectionクラス４３０を持つ。したがって、ProcessingModelクラス４６０を継承するUriageProcessingModelクラス４４０も、Connectionクラス４３０を持つことになる。
【００３４】
６つのジョブクラスのうち、UriageSourceクラス４００とMiseMaSourceクラス４０６はRecordStreamSourceクラス４８０を継承するジョブクラスである。RecordStreamSourceクラス４８０は、売上データ３００や店マスタデータ３０６のようにジョブの前提となるデータを管理するための基本仕様が定義されたクラスである。UriageAggregatorクラス４０２は、RecordStreamAggregatorクラス４８２を継承する。RecordStreamAggregatorクラス４８２は、売上集約処理３０２のようにデータを集約するジョブについての基本仕様が定義されたクラスである。MiseMaMatcherクラス４０８は、RecordStreamMatcherクラス４８４を継承する。RecordStreamMatcherクラス４８４は、店名追加処理３０８のように２種類のデータを結合するジョブについての基本仕様が定義されたクラスである。MiseUriageTotalSinkクラス４１０とAreaUriageTotalSinkクラス４０４は、RecordStreamSinkクラス４８６を継承する。RecordStreamSinkクラス４８６は、地区別売上データ３０４や店別売上データ３１０のようにジョブの処理結果として生成されるデータを管理するための基本仕様が定義されたクラスである。
このように、６つのジョブクラスは、４種類のクラス（以下、「ジョブベースクラス」とよぶ）のいずれかを継承している。更に遡ると、すべてのジョブベースクラスは、Nodeクラス４９０を継承する。Nodeクラス４９０は、ジョブのタイプによらない基本的な仕様が定義されたクラスである。
【００３５】
Nodeクラス４９０は、NodeFlowControllerクラス５００を包含する。NodeFlowControllerクラス５００は、ジョブオブジェクトによる処理の実行を仲介するためのクラスである（以下、このようなクラスのことを「仲介クラス」とよぶ）。仲介オブジェクトは、コントロールオブジェクトによってジョブオブジェクトごとに生成される。仲介クラスの機能については図１１、１２で詳述する。
【００３６】
同図に示すクラス図によれば、データフローダイアグラム３１２に対応するクラスであるジョブクラスとモデルクラスのほかに、ジョブベースクラスとモデルベースクラスが定義されている。このジョブベースクラスとモデルベースクラスがフレームワークを構成する。開発者がエンタープライズシステム２０４を設計するときには、ジョブベースクラスとモデルベースクラスの基本仕様を利用しながら、設計対象のエンタープライズシステム２０４に特有の機能をジョブクラスやモデルクラスに定義すればよい。これにより、クラスの再利用性というオブジェクト指向言語の特性を効果的に利用できる。エンタープライズシステム２０４の場合、何百、何千というジョブの基本仕様は数パターンに集約できることが多いため、オブジェクト指向言語の継承機能は特に有効である。
【００３７】
図７は、仲介クラスの継承に関するクラス図である。
NodeFlowControllerクラス５００からSTNodeFlowControllerクラス５０２が継承され、更に、STRecordStreamSourceクラス５１０、STRecordStreamMatcherクラス５１２、STRecordStreamAggregatorクラス５１４およびSTRecordStreamSinkクラス５１６の４種類の仲介クラスが継承されている。STRecordStreamSourceクラス５１０は、RecordStreamSourceクラス４８０に対応し、その処理の実行を仲介するためのクラスである。STRecordStreamMatcherクラス５１２、STRecordStreamAggregatorクラス５１４およびSTRecordStreamSinkクラス５１６は、それぞれ、RecordStreamMatcherクラス４８４、RecordStreamAggregatorクラス４８２およびRecordStreamSinkクラス４８６に対応してそれらの処理の実行を仲介するクラスである。NodeFlowControllerクラス５００から継承された４種類の仲介クラスによって、ジョブクラスの処理の実行が仲介されることになる。
以上のクラス図をふまえ、サンプルのソースコードを参照しながら、基幹的な処理の内容を処理順序にしたがって説明する。以下に示すソースコードはＪＡＶＡ（登録商標）にて記述されている。
【００３８】
図８は、エンタープライズシステムの実行開始にあたって、最初に実行される関数を示す図である。
この関数（メソッド：method）はdoTest関数である。doTest関数は、UriageProcessingModelクラス４４０のpublicでstaticなメンバ関数であり、UriageProcessingModelクラス４４０の外からコール可能である。doTest関数が実行されると、UriageProcessingModelクラス４４０がインスタンス化され、testProcessingModelという名前のモデルオブジェクトが生成される（Ｓ１００）。インスタンス化にともなって実行される詳細な処理内容については、次の図９に関連して説明する。
【００３９】
次に、SingleThreadFlowControllerクラス４５０がインスタンス化され、singleThreadFlowControllerという名前のコントロールオブジェクトが生成される（Ｓ２００）。インスタンス化にともなって実行される詳細な処理内容については、後の図１０に関連して説明する。
【００４０】
最後に、コントロールオブジェクトのdoTask関数に生成されたばかりのモデルオブジェクトが引数として渡されている（Ｓ３００）。doTask関数に関する詳細な処理内容については、図１０以降に関連して説明する。
【００４１】
まとめると、doTest関数は、モデルオブジェクトとコントロールオブジェクトを生成し、コントロールオブジェクトにモデルオブジェクトを渡して、コントロールオブジェクトに所定の処理を実行させている。
【００４２】
図９は、モデルオブジェクト生成時に実行されるソースコードを示す図である。
Ｓ１００において、UriageProcessingModelクラス４４０がインスタンス化されるときには、まず、UriageProcessingModel()として示されるコンストラクタ関数が実行される（Ｓ１０２）。このコンストラクタ関数の実行に際して、各ジョブクラスがインスタンス化される（Ｓ１０４）。ここでは、UriageProcessingModelクラス４４０のメンバ変数として、UriageSourceクラス４００、MiseMaSourceクラス４０６、UriageAggregatorクラス４０２、MiseMaMatcherクラス４０８、MiseUriageTotalSinkクラス４１０およびAreaUriageTotalSinkクラス４０４の各ジョブクラスがインスタンス化され、それぞれ、uriageSource、miseMaSource、uriageAggregator、miseMaMatcher、miseUriageTotalSinkrおよびareaUriageTotalSinkという名前のジョブオブジェクトが生成される。また、UriageProcessingModelクラス４４０のインスタンス化に際しては、モデルベースクラスが持っている関係クラス、すなわち、Connectionクラス４３０もインスタンス化される。Connectionクラス４３０は、リスト形式にて各ジョブオブジェクトのデータの依存関係を管理するためのクラスである。
【００４３】
次に、コンストラクタ関数の中の、createModel関数が実行される（Ｓ１０６）。これにより、Ｓ１０４にて生成された各ジョブオブジェクトがモデルオブジェクトにノードとしてに登録される。また、各ジョブオブジェクトが関係オブジェクトにノードとして登録される。具体的には、ここでは、以下のようなデータの依存元ジョブオブジェクトと依存先ジョブオブジェクトとが対応付けて登録される。
・（依存元オブジェクト、依存先オブジェクト）
・（uriageSourceオブジェクト、uriageAggregatorオブジェクト）
・（uriageAggregatorオブジェクト、miseMaMatcherオブジェクト）
・（uriageAggregatorオブジェクト、areaUriageTotalSinkオブジェクト）
・（miseMaSourceオブジェクト、miseMaMatcherオブジェクト）
・（miseMaMatcherオブジェクト、miseUriageTotalSinkオブジェクト）
こうして、必要なジョブオブジェクトとそのデータの依存関係が定義される。いいかえれば、モデルオブジェクトは、その生成時に、登場キャラクタたるジョブオブジェクトと、その関係を示す関係オブジェクトを生成する。
【００４４】
図１０は、コントロールオブジェクト生成時とデータフローの実行開始に際して実行されるソースコードを示す図である。
前述のごとく、図８に示したdoTest関数のＳ２００において、SingleThreadFlowControllerクラス４５０がインスタンス化される。このとき、まず、SingleThreadFlowController()として示されるコンストラクタ関数が実行される（Ｓ２０２）。このコンストラクタ関数の実行によって、ProcessingModelクラス４６０からmodelという名前の変数が用意される。このProcessingModelクラス４６０は、UriageProcessingModelクラス４４０の継承元となるモデルベースクラスであるから、この段階では、modelという名前の変数には、ＣＤの売上処理に関する具体的なモデルは設定されない。そして、SingleThreadFlowControllerクラス４５０からsingleThreadFlowControllerという名前のコントロールオブジェクトが生成されることになる。
【００４５】
こうして、図８のＳ１００とＳ２００に示した、モデルオブジェクトとコントロールオブジェクトの生成が完了し、図６に示した各クラスに基づいてさまざまなオブジェクトが生成されることになる。
【００４６】
前述のごとく、図８のdoTest関数は、モデルオブジェクトとコントロールオブジェクトの生成が終了すると、コントロールオブジェクトのdoTask関数をコールする。このとき、モデルオブジェクトがコントロールオブジェクトのdoTask関数の引数として渡されている。モデルオブジェクトは、setModel関数によって、Ｓ２０４にて生成されたmodelという名前のオブジェクトに、Ｓ１００にて生成されたＣＤの売上処理に関するtestProcessingModelという名前のモデルオブジェクトを設定している（Ｓ３１０）。こうして、コントロールオブジェクトは、処理の対象とすべき具体的なモデルオブジェクトを取得する。
【００４７】
次に、doTask関数は、ジョブオブジェクト間でデータを送受するための容れ物となるオブジェクトを設定するためのinjectRecordStream関数を実行し（Ｓ３２０）、各ジョブオブジェクトにより処理の実行の仲介役となる仲介オブジェクトを生成するためのinjectFlowController関数を実行する（Ｓ３３０）。最後に、mainTask関数を実行して、モデルオブジェクトが包含する各ジョブオブジェクトに処理を実行させる（Ｓ３４０）。
【００４８】
図１１は、図１０のＳ３２０からＳ３４０までの処理に対応するソースコードを示す図である。
前の図１０に示したdoTask関数のＳ３２０の実行にともなって、injectRecordStream関数が実行される。これによって、ジョブオブジェクト間でデータを受け渡すためのオブジェクトとして、STRecordStreamクラスがインスタンス化される。このように、ジョブオブジェクト間においてデータ受け渡しするための基本的なインタフェースも、コントロールオブジェクト側にて定義される。次に、doTask関数のＳ３３０の実行にともなって、injectFlowController関数が実行される。injectFlowController関数は、モデルオブジェクトに登録されたジョブオブジェクトを順次取得しながら、各ジョブオブジェクトについてinjectFlowControllerToNode関数を実行する（Ｓ３３２）。
【００４９】
このinjectFlowControllerToNode関数においては、ジョブオブジェクトがどのタイプのジョブベースクラスに基づくかが判定される。そして、基づくジョブベースに応じた仲介オブジェクトが生成される。たとえば、ジョブオブジェクトがuriageSourceオブジェクトまたはmiseMaSourceオブジェクトの場合は、RecordStreamSourceクラス４８０に基づくので、STRecordStreamSourceオブジェクトが生成される。また、たとえば、UriageAggregatorオブジェクトの場合は、RecordStreamAggregatorクラス４８２に基づくので、STRecordStreamAggregatorオブジェクトが設定される。こうして、４種類の仲介オブジェクトのうちのいずれかが生成される。そして、setTargetNode関数によって、仲介オブジェクトのメンバ変数に、対応するジョブオブジェクトが設定される。つまり、仲介オブジェクトに、対応するジョブオブジェクトへの参照が設定される（Ｓ３３４）。この仲介オブジェクトの生成とジョブオブジェクトへの参照の設定が、ジョブオブジェクトの数だけ繰り返される。
【００５０】
次に、doTask関数のＳ３４０の実行にともなって、mainTask関数が実行される。mainTask関数は、エンタープライズシステムを実際に稼働されるための関数である。図３のデータフローダイアグラム３１２に示したように、全体としての処理は、売上データ３００を前提として開始される。そのため、まず、モデルオブジェクトに登録されたジョブオブジェクト順次取得しながら、RecordStreamSourceクラス４８０に基づくジョブオブジェクトを検出する（Ｓ３４２）。ただし、MiseMaSourceオブジェクトのように、他のジョブオブジェクトによる中間データと共に利用されるジョブオブジェクトの場合には、RecordStreamSourceクラス４８０に基づくジョブオブジェクトであっても、ここでは処理対象としない（Ｓ３４４）。isMaSource関数は、これを調べるための関数である。
【００５１】
UriageSourceオブジェクトが検出されると、対応する仲介オブジェクトが取り出され（Ｓ３４６）、その仲介オブジェクトのdoTask関数が実行される（Ｓ３４８）。
【００５２】
図１２は、仲介オブジェクトを介してジョブオブジェクトに処理を実行させる過程に対応したソースコードの一例を示す図である。
同図に示すソースコードは、UriageSourceオブジェクトの仲介オブジェクトとなるSTRecordStreamSourceクラス５１０が、自処理の開始に際して呼び出すdoTask関数を示す。なお、他の仲介クラスもdoTask関数をメンバ関数として備える。STRecordStreamSourceクラス５１０のdoTask関数においては、まず、UriageSourceクラス４００のメンバ関数であるdoRead関数を呼び出し、doRead関数によって、UriageSourceクラス４００で実装された処理が実行される（Ｓ３５０）。具体的には、店マスタデータ３０６という所定のマスタデータを読み出す処理が実行される。つまり、RecordStreamSourceクラスに基づくジョブオブジェクトを設計する開発者がdoRead関数に所望の処理内容を定義すれば、あらかじめ用意されている仲介クラスのオブジェクトによって適切なタイミングで呼び出されて実行される。
【００５３】
次に、doWrite関数を実行し、関係オブジェクトを参照して次の処理対象となるジョブオブジェクトを特定するとともに、特定したジョブオブジェクトの仲介オブジェクトを取り出して、その仲介オブジェクトのdoTask関数を実行する（Ｓ３５２）。ここでは、UriageAggregatorオブジェクトを特定するとともに、その仲介オブジェクトとなるSTRecordStreamAggregatorクラス５１４を取り出して、そのdoTask関数を実行する。以後は図示しないが、このdoTask関数も、自分の処理が終了するときには、AreaUriageTotalSinkオブジェクトとMiseMaMatcherオブジェクトを次の処理対象として特定する。なお、MiseMaMatcherクラス４０８の処理オブジェクトは、自分の処理に先立って、MiseMaSourceクラス４０６の処理オブジェクトにdoTask関数の実行を指示し、その実行結果を待ってから、自分の処理を実行し、MiseUriageTotalSinkオブジェクトを次の処理対象として特定する。
【００５４】
このように、データフローダイアグラム３１２に示された、いいかえれば、関係オブジェクトに管理されている各ジョブオブジェクトのデータの依存関係にしたがって、複数のジョブオブジェクトが連鎖的に処理を実行することになる。
【００５５】
以上の実施例に示したジョブ管理装置１００によれば、モデルオブジェクトとコントロールオブジェクトによって、ジョブの処理内容の管理とジョブの実行方法の管理とを明確に分離することができる。
ＣＯＢＯＬなどの手続き型言語の場合、これら２種類の定義は一体としてなされることが多かった。そのため、開発者は、ジョブの静的な関係定義と動的な処理定義を同時に意識しながらシステムを設計する必要があった。これに対して、本実施例にて示したフレームワークによれば、これら２種類の定義を明確に分離できる。そのため、ジョブの処理定義に過度に影響されることなく、ジョブの関係定義を行うことができる。また、その逆も真である。このような、分離設計を可能とするフレームワークは、エンタープライズシステム２０４の拡張性・保守性・堅牢性を高めることができる。
【００５６】
たとえば、一部のジョブオブジェクトにだけ処理を注入することにより、エンタープライズシステム２０４の一部の機能だけをテストする作業を、コントロールオブジェクト側の変更操作だけで実現できる。
具体例として、１００個のジョブオブジェクトによって構成されるエンタープライズシステム２０４のうち、３個のジョブオブジェクトの機能だけをテストしたい場合について説明する。このような場合、まず、１００個のジョブオブジェクトを生成しておく。そして、実際には、この３個のジョブオブジェクトにだけ処理を注入する。次に、さきほどの３個のジョブオブジェクトを含む５個のジョブオブジェクトの機能をテストしたい場合には、生成済の１００個のジョブオブジェクトのうち、今度は５個のジョブオブジェクトに処理を注入する。すなわち、はじめに１００個のジョブオブジェクトを生成しておけば、２回目のテストのために新たにテスト対象として加わった２個のジョブオブジェクトを生成する必要がない。このような処理方法によると、最初に全てのジョブオブジェクトを生成しておけば、テスト対象の変更により新たなインスタンス化処理を実行しなくて済むというメリットがある。
【００５７】
本実施例に示すエンタープライズシステム２０４の場合、ジョブオブジェクトはすべてモデルクラスによって生成され、他のジョブクラスから生成されることはない。このため、ジョブオブジェクトの生成に関しても、ジョブクラスに先天的な依存関係を持たさなくて済む。これにより、各ジョブクラスの独立性を高めることができる。また、プログラマは、UriageProcessingModelクラス４４０を参照することにより、処理対象となるジョブクラスを一元的に参照できるため、ソースコードの可読性を高める効果もある。
【００５８】
また、図６に関連して説明したように、ジョブクラスは典型的な４つのジョブベースクラスのいずれかを継承するかたちで定義されているため、何十、何百、何千というジョブオブジェクトを制御する場合であっても、ジョブクラスの設計負担が大幅に軽減される。これは、処理クラスやモデルクラスなど他のクラスについても同様である。
【００５９】
更に、Ｓ３３２のinjectFlowControllerToNode関数に示したように、各ジョブクラスの由来に応じて、割り当てるべき仲介クラスが特定されている。したがって、多種類のジョブクラスに対して、多種類の処理クラスを割り当てる場合であっても、ジョブクラスのタイプに応じて、処理クラスのタイプを結びつけるという方法により、ジョブクラスと処理クラスの対応関係に関するソースコードの可読性が向上する。
【００６０】
本実施例においては、シングルスレッドモデルを前提としてシステムを説明したが、これをマルチスレッド化することも容易である。たとえば、SingleThreadFlowControllerクラス４５０のmainTask関数は、RecordStreamSourceクラス４８０に基づくジョブオブジェクトであるか否かにかかわらず、全てのジョブオブジェクトに対して一斉にdoTask関数の開始を指示してもよい。
【００６１】
マルチスレッドモデルについて図４を再度参照しながら説明する。なお、ここでは図４のSingleThreadFlowControllerクラス４５０は、MultiThreadFlowControllerクラス４５０と読み替える。
まず、モデルオブジェクトには、シングルスレッドモデルとマルチスレッドモデルとのいずれのモデルとしてジョブを実行されるかを示す情報も定義される。マルチスレッドモデルとしてジョブを実行させる場合は、MultiThreadFlowControllerクラス４５０は、各ジョブオブジェクトの仲介オブジェクトのメンバ関数であるdoTask関数に実行を指示する。ここで、各doTask関数はマルチスレッド化されており、時間的に並行して実行可能な関数である。このdoTask関数の実行指示により対応する各ジョブオブジェクトの所定のメンバ関数が呼び出され、ジョブの処理が開示されるが、各処理は実行待機状態に移行する。ただし、UriageSourceオブジェクトについての処理関数だけは即座に実行開始となる。
【００６２】
UriageSourceオブジェクトについての処理が完了すると、UriageAggregatorオブジェクトの処理が実行状態となる。UriageAggregatorクラス４０２の処理が完了すると、AreaUriageTotalSinkクラス４０４とMiseMaMatcherクラス４０８は同時並行的に実行状態となる。AreaUriageTotalSinkクラス４０４とMiseMaMatcherクラス４０８はデータの依存関係を持たないので並行処理が可能である。MiseMaMatcherクラス４０８は自己の処理を実行するために、MiseMaSourceクラス４０６の処理の実行を指示し、その処理結果を受けたときに自分の処理が実行状態になる。このときに、並行してAreaUriageTotalSinkオブジェクトの処理は実行されている。このように、ＣＯＢＯＬが苦手なマルチタスク処理を、マルチスレッド処理として実現できるため、システム全体としてのパフォーマンスを向上させることができる。特に、ＤＦＤにおいて、フローが枝分かれするほど、同時並行的に実行できる処理関数を増やすことができる。
【００６３】
また、ジョブ管理装置１００の機能は、複数のハードウェア資源によって実現されてもよい。たとえば、コントロールオブジェクトに各ジョブオブジェクトが配置されるべき実行装置を示す情報が定義され、この情報に基づきジョブオブジェクトと仲介オブジェクトとが複数のジョブ実行装置に分散配置されてもよい。このような態様によれば、ジョブ実行装置Ａでジョブオブジェクトαの処理を実行しつつ、ジョブ実行装置Ｂでジョブオブジェクトβの処理を実行するという処理方法が可能となる。これにより、時間的な効率化だけでなく、処理負荷の分散も効率的に行うことができる。コントロールクラスは、ジョブ実行装置群において処理負荷が局所化しないように、他のジョブ実行装置よりも処理負荷が軽い状態にあるジョブ実行装置に対して優先的にジョブを割り当ててもよい。従来、ジョブの分散配置を実現するためには、複数のジョブ実行装置への分散配置を前提とした設計が必要であったが、本実施例に示した設計方法によれば、ジョブ管理装置１００から外部のジョブ実行装置にジョブの実行主体を移行させるのが容易となる。
【００６４】
以上、実施の形態をもとに本発明を説明した。なお本発明はこの実施の形態に限定されることなく、そのさまざまな変形例もまた、本発明の態様として有効である。たとえば、本実施例においては、エンタープライズシステムを想定して説明したが、より具体的には、電子商取引、物流管理などへの応用が考えられる。また、本実施例において示したフレームワークは、ワークフロー管理のように、複数のジョブを定義して制御するというモデルに広く応用可能である。
【００６５】
請求項に記載のオブジェクト生成部および実行制御部の機能は、本実施例においては主としてSingleThreadFlowControllerクラス４５０によって実現される。請求項に記載のメンバ関数は、本実施例においては、たとえばＳ３４８にて示した、各仲介クラスのdoTask関数が相当する。
請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【００６６】
本発明は上述の各実施形態に限定されるものではなく、各実施形態の各要素を適宜組み合わせたものも、本発明の実施形態として有効である。また、当業者の知識に基づいて各種の設計変更等の変形を各実施形態に対して加えることも可能であり、そのような変形が加えられた実施形態も本発明の範囲に含まれうる。
【００６７】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００６８】
請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【符号の説明】
【００６９】
１００  ジョブ管理装置、  １１０  ユーザインタフェース処理部、  １２０  通信部、  １３０  データ処理部、  １４０  モデル管理部、  １５０  フロー制御部、  １６０  データ保持部、  １７０  オブジェクト保持部、  ２００  ノード端末、  ２０２  インターネット、  ２０４  エンタープライズシステム、  ２０６  データベース、  ３００  売上データ、  ３０２  売上集約処理、  ３０４  地区別売上データ、  ３０６  店マスタデータ、  ３０８  店名追加処理、  ３１０  店別売上データ、  ３１２  データフローダイアグラム、  ４００  UriageSourceクラス、  ４０２  UriageAggregatorクラス、  ４０４  AreaUriageTotalSinkクラス、  ４０６  MiseMaSourceクラス、  ４０８  MiseMaMatcherクラス、  ４１０  MiseUriageTotalSinkクラス、  ４２０  ジョブクラス群、  ４３０  Connectionクラス、  ４４０  UriageProcessingModelクラス、  ４５０  SingleThreadFlowControllerクラス、  ４６０  ProcessingModelクラス、  ４８０  RecordStreamSourceクラス、  ４８２  RecordStreamAggregatorクラス、  ４８４  RecordStreamMatcherクラス、  ４８６  RecordStreamSinkクラス、  ４９０  Nodeクラス、  ５００  NodeFlowControllerクラス、  ５０２  STNodeFlowControllerクラス、  ５１０  STRecordStreamSourceクラス、  ５１２  STRecordStreamMatcherクラス、  ５１４  STRecordStreamAggregatorクラス、  ５１６  STRecordStreamSinkクラス。
【図１】
2014021665.tif 000003
【図２】
2014021665.tif 000004
【図３】
2014021665.tif 000005
【図４】
2014021665.tif 000006
【図５】
2014021665.tif 000007
【図６】
2014021665.tif 000008
【図７】
2014021665.tif 000009
【図８】
2014021665.tif 000010
【図９】
2014021665.tif 000011
【図１０】
2014021665.tif 000012
【図１１】
2014021665.tif 000013
【図１２】
2014021665.tif 000014