JP4978432B2 - 業務仕様理解支援システム及び方法 - Google Patents

Description

情報システムで使用されているインタフェースとその処理を行うプログラムの解析を行い、プログラムの理解を支援するリバースエンジニアリング支援に関する。

従来、プログラム等のシステム情報からシステムの仕様に関する情報を抽出するリバースエンジニアリング技術は広く活用されている。しかし、プログラム等から抽出したシステム仕様のみでは業務機能の理解が可能な仕様を回復することは不可能である。そこで、プログラムの成す業務機能的に意味のある集合を抽出し、それに意味を付加するようなシステムが特許文献１で提案されている。このシステムでは、業務機能と入出力論理データの対応、業務機能とプログラムの対応、論理データと物理データの対応をそれぞれユーザに入力させ、それらとリバースエンジニアリングの解析結果を組み合わせることで、抽出された情報システムの要素に業務的な意味付けをしている。

また、プログラム等のシステム情報ではなく、実際に業務機能で使用している帳票に着目し、その帳票の様式から複数のデータ構造の異なる帳票が絡み合った事務処理業務機能の処理仕様を自動的に生成する提案が特許文献２でなされている。このシステムでは、帳票データ群の様式を入力として、それらとあらかじめ用意された業務辞書と業務知識ベースを組み合わせることで整合性の取れたデータ構造に従った業務機能処理仕様を生成している。

特開２００６−２８５７０７ 特開平０４−１６９９６８

情報システムから業務仕様を抽出する際には、例えば辞書などの形態で業務知識を情報システムに付与することが必要である。しかし、業務知識を有する人は、プログラムや情報システムの構造、データ構造について深い知識をもっているとは限らず、直接的にそれらと結びついた形で業務知識を入力させるのには限界がある。例えば、情報システムを用いて業務を実際に行う人は、ある業務機能を処理する際にどのプログラムが動いていて、どのデータが参照、更新されているかを意識して業務を行うことはなく、業務機能処理のために必要な入力のみを意識して業務を行うことが多い。

また、特にオンラインシステムでは、複数のアプリケーションが同一のデータベースに対して更新を行う場合が多い。このようなシステムから業務仕様を抽出する際には、各業務機能で処理される情報を、データベース単位ではなくデータ項目単位で解析する必要がある。

本発明が解決しようとする課題は、プログラム等の現行システム情報に加え、業務知識を有する人が容易に定義できる情報を用いてデータ項目レベルで解析を行うことにより、業務的に理解できる仕様を抽出することができることである。

本発明のシステムでは、業務機能とそれに対応する一連の画面などのインタフェースを入力とし、現行システムの情報を解析することにより、該当業務機能において更新するデータ項目、および参照するデータ項目を抽出する。業務機能とは、1人のユーザがある業務的な目的を達成するために行う一連の操作のことである。ユーザから入力される業務機能とインタフェースの対応は、情報システムと外部との対応でしかないため、情報システムを構成するプログラムと業務機能との対応はそれだけでは示せない。

そこで、ユーザにより指定された業務機能に対応するインタフェースそのものを解析し、入出力データ項目と対応するプログラムを求める。
次に、プログラムを解析し、プログラムに対する入出力データ項目とおそのデータ項目対応するデータベースを求める。
それぞれで求められた結果を用い、１つの業務機能において更新されるデータ項目と、そのデータ項目を生成するために必要となるデータ項目がどのインタフェースから入力されたものであるかを抽出する。

これらの情報から、１つの業務機能で更新されるデータを生成するために必要なデータ項目であるにもかかわらず、その業務機能内で入力されないデータ項目を特定する。特定されたデータ項目を前提条件項目と呼ぶ。ある業務機能に前提条件項目が存在する場合、その業務機能を処理するより先に前提条件項目を更新する業務機能が処理されている必要がある。そのような２つの業務機能間に成立する関係を、依存関係と呼ぶ。
これまでの解析結果から、ある業務機能に対して、前提条件項目と判断されたデータ項目が、どの業務機能において更新されるかを判定することで、２つの業務機能間にある依存関係を求める。

このようにして求められた依存関係をユーザに表示することで、情報システムから抽出された業務仕様を、よりユーザに理解しやすい形式で提示することができる。

業務システムの理解を支援することができる。

本発明の実施の形態を以下に述べる。

図２２は、本システムのハードウェア構成を表す図の一例である。処理装置２２０１はプロセッサ２２０２とメモリ２２０３とインタフェース２２０５（以下、I/Fと表記する）とを有する。また、本システムにはハードディスクドライブ等の記憶装置２２０６が接続されている。

