米国特許情報 | 欧州特許情報 | 国際公開(PCT)情報 | Google の米国特許検索
 
     特許分類
A 農業
B 衣類
C 家具
D 医学
E スポ−ツ;娯楽
F 加工処理操作
G 机上付属具
H 装飾
I 車両
J 包装;運搬
L 化学;冶金
M 繊維;紙;印刷
N 固定構造物
O 機械工学
P 武器
Q 照明
R 測定; 光学
S 写真;映画
T 計算機;電気通信
U 核技術
V 電気素子
W 発電
X 楽器;音響


  ホーム -> 計算機;電気通信 -> 株式会社野村総合研究所

発明の名称 ジョブ管理装置およびジョブ管理方法
発行国 日本国特許庁(JP)
公報種別 公開特許公報(A)
公開番号 特開2007−156791(P2007−156791A)
公開日 平成19年6月21日(2007.6.21)
出願番号 特願2005−350643(P2005−350643)
出願日 平成17年12月5日(2005.12.5)
代理人 【識別番号】100105924
【弁理士】
【氏名又は名称】森下 賢樹
発明者 木村 綾太郎
要約 課題
オブジェクト指向言語に基づいてエンタープライズシステムを開発する。

解決手段
UriageProcessingModelクラス440は、各ジョブオブジェクトの関係を定義する。UriageProcessingModelクラス440は、ジョブオブジェクトのクラス群420(以下「ジョブクラス」)と、各ジョブオブジェクトの依存関係をリストとして管理するConnectionクラス430のオブジェクトを持つ。UriageProcessingModelクラス440は、ジョブとその依存関係をジョブオブジェクトのクラス群420とConnectionクラス430の機能を使って管理することになる。SingleThreadFlowControllerクラス450は、各ジョブオブジェクトで必要とする処理内容を定義するクラスである。SingleThreadFlowControllerクラス450によって各ジョブに後天的に処理が注入される。
特許請求の範囲
【請求項1】
前段にあたるジョブの出力データに基づいて後段にあたるジョブが実行されるように依存関係が定められた複数のジョブを実行するための装置であって、
ジョブのタイプに応じてあらかじめ定義されたクラスから、ジョブオブジェクトを生成するジョブオブジェクト生成部と、
各ジョブオブジェクトの依存関係を示すジョブリスト情報を生成するジョブリスト情報生成部と、
ジョブの処理内容を示す処理関数を、ジョブオブジェクトが生成された後に設定する処理注入部と、
前記ジョブリスト情報を参照してジョブオブジェクトを選択し、そのジョブオブジェクトについて設定された処理関数を実行させる実行指示部と、
を備えることを特徴とするジョブ管理装置。
【請求項2】
前記実行指示部によって選択されたジョブオブジェクトの処理関数は、前記ジョブリスト情報に基づいて次に出力データを渡すべきジョブを特定し、特定したジョブについての処理関数を実行させることを特徴とする請求項1に記載のジョブ管理装置。
【請求項3】
ジョブオブジェクトは、他のジョブオブジェクトによって生成されることはなく、前記ジョブオブジェクト生成部によって直接生成されることを特徴とする請求項1または2に記載のジョブ管理装置。
【請求項4】
前記ジョブオブジェクト生成部と前記ジョブリスト情報生成部の各機能をその機能の一部として含むオブジェクトとしてモデルオブジェクトを生成するモデルオブジェクト生成部と、
前記処理注入部と前記実行指示部の各機能をその機能の一部として含むオブジェクトとしてコントロールオブジェクトを生成するコントロールオブジェクト生成部と、を更に備え、
前記コントロールオブジェクトは、前記モデルオブジェクトを処理対象とすることによって、前記処理注入部と前記実行指示部の各機能を発揮させることを特徴とする請求項1から3のいずれかに記載のジョブ管理装置。
【請求項5】
ジョブオブジェクトは、処理関数をメンバ関数として含む処理オブジェクトと関連づけられ、
前記処理注入部は、ジョブオブジェクトの生成後に、ジョブオブジェクトに処理オブジェクトを設定することにより、ジョブオブジェクトについての処理関数を設定することを特徴とする請求項1から4のいずれかに記載のジョブ管理装置。
【請求項6】
前記処理注入部は、ジョブオブジェクトが基づくクラスのタイプに応じて、設定すべき処理オブジェクトを選択することを特徴とする請求項5に記載のジョブ管理装置。
【請求項7】
各処理関数は時間的に並行して実行可能であって、
所定の処理関数は、前記ジョブリスト情報を参照して次に実行すべき複数の処理関数を特定し、前記複数の処理関数を時間的に並行して実行させることを特徴とする請求項1から6のいずれかに記載のジョブ管理装置。
【請求項8】
前記ジョブオブジェクト生成部は、ネットワークを介して接続された複数の外部装置に対して複数のジョブオブジェクトを分散配置可能であり、
前記複数の外部装置に分散配置された各ジョブオブジェクトの処理関数は時間的に並行して実行可能であることを特徴とする請求項1から7のいずれかに記載のジョブ管理装置。
【請求項9】
組織業務の構成単位としてのジョブに対応するジョブオブジェクトを、ジョブのタイプに応じてあらかじめ定義されたクラスから生成するステップと、
各ジョブオブジェクトの依存関係を示すジョブリスト情報を生成するステップと、
ジョブの処理内容を示す処理関数を、ジョブオブジェクト生成後に設定するステップと、
前記ジョブリスト情報を参照してジョブオブジェクトを選択し、そのジョブオブジェクトについて設定された処理関数を実行させるステップと、
を備えることを特徴とするジョブ管理方法。
【請求項10】
前段にあたるジョブの出力データに基づいて後段にあたるジョブが実行されるように、複数のジョブの依存関係を定義するオブジェクトとしてモデルオブジェクトを生成する機能と、
各ジョブの処理内容を定義するコントロールオブジェクトを生成する機能と、
コントロールオブジェクトの第1のメンバ関数を実行することにより、モデルオブジェクトにおいて定義されるジョブの処理内容を設定する機能と、
コントロールオブジェクトの第2のメンバ関数を実行することにより、第1のジョブについての処理を実行させる機能と、
前記依存関係にしたがって、前記第1のジョブの出力データを渡すべき第2のジョブを特定する機能と、
前記第2のジョブについての処理を実行させる機能と、
をコンピュータに発揮させることにより、複数のジョブを依存関係にしたがって実行させることを特徴とするジョブ管理プログラム。
発明の詳細な説明
【技術分野】
【0001】
この発明は、ジョブの実行を制御するための技術、特に、依存関係を有する複数のジョブを実行制御するための技術、に関する。
【背景技術】
【0002】
企業や公共施設などの運用を支えるエンタープライズシステム(Enterprise System)は、今や、大小さまざまな組織の基盤システムとして導入されている。エンタープライズシステムは、ノード端末やデータベースから得られるデータを集計、蓄積、解析、加工した上でより付加価値の高い情報を出力する。エンタープライズシステムは複雑化する組織マネジメントをより効率化するために発展を続けている。
【0003】
このようなエンタープライズシステムは、ジョブの集合体としてモデリングされることが多い。ジョブとは、データベースの更新処理や、各ノード端末から得られたデータに対する演算処理など、システムにおいて基本的な実行単位となる処理である。これらのジョブは、前段にあたるジョブの実行結果に基づいて後段にあたるジョブが実行されるように互いに依存関係を有したかたちで設計される。
【0004】
エンタープライズシステムの構築にあたっては、COBOL(COmmon Business Oriented Language)などの手続き型言語が広く採用されている。COBOLは、その文法がシンプルであることから、エンタープライズシステムにおいてジョブを順次処理するという処理モデルにおいては実績のある言語である。
【特許文献1】特開平7−129415号公報
【発明の開示】
【発明が解決しようとする課題】
【0005】
その一方、JAVA(登録商標)やC++などのオブジェクト指向言語が、ソフトウェア開発の現場において急速に普及しつつある。オブジェクト指向言語は、データとそのデータにアクセスするためのインタフェースをクラス(class)としてカプセル化する。クラスという一種の構造体によってデータが保護されるため、オブジェクト指向言語は、コードの再利用性・保守性・堅牢性などの諸点において手続き型言語よりも優れている。オブジェクト指向言語が普及するにつれて、開発現場でもCOBOLプログラマよりもJAVA(登録商標)プログラマの方が増加しつつある。とりわけ、中国・台湾・インドをはじめとする東アジア諸国では、COBOLプログラマよりもJAVA(登録商標)プログラマの方が確保しやすい。加えて、団塊の世代が一斉に定年退職する、いわゆる2007年問題によって、熟練したCOBOLプログラマの多くが現場を去るという直近の事情もある。
このような背景から、JAVA(登録商標)によってエンタープライズシステムを開発する必要性が顕在化しつつあると本発明者は認識した。
【0006】
ただし、大量のデータをバッチ処理する形態となることが多いエンタープライズシステムにおいてオブジェクト指向言語の優位性を発揮させるためには、手続き型言語による設計思想とは異なる設計思想に基づく必要がある。オブジェクト指向言語の特徴はソフトウェアの部品化であり、クラスの機能をいかに定義するかによってそのクラスの有用性が決まる。本発明者は、オブジェクト指向言語を前提としてエンタープライズシステムを設計するための新たなフレームワークを提供することにより、その優位性を好適に発揮させることができると想到した。
【0007】
本発明はこうした状況に鑑みてなされたものであり、その主たる目的は、オブジェクト指向言語に基づいて、複数のジョブを実行制御するシステムを効率的に設計するための技術、を提供することにある。
【課題を解決するための手段】
【0008】
本発明のある態様は、前段にあたるジョブの実行結果に基づいて後段にあたるジョブが実行されるように依存関係が定められた複数のジョブを実行するためのジョブ管理装置である。
この装置は、ジョブのタイプに応じてあらかじめ定義されたクラスからジョブオブジェクトを生成し、各ジョブオブジェクトの依存関係を示すジョブリスト情報を生成する。そして、ジョブの処理内容を示す処理関数を、ジョブオブジェクトが生成された後に設定した上で、ジョブリスト情報に基づいて選択したジョブオブジェクトの処理関数を実行させる。
【0009】
なお、以上の構成要素の任意の組合せ、本発明を方法、装置、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。
【発明の効果】
【0010】
本発明によれば、オブジェクト指向言語に基づくジョブの実行制御システムを効率的に設計する上で効果がある。
【発明を実施するための最良の形態】
【0011】
図1は、エンタープライズシステムのハードウェア構成図である。
エンタープライズシステム204は、企業や公共施設のような組織の業務管理のために導入されるシステムである。エンタープライズシステム204は、地理的に分散された複数の組織を統合するシステムとして構成されてもよい。
【0012】
本実施例におけるエンタープライズシステム204は、ジョブ管理装置100、ノード端末200およびデータベース206を含む。これらは、インターネット202を介して互いに接続されている。
ジョブ管理装置100は、各ジョブの関係を定義したデータフローダイアグラム(DFD:Data Flow Diagram)にしたがって複数のジョブを順次実行する。データフローダイアグラム(以下、「DFD」ともよぶ)については、後に図3等に関連して詳述する。また、ジョブ管理装置100の機能については、次の図2以降に関連して詳述する。
【0013】
ノード端末200は、ユーザが業務遂行のために使用するコンピュータ端末である。ノード端末200は業務上のさまざまなデータを取得する。ジョブ管理装置100は、ジョブの実行に際して、ノード端末200やデータベース206とデータを送受する。ジョブ管理装置100は、ノード端末200やデータベース206から取得したデータに基づいて各種のジョブを実行する。
【0014】
まとめると、ノード端末200やデータベース206から得られるデータを変数として、ジョブ管理装置100はさまざまなジョブを実行する。また、ジョブ管理装置100は、各ジョブの実行タイミングを統合的に制御する。このように、ノード端末200やデータベース206から得られるデータに基づいて、あらかじめ処理内容が定義されたジョブが順次実行されることにより、エンタープライズシステム204全体としての運用がなされている。
【0015】
図2は、ジョブ管理装置の機能ブロック図である。
ここに示す各ブロックは、ハードウェア的には、コンピュータのCPUをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
ここでは、主として各機能ブロックの発揮すべき機能について述べ、その具体的な作用については、図3以降に関連して説明する。
【0016】
ジョブ管理装置100は、ユーザインタフェース処理部110、通信部120およびデータ処理部130を含む。
ユーザインタフェース処理部110は、ユーザからの入力処理やユーザに対する情報表示のようなユーザインタフェース全般に関する処理を担当する。通信部120は、ノード端末200やデータベース206との通信処理を担当する。データ処理部130は、ユーザインタフェース処理部110や通信部120から取得されたデータを元にして各種のデータ処理を実行する。データ処理部130は、ユーザインタフェース処理部110および通信部120の間のインタフェースの役割も果たす。
【0017】
データ処理部130は、モデル管理部140とフロー制御部150を含む。
モデル管理部140は、各ジョブの依存関係を示す「静的なモデル」に関するデータを管理する。フロー制御部150は、各ジョブの処理内容を定義するとともに、各ジョブの実行を制御する。ここで注目すべきは、本実施例におけるジョブ管理装置100においては、ジョブの静的な依存関係を管理するモデル管理部140と、ジョブの動的な処理内容を管理するフロー制御部150が機能上分離されていることである。そのため、ジョブの「依存関係の定義」と「処理内容の定義」について、一方の設計作業が他方の設計内容によって制約されない枠組み(フレームワーク)となっている。
以上をふまえて、より具体的なソフトウェア構造について説明する。
【0018】
図3は、本実施例におけるデータフローダイアグラムを示す図である。
同図に示すデータフローダイアグラム312は、所定の期間における4つCD(Compact Disc)店のCDの売上枚数を集計して、地域別および店別の売上枚数を計算するという処理過程を示している。このデータフローダイアグラム312には、売上データ300、売上集約処理302、地区別売上データ304、店マスタデータ306、店名追加処理308および店別売上データ310の6つの構成要素(Entity)が定義されている。
【0019】
売上データ300は、4つのCD店におけるCD売上枚数を示すデータである。ここで、CD店を識別するために、各CD店には「01」〜「04」として示す「店ID」が付与されている。また、各CD店が所属する地区を識別するために、各地区には「A」または「B」として示す「地区ID」が付与されている。売上データ300によれば、「01」および「02」のCD店は、「A」地区に属し、「03」と「04」のCD店は「B」地区に属している。ここで「01」のCD店には、2つのノード端末200が設置されており、それぞれのノード端末200からは、CD売上枚数として「1枚」と「2枚」が入力されている。同様に「02」や「04」のCD店にも、2つのノード端末200が設置されている。すなわち、売上データ300は、2つの地区、4つのCD店、7つのノード端末200から得られるデータである。
【0020】
売上集約処理302は、各CD店に設置されるノード端末200から得られた売上データ300をまとめて、CD店ごとのCD売上枚数を計算する。そして、このCD店ごとのCD売上枚数に関する情報(以下、「中間データ」とよぶ)を店名追加処理308に渡す。その一方、地区ごとのCD売上枚数を計算して地区別売上データ304を生成する。
【0021】
店名追加処理308は、売上集約処理302から受け取った中間データと店マスタデータ306に基づいて、店別売上データ310を生成する。店マスタデータ306は、店IDと店名を対応づけるデータであり、データベース206から得られるデータである。店別売上データ310は、CD店ごとのCD売上枚数を集計したデータであり、かつ、店IDだけでなく対応する店名も含むデータである。
【0022】
仮に、データフローダイアグラム312をCOBOLによって実装するとする。COBOLはマルチスレッド環境を想定して設計された言語ではない。そのため、売上集約処理302と店名追加処理308をマルチタスク処理として定義する場合、売上集約処理302のメモリ空間と、店名追加処理308のメモリ空間は別々に割り当てられることになる。したがって、売上集約処理302は、中間データをいったんファイル化し、店名追加処理308はこのファイルから中間データを読み出すという処理方法になる。
【0023】
これに対し、本実施例において使用されるプログラミング言語であるJAVA(登録商標)は、マルチスレッド環境にて使用されることを充分に想定して設計された言語である。そのため、売上集約処理302と店名追加処理308をマルチタスク処理として定義する場合でも、各処理は別々のスレッドにて実行可能である。同一プロセス空間に属するスレッド間でメモリを共有するのは簡単であることから、売上集約処理302は、中間データをファイル化しなくても、店名追加処理308に渡すことができる。このようなマルチスレッドに関する優位性と実現性については後に詳述する。
【0024】
本実施例においては、データフローダイアグラム312に含まれる6つの構成要素を「ジョブ」として定義し、各ジョブごとにクラス(以下、「ジョブクラス」ともよぶ)を定義する。フロー制御部150は、ジョブクラスをインスタンス化することにより生成されるオブジェクト(以下、「ジョブオブジェクト」ともよぶ)に対して、その処理内容を設定することになる。以下においては、「Xクラス(「X」は文字列)」をインスタンス化して生成されるオブジェクトのことを単に「Xオブジェクト」と表記するものとする。
【0025】
図4は、図3のDFDに対応するジョブクラスの依存関係を示す図である。
UriageSourceクラス400は、売上データ300に対応するジョブクラスであり、売上データ300を各CD店のノード端末200から収集して保持するクラスである。UriageAggregatorクラス402は、売上集約処理302に対応するジョブクラスである。以下、同様に、AreaUriageTotalSinkクラス404は地区別売上データ304、MiseMaSourceクラス406は店マスタデータ306、MiseMaMatcherクラス408は店名追加処理308、MiseUriageTotalSinkクラス410は店別売上データ310にそれぞれ対応するジョブクラスである。
【0026】
ここで、UriageSourceクラス400が、UriageAggregatorクラス402へ売上データ300を渡したり、UriageAggregatorクラス402をインスタンス化するための処理が記述されると、UriageSourceクラス400とUriageAggregatorクラス402の結合が強くなってしまう。ジョブクラス同士の結合が強くなると、あるジョブクラスの依存関係や処理内容の変更が他の多くのジョブクラスのパフォーマンスに影響しやすくなってしまうため望ましくない。いいかえれば、再利用性・保守性・堅牢性に優れたジョブクラスを設計するためには、ジョブクラス同士の結合が弱い方が望ましい。
そこで、本実施例においては、UriageSourceクラス400からMiseUriageTotalSinkクラス410までの各ジョブクラスに対して、後述するNodeFlowControllerクラス500によって後天的に「処理を注入する(inject)」という手法を採用している。すなわち、ジョブクラスそのものは、先天的には依存関係を持たないかたちで設計されている。
【0027】
図5は、ジョブ管理装置の基本的な機能を実現するためのクラスの関係を示す模式図である。より詳細には、次の図6および図7に関連して説明するが、同図において、まず、クラスの関係の概要を示す。
UriageProcessingModelクラス440は、データフローダイアグラム312に示した各ジョブクラスの関係を定義するクラスである。UriageProcessingModelクラス440は、図4に示した6つのジョブクラスを含むジョブクラス群420を持つ。同図に示す菱形記号は、UML(Unified Modeling Language)の表記法に基づき、「集約(aggregation)」を示す記号である。すなわち、UriageProcessingModelクラス440は、その一部としてジョブクラス群420を持つ。したがって、UriageProcessingModelクラス440がインスタンス化されるときには、その一部であるジョブクラス群420も付随してインスタンス化される。UriageProcessingModelオブジェクトは、各ジョブオブジェクトを持つことになる。
【0028】
UriageProcessingModelクラス440は、Connectionクラス430も持つ。Connectionクラス430は、ジョブクラス群420における各ジョブクラスの依存関係をリストとして管理するクラスである(以下、このようなタイプのクラスのことを「関係クラス」とよぶ)。UriageProcessingModelクラス440は、ジョブとその依存関係をジョブクラス群420とConnectionクラス430の機能を使って管理することになる。
【0029】
SingleThreadFlowControllerクラス450は、各ジョブクラスの処理内容を定義するクラスである。SingleThreadFlowControllerクラス450の機能によって、エンタープライズシステム204が実際に稼働することになる。SingleThreadFlowControllerクラス450は、UriageProcessingModelクラス440を持っている。より厳密には、SingleThreadFlowControllerクラス450は、UriageProcessingModelクラス440への参照(reference)を設定されているが、本明細書では、参照も含めて「持つ」と定義する。したがって、UriageProcessingModelクラス440がインスタンス化されるときには、UriageProcessingModelクラス440、更に、ジョブクラス群420とConnectionクラス430が連鎖的ににインスタンス化されることになる。
【0030】
先の図2に示した機能ブロック図と対比すると、モデル管理部140の機能はUriageProcessingModelクラス440、ジョブクラス群420、Connectionクラス430の各機能によって実現され、フロー制御部150の機能はSingleThreadFlowControllerクラス450の機能によって実現されることになる。以下、UriageProcessingModelクラス440のようなジョブの関係を定義するクラスことを「モデルクラス」、SingleThreadFlowControllerクラス450のようなジョブの処理内容を定義するクラスのことを「コントロールクラス」とよぶ。
【0031】
図6は、ジョブクラスとモデルクラスの関係を示すクラス図である。
前の図5に示したように、UriageProcessingModelクラス440は、UriageSourceクラス400からMiseUriageTotalSinkクラス410までの6つのジョブクラスを持つ。UriageProcessingModelクラス440自体は、SingleThreadFlowControllerクラス450に持たれている。UriageProcessingModelクラス440は、ProcessingModelクラス460を継承するモデルクラスである。すなわちUriageProcessingModelクラス440は、ProcessingModelクラス460において定義された機能を受け継ぎつつ、CDの売上処理を管理するために特有の機能が追加されたクラスとして定義される。ProcessingModelクラス460の作成にあたっては、CDの売上処理を管理するために特有の機能のみを追加すればよいので、スクラッチからUriageProcessingModelクラス440自体を作成するのに比べて、開発や保守にともなう負担が軽減される。以下、ProcessingModelクラス460のように、モデルクラスの継承元となる、基本的なクラスのことを「モデルベースクラス」とよぶことにする。ProcessingModelクラス460は、Connectionクラス430を持つ。したがって、ProcessingModelクラス460を継承するUriageProcessingModelクラス440も、Connectionクラス430を持つことになる。
【0032】
6つのジョブクラスのうち、UriageSourceクラス400とMiseMaSourceクラス406はRecordStreamSourceクラス480を継承するジョブクラスである。RecordStreamSourceクラス480は、売上データ300や店マスタデータ306のようにジョブの前提となるデータを管理するための基本仕様が定義されたクラスである。UriageAggregatorクラス402は、RecordStreamAggregatorクラス482を継承する。RecordStreamAggregatorクラス482は、売上集約処理302のようにデータを集約するジョブについての基本仕様が定義されたクラスである。MiseMaMatcherクラス408は、RecordStreamMatcherクラス484を継承する。RecordStreamMatcherクラス484は、店名追加処理308のように2種類のデータを結合するジョブについての基本仕様が定義されたクラスである。MiseUriageTotalSinkクラス410とAreaUriageTotalSinkクラス404は、RecordStreamSinkクラス486を継承する。RecordStreamSinkクラス486は、地区別売上データ304や店別売上データ310のようにジョブの処理結果として生成されるデータを管理するための基本仕様が定義されたクラスである。
このように、6つのジョブクラスは、4種類のクラス(以下、「ジョブベースクラス」とよぶ)のいずれかを継承している。更に遡ると、すべてのジョブベースクラスは、Nodeクラス490を継承する。Nodeクラス490は、ジョブのタイプによらない基本的な仕様が定義されたクラスである。
【0033】
Nodeクラス490は、NodeFlowControllerクラス500を包含する。NodeFlowControllerクラス500は、ジョブオブジェクトの処理内容を決定するためのクラスである(以下、このようなクラスのことを「処理クラス」とよぶ)。そのため、ジョブクラスがインスタンス化されると、ジョブオブジェクトごとに処理オブジェクトが生成されることになる。ただし、ジョブクラスがインスタンス化される時点においては、処理クラスには特定の処理内容は設定されない。後に詳述する方法にて、SingleThreadFlowControllerクラス450、すなわち、コントロールクラスが処理を注入するときに、具体的な処理内容が設定される。
【0034】
同図に示すクラス図によれば、データフローダイアグラム312に対応するクラスでありジョブクラスやモデルクラスのほかに、ジョブベースクラスやモデルベースクラスが定義されている。したがって、開発者がエンタープライズシステム204を設計するときには、あらかじめ用意されているジョブベースクラスやモデルベースクラスの基本仕様を利用しながら、設計対象となるエンタープライズシステム204に特有の機能をジョブクラスやモデルクラスに定義すればよい。これにより、クラスの再利用性というオブジェクト指向言語の特性を効果的に利用できる。エンタープライズシステム204の場合、何百、何千というジョブの基本仕様は数パターンに集約できることが多いため、オブジェクト指向言語の継承機能は特に有効である。
【0035】
図7は、処理クラスの継承に関するクラス図である。
前の図6で見たように、NodeFlowControllerクラス500は、ジョブオブジェクトの処理内容を定義するための処理クラスである。NodeFlowControllerクラス500からSTNodeFlowControllerクラス502が継承され、更に、STRecordStreamSourceクラス510、STRecordStreamMatcherクラス512、STRecordStreamAggregatorクラス514およびSTRecordStreamSinkクラス516の4種類の処理クラスが継承されている。STRecordStreamSourceクラス510は、RecordStreamSourceクラス480に対応して、その処理内容を定義するためのクラスである。STRecordStreamMatcherクラス512、STRecordStreamAggregatorクラス514およびSTRecordStreamSinkクラス516は、それぞれ、RecordStreamMatcherクラス484、RecordStreamAggregatorクラス482およびRecordStreamSinkクラス486に対応してそれらの処理内容を定義するクラスである。NodeFlowControllerクラス500から継承された4種類の処理クラスによって、ジョブクラスの処理内容が定義されることになる。
以上のクラス図をふまえ、サンプルのソースコードを参照しながら、基幹的な処理の内容を処理順序にしたがって説明する。以下に示すソースコードはJAVA(登録商標)にて記述されている。
【0036】
図8は、エンタープライズシステムの実行開始にあたって、最初に実行される関数を示す図である。
この関数(メソッド:method)はdoTest関数である。doTest関数は、UriageProcessingModelクラス440のpublicでstaticなメンバ関数であり、UriageProcessingModelクラス440の外からコール可能である。doTest関数が実行されると、UriageProcessingModelクラス440がインスタンス化され、testProcessingModelという名前のモデルオブジェクトが生成される(S100)。インスタンス化にともなって実行される詳細な処理内容については、次の図9に関連して説明する。
【0037】
次に、SingleThreadFlowControllerクラス450がインスタンス化され、singleThreadFlowControllerという名前のコントロールオブジェクトが生成される(S200)。インスタンス化にともなって実行される詳細な処理内容については、後の図10に関連して説明する。
【0038】
最後に、コントロールオブジェクトのdoTask関数に生成されたばかりのモデルオブジェクトが引数として渡されている(S300)。doTask関数に関する詳細な処理内容については、後の図10以降に関連して説明する。
【0039】
まとめると、doTest関数は、モデルオブジェクトとコントロールオブジェクトを生成し、コントロールオブジェクトにモデルオブジェクトを渡して、コントロールオブジェクトに所定の処理を実行させている。
【0040】
図9は、モデルオブジェクト生成時に実行されるソースコードを示す図である。
S100において、UriageProcessingModelクラス440がインスタンス化されるときには、まず、UriageProcessingModel()として示されるコンストラクタ関数が実行される(S102)。このコンストラクタ関数の実行に際して、各ジョブクラスがインスタンス化される(S104)。ここでは、UriageProcessingModelクラス440のメンバ変数として、UriageSourceクラス400、MiseMaSourceクラス406、UriageAggregatorクラス402、MiseMaMatcherクラス408、MiseUriageTotalSinkクラス410およびAreaUriageTotalSinkクラス404の各ジョブクラスがインスタンス化され、それぞれ、uriageSource、miseMaSource、uriageAggregator、miseMaMatcher、miseUriageTotalSinkrおよびareaUriageTotalSinkという名前のジョブオブジェクトが生成される。なお、各ジョブオブジェクトの生成に際しては、それぞれ、NodeFlowControllerクラス500から処理オブジェクトが生成される。ただし、この段階では処理オブジェクトには特段の処理内容は定義されない。また、UriageProcessingModelクラス440のインスタンス化に際しては、モデルベースクラスが持っている関係クラス、すなわち、Connectionクラス430もインスタンス化される。Connectionクラス430は、リスト形式にて各ジョブオブジェクトのつながりを管理するためのクラスである。
【0041】
次に、コンストラクタ関数の中の、createModel関数が実行される(S106)。これにより、S104にて生成された各ジョブオブジェクトが関係オブジェクトにノードとして登録される。こうして、必要なジョブオブジェクトとそのつながりが定義される。いいかえれば、モデルオブジェクトは、その生成時に、登場キャラクタたるジョブオブジェクトと、その関係を示す関係オブジェクトを生成する。
【0042】
図10は、コントロールオブジェクト生成時とデータフローの実行開始に際して実行されるソースコードを示す図である。
前の図8に示したdoTest関数のS200において、SingleThreadFlowControllerクラス450がインスタンス化される。このとき、まず、SingleThreadFlowController()として示されるコンストラクタ関数が実行される(S202)。このコンストラクタ関数の実行によって、ProcessingModelクラス460からmodelという名前の変数が用意される。このProcessingModelクラス460は、UriageProcessingModelクラス440の継承元となるモデルベースクラスであるから、この段階では、modelという名前の変数には、CDの売上処理に関する具体的なモデルは設定されない。そして、SingleThreadFlowControllerクラス450からsingleThreadFlowControllerという名前のコントロールオブジェクトが生成されることになる。
【0043】
こうして、図8のS100とS200に示した、モデルオブジェクトとコントロールオブジェクトの生成が完了し、図6に示した各クラスに基づいてさまざまなオブジェクトが生成されることになる。ここまでの処理のことを「生成初期化処理」とよぶことにする。
【0044】
先に示した図8のdoTest関数は、生成初期化処理が終了すると、コントロールオブジェクトのdoTask関数をコールしている。このとき、モデルオブジェクトがコントロールオブジェクトのdoTask関数の引数として渡されている。モデルオブジェクトは、setModel関数によって、S204にて生成されたmodelという名前のオブジェクトに、S100にて生成されたCDの売上処理に関するtestProcessingModelという名前のモデルオブジェクトを設定している(S310)。こうして、コントロールオブジェクトは、処理の対象とすべき具体的なモデルオブジェクトを取得する。
【0045】
次に、doTask関数は、ジョブオブジェクト間でデータを送受するための容れ物となるオブジェクトを設定するためのinjectRecordStream関数を実行し(S320)、各ジョブオブジェクトの処理を注入するためのinjectFlowController関数を実行する(S330)。最後に、mainTask関数を実行して、モデルオブジェクトが包含する各ジョブオブジェクトに処理を実行させる(S340)。なお、S310からS330までの処理のことを「注入初期化処理」とよぶことにする。
【0046】
図11は、図10のS310からS340までの処理に対応するソースコードを示す図である。
前の図10に示したdoTask関数のS320の実行にともなって、injectRecordStream関数が実行される。これによって、ジョブオブジェクト間でデータを受け渡すためのオブジェクトとして、STRecordStreamクラスがインスタンス化される。このように、ジョブオブジェクト間においてデータ受け渡しするためのフォーマットも、コントロールオブジェクト側にて定義される。次に、doTask関数のS330の実行にともなって、injectFlowController関数が実行される。injectFlowController関数は、関係オブジェクトを走査して、順次ジョブオブジェクトを選択し、各ジョブオブジェクトについてinjectFlowControllerToNode関数を実行する(S332)。
【0047】
このinjectFlowControllerToNode関数においては、一時的な処理オブジェクトnfcが生成される。次に、処理対象となるジョブオブジェクトがどのタイプのジョブベースクラスに基づくかが判定される。たとえば、処理対象のジョブオブジェクトが、RecordStreamSourceクラス480に基づくときには、nfcという名前の処理オブジェクトには、STRecordStreamSourceクラス510に基づく処理オブジェクトが設定される。たとえば、UriageAggregatorオブジェクトは、RecordStreamAggregatorクラス482に基づくので、nfcにはSTRecordStreamAggregatorオブジェクトが設定される。こうして、処理オブジェクトnfcには、4種類のオブジェクトのうちのいずれかが設定される。そして、setTargetNode関数によって、処理対象のジョブオブジェクトに対応する処理オブジェクトとして設定される(S334)。この段階で、ジョブオブジェクトの処理内容が決定することになる。すなわち、コントロールオブジェクトによってジョブオブジェクトに処理が「注入」される。
【0048】
注入初期化処理が完了すると、エンタープライズシステム204を実際に稼働させるためのmainTask関数が実行される(S340)。図3のデータフローダイアグラム312に示したように、全体としての処理は、売上データ300を前提として開始される。そのため、まず、関係オブジェクトを走査して、RecordStreamSourceクラス480に基づくジョブオブジェクトを特定する(S342)。ただし、MiseMaSourceオブジェクトのように、他のジョブオブジェクトによる中間データと共に利用されるジョブオブジェクトの場合には、RecordStreamSourceクラス480に基づくジョブオブジェクトであっても、ここでは処理対象としない(S344)。isMaSource関数は、これを調べるための関数である。
【0049】
MiseMaSourceクラス406に基づくUriageSourceオブジェクトが検出されると、対応する処理オブジェクトが取り出され(S346)、その処理オブジェクトのdoTask関数が実行される(S348)。以後は図示しないが、UriageSourceオブジェクトに対応する処理オブジェクトのdoTask関数は、自分の処理が終了するときに、関係オブジェクトを参照して次の処理対象となるジョブであるUriageAggregatorオブジェクトを特定する。UriageAggregatorオブジェクトの処理オブジェクトが取り出され、その処理オブジェクトの処理関数であるdoTask関数が実行される。このdoTask関数も、自分の処理が終了するときには、AreaUriageTotalSinkオブジェクトとMiseMaMatcherオブジェクトを次の処理対象として特定する。なお、MiseMaMatcherクラス408の処理オブジェクトは、自分の処理に先立って、MiseMaSourceクラス406の処理オブジェクトにdoTask関数の実行を指示し、その実行結果を待ってから、自分の処理を実行し、MiseUriageTotalSinkオブジェクトを次の処理対象として特定する。
【0050】
このように、データフローダイアグラム312に示された、いいかえれば、関係オブジェクトに管理されている依存関係にしたがって、複数のジョブオブジェクトが連鎖的に処理を実行することになる。
【0051】
以上の実施例に示したジョブ管理装置100によれば、モデルオブジェクトとコントロールオブジェクトによって、ジョブの静的な関係定義と、ジョブの動的な処理定義を明確に分離することができる。
COBOLなどの手続き型言語の場合、これら2種類の定義は一体としてなされることが多かった。そのため、開発者は、ジョブの静的な関係定義と動的な処理定義を同時に意識しながらシステムを設計する必要があった。これに対して、本実施例にて示したフレームワークによれば、これら2種類の定義を明確に分離できる。そのため、ジョブの処理定義に過度に影響されることなく、ジョブの関係定義を行うことができる。また、その逆も真である。このような、分離設計を可能とするフレームワークは、エンタープライズシステム204の拡張性・保守性・堅牢性を高めることができる。
【0052】
たとえば、一部のジョブオブジェクトにだけ処理を注入することにより、エンタープライズシステム204の一部の機能だけをテストする作業を、コントロールオブジェクト側の変更操作だけで実現できる。
具体例として、100個のジョブオブジェクトによって構成されるエンタープライズシステム204のうち、3個のジョブオブジェクトの機能だけをテストしたい場合について説明する。このような場合、まず、100個のジョブオブジェクトを生成しておく。そして、実際には、この3個のジョブオブジェクトにだけ処理を注入する。次に、さきほどの3個のジョブオブジェクトを含む5個のジョブオブジェクトの機能をテストしたい場合には、生成済の100個のジョブオブジェクトのうち、今度は5個のジョブオブジェクトに処理を注入する。すなわち、はじめに100個のジョブオブジェクトを生成しておけば、2回目のテストのために新たにテスト対象として加わった2個のジョブオブジェクトを生成する必要がない。このような処理方法によると、最初に全てのジョブオブジェクトを生成しておけば、テスト対象の変更により新たなインスタンス化処理を実行しなくて済むというメリットがある。
【0053】
本実施例に示すエンタープライズシステム204の場合、ジョブオブジェクトはすべてモデルクラスによって生成され、他のジョブクラスから生成されることはない。このため、ジョブオブジェクトの生成に関しても、ジョブクラスに先天的な依存関係を持たさなくて済む。これにより、各ジョブクラスの独立性を高めることができる。また、プログラマは、UriageProcessingModelクラス440を参照することにより、処理対象となるジョブクラスを一元的に参照できるため、ソースコードの可読性を高める効果もある。
【0054】
また、図6に関連して説明したように、ジョブクラスは典型的な4つのジョブベースクラスのいずれかを継承するかたちで定義されているため、何十、何百、何千というジョブオブジェクトを制御する場合であっても、ジョブクラスの設計負担が大幅に軽減される。これは、処理クラスやモデルクラスなど他のクラスについても同様である。
【0055】
更に、S332のinjectFlowControllerToNode関数に示したように、各ジョブクラスの由来に応じて、割り当てるべき処理クラスが特定されている。したがって、多種類のジョブクラスに対して、多種類の処理クラスを割り当てる場合であっても、ジョブクラスのタイプに応じて、処理クラスのタイプを結びつけるという方法により、ジョブクラスと処理クラスの対応関係に関するソースコードの可読性が向上する。
【0056】
本実施例においては、シングルスレッドモデルを前提としてシステムを説明したが、これをマルチスレッド化することも容易である。たとえば、SingleThreadFlowControllerクラス450のmainTask関数は、RecordStreamSourceクラス480に基づくジョブオブジェクトであるか否かにかかわらず、全てのジョブオブジェクトに対して一斉にdoTask関数の開始を指示してもよい。
【0057】
マルチスレッドモデルについて図4を再度参照しながら説明する。
まず、SingleThreadFlowControllerクラス450は、各ジョブオブジェクトの処理オブジェクトの処理関数であるdoTask関数に実行を指示する。ここで、各doTask関数はマルチスレッド化されており、時間的に並行して実行可能な関数である。この指示によって、各doTask関数は実行待機状態に移行するが、UriageSourceオブジェクトについての処理関数だけは即座に実行開始となる。
【0058】
UriageSourceオブジェクトについての処理関数が実行を完了すると、UriageAggregatorオブジェクトの処理関数が実行開始となる。UriageAggregatorクラス402の処理関数が実行完了すると、AreaUriageTotalSinkクラス404とMiseMaMatcherクラス408は同時並行的に実行開始を指示される。AreaUriageTotalSinkクラス404とMiseMaMatcherクラス408は依存関係を持たないので結果として並行処理が可能となる。MiseMaMatcherクラス408は自己の処理関数を実行するために、MiseMaSourceクラス406の処理関数に実行を指示し、その処理結果を受けたときに自分の処理関数を実行開始することになる。このときに、並行してAreaUriageTotalSinkオブジェクトの処理関数は実行されている。このため、COBOLが苦手なマルチタスク処理を、マルチスレッド処理として実現できるため、システム全体としてのパフォーマンスを向上させることができる。特に、DFDにおいて、フローが枝分かれするほど、同時並行的に実行できる処理関数を増やすことができる。
【0059】
また、ジョブ管理装置100の機能は、複数のハードウェア資源によって実現されてもよい。たとえば、ジョブオブジェクトは、複数のジョブ実行装置に分散配置されてもよい。このような態様によれば、ジョブ実行装置Aでジョブオブジェクトαの処理を実行しつつ、ジョブ実行装置Bでジョブオブジェクトβの処理を実行するという処理方法が可能となる。これにより、時間的な効率化だけでなく、処理負荷の分散も効率的に行うことができる。コントロールクラスは、ジョブ実行装置群において処理負荷が局所化しないように、他のジョブ実行装置よりも処理負荷が軽い状態にあるジョブ実行装置に対して優先的にジョブを割り当ててもよい。従来、ジョブの分散配置を実現するためには、複数のジョブ実行装置への分散配置を前提とした設計が必要であったが、本実施例に示した設計方法によれば、ジョブ管理装置100から外部のジョブ実行装置にジョブの実行主体を移行させるのが容易となる。
【0060】
以上、実施の形態をもとに本発明を説明した。なお本発明はこの実施の形態に限定されることなく、そのさまざまな変形例もまた、本発明の態様として有効である。たとえば、本実施例においては、エンタープライズシステムを想定して説明したが、より具体的には、電子商取引、物流管理などへの応用が考えられる。また、本実施例において示したフレームワークは、ワークフロー管理のように、複数のジョブを定義して制御するというモデルに広く応用可能である。
【0061】
請求項に記載のジョブオブジェクト生成部の機能は、本実施例においては主としてUriageProcessingModelクラス440によって実現される。請求項に記載のジョブリスト情報生成部の機能は、本実施例においては主としてUriageProcessingModelクラス440やConnectionクラス430によって実現される。請求項に記載の処理注入部と実行制御部の機能は、本実施例においては、主としてSingleThreadFlowControllerクラス450によって実現される。したがって、請求項に記載のモデルオブジェクト生成部の機能は、本実施例においては主としてモデル管理部140、とりわけ、UriageProcessingModelクラス440によって実現される。請求項に記載のコントロールオブジェクト生成部の機能は、本実施例においてはフロー制御部150、とりわけ、SingleThreadFlowControllerクラス450によって実現される。請求項に記載の処理関数は、本実施例においては、たとえば、S348にて示したdoTask関数が相当する。
請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【図面の簡単な説明】
【0062】
【図1】エンタープライズシステムのハードウェア構成図である。
【図2】ジョブ管理装置の機能ブロック図である。
【図3】本実施例におけるデータフローダイアグラムを示す図である。
【図4】図3のDFDに対応するジョブクラスの依存関係を示す図である。
【図5】ジョブ管理装置の基本的な機能を実現するためのクラスの関係を示す模式図である。
【図6】ジョブクラスとモデルクラスの関係を示すクラス図である。
【図7】処理クラスの継承に関するクラス図である。
【図8】エンタープライズシステムの実行開始にあたって、最初に実行される関数を示す図である。
【図9】モデルオブジェクト生成時に実行されるソースコードを示す図である。
【図10】コントロールオブジェクト生成時とデータフローの実行開始に際して実行されるソースコードを示す図である。
【図11】図10のS310からS340までの処理に対応するソースコードを示す図である。
【符号の説明】
【0063】
100 ジョブ管理装置、 110 ユーザインタフェース処理部、 120 通信部、 130 データ処理部、 140 モデル管理部、 150 フロー制御部、 200 ノード端末、 202 インターネット、 204 エンタープライズシステム、 206 データベース、 300 売上データ、 302 売上集約処理、 304 地区別売上データ、 306 店マスタデータ、 308 店名追加処理、 310 店別売上データ、 312 データフローダイアグラム、 400 UriageSourceクラス、 402 UriageAggregatorクラス、 404 AreaUriageTotalSinkクラス、 406 MiseMaSourceクラス、 408 MiseMaMatcherクラス、 410 MiseUriageTotalSinkクラス、 420 ジョブクラス群、 430 Connectionクラス、 440 UriageProcessingModelクラス、 450 SingleThreadFlowControllerクラス、 460 ProcessingModelクラス、 480 RecordStreamSourceクラス、 482 RecordStreamAggregatorクラス、 484 RecordStreamMatcherクラス、 486 RecordStreamSinkクラス、 490 Nodeクラス、 500 NodeFlowControllerクラス、 502 STNodeFlowControllerクラス、 510 STRecordStreamSourceクラス、 512 STRecordStreamMatcherクラス、 514 STRecordStreamAggregatorクラス、 516 STRecordStreamSinkクラス。




 

 


     NEWS
会社検索順位 特許の出願数の順位が発表

URL変更
平成6年
平成7年
平成8年
平成9年
平成10年
平成11年
平成12年
平成13年


 
   お問い合わせ info@patentjp.com patentjp.com   Copyright 2007-2013