JP4872529B2 - リバースエンジニアリング支援方法 - Google Patents

Description

本発明は、情報システムで使用されているプログラムの解析を行いプログラムの理解を支援するリバースエンジニアリング支援システムに関する。

従来より、情報システムで使用されているプログラムの解析を行うことにより、情報システムの理解を支援するリバースエンジニアリング支援システムは、広く使用されている。
しかし、一般に資産解析による情報システムの仕様抽出手段は、計算機システムに近い低レベルの仕様情報を抽出する目的では有効であるが、業務に近い高レベルの仕様の抽出を行う目的では有効ではない。これは、解析によりプログラムに対し機械的に意味づけを行うことには限界がある為である。
情報システムの業務的な理解の為には、解析で得た情報に対し、人間である作業者が意味解釈作業を行うことが必要であるが、このような作業を支援する為の技術として、例えば、特許文献１に示すシステムは、プログラムのモジュール構造や構文構造等の階層化された情報に対し、作業者が意味情報を付加していく過程を支援する技術を開示している。

特開9-101884号公報

しかし、業務的に意味のある処理プログラムの集合は、情報システムとしてひとまとまりの構造として管理されているとは限らず、すでにある構造に対して意味付けを行うこのようなやりかたには限界がある。例えば、全体として意味をなす一連の命令が、単にソースプログラムの一部として書かれており、その前後には特に、構文上の区切りが無いということが考えられるからである。

或いは、また、同一プログラムの中の異なる機能の内の1つが、入力データによって選択されて動く場合や、同一のデータ格納域の中に、意味の異なる複数の型のレコードが格納される場合等、業務的な意味と、情報システムの構造が、1対1に対応しないことも考えられる。

本発明の目的は、リバースエンジニアリングの解析結果を元に、情報システムの要素の成す業務的に意味のある集合を見出し、これに意味を付加する作業を支援する業務仕様作成支援システムを提供することで、その結果、解析対象の情報システムに対する抽象度の高い、高水準の理解を支援することである。また、本発明の他の目的は、上に述べたように業務的な意味と情報システムの要素が1対1に対応しない場合でも、その要素が内包する複数の意味を、認識する作業を支援する業務仕様作成支援システムを提供することである。

本発明のシステムでは、解析対象のプログラムと入出力物理データを頂点とするグラフである物理モデル、業務機能と入出力論理データを頂点とするグラフである業務モデル、業務機能とプログラム機能の対応及び論理データと物理データの対応表である対応モデルを記憶し、ユーザが指定した業務機能に対し、対応する物理モデルを分析して業務機能に対応する部分グラフを計算し、これをもとに、業務機能に対応するプログラムの集合や、業務入出力データに対応する物理データの集合を計算する。

業務モデル及び対応モデルは、ユーザが入力する情報である為、支援システムの初期状態では、情報が不足していたり、対象システムの実情に合っていないが、上述のようにして物理モデルの部分グラフより求めたものとの比較をユーザに示すことにより、ユーザが業務モデル及び対応モデルを修正して、モデルの精度を向上していく過程を支援する。
さらに上記システムの拡張として、同一物理データが、異なる論理データを格納する場合を扱う為に物理データをデータ格納域とデータの満たす制約の組で表し、同一プログラムに異なる機能が含まれる場合を扱う為に、プログラム機能をプログラムと入力データの満たす制約の組で表した上で、部分グラフの計算に、これら制約条件の間の整合性を使用することを行う。このような方法により、同一物理データに異なるデータが格納される場合、同一プログラムに異なる機能が含まれる場合においても、業務モデルと物理モデルの対応をとることができる。

本発明によれば、業務モデル、対応モデルを修正しながら、業務モデルの業務機能と、物理モデルのプログラムの集合の対応付けを行っていくことで、対象システム全体の理解に基づく業務仕様の作成を支援することができる。

以下に、本発明の実施例を、図面を用いて詳細に説明する。

図１に本発明のリバースエンジニアリング支援システムの構成図を示す。
図1は、本発明の一実施形態である業務仕様作成支援システムの構成図を示す。本システムは、バス等で接続されたCPU31、ディスプレイ装置32、キーボード33、マウス等の指示装置34、ディスク装置20、メモリ10で構成される。メモリ10は、制御部40、プログラム解析部41、データ起点処理部42、機能起点処理部43、表示部44、モデル登録／修正部45の各プログラムを含む。ディスク装置20は、対象プログラム21、物理モデル22、対応モデル23、業務モデル24の各データベースを含む。

対象プログラム21は、図１に示すシステムの解析対象であるプログラムの集合である。ここで、「プログラム」とは、ジョブ制御言語の記述、汎用プログラム言語で書かれたソースプログラムの全体、または、関数、手続きなどその一部分等、手続きを定義する任意のものを意味する。特に、実行時の環境や入力データの値によって決まる、プログラム中の特定の実行文の系列を「プログラム」としても良い。

図2は、物理モデル22及び業務モデル24のグラフ構造を示す図である。物理モデルのグラフ構造（図2の右側）では、グラフの頂点は、プログラム54又は物理データ53である。物理データ53は、レコード、レコードの集合を保存するプログラム中の変数、ファイル、テーブル等任意のものである。また、プログラム頂点と物理データ頂点は向きのある辺で接続され、データの入出力を表す。このような情報は、従来のプログラム解析技術を用いて対象プログラム21を解析することにより、得ることができる。