メモリ２２０３に格納された業務I/F選択プログラム、I/F解析プログラム、プログラム解析プログラム、前提条件探索プログラム、依存関係解析プログラム、依存関係表示プログラムなど各種プログラム２２０４をプロセッサ２２０２が実行することで、各処理を行う。

これらは、各処理を行う処理部として集積回路化するなどしてハードウェアで実現することもできる。

以下説明を簡略化するため、各種プログラム２２０４をプロセッサ２２０３が実行することで実現される各処理部を各処理の主体として説明する。なお各処理部をハードウェアで実現した場合にはその各処理部が主体となって各処理を行う。

図１にシステムの構成を示す。本実施例のシステムは、ユーザからの入力を受け付け、業務機能を決定する機能を有する業務I/F選択処理部１０と、対象システムが有するインタフェースの集合であるI/F集合１１と、I/F集合１１を表示しユーザからの入力を受け付ける画面１２と、業務機能とI/Fの対応関係を管理する業務I/Fテーブル１３と、対象システムが有するI/Fのソースプログラムの集合であるI/Fソースプログラム５１と、I/Fの解析を行うI/F解析処理部５０と、I/Fの解析結果を管理するI/Fテーブル５２と、対象システムが有する処理プログラムのソースプログラムの集合である処理ソースプログラム６１と、プログラムの解析を行うプログラム解析処理部６０と、プログラムの解析結果を管理するプログラムテーブル６２と、業務機能内で処理されるデータ項目を解析してその入力元を探索する前提条件探索処理部７０と、前提条件探索の結果を管理する業務テーブル７１と、業務機能間の依存関係を特定する依存関係解析処理部８０と、依存関係解析の結果を管理する前提業務機能テーブル８１と、それまでの処理によって求められた業務機能間の依存関係をユーザに表示する依存関係表示処理部９０で構成される。

図２に本実施例で対象とするシステムの一例を示す。本実施例で対象とするシステムは、１つ以上のI/Fと、それに対応するプログラムと、そのプログラムによって参照、更新されるデータベース（以下、DBと表記する）で構成されるものとする。
図２は、受注登録業務機能に対するユーザに対する出入力と、それらに対応するプログラムに対する出入力の処理の流れを模式図として表したものである。

処理の流れを以下に示す。
ユーザに対して受注登録画面が表示される。ユーザは、受注登録画面に対して得意先コード（CD）、商品CD、商品数量を入力する。受注登録画面は、入力されたデータ項目のうち、商品CDを引数として受注登録確認処理プログラムを呼び出す。受注登録確認処理プログラムは、商品CDをキーとして商品マスタを検索し、結果として商品CDに対応する商品名を引き当てる。受注登録確認処理プログラムは、商品CDと商品名を引き継いで受注登録確認画面を生成する。受注登録確認画面では、｛得意先CD、商品名、商品数量｝をユーザに表示する。受注登録画面は、ユーザの「登録」ボタン押下によって｛得意先CD、商品CD、商品名、商品数量｝を引数として受注登録処理プログラムを呼び出す。受注登録処理プログラムは、得意先CDをキーとして得意先マスタを検索し、結果として得意先CDに対応する得意先名を引き当てる。さらに受注登録処理プログラムは、｛得意先CD、得意先名｝から得意先IDを生成し、受注NO（ナンバー）を自動生成する。受注登録処理プログラムは、受注NOをキーとして、受注伝票レコード｛受注NO、商品CD、商品名、商品数量、得意先ID｝を更新する。

本実施例では、以上のようにユーザによって処理される一連の流れを業務機能として定義し、この業務機能で利用される画面の集合をユーザからの主な入力とする。

図３に、本実施例の全体処理フローを示す。対象とする情報システムが所有する全てのI/Fを表示し、ユーザはその情報を基にどの業務機能でどのI/Fを、どのような順番で使用するのかを入力する。業務I/F選択処理部は、ユーザによって入力された情報を基に、業務I/Fテーブル１３を生成する（ステップ１００）。

図１０は業務I/Fテーブルの一例を示す図である。業務I/Fテーブル１３は、業務機能名を格納する業務機能１４、業務機能１４に示された業務機能にて利用するI/F名を格納するI/F１５、I/F１５に示したI/Fが業務機能１４に示された業務機能内で利用される順番を格納する順番１６を有している。

ユーザに対して業務知識の入力画面を表示する（ステップ１００）。当画面では、ある業務機能において、どんなI/Fを、どんな順序で利用するのかを入力させる。例えば、受注登録業務機能において、１番目に受注登録画面を使用し、2番目に受注登録確認画面を使用する場合、図１０に示したような業務機能I/Fテーブルが得られる。

