以下、本発明の一実施例を、図面を参照しながら詳細に説明する。
図1は、本実施例におけるジョブネット検証装置201の構成例を示すブロック図である。
ジョブネット検証装置201は、ジョブネット解析部111、グループ・優先度決定部112、ユーザ入力表コマンド定義表作成部113、コマンド定義表入力部114、コマンド定義表更新検出部115、コマンド定義表更新通知部116、検証範囲特定部117、部分的検証実行部118、の機能ブロックを含む。またジョブネット検証装置201は、解析結果保持部121、定義済みコマンド保持部122、コマンド定義更新差分保持部123、不具合パターン保持部124、の記憶部を有する。
ジョブネット解析部111は、ジョブネット定義101、ジョブが実行するプログラムのソースコード102、および利用製品コマンド一覧103を受け付け、これらからジョブの実行順序情報および実行コマンド情報を生成し、解析結果保持部121に登録する。
グループ・優先度決定部112は、解析結果保持部121から上記実行コマンド情報を取得し、同一引数を操作するコマンドをグループ化し、各グループに対し、コマンド定義表作成時の優先順位を付与したグループ化・優先度付与済みコマンド一覧情報を作成し、これをユーザ入力用コマンド定義表生成部113へ入力する。この際、定義済みコマンド保持部122に定義済みコマンド情報が登録されている場合には、定義済みコマンド情報に含まれるコマンドを、グループ化と優先度付与の対象から除外する。
ユーザ入力用コマンド定義表生成部113は、上記グループ化・優先度付与済みコマンド一覧情報を受け付け、ユーザが、各コマンドに対し引数種別と操作種別を定義、入力するためのユーザ入力用コマンド定義表を作成し、これをコマンド定義表入力部へ入力する。
コマンド定義表入力部114は、上記ユーザ入力用コマンド定義表を受け付け、これを、コマンド定義表作成画面を通じてユーザに提示する。また、コマンド定義表作成画面を通じ、コマンド定義表に対するユーザからの入力を受け付ける。更に、ユーザから入力された定義情報を含むコマンド定義表を、コマンド定義表更新検出部115へ入力する。
コマンド定義表更新検出部115は、コマンド定義表入力部114から上記コマンド定義表を受け付ける。そしてコマンド定義表更新検出部115は、定義済みコマンド保持部122から定義済みコマンド情報を取得し、定義済みコマンド情報に含まれないが、コマンド定義表入力部114から受け付けたコマンド定義表には含まれる情報を、コマンド定義更新差分情報として、コマンド定義更新差分保持部123に登録する。その後、コマンド定義表において、操作種別が定義されたコマンドを、定義済みコマンド保持部122に登録する。
コマンド定義表更新通知部116は、定義済みコマンド保持部122から定義済みコマンド情報を、コマンド定義更新差分保持部123からコマンド定義更新差分情報をそれぞれ取得し、これらの情報を検証範囲特定部117へ入力する。
検証範囲特定部117は、上記定義済みコマンド情報およびコマンド定義更新差分情報を受け付け、新たに定義されたコマンドに基づき、リソース競合が発生し得るかを検証可能となるリソース操作のペアの集合を検証可能範囲情報として作成する。この情報を、部分的検証実行部118へ入力する。
部分的検証実行部118は、上記検証可能範囲情報を受け付け、不具合パターン保持部124から不具合パターン情報を取得する。その後、上記検証可能範囲情報から、検証対象とするリソース操作のペアを1つずつ選択し、当該ペアが不具合パターン情報に合致するパターンであるか、並行実行し得るかを検証する。当該ペアが不具合パターンに合致し、かつ並行実行し得る場合、当該ペアを検証対象ジョブネットで発生し得るリソース競合として、検証結果104に登録する。
図2は、図1に示したジョブネット検証装置を実現するハードウェア構成の例を示している。
図2において、ジョブネット検証装置201は、一例としてパーソナルコンピュータ(PC)等の、汎用的な計算機で、CPU202、メモリ203、補助記憶装置204、表示装置205、入力装置206、及び外部媒体入出力装置207を備える。
CPU202は、メモリ203に記憶されたプログラムを実行することによって、各種処理を実行する。メモリ203は、CPU202のワークエリアとして機能し、プログラム及びプログラムの実行に必要なデータを記憶する。具体的には、メモリ203には、CPU202に実行されることによって、ジョブネット検証装置201をジョブネット解析部111、グループ・優先度決定部112、ユーザ入力表コマンド定義表作成部113、コマンド定義表入力部114、コマンド定義表更新検出部115、コマンド定義表更新通知部116、検証範囲特定部117、および部分的検証実行部118の機能ブロックを備えた装置として動作させるためのプログラム、及びこのプログラムの実行に必要なデータが記憶される。
なお、以下では、ジョブネット検証装置201で実行される各種処理の内容を説明する際、ジョブネット解析部111等の機能ブロックを処理の主体として説明することがある。ただし先に述べたとおり、実際にはジョブネット解析部111等は、プログラムがCPU202に実行されることによって実現される機能ブロックであるから、正確には処理の主体はCPU202である。ただし説明が冗長になることを避けるため、本実施例では、ジョブネット解析部111等の機能ブロックを処理の主体として、各種処理の内容を説明する。
また、ジョブネット検証装置201で実行されるプログラム(ジョブネット検証装置201を、以下で説明する各機能ブロックを有する装置として動作させるためのプログラム)は、プログラム配布サーバや計算機が読み取り可能な記憶メディアによって提供され、プログラムを実行する各装置にインストールされてもよい。計算機が読み取り可能な記憶メディアとは、非一時的なコンピュータ可読媒体で、例えばICカード、SDカード、DVD等の不揮発性記憶媒体である。
補助記憶装置204は、各種データを格納する。補助記憶装置204は、例えばハードディスク装置などの、不揮発性記憶媒体を用いた記憶装置である。上で述べた解析結果保持部121、定義済みコマンド保持部122、コマンド定義更新差分保持部123、および不具合パターン保持部124は、補助記憶装置204の有する記憶領域を用いて構成される。そのため、本実施例において、「解析結果保持部121(または定義済みコマンド保持部122、コマンド定義更新差分保持部123、および不具合パターン保持部124)に情報を格納する」という記述がある箇所は、実際には解析結果保持部121(または定義済みコマンド保持部122、コマンド定義更新差分保持部123、および不具合パターン保持部124)を構成する補助記憶装置204の記憶領域に情報が格納されることを意味する。
また別の実施形態として、解析結果保持部121、定義済みコマンド保持部122、コマンド定義更新差分保持部123、および不具合パターン保持部124は、メモリ203の記憶領域を用いて構成されていてもよい。
あるいは、ジョブネット解析部111、グループ・優先度決定部112、ユーザ入力表コマンド定義表作成部113、コマンド定義表入力部114、コマンド定義表更新検出部115、コマンド定義表更新通知部116、検証範囲特定部117、および部分的検証実行部118を構成するプログラムの少なくとも一部についても、補助記憶装置204に格納されてもよい。その場合、各種処理実行の際には、CPU202は補助記憶装置204に格納されたプログラムをメモリ203へ読み出して、プログラムを実行する。また各プログラムは、あらかじめ、メモリ203または補助記憶装置204に格納されていても良いし、必要に応じ、利用可能な媒体を介して、他の装置からメモリ203または補助記憶装置204に導入されてもよい。媒体とは、例えば、外部媒体入出力装置207に着脱可能な記憶媒体、または、ネットワークや、ネットワークを伝搬する搬送波やデジタル信号などの通信媒体を指す。
表示装置205は、プログラムの処理結果などを表示する。表示装置205は、例えば、ディスプレイなどである。入力装置206は、処理の実行指示及び処理に必要な情報の入力などを利用者から受け付ける。入力装置206は、例えば、キーボード及びマウスなどである。
外部媒体入出力装置207は、外部媒体に格納されているデータなどの入出力を行う。外部媒体は、外部媒体入出力装置207に着脱可能で可搬性のある記憶媒体であり、外部媒体出力装置207は、外部媒体に読み書き可能なドライブ装置などである。たとえば、ジョブネット定義101やソースコード102等の、ジョブネットの検証で必要となる情報は、外部媒体入出力装置207を介して、ジョブネット検証装置201に入力される。ただし別の実施形態として、ジョブネット検証装置201にネットワークインタフェースを備え、ネットワーク経由でジョブネットの検証で必要となる情報がジョブネット検証装置201に入力されてもよい。
なお、ジョブネット検証装置は、必ずしも単一の計算機で構成されなければならないわけではなく、複数台の計算機を用いてジョブネット検証装置を構成することも可能である。図3には、図1に示したジョブネット検証装置を実現するハードウェア構成の、別の例が示されている。
図3のジョブネット検証装置300(以下では、図2に示された装置と区別するために、図3のジョブネット検証装置300を「ジョブネット検証システム300」と呼ぶこともある)は、コマンド定義表入力装置301と検証実行装置303を有する。コマンド定義表入力装置301と検証実行装置303はいずれも、ジョブネット検証装置201と同様のハードウェア要素(CPU202〜外部媒体入出力装置207)を持つ、汎用的な計算機である。さらにコマンド定義表入力装置301と検証実行装置303は、ネットワーク302に接続するためのネットワークインタフェースを有し、ネットワーク302を介して通信可能に構成される。
コマンド定義表入力装置301は、ジョブネット解析部111、解析結果保持部121、グループ・優先度決定部112、ユーザ入力表コマンド定義表作成部113、コマンド定義表入力部114、コマンド定義表更新検出部115、定義済みコマンド保持部122、コマンド定義更新差分保持部123およびコマンド定義表更新通知部116を持つ。
コマンド定義表入力装置301の定義済みコマンド保持部122およびコマンド定義更新差分保持部123に格納された定義済みコマンド情報およびコマンド定義更新差分情報は、ネットワーク302を通じて検証実行装置303に送信される。
検証実行装置303は、検証範囲特定部117、部分的検証実行部118、不具合パターン保持部124を持つ。
検証実行装置303は、ネットワーク302を介してコマンド定義表入力装置301から定義済みコマンド情報およびコマンド定義更新差分情報を受信し、検証範囲特定部117および部分的検証実行部118を実行することで検証を行う。ジョブネット検証システム300は、検証結果104を検証実行装置303の表示装置上に表示するように構成されていてもよいし、あるいはネットワーク302を通じて検証結果104を検証実行装置303からコマンド定義表入力装置301上に送信し、コマンド定義表入力装置301の表示装置上に表示するように構成されていてもよい。
図3に示されたジョブネット検証システム300では、定義済みコマンド情報およびコマンド定義更新差分情報を装置間で受け渡す手段としてネットワークが用いられているが、外部媒体入出力装置を使用して、ネットワーク以外、例えば着脱可能な記憶媒体による、情報の受け渡しが行われても良い。
なお、ここではコマンド定義表入力装置301に、ジョブネット解析部111、解析結果保持部121、グループ・優先度決定部112、ユーザ入力表コマンド定義表作成部113、コマンド定義表入力部114、コマンド定義表更新検出部115が存在し、それ以外の機能ブロックが検証実行装置303に存在する例を説明したが、各機能ブロックはコマンド定義表入力装置301と検証実行装置303の何れに存在しても、本実施例で説明するジョブネットの検証は可能である。また、ここでは2台の計算機(コマンド定義表入力装置301と検証実行装置303)でジョブネット検証システムが構成される例を説明したが、これ以外の構成、例えば3台以上の計算機でジョブネット検証システムが構成されてもよい。
また、図2のジョブネット検証装置201、そして図3のジョブネット検証システム300の何れによっても、本実施例にて説明するジョブネットの検証は実行可能だが、以下では主に、図2のジョブネット検証装置201でジョブネットの検証が行われる例について説明する。
図4は、本実施例に係るジョブネット検証装置201が入力として受け付けるジョブネット定義101の例である。ジョブネット定義101の例として、ジョブネット定義イメージ410、ジョブネット定義テキスト420があり得る。ジョブネット定義イメージ410は画像形式のジョブネット定義例で、ジョブネット定義テキスト420はテキスト形式のジョブネット定義例である。本実施例では、ジョブ管理製品(プログラム)であるJP1/Automatic Job Management Systemによって定義されるジョブネット定義の例について説明するが、本実施例に係るジョブネット検証装置または方法は、必ずしも上記製品で定義されたジョブネットの検証に限定されない。処理の実行順序を定義し、当該定義に従った処理の自動化を実現するその他のジョブ管理製品で実行されるジョブネットに対しても、本実施例に係るジョブネット検証方法を適用できる。
ジョブネット定義イメージ410には、入れ子のジョブネット定義例が示されており、ルートジョブネットA411には、子要素としてジョブネットB412、ジョブネットD414、ジョブネットG415が定義されている。ジョブネット間の矢印を関連線と呼び、関連線はジョブネット間の実行順序を定義している。関連線416は、ジョブネットB412の実行後に、ジョブネットD414が実行されることを定義している。また、各ジョブネットは子要素としてジョブを保持しており、例えばジョブネットB412はジョブC413を呼び出すことが定義されている。ジョブは、ジョブネット管理プログラムにおける処理の最小単位で、各ジョブには、ジョブが実行するプログラムまたはコマンドが関連付けられる。
一方、ジョブネットG415と他のジョブネット(ジョブネットB412、ジョブネットD414)の間には関連線が存在しない。これはジョブネットG415と他のジョブネットの間に順序関係が定義されていないことを意味する。つまりジョブネットG415は、他のジョブネットの前に実行されるか、後に実行されるか、明確に定まっていない。そのためジョブネットG415が保持するジョブは、他のジョブネットが保持するジョブと並行に実行される可能性もある。
ジョブネット定義テキスト420には、ジョブネット定義イメージ410と同じジョブネットに対する定義例の一部が示されている。テキスト形式のジョブネット定義では、unitから始まるステートメントによりジョブネット、ジョブを定義する。ルートジョブネットA421は、子要素にジョブネットB422を持つことが示されている。また、ジョブネットB422は、子要素にジョブC423を持つことが示されている。ジョブC423の定義中には、teから始まるステートメントにて、当該ジョブが実行するプログラム(またはスクリプト)が定義されている。更に、arから始まるステートメント425には、関連線416の定義が記述されており、ジョブネットB22の実行後に、ジョブネットD424が実行されることが示されている。
なお、ジョブネット定義イメージ410と、ジョブネット定義テキスト420のいずれが、ジョブネット検証装置201の入力として渡されてもよいが、以下では特に断りのない限り、ジョブネット検証装置201への入力情報としてジョブネット定義テキスト420が用いられる例について説明する。
図5は、本実施例に係るジョブネット検証装置201が入力として受け付ける、ジョブが実行するプログラムのソースコード例である。図5ではソースコード例として、Korn Shellのスクリプトが示されている。
ジョブが実行するプログラムは、図5の例のようなシェルスクリプトの他、実行形式のオブジェクトコード(何らかのプログラミング言語で記述されたソースプログラムをコンパイルすることで生成されるプログラムコード)のこともある。ジョブが実行するプログラムが実行形式のオブジェクトコードの場合、本実施例に係るジョブネット検証装置201への入力には、オブジェクトコードの元となるソースプログラム(コンパイル前のソースプログラム)が用いられる。ジョブが実行するプログラムが図5のようなスクリプト(インタープリタによって処理されるソースコードも含まれる)の場合には、このスクリプトが直接ジョブネット検証装置201への入力に用いられる。本実施例では、ジョブネット検証装置201の入力に用いられる、オブジェクトコードの元となるソースプログラムとスクリプトのいずれも、「ソースコード」と呼ぶ。
ジョブが実行するプログラムがスクリプトの場合、スクリプトから別のプログラム(外部プログラムと呼ぶ)が呼び出され、そのプログラムが実行されることがある。図5のソースコード501には、ジョブが外部プログラムを呼び出す例が示されている。ステートメント502は、Linux(R)でサポートされるcatコマンド等を実行して、ファイル”/etc/some.conf”を読み込んでファイル”/TMP/config”に書き込む処理を実行するためのものである。またステートメント503は、DB製品HiRDB(R)が提供するコマンドを実行することで、データロード処理を実行するためのものである。
スクリプトから呼び出される外部プログラムは一般に「コマンド」と呼ばれるので、本実施例においても、ジョブが実行するプログラムから呼び出されるプログラムのことを「コマンド」と呼ぶ。またジョブが実行するプログラムが実行形式のオブジェクトコードの場合、外部プログラム(あるいはライブラリ)に定義されている関数が呼び出されることがある。本実施例では、ジョブが実行するプログラムから呼び出される関数のことも、「コマンド」と呼ぶこととする。
図6は、本実施例におけるジョブネット解析部の処理手順例を示すフローチャートである。
以下に示す処理は、ジョブネット検証装置201の備えるCPU202が、メモリ203に格納されたプログラムを実行することによって実現される。そしてこのプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
ジョブネット解析部111は、検証対象のジョブネットのジョブネット定義101、検証対象のジョブネットの子要素の各ジョブが実行するプログラムのソースコード102、そして利用製品コマンド一覧103を受領すると、実行を開始する。ジョブネット解析部111はまず、ジョブネット定義101から、検証対象とするジョブネットにて実行される全ジョブの情報を取得する(ステップ601)。ここで取得された、検証対象とするジョブネットにて実行される全ジョブの情報のことを、「全ジョブ一覧」と呼ぶ。
続いてジョブネット解析部111は、ジョブネット定義101の内容を解析することで、検証対象ジョブネット内で定義される、ジョブの実行順序に関する情報を、ステップ601で取得した全ジョブに対して生成する(ステップ602)。ここで生成されるジョブの実行順序に関する情報を、「ジョブ実行順序情報」と呼ぶ。例えばジョブネット解析部111が、ジョブネット定義101として、図4に示されたジョブネット定義テキスト420を受け付けて、その内容を解析する場合、ステートメント425に定義された関連線により、ジョブネットB422を実行後に、ジョブネットD424を実行するという順序関係を識別できる。また、ジョブネットB412は下位にジョブC413を持つ。したがってジョブネット解析部111は、ジョブネットB422からジョブC423、ジョブC423からジョブネットD424という実行順序関係を取得することができる。
ステップ602の後、ジョブネット解析部111は利用製品コマンド一覧103を用いて、ステップ601で取得した全ジョブ一覧に含まれる各ジョブが実行するプログラムのソースコード102を解析し、各ジョブが実行するコマンド及びその引数の一覧を生成する(ステップ603)。ここで作られる情報は、実行コマンド情報と呼ばれる。
なお、利用製品コマンド一覧103とはたとえば、ジョブネットが実行される計算機で実行可能な全てのコマンド名の一覧が記述されたテキストファイルで、あらかじめユーザ(ジョブネットの検証者)が作成しておく情報である。ただし利用製品コマンド一覧103のデータ形式は、必ずしもテキスト形式に限定されない。ソースコード102に含まれる各コマンドを特定可能な情報を含んでいれば、利用製品コマンド一覧103のデータ形式には任意の形式が採用可能である。
また、ジョブネット解析部111に入力される利用製品コマンド一覧103は一つとは限らない。ジョブネットが実行される計算機に、複数のプログラム製品がインストールされている場合、プログラム製品ごとの利用製品コマンド一覧103がジョブネット解析部に入力される。
例えば、ジョブネット解析部111が図5に記述されたソースコード501の解析を行う例を説明する。ソースコード501は、Linux(R)のコマンドである”cat”および”>”(リダイレクト)と、データベース管理プログラムのHiRDB(R)のコマンドである”pdload”を含んでいる。この場合ジョブネット解析部111は、Linuxのコマンド一覧が記述された利用製品コマンド一覧103とHiRDBのコマンド一覧が記述された利用製品コマンド一覧103を用いて解析を行う。
図5の例では、ステートメント502,503以外の行は、利用製品コマンド一覧103に記述されたコマンドを含まないため読み飛ばされる。ステートメント502は、Linuxコマンドである”cat”および”>”(リダイレクト)を含むため、ジョブネット解析部111はコマンド”cat”とその引数(/etc/some.conf)の組み合わせと、”>”と引数(/TMP/config)の組み合わせを、実行コマンド情報として生成する。また、ステートメント503には、HiRDB(R)のコマンドである”pdload”が含まれているので、ジョブネット解析部111はコマンド”pdload”とその引数(-ln -is -d -c ${DEFFILE} ${TBLID}\ source ${SOTFILE} error=${ERRFILE} idxwork /AAA)の組み合わせを、実行コマンド情報として生成する。
ジョブネット解析部111は、ステップ602で取得したジョブ実行順序情報およびステップ603で生成した実行コマンド情報を、解析結果として解析結果保持部121に格納する。(ステップ604)
なお、本実施例では実行順序情報および実行コマンド情報を、ジョブネット定義テキストおよびソースコードから取得する例を説明しているが、これら以外の情報から実行順序情報および実行コマンド情報を取得してもよい。たとえばジョブネットの仕様書など、ジョブの実行順序やジョブが実行するコマンドについて記述された情報を入力として受け付けて、実行順序情報および実行コマンド情報を取得してもよい。
図7は、解析結果保持部121に格納されるジョブ実行順序情報の例である。ジョブ実行順序情報701は、先に実行される先行ジョブ702と、先行ジョブ702に続いて実行される後続ジョブ703とのペアを、表形式で保持する。
図8は、解析結果保持部121に格納される実行コマンド情報の例である。実行コマンド情報801は、ジョブID802と、実行コマンド803という、2つのカラムを有する、表形式の情報である。ジョブID802は、実行コマンド803に格納されたコマンド(及びその引数)を実行するジョブのジョブIDが格納される。
なお、ここではジョブ実行順序情報701と実行コマンド情報801が表形式の情報である例を説明したが、これらの情報の格納形式に、表以外の形式(たとえばグラフデータ構造等)が用いられてもよい。
図9は、本実施例におけるグループ・優先度決定部およびユーザ入力用コマンド定義表生成部の処理手順例を示すフローチャートである。
以下に示す処理は、ジョブネット検証装置201の備えるCPU202が、メモリ203に格納されたプログラムを実行することによって実現される。そしてこのプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
グループ・優先度決定部112は解析結果保持部121から実行コマンド情報801を取得する。(ステップ901)
グループ・優先度決定部112は、続けて定義済みコマンド保持部122から定義済みコマンド情報1201を取得する(ステップ902)。なお、定義済みコマンド情報1201は、引数種別と操作種別が定義済みのコマンドの一覧であり、詳細は図12にて説明する。
グループ・優先度決定部112は、ステップ901で取得した実行コマンド情報801に含まれる各行と、ステップ902で取得した定義済みコマンド情報1201に含まれる各行とを比較する。グループ・優先度決定部112は、各情報が持つジョブID同士、コマンド同士を比較し、双方が一致する行があった場合、当該行を実行コマンド情報801から除外する。これにより、以後のステップでは、操作種別が定義済みでないコマンドのみを対象にグループ化、優先度付与が行われる。(ステップ903)
グループ・優先度決定部112は、実行コマンド情報801の実行コマンド803に格納されている各コマンドのグループ化を行う(ステップ904)。ここでのグループ化では、各コマンドの引数の内容に基づいて、各コマンドの属するグループが決定される。具体的には同一名の引数を含むコマンドは同一グループに属すものと決定される。例えば、コマンド”rm x.txt”は引数”x.txt”というグループに属すと決定される。また、コマンド“cat x.txt y.txt”は、”x.txt”グループと”y.txt”グループに属すると決定される。
グループ・優先度決定部112は、ステップ904で生成した各コマンドグループにて、グループに含まれるコマンドの数が少ない順に優先度を付与する(ステップ905)。例えば、x.txt、y.txt、z.txtを引数にとるコマンドがそれぞれ2個、3個、4個であった場合、x.txtグループに最も高い優先度を、z.txtグループに最も低い優先度を付与する。これは以下の理由による。
本実施例に係るジョブネット検証装置は、ジョブが実行するコマンドの引数に指定されたリソースについて、ジョブネット実行時に競合が発生し得るか検証する。この検証のために、ユーザはリソースの操作種別を指定(定義)する必要がある。x.txtの検証を開始、完結させるためには、ユーザは2個のコマンドについて引数種別と操作種別を定義すれば良い。一方z.txtの検証を開始、完結させるためには、ユーザは4個のコマンドについて引数種別と操作種別を定義しなければならない。したがって、x.txtに関するコマンドから、引数種別と操作種別の定義を始めれば、より早く検証を開始、完結させることができる。よって本実施例では、グループに含まれるコマンド数が少ない順に優先度を付与している。
続いてグループ・優先度決定部112は、ユーザ入力用コマンド定義表生成部113を実行することによって、ステップ904およびステップ905で決定したグループと優先度に基づき、ユーザ入力用コマンド定義表1001を生成する(ステップ906)。
なお、本実施例では引数名を基準としたグループ・優先度決定を行っているが、グループ化のための基準はこれに限られない。例えばジョブを基準としたグループを作成するようにしてもよい。
図10は、本実施例におけるユーザ入力用コマンド定義表の例である。ユーザ入力用コマンド定義表1001は、コマンドが取る引数の種別と、引数に対する操作の種別をユーザに入力してもらうための表である。ユーザ入力用コマンド定義表1001には、グループ・優先度決定部112が決定したグループ1002、定義対象とするコマンド1003、当該コマンドが取る引数1004が、ユーザ入力用コマンド定義表生成部113により自動で入力される。また各グループは、グループ・優先度決定部112が決定した優先度によって、優先度が高いグループほどユーザ入力用コマンド定義表1001の上に位置し、低いほど下に位置するように、配置される。
なお、各グループにコマンドが重複して属することもある。たとえばコマンド“cat x.txt y.txt”は、”x.txt”グループと”y.txt”グループに属する。ただしユーザ入力用コマンド定義表1001には、コマンドを重複して配置させる必要はない。そのためコマンドが複数のグループに属する場合、ユーザ入力用コマンド定義表生成部113がそのコマンドをユーザ入力用コマンド定義表1001に配置する際、優先度の高いグループにのみ配置する。
ユーザ入力用コマンド定義表1001が生成されると、ユーザは、各コマンド1003の各引数1004に対し、引数種別1005および操作種別1006に情報を入力する。引数種別1005は、引数1004の種別を表す情報であり、ユーザは引数種別1005に情報を入力する際、「リソース」または「リソース以外」のいずれかの情報を設定する。操作種別1006は引数1004に対して行われる操作の種類を表す情報であり、“CREATE”、“READ”、“UPDATE”、“DELETE”のいずれかが操作種別1006に設定される。
なお、本実施例におけるコマンド定義表は、ジョブが実際に実行するコマンドの引数に対して、引数種別1005および操作種別1006が指定されるものだが、コマンド定義表の内容や形式は、これに限定されない。引数に指定されたリソースに対してコマンドが実行するリソース操作の種別が定義された情報であればよい。例えば、コマンド定義表を、実際に実行されるコマンドでなく、より一般化しコマンド自体の定義を入力する表としてもよい。また本実施例では一例として、リソースがファイルである例を説明するが、引数で指定されるリソースはファイル以外のリソースでも良い。
図11は、本実施例におけるジョブネット検証装置201の表示装置205に表示されるコマンド定義表作成画面の例である。コマンド定義表作成画面1101は、コマンド定義表入力部114がユーザに提示する画面であり、ユーザからユーザ入力用コマンド定義表1001に対する入力を受け付けるための画面である。
コマンド定義表作成画面1101は、コマンド定義タブ1102および検証結果タブ1103を含む。コマンド定義タブ1102は、グループ・優先度決定部112が生成したユーザ入力用コマンド定義表1001への情報入力を行うための画面であり、ユーザ入力用コマンド定義ウィンドウ1104、表更新ボタン1106、検証ボタン1107を含む。検証結果タブ1103は、検証結果を確認するための画面であり、検証結果104を、例えば図19に示す表形式で表示する。
コマンド定義タブ1102では、ユーザは引数種別と引数への操作種別を、プルダウンリスト1105から選択することで、ユーザ入力用コマンド定義表1001に対する入力を行う。
ユーザが表更新ボタン1106を押下することで、グループ・優先度決定部112およびユーザ入力用コマンド定義表生成部113が実行される。これにより、コマンドに対するグループ、優先度の決定(または再決定)が行われ、生成されたユーザ入力用コマンド定義表1001の内容を反映したユーザ入力用コマンド定義ウィンドウ1104が、表示装置205に表示される。
ユーザ入力用コマンド定義ウィンドウ1104の表示の際、コマンド定義表入力部114はユーザ入力用コマンド定義ウィンドウ1104に表示される情報と同じ情報を格納した表を、たとえばメモリ203上に作成する。ここで作成される表を、最新版コマンド定義表1104’と呼ぶ。なお、ユーザ入力用コマンド定義ウィンドウ1104上で、引数種別または操作種別がまだ指定されていない箇所があっても、ユーザは表更新ボタン1106を押下してもよい。ユーザ入力用コマンド定義ウィンドウ1104に表示される情報のうち、引数種別と操作種別がまだ指定されていないコマンドの引数、或いは引数種別が“リソース以外”のコマンドの引数に関する情報は、最新版コマンド定義表1104’に反映されない。
なお、本実施例では、ユーザが表更新ボタン1106を押下したことに応じて表更新が開始される例を説明しているが、表更新の開始される契機はこれに限定されない。たとえば適当な時間間隔や特定のイベントをトリガとし、グループ・優先度決定部112およびユーザ入力用コマンド定義表生成部113が実行されるようにしてもよい。また、表更新ボタン1106が押下されることで実行される機能ブロック(グループ・優先度決定部112、ユーザ入力用コマンド定義表生成部113)とコマンド定義表入力部114のセットのことを「コマンド定義表作成部」と呼ぶこともある。
一方、ユーザが検証ボタン1107を押下すると、コマンド定義表更新検出部115、コマンド定義表更新通知部116、検証範囲特定部117および部分的検証実行部118が実行される。なお、検証ボタン1107が押下されることで実行される機能ブロック(コマンド定義表更新検出部115、コマンド定義表更新通知部116、検証範囲特定部117、部分的検証実行部118)のセットのことを「リソース競合検証部」と呼ぶこともある。
本実施例では、ユーザが検証ボタン1107を押下し、それに応じて検証が開始される例を説明しているが、適当な時間間隔や特定のイベントをトリガとし、コマンド定義表更新検出部115、コマンド定義表更新通知部116、検証範囲特定部117および部分的検証実行部118が実行されるようにしてもよい。
なお、本実施例に係るジョブネット検証装置201は、コマンド定義表更新検出部115、コマンド定義表更新通知部116、検証範囲特定部117あるいは部分的検証実行部118の実行と並行して、ジョブネット解析部111、あるいはグループ・優先度決定部112やユーザ入力用コマンド定義表生成部113を実行することもできる。そのためユーザは、部分的検証実行部118等によってジョブネットの検証が行われている間に、並行してジョブネット定義101の更新を行ってもよい。
あるいはユーザは、ジョブネットの検証が行われている間に、新たなユーザ入力用コマンド定義ウィンドウ1104(及び最新版コマンド定義表1104’)の作成を、ジョブネット検証装置201上で行うこともできる。これによりユーザは、ユーザ入力用コマンド定義ウィンドウ1104への情報入力(引数種別や操作種別の入力)を部分的に行った時点でジョブネット検証装置201にジョブネットの検証を行わせ、並行して、ユーザ入力用コマンド定義ウィンドウ1104に対して、未設定の箇所の情報入力を行うことができる。
ユーザが定義すべきコマンドは、案件が異なれば利用製品も異なるため、検証対象とするジョブネットが変われば、定義すべきコマンドも変わる。すなわち、コマンド定義表は、検証対象とするジョブネットごと,開発案件ごとに作成する必要がある。
図12は、本実施例における定義済みコマンド保持部122に格納される定義済みコマンド情報の例である。コマンドの定義はコマンド定義表入力部114を通じてユーザが入力する。ユーザに入力された情報は、定義済みコマンド情報1201として表形式で保持する。定義済みコマンド情報1201には、どのジョブが、どのようなコマンドを実行するのか、についての情報が、ジョブID1202、コマンド1203に保持される。更に、各コマンドに指定される引数、各引数の種別、各引数に対して行われる操作についての情報が、引数1204、引数種別1205、操作種別1206に格納される。なお、本実施例では、ユーザの入力により、引数種別が“リソース以外”と定義された引数の情報は、定義済みコマンド情報1201には含まれない。
図13は、本実施例におけるコマンド定義更新差分保持部123に格納されるコマンド定義更新差分情報の例である。コマンド定義更新差分情報1301は、最新のコマンド定義表が持つ情報と、定義済みコマンド保持部122に保持されている情報との差分にあたる。すなわち、コマンド定義更新差分情報1301とは、定義済みコマンド保持部122には保持されていないが、最新版コマンド定義表1104’には保持されている情報を指す。本実施例に係るジョブネット検証装置201はコマンド定義更新差分情報1301を、図12に示す定義済みコマンド情報1201と同じ表形式で保持する。
図14は、本実施例におけるコマンド定義表更新検出部の処理手順例を示すフローチャートである。
以下に示す処理は、ジョブネット検証装置201の備えるCPU202が、メモリ203に格納されたプログラムを実行することによって実現される。そしてこのプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
コマンド定義表更新検出部115は、コマンド定義表入力部114から最新版コマンド定義表1104’を取得する。(ステップ1401)
コマンド定義表更新検出部115は、続けて定義済みコマンド保持部122から、定義済みコマンド情報1201を取得する。(ステップ1402)
コマンド定義表更新検出部115は、ステップ1401で取得した最新版コマンド定義表1104’と、ステップ1402で取得した定義済みコマンド情報1201とを比較し、その差分に相当するコマンドを、コマンド定義更新差分情報1301として生成する。例えば、最新版コマンド定義表1104’と、定義済みコマンド情報1201を取得した場合、コマンド”ls -l /work/y.txt /work/z.txt”に対する定義は、定義済みコマンド情報1201には存在しないが、最新版コマンド定義表1104’には存在するため、当該コマンドの定義情報を、コマンド定義更新差分情報1301として生成する。(ステップ1403)
コマンド定義表更新検出部115は、ステップ1403で取得したコマンド定義更新差分情報1301を、定義済みコマンド保持部122に追記する。(ステップ1404)
更にコマンド定義表更新検出部115は、ステップ1403で取得したコマンド定義更新差分情報1301で、コマンド定義更新差分保持部123の情報を置換する。(ステップ1405)
なお、検証対象のジョブネット定義に対して初めて検証が行われる場合、定義済みコマンド保持部122には定義済みコマンド情報1201が存在しない。ステップ1402でコマンド定義表更新検出部115は、定義済みコマンド情報1201が存在しないことを検知した場合、ステップ1403は実行しない。またこの時、コマンド定義表更新検出部115は、ステップ1404では最新版コマンド定義表1104’の内容をコマンド定義更新差分情報1301として、定義済みコマンド保持部122に格納し、またステップ1405では、最新版コマンド定義表1104’の内容をコマンド定義更新差分保持部123に格納する。
図15は、本実施例におけるコマンド定義表更新通知部の処理手順例を示すフローチャートである。
以下に示す処理は、ジョブネット検証装置201の備えるCPU202が、メモリ203に格納されたプログラムを実行することによって実現される。そしてこのプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
コマンド定義表更新通知部116は、定義済みコマンド保持部122から、定義済みコマンド情報1201を取得する。(ステップ1501)
コマンド定義表更新通知部116は、コマンド定義更新差分保持部123から、コマンド定義更新差分情報1301を取得する。(ステップ1502)
最後にステップ1503でコマンド定義表更新通知部116は、ステップ1501およびステップ1502で取得した情報を、検証範囲特定部117に通知する。
図16は、本実施例における検証範囲特定部の処理手順例を示すフローチャートである。
以下に示す処理は、ジョブネット検証装置201の備えるCPU202が、メモリ203に格納されたプログラムを実行することによって実現される。そしてこのプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
先に述べたとおり、検証範囲特定部117はコマンド定義表更新通知部116から、定義済みコマンド情報1201と、コマンド定義更新差分情報1301を受領する。これに応じて図16の処理が開始される。
検証範囲特定部117は、コマンド定義更新差分情報1301に含まれる各行(コマンド)に対し、ステップ1602以降の処理を適用する。まずコマンド定義更新差分情報1301に、ステップ1602以降の処理を適用していない行が残っているかを確認する。(ステップ1601)
検証範囲特定部117は、未処理の行が残っている場合には、コマンド定義更新差分情報1301から未処理の行を一つ選択する。(ステップ1602)
検証範囲特定部117は、続いてステップ1602で選択した行に記述されたコマンドが操作する各引数(引数1304に記録されている引数)に対し、ステップ1604以降の処理を適用する。よって、ステップ1602で選択された行の引数1304に、ステップ1604以降の処理を適用していない引数が残っているか確認する。(ステップ1603)
検証範囲特定部117は、未処理の引数が残っている場合には、未処理の引数を一つ選択する。(ステップ1604)
ステップ1605で検証範囲特定部117は、ステップ1604で選択した引数と同名の引数を有するコマンドの定義情報を、同名引数操作コマンド情報として、定義済みコマンド情報1201から抽出する。具体的には検証範囲特定部117は、定義済みコマンド情報1201の行の中から、引数1204に、ステップ1604で選択した引数と同名の引数が含まれている行を抽出する。
ステップ1606で検証範囲特定部117は、ステップ1602で選択した行の情報およびステップ1605で抽出した同名引数操作コマンド情報を簡略化した情報を生成する。具体的には検証範囲特定部117は、検証時に必要となるジョブID、引数名、引数に対する操作種別の三つ組を生成する。ここで生成された情報を「リソース操作情報」と呼ぶ。また、ステップ1602で選択された行の情報を簡略化して生成されるリソース操作情報は、「更新差分情報のリソース操作情報」と呼び、一方同名引数操作コマンド情報から生成されるリソース操作情報は、「定義済みコマンドのリソース操作情報」と呼ぶ。なお本実施例では、このリソース操作情報を、<ジョブID,引数名,引数の操作種別>という形式で表記する。リソース操作情報の例については後述する。
検証範囲特定部117は、更新差分情報のリソース操作情報と、定義済みコマンドのリソース操作情報のペア(コマンドペアと呼ばれる)を作成する。(ステップ1607)
検証範囲特定部117は、ステップ1607で作成したコマンドペアの集合を、検証範囲情報として保持する。(ステップ1608)
ここでステップ1602〜ステップ1608の処理の具体例を、図12に記載された定義済みコマンド情報1201と、図13に記載されたコマンド定義更新差分情報1301の例を用いて説明する。例えば、ステップ1602にて、検証範囲特定部117がコマンド定義更新差分情報1301から、コマンド1303が”ls -l /work/y.txt /work/z.txt”の行を選択し、ステップ1604にてこの行の中から引数”/work/y.txt”を選択した場合を考える。この場合、ステップ1605では検証範囲特定部117は定義済みコマンド情報1201から、コマンド1203が”sort /work/x.txt /work/y.txt -o /work/z.txt”と”rm /work/x.txt /work/y.txt”の行を抽出する。
その後、ステップ1606では検証範囲特定部117は、ステップ1602及びステップ1605で得られた情報から、ジョブID、引数名、引数に対する操作種別の三つ組であるリソース操作情報を生成する。たとえばステップ1602で得られた行からは、<JobE, /work/y.txt, READ>が生成される。これが更新差分情報のリソース操作情報である。一方、ステップ1605で得られた同名引数操作コマンド情報からは、定義済みコマンドのリソース操作情報として、<JobE, /work/y.txt, READ>, <JobH, /work/y.txt, DELETE>が得られる。
そのためステップ1607では、更新差分情報のリソース操作情報と定義済みコマンドのリソース操作情報のペアとして、2つのペア
(<JobE, /work/y.txt, READ>, <JobE, /work/y.txt, READ>)と,
(<JobE, /work/y.txt, READ>, <JobH, /work/y.txt, DELETE>)
が作成される。検証範囲特定部117はこの2つのコマンドペアを検証範囲情報として保持する(ステップ1608)。
なお本実施例では、リソース操作情報(ジョブID、引数、操作種別の三つ組)のペアを検証範囲情報として保持しているが、ジョブID、引数、操作種別の三つ組のペアを特定可能な情報が含まれているものであれば、それを検証範囲情報として用いることができる。
検証範囲特定部117は、ステップ1608の後、再度未処理の引数が残っていないかを確認し(ステップ1603)、残っている場合にはステップ1604以降を繰り返す。全引数に対し処理を行った場合には、コマンド定義更新差分情報1301に、未処理のコマンドが残っていないか再度確認する(ステップ1601)。未処理のコマンドが残っている場合にはステップ1602以降を繰り返す。未処理の引数が残っていない場合には、ステップ1608で作成した検証範囲情報を、部分的検証実行部118に通知する。(ステップ1609)
図17は、本実施例における不具合パターン保持部に格納される不具合パターン情報の例である。不具合パターン情報1701は、同一のリソースにアクセスする2つのジョブが実行された時に不具合(エラー)が発生し得るリソース操作の組み合わせに関する情報である。不具合パターン情報1701は、不具合パターン名1702、リソース操作種別(1)1703、and/or1704、リソース操作種別(2)1705のカラムを有する表である。
リソース操作種別(1)1703とリソース操作種別(2)1705には、不具合が発生し得るリソース操作の種類が格納される。不具合パターン名1702には、発生し得る不具合の種類(名称)が格納される。またand/or1704は、リソース操作種別(1)1703とリソース操作種別(2)1705で特定される2つの操作が同時に成立すべきか、何れかが成立すべきかを表す情報である。and/or1704にandが格納されている場合、リソース操作種別(1)1703とリソース操作種別(2)1705で特定される2つの操作が同時に成立すると、不具合パターン名1702に格納されている種類の不具合が発生することを意味する。
図17の例では、不具合パターン名1702が「不在リソースへのアクセス」の行のリソース操作種別(1)1703とリソース操作種別(2)1705にはそれぞれ、“DELETE”、“not CREATE”が格納されている。またand/or1704にandが格納されている。これは、リソースの削除(DELETE)を行うジョブ(これを仮に「JobA」とする)と、リソース作成以外の操作(not CREATE)を行うジョブ(これを仮に「JobB」とする)が並行実施された場合、ジョブ(特にJobB)が、存在しないリソースにアクセスする可能性があることを意味する。
たとえばJobAがリソース削除を行った直後に、JobBがそのリソースに対する操作(たとえばリソース読み出し(READ),リソースの更新(UPDATE)である)を行おうとすると、対象のリソースが削除されている為、エラーが発生する。不具合パターン情報1701にはこのように、不具合(リソース競合)が発生し得るリソース操作の組み合わせに関する情報が1つ以上格納される。
不具合パターン情報1701は、あらかじめジョブネット検証装置201が保持している情報である。たとえばジョブネット検証装置201が実行するプログラムに不具合パターン情報1701がコーディングされているとよい。ただし別の実施形態として、利用製品コマンド一覧103等と同様に、ユーザがジョブネット検証を行う際に、不具合パターン情報1701をジョブネット検証装置201に入力するようにしてもよい。
図18は、本実施例における部分的検証実行部の手順例を示すフローチャートである。
以下に示す処理は、ジョブネット検証装置201の備えるCPU202が、メモリ203で実行するプログラムによって実現される。そしてこのプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
部分的検証実行部118は、解析結果保持部121からジョブ実行順序情報701を取得し、これを1つのグラフに統合したコールグラフを生成する。(ステップ1801)
部分的検証実行部118は、検証範囲特定部117から通知された検証範囲情報に含まれる各コマンドペアに対し、ステップ1803以降の処理を適用する。したがって、検証範囲情報に、未処理のコマンドペアが残っているかを確認する。(ステップ1802)
部分的検証実行部118は、未処理のコマンドペアが残っている場合には、検証範囲情報から未処理のコマンドペアを一つ選択する。(ステップ1803)
部分的検証実行部118は、ステップ1803で選択したコマンドペアが実行するリソース操作種別が、不具合パターン保持部124に格納された不具合パターンに合致するか判定を行う。(ステップ1804)
部分的検証実行部118は、ステップ1804における判定の結果、不具合パターンに合致しない場合には、リソース競合が発生しないと判断し、ステップ1802を再実行する。不具合パターンに合致する場合には、部分的検証実行部118はステップ1803で選択したコマンドペアが並行実行され得るかを判定する(ステップ1805)。これは、各コマンドを実行するジョブについて、ステップ1801で生成したコールグラフ上で、いずれか一方のジョブからもう一方のジョブに到達できるか否かを判定することで実現できる。
コールグラフの例を図20に示す。図20のコールグラフ上で、2つのジョブ(たとえばJobCとJobE)が並行実行され得るか判定する場合、部分的検証実行部118は一方のジョブ(たとえばJobC)を起点として深さ方向に探索を行うことで、JobEに到達することが可能か判定する。図20の場合、JobCから深さ方向(リーフノードの方向)にグラフを辿っていくとJobEに到達できる。この場合、JobEはJobCの後に実行されるという順序関係がジョブネット定義に定義されていることを意味する。そのため部分的検証実行部118は、JobEとJobCは並行実行されることはないと判断する。
一方JobCとJobHは、並行実行され得るジョブである。JobCから深さ方向にグラフを辿ってもJobHに到達せず、あるいはJobHから深さ方向にグラフを辿っても、JobCに到達しないからである。そのためこの場合、部分的検証実行部118は、JobCとJobHは並行実行され得ると判断する。なおコールグラフ上でのジョブ間の到達可能性はこれ以外の方法で判定されてもよい。たとえばグラフを隣接行列として表現し、隣接行列のべき乗を計算することでも実現できる。
また、ステップ1803で選択したコマンドペアに登録されているジョブが同じ場合もある。たとえば先に説明した検証範囲特定部117の処理(ステップ1607の処理)で、(<JobE, /work/y.txt, READ>, <JobE, /work/y.txt, READ>)というコマンドペアが作成される例を説明した。本実施例では、ジョブIDが同じコマンドペアについては、部分的検証実行部118はステップ1805で、並行実行されることはないと判定する。本実施例に係るジョブネット検証装置201は、ジョブ間で発生し得るリソース競合の検出を目的としており、ジョブ内で発生し得るリソース競合は検出対象外だからである。
部分的検証実行部118は、ステップ1805における判定の結果が到達可能であった場合、リソース競合が発生しないと判断し、ステップ1802を再実行する。到達不可能であった場合には、不具合パターンに合致し、並行実行し得るコマンドペアである。よって部分的検証実行部118は、当該コマンドペアはリソース競合を生じ得ると判断し、発生し得る不具合パターン、リソース競合が発生するリソース、リソース競合を発生させる2つのジョブに関する情報を検証結果104に記録する。(ステップ1806)
部分的検証実行部118は、ステップ1806の後、再度未処理のコマンドペアが残っていないかを確認し(ステップ1802)、残っている場合にはステップ1803以降を繰り返す。全コマンドペアに対し処理が行われた場合には、部分的検証実行部118は保持している検証結果104を表示装置205に出力する。(ステップ1807)
例えば、検証範囲特定部117から、以下の2つのコマンドペア
(<JobE, /work/y.txt, READ>, <JobE, /work/y.txt, READ>)と,
(<JobE, /work/y.txt, READ>, <JobH, /work/y.txt, DELETE>)
が通知された場合を考える。前者のコマンドペアは、操作種別がREAD, READであり、不具合パターン情報1701の何れにも合致しない。よって、当該コマンドペアによってリソース競合は発生しえないと判断される。また、後者のコマンドペアは、不具合パターン情報1701に合致する。また、ジョブネット定義402に従えば、ジョブEおよびジョブHは並行実行し得る。したがって、当該コマンドペアは、リソース競合を発生し得ると判断され、部分的検証実行部118はこのコマンドペアの情報を検証結果104に記録する。
なお、本実施例では、2つのリソース操作コマンドのペアに着目する検証方法を用いたが、ジョブ実行順序情報、実行コマンド情報、コマンド定義表に含まれる情報を用いた、いかなる検証方法を用いてもよい。
図19は、本実施例における検証結果の例である。検証結果104には、検証対象としたジョブネットで発生し得るリソース競合の情報が含まれる。具体的には、発生し得る不具合パターン名1902、リソース競合の対象となるリソース名1903とリソース種別1904が含まれる。また、リソース競合を引き起こす2つのジョブそれぞれについて、ジョブID1905、リソース競合を引き起こすコマンド1907、当該コマンドの操作種別1908が含まれる。
以上が、本実施例に係るジョブネット検証装置及びジョブネット検証装置で実行されるジョブ検証方法の説明である。本実施例に係るジョブネット検証装置は、ジョブの実行順序に相当するジョブネット定義、ジョブが実行するプログラムのソースコード、検証対象のジョブネットが実行されるシステムで利用される製品(プログラム群)が持つコマンド一覧を入力として受け付ける。ジョブネット検証装置はこれらを解析することで、ジョブの実行順序と、ジョブが実行するコマンドの情報を獲得する。更にジョブネット検証装置は、ジョブが実行する各コマンドの各引数がリソースであるか否か、そして引数がリソースである場合に当該引数(リソース)に対して行われる操作の種類についての情報をユーザに入力させ、コマンド定義表を生成する。そしてジョブネット検証装置は、ジョブ実行順序、実行コマンド、コマンド定義表の情報を用い、ジョブネットの実行時にリソース競合が発生し得るかを検証する。
また、上記ジョブネット検証の際に、ジョブネット検証装置は同一リソースに対する操作を実行する2つのコマンドの組み合わせ(コマンドペア)を全通り列挙し、全てのコマンドペアについて、当該コマンドペアが実行するリソース操作種別が不具合パターンに一致するか否か、そして当該コマンドペアが並行実行されるか否か、の双方を判定する。これにより、ジョブネット実行時に発生し得るリソース競合を、網羅的にチェックすることができる。その結果、検出したリソース競合への対策を通じて、システム停止による事故を防止できるようになる。
さらにジョブネット検証装置は検証を行う前に、過去のある時点でのコマンド定義表である旧コマンド定義表と、現時点でのコマンド定義表である新コマンド定義表とを比較し、その差分から、新たに操作種別が定義されたコマンドの一覧であるコマンド定義更新差分情報を作成する。そして、コマンド定義更新差分情報に含まれるコマンドと同一リソースにアクセスするコマンドを、上記旧コマンド定義表から定義済みコマンド情報として抽出する。そして、上記コマンド定義更新差分情報と、上記定義済みコマンド情報から、同一リソースにアクセスするコマンドのペアを全通り作成し、これを検証範囲とした上で、ジョブネット検証を行う。これにより、新たに定義されたコマンドに対してのみ検証を行う、部分的検証が可能になる。
また本実施例に係るジョブネット検証装置では、一部の情報だけが定義済みであるコマンド定義表に対してもジョブネット検証が実行できる。その結果、コマンド定義表を部分的に作成し、検証を開始した後、検証実行と並行してコマンド定義表の作成を再開できるようになる。これにより、コマンド定義表を完成させてから検証を実行する場合と比べ、コマンド定義表作成開始から検証終了までにかかる時間を短縮させることができる。
また、上記コマンド定義表に含まれるコマンドに対し、コマンドをグループ化し、各グループに対して、操作種別を定義する順序に対する優先度を付与する。そして、決定されたコマンドグループ、優先度にしたがって、ユーザが各コマンドの操作種別を入力するためのコマンド定義表を作成する。これにより、ユーザがコマンドの定義を入力する際に、早期に検証を開始できるようコマンド定義の入力順序を示唆でき、ユーザがコマンド定義表に示唆される優先順位にしたがってコマンド定義を入力することで、検証効率を向上させることができる。
以上、本発明の実施例を説明してきたが、これらは、本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施する事が可能である。たとえば上で述べた実施例では、ジョブネット解析部や部分的検証実行部等の機能ブロックが、汎用的な計算機のプロセッサでプログラムが実行されることにより実現される機能ブロックである例を説明したが、別の実施形態として、ジョブネット検証装置の一部または全ての機能ブロックが、FPGAやASIC等のハードウェアで実装されていてもよい。