業務モデルのグラフ構造（図2の左側）は、物理モデルと同等の構造であるが、グラフの頂点は、業務機能52及び論理データ51である。業務モデル及び対応モデルは、システム解析開始時にユーザにより入力された後、機能起点処理部43と、データ起点処理部42の処理で示される物理モデルとの差異により、ユーザにより修正される。初期の業務モデルは、ユーザの知り得る概略のモデルを使用しても良いし、業務システムや、アプリケーションの型における標準モデルを用いても良い。初期の対応モデルは、既知の概略モデルを使用してもよい。

なお、図2に示す物理モデル22及び業務モデル24においては、矢印に沿うループは無いものとし、プログラムの実行順序は、この矢印の方向に沿うものとする。このような仮定は、バッチシステム（実行プログラムとファイル）では通常成り立つが、オンラインシステムやその他の場合でも、実行されるプログラムの系列を評価し、更新毎のデータのインスタンスを区別すれば成立する。

また、本実施形態では、物理モデル22と業務モデル24との間の対応を対応モデル23により管理する。対応モデル23は、図2において点線58及び59で示される。対応モデル23のデータ構造は、後述する図5で示す。

図3は、物理モデル22のデータ構造例を示す図である。図3のプログラム表60及び物理データ表61は、後に述べる検索のアルゴリズムにおいて、それぞれ、プログラム63及び物理データ65に関する作業状態をマーク欄64または66に記録するのに用いられる。処理の初期状態では、マーク欄64及び66はクリアされ空白であるものとする。図3の物理I/O関連表62は、実際のグラフの構造（プログラム67と物理データ68の入出力関係）を定義する。例えば、レコード71は、物理データFILE-aがプログラムPGM-xの入力データであることを示す。

図4は、業務モデル24のデータ構造例を示す図であり、業務I/O関連表82は、グラフの構造（業務機能87に対応する論理データ88と、その論理データが入力データであるか出力データであるかを示すI/O区分89）を定義する。

図5は、対応モデル23のデータ構造例を示す図であり、論理データ93と物理データ94との対応を示すデータ対応モデル91と、業務機能95とプログラム96との対応を示す機能対応モデル92から構成される。例えば、データ対応モデル91のレコード97は、論理データ「受注」が、物理データ「FILE-a」に対応していることを示す（図2の点線58に相当する。）。また、機能対応モデル92では、業務機能「受注登録」に対し、「PGM-x、PGM-z、PGM-w」の3つのプログラムが対応していることを示す（図2の点線59に相当する）。

図6は、図1に示すシステムの処理の概要を説明するフローチャートである。
まず、制御部40は、キーボード33又は指示装置34から入力されたユーザからの解析指示を読み込み、プログラム解析部41を起動して対象プログラム21を解析し、物理モデル22を作成する（ステップ101）。次に、制御部40は、ユーザによって入力されたモデル登録指示を読み込み、モデル登録/修正部45を起動する。モデル登録/修正部45は、ユーザから入力された業務モデル及び対応モデルを読み込んで、業務モデル24及び対応モデル23の登録を行う（ステップ102）。次に、制御部40は、ユーザからの指示が、データ起点処理か、機能起点処理か、終了かを判断する（ステップ103）。

ステップ103の判断の結果、ユーザからの指示が「データ起点処理」である場合は、制御部40は、ユーザによって指定された業務機能に対し、データ起点処理部42を起動し、処理の結果を画面表示する（ステップ104）。ここで、データ起点処理は、業務モデル／対応モデルのデータを起点に、物理モデルから、指定された業務機能に対応する部分グラフを抜き出す処理である。ステップ104の詳細については、図7において説明する。

ステップ103の判断の結果、ユーザからの指示が「業務起点処理」である場合は、制御部40は、ユーザによって指定された業務機能に対し、機能起点処理部43を起動し、処理の結果を画面表示する（ステップ105）。ここで、機能起点処理は、業務モデル／対応モデルの機能部分を起点に、物理モデルより、指定された業務機能に対応する部分グラフを抜き出す処理である。ステップ105の詳細については、図12において説明する。

ステップ104、105で表示された画面によって、ユーザによる修正要否、修正方式の入力を受け付ける。この入力を受けて、制御部40は、対応するユーザの業務モデルまたは対応モデルを更新し（ステップ106）、再び、指示を受け付ける状態に戻る（ステップ103）。このように、ステップ103〜106の過程を繰り返すことにより、ユーザは、業務モデルと物理モデルの差異を確認して修正指示を行うことにより、業務モデル、及び対応モデルの精度を高めていくことができる。

図7は、図6におけるステップ104（データ起点処理）の詳細を示すフローチャートである。
まず、データ起点処理部42は、業務モデル24に含まれる業務I/O関連表82の業務機能欄87を、ユーザによって指定された業務機能に従って検索することにより、関連する論理データの集合Sを得る（ステップ111）。例えば、ユーザによって指定された業務機能が「受注登録」である場合は、データ起点処理部42は、「受注登録」をキーとして業務I/O関連表82の業務機能欄87を検索し、「受注」、「担当者」、「受注伝票」の3つの論理データを含む集合Sを得て、Sをメモリ10の図示しない記憶領域に格納する。