次に、業務機能I/Fテーブルを基に、対象システムに関する解析業務機能テーブル１７を作成する（ステップ２００）。
対象システムの解析は、業務機能ごとに行われる。解析業務機能テーブル１７は、解析の対象となる業務機能を管理する。

図１１は、解析する業務機能を管理する解析業務機能テーブルの一例を示す図である。解析業務機能テーブルは、解析の対象とする業務機能名を格納する業務機能１８と、当該の業務機能が解析されたことがあるかどうかを示すフラグ１９を有する。

次に、解析業務機能テーブル１７のフラグ１９を参照し、全てがマーク済みであるかどうかを判断する（ステップ３００）。
全てマーク済みである場合、対象とする全ての業務機能について解析は終了していると判断し、ステップ８００に進む。
それ以外の場合、解析は終了していないと判断し、ステップ４００に進む。

次に、解析業務機能テーブルを1行読み込み、業務機能１８に格納されている業務機能名を取り出し、フラグ１８にマークする（ステップ４００）。フラグ１９に対するマークとして、例えば“○”などの記号を入力する。

次に、取り出された業務機能に含まれるI/Fを対象として、I/F解析処理部がI/F解析を行う（ステップ５００）。

I/F解析の結果は、I/Fテーブル５２に格納される。

図１３は、I/Fテーブルの一例を示す図である。I/Fテーブルは、解析の対象であるI/F名を格納するI/F５３と、当該I/Fの出力データ項目を格納する出力項目５４と、その出力データ項目の出力先を格納する出力先５５と、その出力先がプログラムであるのか、I/Fであるのかを示す種別５６と、その出力データ項目の元となる入力データ項目を格納する入力項目５７と、その入力データ項目がユーザから入力されたのか、そうでないのかを示す入力元５８を有する。

次に、取り出された業務機能に含まれるI/Fに対応する全てのプログラムを対象として、プログラム解析処理部がプログラム解析を行う（ステップ６００）。
プログラム解析の結果は、プログラムテーブル６２に格納される。

図１５は、プログラムテーブルの一例を示す図である。プログラムテーブルは、解析の対象であるプログラム名を格納するプログラム６３と、当該のプログラムの出力データ項目を格納する出力項目６４と、その出力データ項目の出力先を格納する出力先６５と、その出力先がI/Fであるのか、DBであるのかを示す種別６６と、その出力データ項目の基となるデータ項目を格納する入力項目６７と、その入力データ項目がDBから取得されたのか、そうでないのかを示す入力元６８を有する。

次に、取り出された業務機能内において、DBに対して更新が行われる全てのデータ項目を対象として、前提条件探索処理部が前提条件探索を行う（ステップ７００）。
前提条件探索の結果は、業務機能テーブル７１に格納される。

図１７は、業務機能テーブルの一例を示す図である。業務機能テーブルは、解析の対象であるデータ項目が所属する業務機能名を格納する業務機能７２と、その業務機能内の前提条件である入力項目を格納する項目７３とを有する。

ここで、”前提条件である”とは、ある業務機能内で更新されるデータ項目、あるいはその基となるデータ項目であるが、その業務機能内ではユーザから入力されないデータ項目であることを意味する。

ステップ３００における判断で、解析業務機能テーブル１７のフラグ１９が全てマーク済みであった場合、対象システムに含まれる全ての業務機能を対象として依存関係解析処理部が依存関係特定を行う（ステップ８００）。
依存関係特定の結果は、前提業務機能テーブル８１に格納される。

図２０は、前提業務機能テーブルの一例を示す図である。前提業務機能テーブルは、解析の対象である業務機能名を格納する業務機能８２と、その前提業務機能の業務機能名を格納する前提業務８３を有する。

ここで、”前提業務機能である”とは、ある業務機能の前提条件であるデータ項目を入力項目としてもつ業務機能を示す。

最後に、対象とするシステムに所属する全ての業務機能を対象として、依存関係表示処理部が表示処理を行うことで、ユーザに対して、業務仕様を提示する（ステップ９００）。

ステップ１００の詳細を説明する。

図４は、ステップ１００にてユーザに表示する画面イメージの一例である。ステップ１００では業務I/F選択処理部が、I/F集合１１からI/Fを取り出して、例えば遷移情報などといったI/F間の関係を表示する。ユーザは、表示された画面に対して、業務機能名を指定する。例えば、テキストフィールドなどによって業務機能名の入力を受け付ける。次にその業務機能で利用するI/Fを選択し、そのI/Fを利用する順番を入力する。例えば、表示されているI/Fに付随するチェックボックスなどによって入力を受け付ける。業務機能名の入力、利用するI/Fの選択、利用順番の入力は、１つの業務機能に対してそれぞれが指定できればよく、その形式について厳格には問わない。

例えば、受注登録業務において、受注登録画面を1番目に利用し、受注登録確認画面を2番目に利用する場合、図１０のように業務I/Fテーブルが作成される。

次に、図５に従ってステップ５００の詳細を説明する。

図５は、I/F解析の詳細処理フローを示した図である。

I/F解析処理部は、ステップ４００にて取り出した業務機能名をキーとして、業務機能I/Fテーブル１３の業務機能１４を探索し、該当する行のI/F２１に格納されているI/Fを抽出し、解析I/Fテーブルに転記する（ステップ５１０）。

図１２は、「受注登録業務機能」をキーとした場合の解析I/Fテーブルの一例を示した図である。解析I/Fテーブルは、解析の対象であるI/F名を格納するI/F２１と、そのI/Fが解析されたことがあるかどうかを示すフラグ２２を有する。
解析I/Fテーブルのフラグ２２を探索し、全てがマークされているか否かを判断する（ステップ５２０）。
全てがマーク済みである場合、対象とする全てのI/Fについて解析は終了したと判断し、ステップ５００の処理を終了する。
それ以外の場合、解析は終了していないと判断し、ステップ５３０に進む。

次に、解析I/Fテーブルのフラグ２２が空欄でない行を１行読み込み、該当する行のI/F２１に格納されているI/F名を取り出して、当該行のフラグ２２にマークする（ステップ５３０)。フラグ２２に対するマークとして、例えば“○”などの記号を入力する。
取り出されたI/F名をキーとして、I/Fソースプログラムから該当するI/Fを取り出し、解析を行う。
I/F解析では、該I/Fがどのようなデータを出力するのかを表す出力項目と、その出力項目がどのようなプログラムまたはI/Fに対して出力されるかを表す出力先と、その出力先がプログラムであるかI/Fであるかを表す種別と、出力項目がどのような入力項目から生成されるのかを表す入力項目と、その入力項目がどこから入力されるかを表す入力元を結果として出力する。

I/Fの解析結果を、I/Fテーブル５２に格納する。
例えば、I/Fの一例を画面であるとして、その画面に表示されるような項目である場合、出力先５５は空欄であるとし、種別５６に”ユーザ”を記入する。
また、例えば、画面におけるテキスト入力など、I/Fに対して明らかにユーザから入力されるようなデータ項目については、入力元５８に”ユーザ”と記入し、それ以外のものは入力元５８を空欄とする。

例えば、解析の対象とするI/Fが「受注登録確認画面」であり、解析の結果、「商品名」は画面に表示される項目であることがわかった場合、I/Fテーブルに｛受注登録確認画面、商品名、“ ”、ユーザ、商品名、“ ”｝からなる１行を記入する。

図１３は、「受注登録確認画面」、「受注登録画面」をそれぞれキーとして、I/F解析を行った結果を格納した一例である。

次に、図６に従ってステップ６００の詳細を説明する。

図６は、プログラム解析の詳細処理フローを示した図である。

プログラム解析処理部が、ステップ５００にて生成したI/Fテーブル５２の種別５６が”プログラム”であるものを探索し、該当する行のI/F５３と出力先５５を抽出し、重複を排除し、それぞれ解析プログラムテーブル２３のI/F２４とプログラム２５に格納する。

図１４は、図１３に示したI/Fテーブルを入力とした場合に生成される解析プログラムテーブルの例を示した図である。解析プログラムテーブルは、解析の対象とするプログラムに対応したI/F名を格納するI/F２４と、解析の対象であるプログラム名を格納するプログラム２５と、解析されたことがあるかどうかを示すフラグ２６を有する。

解析プログラムテーブル２３のフラグ２６を探索し、全てがマークされているか否かを判断する（ステップ６２０）。
全てがマーク済みである場合、対象とする全てのプログラムについて解析は終了したと判断し、ステップ６００の処理を終了する。
それ以外の場合、解析は終了していないと判断し、ステップ６３０に進む。

次に、得られた解析プログラムテーブル２３を１行読み込み、該当する行のプログラム２５に格納されているプログラム名を取り出して、当該行のフラグにマークする（ステップ６３０）。
取り出されたプログラム名をキーとして、処理ソースプログラムから該当するプログラムを取り出し、解析を行う。