次に、データ起点処理部42は、ステップ111で抽出した論理データ（の集合S）をキーとして、データ対応モデル91（図５）の論理データ欄93を検索することにより、対象の論理データの集合に対応する物理データの集合sを得る（ステップ112）。例えば、ステップ111で得られた論理データの集合Sは、S=｛受注、担当者、受注伝票｝なので、データ起点処理部42は、その集合Sの要素をキーとしてデータ対応モデル91の論理データ欄93を検索し、物理データの集合ｓ＝｛FILE-a、FILE-c｝を得る（図5に示す例では、論理データ「担当者」に対応する物理データが不明である場合を想定している）。さらに、このsをメモリ10の図示しない記憶領域に格納する。

次に、データ起点処理部42は、ステップ112で得た物理データの集合sの中から1つのデータを選択して、メモリ10の図示しない記憶領域に含まれる変数vに格納する（ステップ113）。次に、データ起点処理部42は、物理モデル上で、物理データvを起点としてグラフの辺を矢印の方向にたどる検索を行い、vからグラフ上の任意のデータに至る経路の集合を得て、この経路の集合を、メモリ10の図示しない記憶領域に含まれる変数Pに格納する（ステップ114）。例えば、図2のグラフで、FILE-aを起点に考えた場合、ステップ114で得られる経路の集合Pは、P＝{(FILE-a)、(FILE-a→PGM-x→FILE-n) 、(FILE-a→PGM-x→FILE-m)、(FILE-a→PGM-x→FILE-n→PGM-y→FILE-o)、(FILE-a→PGM-x→FILE-m→PGM-z→FILE-d)、(FILE-a→PGM-x→FILE-n→PGM-y→FILE-o→PGM-w→FILE-c)、(FILE-a→PGM-x→FILE-m→PGM-y→FILE-d→PGM-w→FILE-c)}となる。

次に、データ起点処理部42は、ステップ114で得られた変数Pの中から選択した１つの経路を、メモリ10の図示しない記憶領域に含まれる変数pに格納する（ステップ115）。ここで、変数pの最後の頂点が、ステップ112で得られたデータの集合sに含まれる場合、ステップ115で選択された経路p上の全ての頂点に、○を付ける（ステップ116）。ここで、頂点とは、ある経路に含まれる物理データ及びプログラムを意味する。例えば、経路「FILE-a→PGM-x→FILE-n→PGM-y→FILE-o→PGM-w→FILE-c」は、最後の頂点「FILE-c」が、集合sに含まれている為、この経路の頂点である「FILE-a、PGM-x、FILE-n、PGM-y、FILE-o、PGM-w、FILE-c」に対しては、プログラム表60及び物理データ表61（図３）の対応するレコードのマーク欄64、66に「○」が格納される。

ステップ114で得られた変数Pに含まれるすべての経路に対してステップ115〜116の処理を行い（ステップ117）、さらにステップ112で得られた集合ｓに含まれるすべての物理データに対してステップ113〜117の処理を行う（ステップ118）。例えば、図８に示すグラフにおいて、物理データの起点の集合を、{FILE-a、FILE-c}として処理を実行すると、プログラム表60及び物理データ表61の、「FILE-a、PGM-x、FILE-n、FILE-m、PGM-y、PGM-z、FILE-o、FILE-d、PGM-w、FILE-c」に対応するレコード欄64、66に「○」が格納される。

次に、データ起点処理部42は、ステップ116で○が付いたプログラムが入出力する物理データの内、マーク○が付いていない物理データに、マーク△を付ける(ステップ119)。図8の例では、FILE-bが該当する（FILE-bの入力プログラムに○マークが付いていない）。そして、物理データ表61の「FILE-b」に対応するレコードのマーク欄66に、△が格納される。この頂点「FILE-b」は、指定された業務機能が入出力すると推論されたが、現時点の業務モデル及び対応モデルから欠落しているものである。

次に、データ起点処理部42は、ステップ116でマーク○が付いた物理データの内、マーク○が付いていないプログラムから入出力される物理データに、マーク△を付ける(ステップ120)。図8の例においては、物理データFILE-dが該当する（物理データFILE-dを入力データとするプログラムは、PGM-w以外にもう一つ存在する。）。この頂点は、指定された業務機能が入出力すると推論されたが、現時点の業務モデル及び対応モデルから欠落しているものである。図8は、データ起点処理によりマーク付けされた頂点を示す。これらは、図7に示すステップ111〜121のデータ起点処理により認識された部分グラフを表している。

最後に、表示部44は、ステップ120までの処理の結果の部分グラフをディスプレイ装置に送信し、ディスプレイ装置は、処理の結果の部分グラフを図形的に表示する（ステップ121）。図8は、データ起点処理によりマーク付けされた頂点を示す。この際、業務モデルとの関連を表す情報も、合わせて表示し、部分グラフに含まれるプログラムや、部分グラフの端になる物理データが、業務モデル／対応モデルと合っているかを示す。

図9は、図7のステップ121において表示された処理結果の画面例を示す。枠線130は、論理データ「受注」を示しており、枠線130で囲まれた物理データFILE-aを示す図形131は、論理データ「受注」と、物理データFILE-aが対応モデルで表現されていることを示している（図5のデータ対応モデル91のレコード97）。これに対し、物理データFILE-bやFILE-dを表す図形135、136がそのような枠を持たないのは、業務モデル（図5）と対応付けられていないことを示している。また、論理データ「担当者」を表す枠線137が物理データ表す図形を含まないのは、論理データ「担当者」に対応する物理データが不明であること、即ち、対応する物理データを表す情報がデータ対応モデルに存在していないことを示す（図5のデータ対応モデル91のレコード98）。