プログラムの解析結果を、プログラムテーブル６２に格納する。
対象とするプログラムに対する入力データ項目のうち、DBを参照している項目については、入力元６８に該当するDB名を記入し、それ以外のものは入力元６８を空欄とする。
例えば、解析対象のプログラムが「受注登録処理」であり、解析の結果、「得意先ＩＤ」は「得意先ＣＤ」と「得意先名」の２つの入力項目から生成されるデータであることが分かった場合、プログラムテーブルに｛受注登録処理、得意先ＩＤ、受注伝票、ＤＢ、得意先ＣＤ、“ ”｝と｛受注登録処理、得意先ＩＤ、受注伝票、ＤＢ、得意先名、得意先マスタ｝の２行を記入する。

図１５は、「受注登録処理」、「受注登録確認処理」をそれぞれキーとして、プログラム解析を行った結果を格納した一例である。

次に、図７に従ってステップ７００の詳細を説明する。

図７は、前提条件探索処理の詳細処理フローを示したものである。

前提条件探索処理部は、ステップ６００にて生成したプログラムテーブル６２の種別６６が”DB”であり、かつ入力項目６７が空欄でないものを探索し、該当する行を抽出することで、解析データテーブルを作成する（ステップ７１０）。

ステップ７００の処理の目的は、当該業務機能内でDBに対して更新を行うデータ項目を解析し、その入力元を特定することである。プログラムテーブル６２において、入力項目６７が空欄である行の出力項目６４に格納されているデータ項目は、当該行のプログラム６３に格納されているプログラム名に対応するプログラム内において、独自に生成されたデータ項目であると判断できるため、解析データテーブルには含めない。

図１６は、解析データテーブルの一例を示したものである。図１６に示すとおり、解析データテーブル２９は、解析の対象とするデータ項目が所属するプログラム名を格納するプログラム３０と、解析の対象とするデータ項目を格納する出力項目３１と、そのデータ項目の基となるデータ項目を格納する入力項目３２と、その入力項目の入力元を格納する入力元３３と、そのデータ項目が解析されたことがあるかどうかを判断するフラグ３４を有する。

次に、解析データテーブル２９のフラグ３４を探索し、全てがマークされているか否かを判断する（ステップ７２０）。
全てがマーク済みである場合、対象とするデータ項目について解析は終了したと判断し、ステップ７００の処理を終了する。
それ以外の場合、解析は終了していないと判断し、ステップ７３０に進む。

次に、解析データテーブル２９のフラグ３４が空欄であるものを１行読み込み、該当する行の入力項目３２に格納されているデータ項目を取り出し、当該行のフラグ３４にマークする（ステップ７３０）。フラグ３４に対するマークとして、例えば“○”などの記号を入力する。

次に、当該業務機能名と当該行の出力項目３１を、更新項目テーブル７５の業務機能７６と出力項目７７にそれぞれ転記する（ステップ７３５）。

図１９は、更新項目テーブルの一例を示した図である。図１９に示した通り、更新項目テーブルは、対象とする業務機能名を格納する業務機能７６と、その業務機能内でDBに対して更新されるデータ項目を格納する出力項目７７を有する。

次に、当該行の入力項目３２に格納されているデータ項目を対象として入力起点探索処理を行う（ステップ７４０）。
入力起点探索処理とは、あるプログラムやI/Fにおける出力項目が、そのプログラム内やI/F内においてどのような入力項目を基に生成されているかを特定し、特定された入力項目を出力するようなプログラムやI/Fを探索し、その項目をそのプログラムやI/Fにおける出力項目として先述の処理を繰り替えることで、結果としてはじめに着目した出力項目が、対象としている業務機能内においてどのような形式で入力されているかを探索する処理である。

図８は、入力起点探索処理の詳細フローを示した図である。
入力起点探索処理の結果として、該業務機能を業務機能テーブル７１の業務機能７２に格納し、さらに対象とするデータ項目が該業務機能内では入力されないと判断されたデータ項目を業務機能テーブル７１の入力項目７３に格納する。

図１７は、「受注登録業務機能」を解析の対象として、該業務機能内で更新されるDB項目の基となるデータ項目は、｛商品CD、商品名、商品数量、得意先CD、得意先名｝であり、そのうち、入力起点探索処理の結果、受注登録業務機能内で入力されないと判断されるのは、｛商品名、得意先名｝であるという結果を示した一例である。

次に、図８に従って入力起点探索処理（ステップ７４０）の詳細を説明する。
ステップ７４０の入力は、ステップ７３０にて読み込んだ解析データテーブルの１行である。

当該行のプログラム３０に格納されているプログラムと、出力項目３１に格納されているデータ項目と、入力項目３２に格納されているデータ項目をキーとして、プログラムテーブル６２のプログラム６３と出力項目６４と入力項目６７をプログラムテーブルに対する探索条件とし、探索対象をそれぞれプログラムテーブル６２のプログラム６３、出力項目６４、入力項目６７とする（ステップ７４１）。

次に、ステップ７４２またはステップ７５０にて設定された探索条件と探索対象について、プログラムテーブルを探索し、該当する行を取り出す（ステップ７４２）。
次に、取り出した行を読み込み、当該行の入力元６８が空欄であるかどうかを判定する（ステップ７４３）。
入力元６８が空欄でなかった場合、着目したデータ項目の入力元はDBである、と判断し、ステップ７４９に進む。
空欄であった場合、着目したデータ項目の入力元は、該プログラムの外部であると判断する。

例えば、着目しているデータが「商品CD」であった場合、プログラムテーブルより、その入力元は空欄であるため、「商品CD」はプログラム受注登録処理の外部から入力されるデータであると判断する。

次に、当該行のプログラム６３に格納されているプログラムと、入力項目６７に格納されているデータ項目をキーとして、I/Fテーブル５２の出力先５５、出力項目５４を探索し、該当する行を抽出する（ステップ７４４）。
次に、抽出された行の１行を読み込み、入力元５８が空欄かどうかを判定する（ステップ７４５）。
入力元５８が空欄でなかった場合、着目したデータ項目の入力元はユーザであり、そのデータ項目は当該業務機能内で入力されるデータであると判断し、ステップ７４０の処理を終了する。

空欄であった場合、着目したデータ項目の入力元は、ユーザ以外であると判断する。
例えば、着目したデータが「商品CD」であった場合、対応する入力元は空欄であるため、「商品CD」はユーザ以外から入力されるデータであると判断する。

次に、I/Fテーブル５２における当該行のI/F５３に格納されているI/Fをキーとして、業務I/Fテーブル１３のI/F１５を探索し、該当する行の順番１６に格納されている数値を取り出す。さらに、直前に処理されるI/Fを探索するため、（その数値−１）である数値をキーとして業務I/Fテーブル１３の順番１６を探索する（ステップ７４６）。
例えば、ステップ７４４で着目したI/Fが受注登録確認画面であった場合、これをキーとして業務I/Fテーブルを探索することで、直前に処理されるI/Fとして受注登録画面を得る。
該当する行が存在しない場合、解析データテーブル２９の出力項目３２に格納されているデータ項目に関する探索は全て終了したと判断し、ステップ７４０の処理を終了する。
該当する行が存在した場合、解析業務機能テーブル１３のI/F１５をキーとして、解析プログラムテーブル２３を探索し、該当する行のプログラム２５に格納されているプログラムを取り出す。取り出したプログラムと、I/Fテーブル５２のステップ７４４で取り出した行の入力項目５７に格納されているデータ項目をプログラムテーブルに対する探索条件とし、探索対象を、それぞれプログラムテーブル６２のプログラム６３、出力項目６４であるとし、ステップ７４２に戻る。

最後に、対象としている解析業務機能テーブル１７の業務機能１８に格納されている業務機能名と、プログラムテーブル６２の入力項目６７に格納されているデータ項目を、それぞれ業務機能テーブル７１の業務機能７２、入力項目７３に記入する。

この処理を行うことで、業務機能単位に当該業務機能で更新されたデータ項目と、更新されたデータ項目がどの入力データ項目に基づいて生成されたのか、その入力データの発生源はどこなのかを特定することができ、当該業務機能で決定されるデータ項目と、他業務機能からの入力が前提となるデータ項目の情報を生成することができる。

この処理の過程で、業務機能とインタフェースの対応関係と、インタフェースとプログラムの対応関係をデータ項目キーとして探索することに本実施例の特徴がある。

次に、図９に従ってステップ８００の詳細を説明する。

図９は、依存関係解析の詳細処理フローを示した図である。

依存関係解析処理部は、ステップ８００において、ステップ７００で作成された業務機能テーブル７１を入力として、入力項目７３に格納されているデータ項目を更新するような業務機能を特定し、前提業務機能テーブル８１を作成する。

図２０は、前提業務機能テーブルの一例を示したものである。図２０に示すとおり、前提業務機能テーブルは、着目している業務機能名を格納する業務機能８２と、その前提となる業務機能の名称を格納する前提業務８３を有する。
ステップ１００にて作成した解析業務機能テーブル１７のフラグ１９を全て空欄にする（ステップ８１０）。