枠線132は、業務機能「受注登録」を示しており、枠線132で囲まれた物理データやプログラムをあらわす図形は、データ起点処理（図7）により処理された物理データ及びプログラムである。例えば、プログラムPGM-x、PGM-z、PGM-w、に対応する図形138、139、140が強調表示されているのは、現時点の対応モデルと合致しているからであり、PGM-yに対応する図形133が強調表示されていないのは、PGM-yは、データ起点処理で処理されたプログラムであるが、業務モデルとは対応付けられていないからである。

ユーザは、このような画面を確認し、修正要否、修正方式の判断を行う。例えば、図9の例で想定されるユーザの修正指示は、以下のようなものである。
（１）プログラムPGM-yを、業務機能「受注登録」に対応付ける。
（２）物理データFILE-bを、論理データ「担当者」に対応付ける。
（３）業務モデルに新たな出力データとして、論理データ「納期照会」を登録し、物理デ
ータFILE-dを、論理データ「納期照会」に対応付ける。

制御部40は、ユーザのこのような指示を、マウス等の指示装置34から読み込み、データ起点処理部43は、図７のステップ116において、業務モデル及び対応モデルの更新処理を行う。図8、図9の例では、論理データが業務モデルに欠けている場合、または論理データが認識されていたとしても対応モデルが不明である場合の例示である。

図10は、業務モデルと物理モデルの他のパターンを示す例である。図10の例では、物理データが本来「FILE-a」160〜「FILE-d」163の4つでよいのに対し、物理データ「FILE-e」164、「FILE-f」165が余分に指定されていたとする。このような状況でデータ起点処理（図7）を行った場合、グラフは、指定した物理データの集合のサブセットを端の頂点として持つ複数のグラフに分かれる。このような部分グラフを図１０の点線の枠線166、167、168で示す。つまり、図10は、ある物理データが、業務の流れに入るか、それとも業務の流れに関係ないかが画面上で区別されている。

図10に示すような部分グラフは、余分なデータが業務モデルに含まれている場合の他、業務モデルの業務機能の粒度が実際のものよりも荒く、より詳細な分割が可能な場合にも、現われ得る。このような部分グラフの判別は、データ起点処理においてマーク付けを行う際、グラフの連結成分を表す識別子をマーク欄に入れることにより、行うことができる。

図11は、データやグラフが図10に示すような場合の、データ起点処理（図7）のステップ116の処理を説明するフローチャートである。

まず、データ起点処理部42は、経路pの最後の頂点が、指定された物理データの集合sに含まれるかどうかを判定する（ステップ181）。含まれていなければ、処理は終了する。含まれている場合は、データ起点処理部42は、経路p上に含まれる物理データの集合sの要素である頂点に対応する物理データ表61のマーク欄66に○を記憶し（ステップ182）、経路pを集合sの要素で区切った区間を1つ選択する（ステップ183）。

データ起点処理部42は、ステップ183で選択された区間の各頂点を調べ、頂点の中に連結成分の識別子が付加されたものがあるかどうかを調べる（ステップ184）。識別子が付加された頂点がなければ、データ起点処理部42は新しい識別子を発番し、その区間の全頂点に付加する（ステップ185）。識別子が付加された頂点があり、かつ、区間全体で識別子が唯1つだけであれば、データ起点処理部42は、この識別子を区間の全頂点に付加する（ステップ186）。区間中で識別子が複数ある場合には、データ起点処理部42は、このうちの1つを選択し、他の識別子をその選択した識別子に置き換える（ステップ187）。なお、この識別子置き換え処理は、物理モデル全体に対して行われる。その後、データ起点処理部42は、その選択された識別子を、対象区間の全頂点に付加する（ステップ186）。

データ起点処理部42は、経路p上の未処理の区間がなくなるまで、ステップ183〜187の処理を行う（ステップ188）。以上の処理で、部分グラフの内部の頂点に、連結成分毎に識別子を設定することができ、図１０のような表示が可能になる。ディスプレイ装置に図１１のような点線を表示することにより、ユーザは、余分に指定されたデータや、分割可能な業務機能を確認し、以下のような指示を行うことができる。
（１）物理データFILE-eに対応する、業務モデル、対応モデルを削除する。
（２）物理データFILE-fに対応する、業務モデル、対応モデルを削除する。
（３）業務機能を、枠線166、167、168の範囲に分割し、分割した機能のそれぞれに、含まれるプログラムを対応づける。

制御部40は、ユーザのこのような指示を、マウス等の指示装置34から読み込み、データ起点処理部43は、図７のステップ116において、業務モデル及び対応モデルの更新処理を行う。

図１２は、図6のステップ105（機能起点処理）の詳細を示すフローチャートである。
まず、機能起点処理部43は、機能対応モデル92の業務機能欄95を、ユーザによって指定された業務機能で検索することにより、対象の業務機能が対応するプログラムの集合Fを得る（ステップ141）。例えば、指定された業務機能が「受注登録」の場合、図5に示すように、集合Fの内容は、F＝{PGM-x、PGM-z、PGM-w}となる。