次に、解析業務機能テーブル１７のフラグ１９を探索し、全てマーク済みであるかどうかを判断する（ステップ８２０）。
全てがマーク済みである場合、対象とする業務機能全てについて解析は終了したと判断し、ステップ８００の処理を終了する。
それ以外の場合は、解析は終了してないと判断し、ステップ８３０に進む。
次に、解析業務機能テーブル１７を１行読み込み、業務機能１８に格納されている業務機能名を取り出して、フラグ１９にマークする（ステップ８３０）。フラグ１９に対するマークとして、例えば“○”などの記号を入力する。
取り出した業務機能名をキーとして、業務テーブル７１の業務７２を探索し、該当する行の業務機能７２に格納されている業務機能名と項目７３に格納されているデータ項目を取り出し、解析前提項目テーブル３５の業務機能３６、入力項目３７に転記することで、解析前提項目テーブル３５を作成する（ステップ８４０）。

図１８は、解析前提項目テーブルの一例を示した図である。図１８に示したとおり、解析前提項目テーブル３５は、解析の対象となるデータ項目が所属する業務機能名を格納する業務機能３６と、解析の対象であるデータ項目を格納する入力項目３７と、そのデータ項目の解析されたことがあるかどうかを示すフラグ３８を有する。

次に、解析前提項目テーブル３５のフラグ３８を参照し、全てマーク済みであるかどうかを判断する（ステップ８５０）。
全てマーク済みである場合、解析終了と判断し、ステップ８９０に進む。
それ以外の場合、解析は終了していないと判断し、ステップ８５０に進む。

次に、解析前提項目テーブル３５のフラグ３８が空欄である行を１行読み込み、フラグ３８にマークする（ステップ８５０）。フラグ３８に対するマークとして、例えば“○”などの記号を入力する。
当該行の業務機能３６に格納されている業務機能名を取り出す。
当該行の項目３７に格納されている入力項目をキーとして、更新項目テーブル７５の出力７７を探索する（ステップ８７０）。

該当する行があった場合、業務機能３６から取り出した業務機能名と当該行の業務機能７６に格納されている業務機能名を、それぞれ前提業務機能テーブル８１の業務機能８２と前提業務８３に格納する（ステップ８８０）。
例えば｛受注登録業務｝に対して、図１８に示す解析前提項目テーブルより、「受注登録業務」が前提条件とする項目は「商品名」と「得意先」であり、これらの項目をキーとして更新項目テーブル７５の出力項目７７を探索することで、2つの業務機能「商品登録業務」と「得意先登録業務」を得る。前提業務機能テーブル８１には、｛受注登録業務、商品登録業務｝、｛受注登録業務、得意先登録業務｝の2行が追加される。

次にステップ９００では、依存関係表示処理部は、前提業務機能テーブル８１を入力として、業務機能間の依存関係を四角と矢印を用いて描画することで業務機能間の依存関係をユーザに表示する。
例えば、「得意先登録業務機能」、「商品登録業務機能」、「受注登録業務機能」を表す四角を描き、前者２つからからそれぞれ後者１つに向けて矢印を描き、ユーザに表示する。

図２１は、本実施例のシステムの出力としてユーザに表示される画面の一例である。本実施例のシステムの出力結果は、業務機能間の依存間関係を図示したものである。例えば、着目する業務機能名をユーザが入力し、検索ボタンを押すことで、該業務機能と依存関係にある業務機能が表示される。業務機能を表示する際には、業務機能とユーザが利用するI/Fとの関係を明確にする情報を合わせて表示する。例えば、業務機能を表す四角の下に利用するI/Fイメージなどを表示する。

このような表示を行うことで、ユーザにとって、通常の業務で行う処理イメージと、情報システムから抽出した業務仕様との関係が理解しやすくなる。

本実施例の全体処理の概要を表す機能フロー図。 本実施例を実施するための最良形態のシステムの概要図。 本実施例における処理フローの全体図。 業務機能I/テーブルを作成する際のユーザ入力イメージ図。 I/F解析における処理フロー図。 プログラム解析における処理フロー図。 入力起点探索における処理フロー図。 入力起点探索の詳細処理フロー図。 前提業務機能解析のおける処理フロー図。 業務機能とI/Fの対応を示す業務機能I/Fテーブル。 解析の対象となる業務機能を格納する解析業務機能テーブル。 解析の対象となるI/Fを格納する解析I/Fテーブル。 I/F解析の結果を格納するI/Fテーブル。 解析の対象となるプログラムを格納する解析プログラムテーブル。 プログラム解析の結果を格納するプログラムテーブル。 解析の対象となるデータを格納する解析データテーブル。 業務機能解析の結果を格納する業務機能テーブル。 業務機能とその前提項目を格納する解析前提項目テーブル。 業務機能とそのDB更新項目を格納する更新項目テーブル。 前提業務機能解析の結果を格納する前提業務機能テーブル。 本実施例におけるシステムの出力イメージ。 本実施例を実施するための最良形態のハードウェアの概要図。