次に、機能起点処理部43は、集合Fから1つのプログラムを選択して、メモリ10の図示しない記憶領域に含まれる変数fに格納する（ステップ142）。機能起点処理部43は、物理モデル上で、物理データfを起点としてグラフの辺を矢印の方向にたどる検索を行い、fを起点として任意の頂点に至る経路の集合を得て、この経路の集合を、メモリ10の図示しない記憶領域に含まれる変数Pに格納する（ステップ143）。

機能起点処理部43は、ステップ143で得られた経路の集合Pより1つの経路を取り出し、メモリ10の図示しない記憶領域に含まれる変数pに格納する（ステップ144）。経路pの最後の頂点が、ステップ141で取得したプログラムの集合Fに含まれる場合、機能起点処理部43は、経路pのすべての頂点（プログラムまたは物理データ）の物理モデル（プログラム表60または物理データ表61）に対応するレコードのマーク欄64、66に○を記憶する（ステップ145）。ステップ143で得られた変数Pに含まれるすべての経路に対してステップ144〜145の処理を行い（ステップ146）、さらにステップ141で得られた集合Fに含まれるすべての物理データに対してステップ141〜146の処理を行う（ステップ147）。図13に示すグラフにおいて、プログラムの集合を、{PGM-x、PGM-z、PGM-w}として処理を実行すると、プログラム表60及び物理データ表61の、「PGM-x、FILE-n、FILE-m、PGM-y、PGM-z、FILE-o、FILE-d、PGM-w」に相当するレコードのマーク欄に「○」が記入される（ステップ145）。これらの頂点は、指定された業務機能に対応すると推定されたものである。

次に、機能起点処理部42は、ステップ145において○マークが付いたプログラムが入出力する物理データのうち、(1)○マークが付いたプログラムが、入力又は出力のみを行う物理データ、又は(2)○マークが付いていないプログラムに入力される物理データに、△マークを付ける（ステップ148）。例えば、図13では、FILE-a、FILE-b、FILE-cに対し、マーク△を付ける。これらのマークが付けられた頂点は、指定された業務機能の入出力データの候補となる。以上の機能起点処理により、指定した業務機能に相当する部分グラフを抜き出すことができた。

最後に、機能起点処理部42は、ステップ141〜148の処理で得た部分グラフをディスプレイ装置32に送信し、ディスプレイ装置32は、その部分グラフを表示する（ステップ149）。ユーザは、図９と同様の表示を確認し、機能起点処理部42は、業務モデル、対応モデルの更新を行う。

ここまで、物理データは、レコード又はプログラムの変数、ファイル、テーブル等のデータ格納域と直接対応づくものと想定してきたが、ここで述べた実施方法は、これらのデータ格納域に意味内容の異なるデータが格納される場合に、拡張することができる。現実の場合として、意味内容の異なるデータがファイル中に異なるレコードとして共存することや、プログラム実行の度に異なる種類のデータが同じメモリの領域を占める場合を想定する。
また、物理モデルにおける処理についても、プログラムをグラフの頂点と考えてきたが、実施形態をプログラム中に複数の異なる機能が混在している場合に、拡張することができる。実施例１の説明を引用しながら実施例２として以下に説明する。

図１４および、図１５に、この目的の為に、拡張したテーブルの構成を挙げる。
図１４に掲げた物理データ表200は、図3の物理モデルにおける、物理データ表61を代替するものである。図３の物理データ表61と同等のデータ欄202、マーク欄207に加え、新たにデータID欄201と、データ制約欄203を設けた。データ制約欄203には、データ格納域中の異なる種類のレコードを区別する為に、レコードに課す条件を保持する。条件は、レコードのフィールドを用いた算術式、不等式、論理式で表現される。例えば、図中208に示した「y=1」は、FILE-aに格納するレコードのフィールドyに課した条件式「y=1」を表し、これにより、レコード196は、データ格納域FILE-a中の、条件式「y=1」を満たすデータを表す。データ制約は、「−」であっても良く、その場合、レコードには条件を課さないことを意味するものとする。
物理データは、データ格納域とデータ制約の組によって表される為、データ格納域のみでは一意に決まらない。その為に、データID欄201は、レコードを区別するキーとして新たに設ける。

また、プログラム機能表190は、表60を代替するものである。表の役割は元と同様、処理の物理的な実装である、プログラム機能を管理するものである。単一プログラム中の複数の機能を扱う為に、プログラム名だけでは、一意に指定することができない為、表の一意なキーとして、機能ID欄191を設ける。
また、物理I/O関連表210は、表62を代替するものであり、拡張された物理モデルにおける、プログラム機能／物理データの入出力の関係を表現する。

プログラム機能は、機能ID欄212で表現する。物理I/O関連表210の1つのレコードは、プログラム機能とデータ格納域の1つの入力関係又は出力関係を表す。入出力するデータは、データ欄213と、データ制約欄214の組で表現し、入力／出力の区分は、以前と同様、I/O区分欄215により表す。データ制約欄214は、データ欄213の入力データ又は出力データに課される、データ格納域毎の制約条件を保持する。制約条件は、該当レコードのフィールドを用いた算術式、不等式、論理式等か、又は、フィールドに条件を課さないことを意味する特別な値「−」又は、レコードを入力又は出力しないことを意味する特別な値「false」を取ることができるものとする。

機能IDが同一の値を持つ、ひとそろいのレコードが、該当プログラム機能に対する、入出力項目に課す制約の全てを記述する。例えば、レコード220〜223が、機能ID=F1のプログラム機能に対する入出力項目に課す制約を記述するひとそろいのレコードである。
入力データについてのデータ制約は、プログラムに含まれる複数の異なるプログラム機能を区別する為に、プログラムの入力レコードに課す条件を保持する。プログラムと入力制約の組は、該当の条件が成立する場合に実行されるプログラムの部分を、間接的に表現する。

例えば、図中218に示した制約条件「y=1」は、「プログラム機能F1のFILE-aの入力レコードaのフィールドyが1である」という条件を表し、217に示した制約条件「−」は、「FILE-bのレコードには、条件を課さない」ことを示す。また、尚、プログラム機能F1は、プログラム機能表190によれば、プログラムPGM-xに関するものであるので、レコード220とレコード221は合わせて、入力レコードFILE-aに「y=1」という条件を課した場合に実行されるプログラムPGM-xの部分を表現する。

出力データについてのデータ制約は、与えられた入力制約のもとで、プログラムを実行した場合に、出力データが満たす制約である。
例えば、219に示した制約条件「y=1」は、「プログラム機能F1のFILE-nレコードのフィールドyが1である」ことを示す。レコード222は、前に述べたプログラム機能F1の入力に関する前提条件の下で、「プログラムPGM-xの出力であるFILE-nレコードのフィールドyが1」であることを意味する。また、物理I/O関連表210には、FILE-mに関するレコードのデータ制約欄214が、「false」であり、これは、同じ前提条件の下で、FILE-mに関する出力が無いことを意味する。

図１５に、この物理モデルに対応して設けた、データ対応モデル230及び、機能対応モデル231を挙げる。これらは、それぞれ、データ対応モデル91及び、機能対応モデル92を代替するものである。
実施例２における、拡張された物理モデルでは、物理データを特定するキーは、データIDであり、プロウグラム機能を特定するキーは、機能IDである。その為、対応モデルにおいても、データID欄233、機能ID欄235を設け、業務モデルとの対応は、これらとの対応によって表現する。
例えば、図中236に示したレコードは、データID「D1」が国内受注データに対応するということを意味する。他方、物理データ表201によれば、D1は、レコード196で示されており、結局、国内受注データは、「データ格納域FILE-aのデータ中、y=1が成り立つもの」である。

また、図中237に示したレコードは、機能ID「F1」が国内受注登録に対応するということを意味する。F1は、プログラム機能表190及び、物理I/O関連表210によれば、プログラムPGM-x中の入力レコードaに対し、y=1が成立する場合に実行される機能に対応する。
対応モデルは、拡張前と同様、初期状態では分かり得る範囲のモデルを、仮定して作業を始める。この拡張においては、物理モデルも、プログラムの分析だけで、完全に作成することはできない。これに対し、以前と同様、対話処理で、ユーザから情報を追加してもらい、モデルの精度を徐々に高めていく。

この制約付き拡張モデルに基づいたシステムにおいても、データ起点処理、機能起点処理は、同様に行うことができる。基本的には、物理モデルの変更によって、図6、図11、図12、及び関連する図面と説明において、以下の読み替えを行う。
（１）物理データは、データ格納域とこれに課した制約の組であり、処理上は、データIDにより識別する。
（２）プログラムは、物理的なプログラムとその入力に課した制約の組に読み替える(プログラム機能)。処理上は機能IDにより識別する。

（３）物理データを表す頂点から、これを入力するプログラム機能を表す頂点への経路をたどる場合は、
(3-1)プログラム機能に対応するプログラムが物理データに対応するデータ格納域を入力し、かつ、
(3-2)プログラム機能に対応するプログラムの入力項目に付随する制約条件が、物理データに付随する制約条件と両立し得る、
機能IDの集合を取って、これに対応する頂点間のみ、辺で結ぶものとする。

これを行うシステムの処理を、図16に示す：
(3-3)まず、データIDをキーに物理データ表200を検索して、レコードを所得する(ステップ300)。
(3-4)取得したレコードの、データ、データ制約欄の値を、それぞれ、変数d、及び、cに格納する(ステップ301)
(3-5)データ名d及び、I/O区分=「I」で、物理I/O関連表210を検索し、検索結果を配列Rに格納する(ステップ302)
(3-6)配列Rの１つのレコードを取り、このレコードの機能ID、及びデータ制約欄の値を、変数p及びc1に格納する(ステップ303)。
(3-7)制約cとc1が、両立し得るかどうかを、定理証明器等を用いて評価し、両立し得る場合、機能ID pを、結果配列 Aに格納する(ステップ304)。
(3-8)レコードの配列Rのすべてのレコードを処理するまで、以上を繰り返す(ステップ305)。配列Rのすべてのレコードの処理が終了すると図１６の処理は終了となる。

（４）プログラム機能を表す頂点からこれが出力する物理データを現す頂点への経路をたどる場合は、
(4-1)プログラム機能に対応するプログラムが物理データに対応するデータ格納域を出力し、かつ
(4-2)物理データに対応する出力データ格納域に付随する制約条件が、プログラム機能の出力項目に付随する制約条件と両立し得る、
データIDの集合を取って、これに対応する頂点間のみ、辺で結ぶものとする。これを行うシステムの処理を、図17に示す：
(4-3)与えられた機能IDと、I/O区分=「O」で、物理I/O関連表210を検索し、レコードを取得して配列Rに格納する(ステップ310)。
(4-4)配列R内の1つのレコードを取り、このレコードのデータ名、及びデータ制約欄を、変数n及びc1に設定する(ステップ311)。