符号の説明

１０ 業務機能とI/Fとの対応関係を特定し、テーブルを作成する業務I/F選択処理部
１２ 業務機能に対するユーザからの入力を受け付ける業務機能指定画面
１３ 業務機能とI/Fとの対応関係を示す業務機能I/Fテーブル
５０ I/Fの解析を行うI/F解析処理部
５２ I/Fの解析結果を格納するI/Fテーブル
６０ プログラムの解析を行うプログラム解析処理部
６２ プログラムの解析結果を格納するプログラムテーブル
７０ 業務機能に対する前提条件を探索する前提条件探索処理部
７１ 業務機能と前提条件となるデータ項目の対応を示す業務機能テーブル
７５ 業務機能とその中で更新されるデータ項目の対応を示す更新項目テーブル
８０ 業務機能間の依存関係を解析する依存関係解析処理部
８１ 業務機能とその前提となる業務機能との対応を示す前提業務機能テーブル
９０ 業務機能間の依存関係を出力する依存関係表示処理部
９１ 業務機能間の依存関係をユーザに示す依存関係表示画面

Claims (4)

1. 複数の業務が関連し、各業務は１つまたは複数のインタフェースを有する業務システムの業務仕様の理解を支援する業務仕様理解支援方法において、
   業務インタフェース選択処理部が、業務に関する情報と、当該業務に使用される１つまたは複数のインタフェースに関する情報とを受け付け、
   インタフェース解析処理部が、前記受け付けられたインタフェースを解析し、当該インタフェースで使用されるプログラムを抽出し、
   プログラム解析処理部が、前記抽出されたプログラムを解析し、当該プログラムが出力するデータ項目のうち、記憶装置に出力し、データを更新しているデータ項目を抽出し、
   当該抽出されたデータ項目を、当該業務と対応させて記憶装置に格納し、
   前提条件探索処理部が、前記更新されたデータ項目が、当該業務内のインタフェースが入力を受けるデータ項目であるかを判定し、
   前記判定の結果、当該業務内のインタフェースが入力を受け付けるデータ項目でない場合、当該データ項目を前提条件項目と特定し、
   依存関係解析処理部が、前記各業務に対応するように格納された更新されるデータ項目のなかに、当該前提条件項目がある場合、前記格納された更新されるデータ項目を更新する業務を、前提業務として特定し、
   依存関係表示処理部が、当該前提業務が、前記業務に先行する業務である旨の出力をすることを特徴とする業務仕様理解支援方法。
2. 請求項１に記載の業務仕様理解支援方法において、
   前記業務インタフェース選択処理部は、前記受け付けられたインタフェースに関する情報を、対応する業務に関する情報毎に記憶装置に格納し、
   前記インタフェース解析処理部が、前記業務毎に前記インタフェースを解析することを特徴とする業務仕様理解支援方法。
3. 請求項２に記載の業務仕様理解支援方法において、
   前記前提条件探索処理部が、前記インタフェースで当該プログラムに対して出力される各データ項目について、当該データ項目がユーザからの入力データであるか、業務システム内の他のプログラムからインタフェースに対して出力されたデータであるかを識別する情報に基づいて当該業務内のインタフェースが入力を受けるデータ項目であるかを判定していることを特徴とする業務仕様理解支援方法。
4. 複数の業務が関連し、各業務は１つまたは複数のインタフェースを有する業務システムの業務仕様の理解を支援する業務仕様理解支援システムにおいて、
   業務に関する情報と、当該業務に使用される１つまたは複数のインタフェースに関する情報とを受け付ける業務インタフェース選択処理部と、
   前記受け付けられたインタフェースを解析し、当該インタフェースで使用されるプログラムを抽出するインタフェース解析処理部と、
   前記抽出されたプログラムを解析し、当該プログラムが出力するデータ項目のうち、記憶装置に出力しデータを更新しているデータ項目を抽出し、
   当該抽出されたデータ項目を、当該業務と対応させて記憶装置に格納するプログラム解析処理部と、
   前記更新されたデータ項目が、当該業務内のインタフェースが入力を受けるデータ項目であるかを判定し、
   前記判定の結果、当該業務内のインタフェースが入力を受け付けるデータ項目でない場合、当該データ項目を前提条件項目と特定する前提条件探索処理部と、
   前記各業務に対応するように格納された更新されるデータ項目のなかに、当該前提条件項目がある場合、前記格納された更新されるデータ項目を更新する業務を、前提業務として特定する依存関係解析処理部と、
   当該前提業務が、前記業務に先行する業務である旨の出力をする依存関係表示処理部とを有することを特徴とする業務仕様理解支援システム。

Images