(4-5)データ名nで、物理データ表200を検索し、レコードを取得して、配列Qに格納する(ステップ312)。
(4-6)配列Q内のひとつのレコードを取り、このレコードのデータID、データ制約欄を、それぞれ、変数d、cに設定する(ステップ313)。
(4-7)制約cとc1が、両立し得るかどうかを、定理証明器等を用いて評価し、両立し得る場合、データID dを、結果配列 Aに格納する(ステップ314)。
(4-8)以上を、配列R及び、配列Qの要素について繰り返す(ステップ315、及びステップ316)。配列R、Qのすべてのレコードの処理が終了すると図１７の処理は終了となる。ステップ304及び、314においては、制約条件が両立し得るかどうかは、システム的に判断が不可能な可能性がある。その場合、ユーザの判断を入力して評価を確定する。

以上述べたように、物理データ及び、プログラム機能を、制約付きモデルに拡張したシステムでも、制約無しの場合に示した、データ起点処理及び、機能起点処理を、そのまま行うことができる
しかしながら、この制限付モデルを使用したシステムを有効に機能させる為には、ユーザが物理モデルに付加する制約を見出しこれを、モデルに登録していかなければならない。このような物理モデルに対する修正は、例えば、図6、ステップ106において業務モデル、対応モデルに対する修正と同様に、対話的に行う。システムは、以下のように、モデル表示機能において、これを支援することができる。尚、これらの処理の前提となる頂点間の辺の評価には、図16及び、図17の処理を用いる。

（５）複数の機能から入力又は出力されている物理データがある場合、それらの機能及び物理データをハイライト表示して示す。複数の機能からの各入出力について、付随する制約を、それぞれ表示する。例えば、作業者は、機能の入出力に付随する制約を、参考にデータ格納域に制約を課し、物理データを分割することを検討する。
（６）データ格納域が同一で制約が異なる複数の物理データからの、入力又は出力がある機能をハイライト表示する。複数の物理データ対し、付随する制約を、それぞれ表示する。例えば、作業者は、データに付随する制約を機能の入出力に課すことを、検討する。

（７）与えられた入力に対する制約のもとで、プログラム機能の出力データに関する制約を、評価して表示する。このような評価は、既存の技術を用いて行うことができるものとする。図18に処理の流れをしめす。まず、プログラムの記号実行を行い、出力項目を、入力項目の式で表現する(ステップ 320)。次に、ここで得た式を、入力項目に対し、記号的に解き、入力項目を出力項目の式で表す(ステップ 321)。最後に、入力項目に対する制約条件に、出力項目で記述された入力項目を代入する(ステップ 322)。このような評価は、対象の条件やプログラムの種類によっては、行うことができない場合があるが、その場合、ユーザより評価を、入力させるようにする。

以下の例により、制約付の拡張モデルをサポートしたシステムによって、具体的に、モデルの作成処理がどのように行われるかを見る。以下では、受注登録処理のマッピングを精密化し、国内受注登録の処理を、データマッピング処理にて、理解しようとする。
例えば、まず、解析対象システムのエンドユーザよりヒヤリングで得た情報により、国内受注に関しては、レコード中のyというフラグが、1であるという知識を得たものとする。

本実施例のシステムを利用する作業者は、この知識を図6、ステップ106においてシステムに登録して、FILE-aのレコードに対する制約とし、対応モデルも、これに合わせ、y=1の制約を課したレコードを、国内受注に対応付けた。業務モデルとしては、国内受注を入力にして、受注伝票を出力する業務を、新たに「国内受注登録」機能と定義し、再マッピングを行った。図19は、その結果を示すものである。

ここでは、File-aを、データ制約により区別し、アイコン240及び、アイコン241に分けて表示した。アイコンの中に、{….}に記述された条件式は、それぞれのレコードに課した制約条件を示す。
アイコン240は、国内受注に関するものである。PGM-x は、同一のデータ格納域FILE-aに関連する異なる制約のデータを入力している為、システムはこのアイコン243をハイライト表示する。

ユーザは、ハイライト表示されたPGM-xの入力に注目し、PGM-xの入力に課す制約として、物理データの制約であるy=1、y!=1を登録し、機能を2つに分離し、再度マッピングを試みる。その結果を、図20に示す。アイコン263、及び、264は、入力に対する機能の指定により、分離された2つの機能を表す。アイコン中の、プログラム名の上に、{….}で記述された条件式は、プログラムの入力に課された条件式を示す。

この時点では、機能のアイコンが、単純に複製されただけなので、アイコン263、及び264以下の流れは、見やすいもので無い。ユーザは、さらに、下流の流れを分析する為に、ここで、アイコン263及び、アイコン264に相当するプログラム機能の実行結果の評価を指示することができる。
例えば、アイコン263に関しては、入力レコードが、条件式y=1を満たす前提で、PGM-xの実行結果の出力を評価し、その結果、PGM-xの出力レコードnに対し、条件式y=1を得たとする。また、出力レコードmに対しては、出力されないことを示すことができたとする。また、アイコン264に関しては、入力レコードが、条件式y!=1を満たす前提で、PGM-xの実行結果の出力を評価し、その結果、PGM-xの出力レコードnに対し、条件式y!=1を得たとする。このような評価は、常に実行可能とは限らない為、評価がうまく行えなかった場合、作業者が知識を補完する必要がある。

出力の制約に対する評価を行った状態を、図21に示す。実行結果を評価したプログラム機能のアイコンを、アイコン273、アイコン274で示した。アイコン中、プログラム名の下に、{….}で示したものは、出力レコードに関する条件式である。条件式falseは、前に述べたように、レコードが入出力されないことを意味するものとする。この状態でさらに、FILE-n 275は、制約だけ異なる、2つの異なるプログラム機能273、274からの出力が入っている為、強調表示の対象となっている。これに関連して、273、274自体も強調表示の対象になっている。

次に、ユーザは、ハイライト表示されているFILE-n 275への複数機能の出力に課されている条件に着目し、FILE-nに、制約条件を課し、物理データを2つに分ける。図22は、FILE-nへの制約登録の後、再度マッピングを行った結果を示す。分離されたFILE-nは、アイコン285、及び、アイコン286で示されている。前と同じように、アイコンの中には、データに関する制約が、{….}の条件式で示されている。また、PGM-y 287は、同一のデータ格納域FILE-nに関連する異なる制約のデータを入力している為、ハイライト表示される。このような、対話的作業を続け、最後に図23のようなマッピング結果を得る。

このような構成のシステムにより、制約付きの拡張モデルを持つ実施例を用いて、受注登録処理より、「国内受注登録」に関わる部分を抜き出し、プログラム及びデータのこれに関わる部分を、同定することができる。

以上述べたように、本発明のリバースエンジニアリング支援システムは、多数のプログラムより構成される情報システムを、プログラム解析の技術を元にして理解する過程を支援することに利用できる。

本発明の一実施形態である業務仕様作成支援システムのシステム構成図である。 業務モデル24、物理モデル22、対応モデル23のグラフ構造を示す図である。 物理モデル22のデータテーブルの例を示す図である。 業務モデル24のデータテーブルの例を示す図である。 対応モデル23のデータテーブルの例を示す図である。 本システムの処理の概要を示すフローチャートである。 図6のステップ104の処理を詳細に説明したフローチャートである。 図7のデータ起点処理により選択された部分グラフの例である。 図7の処理の結果がディスプレイ装置に表示された画面例を示す図である 図7の処理の結果がディスプレイ装置に表示された別の画面例を示す図である。 部分グラフの連結成分判定の為のステップ116の処理を示すフローチャートである。 図6のステップ105の処理を詳細に説明したフローチャートである。 図6の機能起点処理により選択された部分グラフの例である。 プログラム機能、物理データに対し制約を設けた場合の、拡張された物理モデルのデータテーブルの例を示す図である。 プログラム機能、物理データに対し制約を設けた場合の、対応モデルのデータテーブルの例を示す図である。 制約付き拡張モデルにおける、物理データより、プログラム機能頂点をたどる処理を示す図である。 制約付き拡張モデルにおける、プログラム機能より、物理データ頂点をたどる処理を示す図である。 制約付き拡張モデルにおいて、プログラム機能の入力項目に課した条件より、プログラム機能の出力項目が満たす条件を評価する処理を示す図である。 制約付き拡張モデルにおいて、FILE-aに条件を課した場合の、マッピング処理の結果を示す図である。 制約付き拡張モデルにおいて、FILE-a及び、PGM-xの入力項目に条件を課した場合の、マッピング処理の結果を示す図である。 制約付き拡張モデルにおいて、FILE-a及び、PGM-xの入力項目、及び出力条件に条件を課した場合のマッピング処理の結果を示す図である。 制約付き拡張モデルにおいて、FILE-a、PGM-xの入力項目及び出力条件、及び、FILE-nに条件を課した場合のマッピング処理の結果を示す図である。 制約付き拡張モデルにおいて、「国内受注登録処理」の作業が完了した時点のマッピング処理の結果を示す図である。

符号の説明

10：メモリ、20：ディスク装置、31：CPU、32：ディスプレイ装置、33：キーボード、34：指示装置、21：対象プログラム、22：物理モデル、23：対応モデル、24：業務モデル、40：制御部、41：プログラム解析部、42：データ起点処理部、43：機能起点処理部、44：表示部、45：モデル登録／修正部

Claims (1)

1. 情報システムで使用されているプログラムの解析を行いプログラムの理解を支援するリバースエンジニアリング支援システムにより実行されるリバースエンジニアリング支援方法において、
   業務機能と論理データを頂点とし、これらの間のデータの入出力を表す有向の辺を持つグラフである業務モデル、プログラム機能と物理データを頂点とし、これらの間のデータの入出力を表す有向の辺を持つグラフである物理モデル、業務機能とプログラム機能の対応及び論理データと物理データの対応表である対応モデルを記憶し、ユーザが指定した業務機能に対し、業務機能の入出力である論理データに対応する物理データの集合を検索し、これらを端点とする物理モデルの部分グラフを計算することにより業務機能に対応するプログラム機能の集合を推論することを特徴とするリバースエンジニアリング支援方法。

Images