JP4820924B1 - リバースエンジニアリング支援装置、リバースエンジニアリング支援方法及びそのプログラム - Google Patents

Abstract

【課題】情報処理システムに使用されるソースプログラムから、従来に比較して、細かく、かつ一定の粒度により、業務モデル及び物理モデルを対応させて抽出するリバースエンジニアリング支援装置を提供する。
【解決手段】本発明のリバースエンジニアリング支援装置は、ソースプログラムの業務仕様の抽出を行う装置であり、ソースプログラムのソースコードから、コード種類、コード組合せ及びコード配置と、処理機能を示す単位プログラムとの対応関係が予め設定された第１ルールに従い、ソースコードから、処理機能に対応する単位プログラムを抽出する処理機能抽出部と、単位プログラムの処理機能の種類、組合せ及び配置順番と、単位プログラムの配置順番の変更、統廃合処理との対応関係を予め設定した第２ルールに従い、単位プログラムの配置順の変更、統合及び廃棄の統廃合処理を行い、物理モデルとして出力する処理機能統廃合部とを有する。
【選択図】図１

Description

本発明は、リバースエンジニアリング支援装置、リバースエンジニアリング支援方法及びそのプログラムに関する。

情報処理システムを構成するソースプログラムを解析して、制御構造、データ構造、及びデータ間の依存関係等の仕様情報を自動的に抽出し、抽出した仕様情報を図式チャート等によってユーザに提示するリバースエンジニアリングが広く用いられている。
リバースエンジニアリングにより、解析対象のソースプログラムの行う業務の理解を支援するシステムとして、例えば、特許文献１の業務仕様抽出支援システムがある。
特許文献１においては、ソースプログラムから抽出した物理モデルと、この物理モデルと対応して業務の内容を示す業務モデルとを対応付ける対応テーブルが予め設定されている。ここで、業務モデルとは、業務機能と論理データを頂点とし、これらの間のデータの入出力を表す有向の辺を持つグラフであるモデルである。物理モデルは、プログラム機能と物理データを頂点とし、これらの間のデータの入出力を表す有向の辺を持つグラフであるである。

業務仕様抽出支援システムは、抽出した物理モデルを対応テーブルから検索し、この物理モデルと一致する物理モデルに対応する業務モデルを抽出して表示する。
また、業務仕様抽出支援システムは、抽出した物理モデルと一致する物理モデルが対応テーブルにおいて検出されない場合、対応付けのない物理モデルを表示し、ユーザに対して検出されない物理モデルに対応する業務モデルの作成を促す。

また、業務仕様抽出支援システムは、ソースプログラムのプログラム機能内の条件式によって、業務を分割して業務モデルのバリエーションとして、業務モデルを生成している。
例えば、図１１に示すプログラムにおいて、受注登録という業務機能の業務モデルに、ＰＧＭ＿Ｘ、ＰＧＭ＿Ａ、ＰＧＭ＿Ｂ、ＰＧＭ＿Ｃ及びＰＧＭ＿Ｙというプログラム機能の物理モデルが含まれている場合における業務の分割を行う場合を考える。図１１はソースプログラムの物理モデルのグラフを示している。
ここで、「受注場所」が１（国内を示すフラグ）の場合、ＰＧＭ＿Ｘの分岐処理によりＰＧＭ＿Ｘ、ＰＧＭ＿Ａ及びＰＧＭ＿Ｙが実行され、「受注場所」が２（国外を示すフラグ）の場合、ＰＧＭ＿Ｘの分岐処理によりＰＧＭ＿Ｘ、ＰＧＭ＿Ａ、ＰＧＭ＿Ｂ、ＰＧＭ＿Ｃ及びＰＧＭ＿Ｙが実行されることになる。

したがって、業務仕様抽出支援システムは、ＰＧＭ＿Ｘの分岐処理により、「受注登録」という業務を、図１２の物理モデルのグラフに示すように、「受注登録Ａ（受注場所＝１）」と「受注登録Ｂ（受注場所＝２）」とに分割する。そして、業務仕様抽出支援システムは、「受注登録Ａ」をＰＧＭ＿Ａだけの物理モデルに、「受注登録Ｂ」をＰＧＭ＿Ａ、ＰＧＭ＿Ｂ及びＰＧＭ＿Ｃからなる物理モデルに対応付けている。図１２はソースプログラムの物理モデルのグラフと、業務モデルとの対応を示す図である。

上述した処理により、受注場所が１の場合に国内、受注場所が２の場合に国外と対応付けると、国内における「受注登録」には必要がないが、国外における「受注登録」にＰＧＭ＿Ｂ→ＰＧＭ＿Ｃのフローが必要な業務であり、業務モデルの２つのバリエーションとして、「受注登録」を分割することができる。
また、業務仕様抽出支援システムは、業務モデル及び物理モデルの各々の名称を、ユーザから外部情報として与えられる構成となっている。

特開２００８−５２３１２号公報

リバースエンジニアリングにおいては、業務と情報処理システムとの関係を理解するためには、処理される業務内容を示す業務モデルと、ソースコードから抽出した処理を示す物理モデルとに対し、以下の３つの条件が必要になる。
ａ．業務モデルと物理モデルとの対応関係がある
ｂ．業務モデルと物理モデルとが一定かつ適切な粒度のプロセスに分割されている
ｃ．業務モデルと物理モデルとに対し、適切な名称が付与されている（業務モデルはユーザが理解できる名称であり、物理モデルはプログラム作成者が理解できる名称である必要がある）

ところが、特許文献１の業務仕様抽出支援システムは、業務モデルと物理モデルとの対応関係は示されているが、業務モデルと物理モデルとが適切な粒度に分割されているとは言えない。
すなわち、リエンジニアリングやリビルドなどで業務の改革及び改善のため、業務の取捨選択や共通化を検討する際、業務モデルを荒い粒度で行うと、業務で行われている処理の解析が十分にできない。
例えば、特許文献１の業務仕様抽出支援システムは、図１２において、ソースプログラムの処理が国内と国外とにおける「登録業務」に分離される。
しかしながら、国外における「登録業務（受注場所＝２）」にＰＧＭ＿Ｂ及びＰＧＭ＿Ｃが必要な物理モデルであることは判るが、この物理モデルがどのような処理を行っているかが判らない。

このため、改革及び改善を行う際に、取捨選択を行う情報が不十分であり、業務の内容を検討することができない。
例えば、図１１に示す「登録業務」を受注場所による２つのバリエーションに分割するのではなく、２つのバリエーションの違いが分かる程度の粒度に分割する必要がある。
図１３は、物理モデルのグラフであり、一例として、ソースプログラムにおけるＰＧＭ＿Ｘ、ＰＧＭ＿Ａ、ＰＧＭ＿Ｂ及びＰＧＭ＿Ｃを物理モデルの単位とし、この物理モデルに対して業務モデルを設定している。

これにより、国内の「登録業務（受注場所＝１）」と、国外の「登録業務（受注場所＝２）」との違いが明確となる。
国外の「登録業務」と国内の登録業務との共通な業務及び異なる業務を判定することにより、国内の「登録業務」にも、リスク情報に関する処理を入れるなどの、業務の改善を容易に行うことができる。
したがって、特許文献１の業務仕様抽出支援システムにおける物理モデルと業務モデルとの粒度は、業務の解析を行うためには不十分な大きさである。

このため、従来においては、業務の解析に対応できるように、業務モデルに関しては、ソースプログラムのドキュメント調査、あるいはユーザからのヒアリングをもとに、リバースエンジニアリングの担当者が適切と思う粒度の業務単位に作成していた。同様に、物理モデルに関してはプログラム機能を分割の単位としていた。
このため、リエンジニアリングの担当者毎に業務モデルの粒度が異なって、汎用性のないものとなっている。同様に、物理モデルの粒度をプログラム機能を分割の単位としているため、粒度が一定か否かはプログラムの設計によって異なり、結果として一定の粒度にはならない。

したがって、業務モデルを荒い粒度で設定する場合、担当者毎に粒度の設定が異なってしまい、実際には同じ業務であっても、異なる粒度で設定されてることになり、同じソースプログラムから抽出されたにもかかわらず、結果的に同一の業務とは認識できず、改善における共通化などができなくなる。

また、特許文献１の業務仕様抽出支援システムは、業務モデルと物理モデルとに適切な名称を付与する処理を行っていない。
このため、担当者は、業務仕様抽出支援システムの提示する物理モデル（プログラム機能名、物理データ名、プログラム機能を分割する条件式）に対応させ、業務モデル（業務機能名、論理データ名）から内容を類推し、物理モデル及び業務モデルに対して適切な名称を付与する必要があり、名称付与の作業に手間がかかってしまう。
したがって、担当者の知識によるため、ユーザが理解できる業務モデルの名称や、プログラム作成者が理解できる物理モデルの名称とはならず、改革及び改善の差異に効率的な処理が行えない。

本発明は、このような事情に鑑みてなされたもので、その目的は、情報処理システムに使用されるソースプログラムから、従来に比較して、細かく、かつ一定の粒度により、業務モデル及び物理モデルを対応させて抽出し、かつ業務仕様の改革及び改善を行う際、ユーザまたはプログラム作成者が容易に理解できる名称を業務モデル及び物理モデルの双方に与えることが可能なリバースエンジニアリング支援装置、リバースエンジニアリング支援方法及びそのプログラムを提供することを目的としている。

本発明のリバースエンジニアリング支援装置は、情報処理システムに使用されるソースプログラムに記述された業務仕様の抽出を行い、前記ソースプログラムの解析を支援するリバースエンジニアリング支援装置において、前記ソースプログラムのソースコードを構成するコードから、前記コードの種類、コードの組み合わせ及びコードの配置順序と、予め設定した処理機能を示す単位プログラムとの対応関係が予め設定された第１ルールに従い、前記ソースプログラムのソースコードから、前記処理機能に対応する単位プログラムを抽出する処理機能抽出部と、前記単位プログラムの処理機能の種類、組み合わせ及び配置の順番と、前記単位プログラムの配置の順番の変更、統合及び廃棄を示す統廃合処理との対応関係を予め設定した第２ルールに従い、前記ソースプログラムにおける前記単位プログラムの配置順の変更、統合及び廃棄の統廃合処理を行い、統廃合処理の結果として得られた単位プログラムを物理モデルとして出力する処理機能統廃合部とを有することを特徴とする。

本発明のリバースエンジニアリング支援装置は、前記物理モデルの処理機能の種類、組み合わせ及び配置順序と、前記物理モデルから構成される一般業務モデルとの対応関係を示す予め設定された第３ルールが記述された第３ルールテーブルから、前記処理機能統廃合部から出力される前記物理モデルの処理機能の種類、組み合わせ及び配置順序と一致する前記一般業務モデルを検索し、一致した一般業務モデルを前記物理モデルに対応付ける業務モデル特定部をさらに有することを特徴とする。

本発明のリバースエンジニアリング支援装置は、前記業務モデル特定部が、前記一般業務モデルの名称、当該一般業務の処理対象及び処理における制約条件の組み合わせと、特定の業務ドメインを示す業務モデルの名称であるドメイン特化業務名との対応関係を示す予め設定された第４ルールが記述された第４ルールテーブルから、前記一般業務モデルと一致する前記組み合わせを検索し、検索された前記ドメイン特化業務名を前記一般業務モデルに付与することを特徴とする。

本発明のリバースエンジニアリング支援方法は、情報処理システムに使用されるソースプログラムに記述された業務仕様の抽出を行い、前記ソースプログラムの解析を支援するリバースエンジニアリング支援装置を動作させる方法であり、処理機能抽出部が、前記ソースプログラムのソースコードを構成するコードから、前記コードの種類、コードの組み合わせ及びコードの配置順序と、予め設定した処理機能を示す単位プログラムとの対応関係が予め設定された第１ルールに従い、前記ソースプログラムのソースコードから、前記処理機能に対応する単位プログラムを抽出する過程と、処理機能統廃合部が、前記単位プログラムの処理機能の種類、組み合わせ及び配置の順番と、前記単位プログラムの配置の順番の変更、統合及び廃棄を示す統廃合処理との対応関係を予め設定した第２ルールに従い、前記ソースプログラムにおける前記単位プログラムの配置順の変更、統合及び廃棄の統廃合処理を行い、統廃合処理の結果として得られた単位プログラムを物理モデルとして出力する過程とを有することを特徴とする。

本発明のプログラムは、情報処理システムに使用されるソースプログラムにおける業務仕様の抽出を行い、前記ソースプログラムの解析を支援するリバースエンジニアリング支援装置としてコンピュータを機能させるプログラムであって、前記ソースプログラムのソースコードを構成するコードから、前記コードの種類、コードの組み合わせ及びコードの配置順序と、予め設定した処理機能を示す単位プログラムとの対応関係が予め設定された第１ルールに従い、前記ソースプログラムのソースコードから、前記処理機能に対応する単位プログラムを抽出する処理機能抽出手段、前記単位プログラムの処理機能の種類、組み合わせ及び配置の順番と、前記単位プログラムの配置の順番の変更、統合及び廃棄を示す統廃合処理との対応関係を予め設定した第２ルールに従い、前記ソースプログラムにおける前記単位プログラムの配置順の変更、統合及び廃棄の統廃合処理を行い、統廃合処理の結果として得られた単位プログラムを物理モデルとして出力する処理機能統廃合手段、として機能させるためのプログラムである。

この発明によれば、情報処理システムに使用されるソースプログラムから、第１ルールにより処理機能に対応したコードを単位プログラムとして抽出するため、予め設定した一定の大きさの粒度に分割することができ、かつプログラムを構成する各コードの処理機能毎に単位プログラムを抽出するため、プログラムを従来に比較してより粒度の細かな物理単位に分割することができ、物理モデルから業務モデルを抽出する際に、より詳細なドメインに特化した分類で業務モデルの抽出を行うことが可能となる。
また、この発明によれば、第１のルールにより抽出した単位プログラムを、第２ルールにより処理機能に対応させた統廃合処理を行うことにより、異なる位置に配置されている統合可能な単位プログラムの統廃合による整理を行うことができ、異なる配置にあり同一の処理を行う無駄に配置された単位プログラムを無くし、機能処理として整理された状態で物理モデルの抽出を行うことができ、業務仕様の改革及び改善を効率的に行うことが可能となる。

この発明の一実施形態によるリバースエンジニアリング支援装置の構成例を示す図である。 ソースコードから単位プログラムを抽出する際に用いられる第１ルールが記述された第１ルールテーブルの概要を説明する図である。 単位プログラムを統廃合して物理モデルを生成する際に用いられる第２ルールが記述された第２ルールテーブルの概要を説明する図である。 物理モデルから一般業務モデルを抽出した際に出力される第３出力テーブルの構成を示す図である。 一般業務モデルに対してドメイン特化業務名を付加する際に用いる第４ルールが記述された第４ルールテーブルの概要を説明する図である。 物理モデル及び業務モデルの抽出対象のソースプログラムの一例を示す図である。 処理機能抽出部１１がソースプログラムのソースコードのプログラムを、抽出した単位プログラムに置き換えた単位プログラムのグラフである単位プログラムグラフの構成の一例を示す図である。 図７における単位プログラムグラフにおける単位プログラムを統廃合して生成した物理モデルによる物理モデルグラフを示す図である。 物理モデルグラフにおける物理モデルＩＤと、業務モデルＩＤと、各業務モデルの業務モデル名との対応を示す図である。 物理モデルグラフにおける物理モデルＩＤと、業務モデルＩＤと、業務モデルに付与されたドメイン特化業務名との対応を示す図である。 従来例の業務仕様抽出支援システムの抽出処理を説明するために用いるソースプログラムの構成を示す図である。 従来例の業務仕様抽出支援システムにより抽出された業務モデルの構成を示す図である。 従来の物理モデル及び業務モデルの抽出における問題点を説明する図であり、物理モデルのグラフを示している。

以下、図面を参照して、本発明の実施の形態について説明する。図１は、この発明の一実施形態によるリバースエンジニアリング支援装置の構成を示す概略ブロック図である。
図１において、本実施形態によるリバースエンジニアリング支援装置は、ソースコード入力部１０、処理機能抽出部１１、処理機能統廃合部１２、業務モデル特定部１３、結果出力部１４、処理記憶部１５、第１ルール記憶部１６、第２ルール記憶部１７、第３ルール記憶部１８及び第４ルール記憶部１９を備えている。
ソースコード入力部１０は、外部装置から物理モデル及び業務モデルを抽出する解析対象のソースプログラムを入力し、処理記憶部１５に書き込んで記憶させる。

第１ルール記憶部１６には、適切な大きさの粒度にて物理モデルを抽出するために用いる第１ルールを定義する第１ルールテーブルが記憶されている。この第１ルールテーブルには、コードの種類と、そのコードの組み合わせと、そのコードの配置とに対応し、各コードの組み合わせによる処理機能を示す単位プログラムとの対応関係が示されている。第１ルールに記述されたルールと一致するコードの組み合わせが単位プログラムとして定義される。単位プログラムとしては、ソースコードの構造であるプログラム中のループ、条件式、外部入出力、代入式などの配置場所とそれぞれのコード関連（組み合わせ）とから、処理機能に対応付けられている。
ここで、本実施形態において、処理機能としては、例えばデータベース等で用いられる集合を操作する関係代数などにより実行される「選択」、「集約」、「和」、「射影」、…など、また他に「検索」、「選択」、「登録」などの機能を示す語彙を予め設定して用いることにより、これらの機能を処理するプログラム単位を単位プログラムと定義している。

図２は、ソースコードから単位プログラムを抽出する際に用いられる第１ルールが記述された第１ルールテーブルの概要を説明する図である。図２（ａ）は、第１ルールの例として、「選択」の処理機能の物理モデルと、「集約」の処理機能の物理モデルとの各々に対応させるための、プログラム（ソースコード）中のループ、条件式、外部入出力、代入式などの配置場所（配置の順番）及びそれぞれのコードの関連が記載された、すなわちコードの種類、コードの組み合わせ及びコードの配置と、このコードの組み合わせによる処理機能を示す単位プログラムとの対応関係が第１ルールとして第１ルールテーブルとして記述されている。図２（ｂ）には、第１ルールの説明のために用いるソースコードのテキストファイルを示すものである。図２（ｃ）は、抽出された結果として出力される単位プログラムの例を示す第１出力テーブルである。

この第１出力テーブルは、ソースプログラムから抽出された単位プログラム毎に付与されたプログラムＩＤと、このプログラムＩＤに対応した単位プログラムの処理機能の種類、制約条件、単位プログラムに対する入力、単位プログラムからの出力とから構成されている。ここで、制約条件は、単位プログラム毎の抽出条件に対応して設定されており、例えば図２（ｃ）の場合、処理機能「選択」の抽出条件に対して「Ｂ．状態（Ｂ［ｉ］．ｊｏｕｔａｉ）＝＝入荷済み（ＮＹＵＵＫＡ−ＺＵＭＩ）」が設定され、処理機能「集約」の抽出条件に対して「Ｂ１．在庫場所（Ｂ１［ｉ］．ｚａｉｋｏＢａｓｈｏ）、Ｂ１．商品コード（Ｂ１［ｉ］．ｓｈｏｈｉｎＣｏｄｅ）」が設定されている。すなわち、制約条件は、比較する条件節内に記載された条件式、あるいは条件式内で比較される変数のいずれかである（後述されるドメイン特化業務名を付加する際には双方が物理モデルから抽出される）。

図２（ａ）において、処理機能「選択」は、ソースコードからの単位プログラムとしてのコードの組み合わせの抽出条件として「変数と定数とを比較する条件節内に代入式があり、代入処理が行われている」こと、…などの複数の抽出条件が設定されている。また、処理機能「選択」は、抽出結果として、入力（条件節外で出力オブジェクトに代入しているオブジェクト）、出力（条件節内で出力しているオブジェクト）及び制約条件として条件式を出力するように設定されている。

また、図２（ａ）において、処理機能「集約」は、ソースコードからの単位プログラムとしてのコードの抽出条件として「ループ内で以下の条件を満たす場合：”変数！＝変数”を条件式とする条件節内に代入式があり、代入処理が行われ、かつ条件節の外部に代入式があり、代入処理が行われている」…などの複数の抽出条件が設定されている。また、図２（ｃ）の第１出力テーブルに示されているように、処理機能「集約」は、抽出結果として、入力（ループ内で入力されているオブジェクト）、出力（条件節内で出力されているオブジェクト）及び制約条件として条件式内で比較される変数を出力するように設定されている。
処理機能抽出部１１は、処理記憶部１５から解析対象のソースコードを読み込み、第１ルールに従って、処理機能の機能毎の物理モデルを抽出する。

第２ルール記憶部１７には、プログラムの処理機能の並び順により、単位プログラムの処理機能に対応して、１つまたは複数の単位プログラムからなる物理モデルに統廃合し、ソースコードからの物理モデルの抽出処理を行うために用いる第２ルールを定義する第２ルールテーブルが記憶されている。この第２ルールテーブルには、プログラムの配列順とプログラムの組み合わせに対応して、物理モデルとの対応関係が示されている。

図３は、単位プログラムを統廃合して物理モデルを生成する際に用いられる第２ルールが記述された第２ルールテーブルの概要を説明する図である。図３（ａ）は、第２ルールの例として、プログラムの配列及び処理機能（選択、集約及び和）により、単位プログラムを統廃合処理して、物理モデルを生成するためのルールの一例が記載されている。
図３（ｂ）には、第１ルールにより処理機能抽出部１１が抽出した出力結果のテーブルの一例を示す図である。
図３（ｃ）は、第２ルールにより統廃合処理の結果出力される物理モデルの構成を示すテーブルの図である。物理モデルは、物理モデルＩＤに対応し、統廃合されたプログラムＩＤと、初期機能と、制約条件と、入力及び出力のオブジェクトとから構成されている。ここで、物理モデルの制約条件は、統廃合したプログラムにおける制約条件が反映される。また、物理モデルの入力及び出力に関しては、それぞれ統廃合のプログラムの並び順に基づき、各プログラムの入力及び出力のオブジェクトに対応して再設定される。

図３（ａ）において、第２ルールとして、「処理機能”選択”のプログラムは、一つ前のプログラムの処理機能が「集約」以外の場合、配列の順番を入れ替える」、「連続する”選択”は一つの”選択”にまとめて、制約条件をアンド（論理積演算）で繋げる」、「連続する”和”は一つの”和”にまとめる」、…などのルールが記載されている。
処理機能統廃合部１２は、第２ルールに従い、各処理機能のプログラムを、プログラムの配列順及び組み合わせに対応して統廃合し、物理モデルの生成を行う。

第３ルール記憶部１８には、物理モデルの処理機能の並び順と組み合わせとにより、１つまたは２つの物理モデルからなる一般業務モデルに対応させる処理を行うために用いる第３ルールを定義する第３ルールテーブルが記憶されている。この第３ルールテーブルには、物理モデルの配列順と物理モデルの組み合わせに対応して、一般業務モデルの業務名との対応関係が示されている。

図４は、物理モデルに対して一般業務モデルの業務名（一般業務モデル名）を付加する際に用いる、上述した第３ルールが記述された第３ルールテーブルの概要を説明する図である。
図４（ａ）は、第３ルールテーブルの構成を示すものであり、物理モデルの処理機能及び配置（並び順）の順み合わせと、この組み合わせに対応する一般業務モデル名との対応の一例が示されている。
図４（ｂ）は、物理モデルから一般業務モデルを抽出した際に出力される第３出力テーブルの構成を示す図である。この図４（ｂ）は、業務モデルを識別する業務モデルＩＤに対応して、業務モデルＩＤの示す業務モデルに対応する物理モデルを示す物理モデルＩＤと、物理モデルＩＤの示す物理モデルを構成する単位プログラムを示すプログラムＩＤと、物理モデルＩＤが示す物理モデルの処理機能と、物理モデルＩＤが示す物理モデルの制約条件と、物理モデルに入力されるオブジェクトと、物理モデルから出力されるオブジェクトと、この業務モデルの一般業務名との対応を示している。
業務モデル特定部１３は、第３ルールに従い、各物理モデルを、物理モデルの配列順及び組み合わせに対応して統合し、一般業務モデルの生成を行う。

第４ルール記憶部１８には、一般業務モデルの業務名、処理対象、制約条件と、ドメイン特化業務名と対応関係を示し、一般業務モデルの処理内容に応じてドメイン特化業務名を付与するための第４ルールを定義する第４ルールテーブルが記憶されている。

図５は、一般業務モデルに対してドメイン特化業務名を付加する際に用いる第４ルールが記述された第４ルールテーブルの概要を説明する図である。
図５（ａ）は、第４ルールテーブルの構成を示すものであり、一般業務名、処理対象、制約条件の組み合わせと、この組み合わせに対応するドメイン特化業務名との対応の一例が示されている。
図５（ｂ）は、第４ルールによる処理結果として出力される結果テーブルを示す図である。一般業務モデルの業務デルＩＤ毎に、各業務モデルを構成する物理モデルの物理モデルＩＤと、物理モデルに統廃合されたプログラムのプログラムＩＤと、物理モデルの制約条件、物理モデルが入力及び出力するオブジェクトと、業務モデルＩＤのドメイン特化業務名との対応が記載されたテーブルの図である。
処理機能統廃合部１２は、第２ルールに従い、一般業務モデルの処理対象のドメインに対応して、ドメイン特化業務名を各一般業務モデルに対して付与する処理を行う。

＜処理機能抽出処理＞
次に、図１、図２、図６及び図７を用いて、処理機能抽出部１１が行う処理機能抽出処理について説明する。
処理機能抽出部１１は、ソースコード入力部１０が処理記憶部１５に書き込んで記憶させたソースプログラムを読み出す。
図６は、物理モデル及び業務モデルの抽出対象のソースプログラムとオブジェクト及びソースプログラム間の入力関係の一例を示す図である。このソースプログラムは、プログラムＰＧＭ−１、ＰＧＭ−２、ＰＧＭ−３、ＰＧＭ−４、ＰＧＭ−５、ＰＧＭ−６、ＰＧＭ−７及びＰＧＭ−８から構成され、初期入力オブジェクトとしてファイルＦＩＬＥ−Ａ、ＦＩＬＥ−Ｄ及びＦＩＬＥ−Ｇを読み込み、最終出力オブジェクトとしてＦＩＬＥ−Ｋを出力する。

そして、処理機能抽出部１１は、ソースプログラムにおける各ＰＧＭのソースコードから、ループ、条件式、外部入出力、代入式などのコードの種類、コードの配置を示す第１ルールパラメータを抽出する。この第１パラメータ抽出の際、処理機能抽出部１１は、ソースプログラムに入力されるオブジェクトを処理する順番に、第１ルールパラメータの抽出処理を行う。すなわち、初期入力オブジェクトが入力されるプログラムから順次処理を開始し、そのプログラムから出力される出力オブジェクトが、入力オブジェクトとして入力されるプログラムの順に、第１ルールパラメータの抽出を行う。
例えば、処理機能抽出部１１は、ＦＩＬＥ−Ａを入力するプログラムＰＧＭ−１から抽出処理を開始し、他のプログラムからの出力と統合処理を行うプログラムＰＧＭ−６において一旦停止し、ソースプログラムに入力される他のＦＩＬＥ−Ｄを処理するプログラムＰＧＭ−３から抽出処理を再開する。

同様に、処理機能抽出部１１は、他のプログラムからの出力と統合処理を行うプログラムＰＧＭ−５において一旦停止し、ソースプログラムに入力される他のＦＩＬＥ−Ｇを処理するプログラムＰＧＭ−５から抽出処理を再開し、このとき、プログラムＰＧＭ−５がプログラムＰＧＭ−４から出力されるオブジェクト（ＦＩＬＥ−Ｆ）を入力していることを検出し、プログラムＰＧＭ−５への入力をＦＩＬＥ−ＦとＦＩＬＧとして、プログラムＰＧＭ−５からの単位プログラムの抽出を行う。

次に、処理機能抽出部１１は、ＰＧＭ−６に入力されるオブジェクトであるＦＩＬＥ−Ｃ及びＦＩＬＥ−Ｈを出力するプログラムＰＧＭ−２及びＰＧＭ−５の抽出処理が終了したことを検出すると、ＦＩＬＥ−Ｃ及びＦＩＬＥ−Ｈを入力とするプログラムＰＧＭ−６に対し、単位プログラムを抽出する処理を行う。
そして、処理機能抽出部１１は、プログラムＰＧＭ−６からプログラムＰＧＭ−８までの各プログラムから、入力及び出力されるオブジェクトを含め、単位プログラムの抽出処理を行う。

次に、処理機能抽出部１１は、第１ルール記憶部１６の第１ルールテーブルにおいて、抽出した第１ルールパラメータに対応するパラーメータを検索し（パターンマッチング処理）、第１ルールパラメータと一致するパラーメータに対応して記憶されている処理機能を抽出し、第１ルールパラメータに対応した処理機能を読み出す。
例えば、プログラムＰＧＭ−２が、図２（ｂ）に示すソースコードの場合、ソースコードＰは「変数（Ｂ［ｉ］，ｊｏｕｔａｉ）と、定数（ＮＹＵＵＫＡ−ＺＵＭＩ）を比較する条件節内（ｉｆ文節）で代入の処理として代入（Ｂ１［ｊ］＝Ｂ［ｉ］）する」構造をしており、ソースコードＱは「ループ（ｗｈｉｌｅ文）内で、変数（ｏｌｄＤａｔａ．ｚａｉｋｏＢａｓｈｏ）！＝変数（ｎｅｗＤａｔａ．ｚａｉｋｏＢａｓｈｏ）を条件式とする条件節（ｉｆ文節）内において、代入（Ｃ．ｄａｔａ１＝ｏｌｄＤａｔａ．ｄａｔａ１）しており、同一ループ内の同じ条件式の外部にて代入（ｏｌｄＤａｔａ＝ｎｅｗＤａｔａ）する」構造をしている。

したがって、処理機能抽出部１１は、ソースコードＰから抽出した第１ルールパラメータを抽出条件として、パターンマッチングにより第１ルールテーブルを検索し、一致する抽出条件に対応する処理機能である「選択」を読み出し、処理機能「選択」の単位プログラムとしてプログラムＩＤ２を付与する。
同様に、処理機能抽出部１１は、ソースコードＱから抽出した第１ルールパラメータを抽出条件として、パターンマッチングにより第１ルールテーブルを検索し、一致する抽出条件に対応する処理機能である「集約」を読み出し、処理機能「集約」の単位プログラムとしてプログラムＩＤ２を付与する。

すなわち、処理機能抽出部１１は、プログラムＰＧＭ−２のソースコードと、第１ルールとのパターンマッチングにより、プログラムＰＧＭ−２が、処理機能「選択」及び集約から構成されており、それぞれ「”状態＝＝入荷済み”という条件によりデータを”選択”する」という処理機能「選択」の単位プログラムと、「その”選択”された結果を”在庫場所”と”商品コード”とにより”集約”する」という処理機能「集約」の単位プログラムとから構成されていることを検出し、処理機能単位にソースコードを構成するプログラムを分割している。このプログラムを処理機能単位に分割することにより、ソースプログラムから、従来に比較してより細かく、かつ一定の粒度により、後述する物理モデルを抽出することが可能となる。

そして、処理機能抽出部１１は、処理結果として、図３（ｂ）に示す、ソースプログラムから抽出し単位プログラム毎に付与されたプログラムＩＤと、このプログラムＩＤに対応した単位プログラムの処理機能の種類、制約条件、単位プログラムに対する入力、単位プログラムからの出力とからなる第１出力テーブルを、処理記憶部１５に書き込んで記憶させる。

次に、図７は、処理機能抽出部１１がソースプログラムのソースコードのプログラムを、抽出した単位プログラムに置き換えた単位プログラムのグラフである単位プログラムグラフの構成の一例を示す図である。
すなわち、処理機能抽出部１１は、図６に示すソースプログラムのグラフを、単位プログラムの抽出結果に対応させた図７に示す単位プログラムグラフの関係として図３（ｂ）を生成し、処理記憶部１５に書き込んで記憶させる。

＜処理機能統廃合処理＞
次に、図１、図３、図７及び図８を用いて、処理機能抽出部１１が行う処理機能抽出処理について説明する。図８は、図７における単位プログラムグラフにおける単位プログラムを統廃合して生成した物理モデルによる物理モデルグラフを示す図である。
処理機能統廃合部１２は、処理機能抽出部１１が処理記憶部１５に書き込んで記憶させた図３（ｂ）に示す第１出力テーブルを読み出す。また、処理機能統廃合部１２は、第２ルール記憶部１７に記憶されている第２ルールテーブルを読み出す。

次に、処理機能統廃合部１２は、図８の単位プログラムグラフにおける単位プログラムの配列と、第１出力テーブルにおける各単位プログラムの処理機能の記述とから、ソースプログラムに入力されるオブジェクトから順番に、単位プログラムの配列順（並び順）と、単位プログラムの機能の組み合わせと等からなる第２ルールパラメータを抽出する。
ここで、処理機能統廃合部１２は、初期入力オブジェクトが入力される単位プログラムから順次処理を開始し、その単位プログラムから出力される出力オブジェクトが、入力オブジェクトとして入力される単位プログラムの順に、第２ルールパラメータの抽出を行う。
そして、処理機能統廃合部１２は、第１出力テーブルから抽出された第２ルールパラメータと、第２ルールテーブルに記述された第２ルールにおける各ルールに記述されたパラーメータとマッチングすることにより（一致する第２ルールパラメータに一致するパラメータが記載されたルールを検索し）、第２ルールパラメータと一致したルールに基づいた統廃合の処理を行う。このとき、処理機能統廃合部１２は、第２ルールに記述された順番に、ルールに基づいた統廃合処理を行う。

例えば、処理機能統廃合部１２は、図７に示す単位プログラムの処理順番において、処理機能「選択」のプログラムＩＤ７の前に配置された処理機能「選択」のプログラムＩＤ３及びＩＤ４の間に、処理機能「集約」の単位プログラムが配置されておらず、第２ルールにおける「”選択”は、一つ前の処理機能が”集約”以外の場合、順番を入れ替える」とするルールに対応することを検出する。
そして、処理機能統廃合部１２は、プログラムＩＤ４及びＩＤ５の各々の配列位置の次の配列位置にプログラムＩＤ７「選択」を配置し、プログラムＩＤ６及びプログラムＩＤ８の間にあるプログラムＩＤ７「選択」を削除（廃棄）する。

次に、処理機能統廃合部１２は、プログラムＩＤ１及びＩＤ２の単位プログラムが双方ともに処理機能「選択」であり、第２ルールにおける「連続する”選択”は一つの”選択”にまとめ、制約条件をアンドで繋げる」とするルールに対応することを検出する。
そして、処理機能統廃合部１２は、処理機能「選択」のプログラムＩＤ１及びＩＤ２の単位プログラムを、処理機能「選択」の物理モデルとして統合し、識別情報として物理モデルＩＤ１を付与する。

同様に、処理機能統廃合部１２は、処理機能「選択」のプログラムＩＤ３、ＩＤ４及びＩＤ７の単位プログラムも、第２ルールにおける「連続する”選択”は一つの”選択”にまとめ、制約条件をアンドで繋げる」とするルールに対応することを検出する。
そして、処理機能統廃合部１２は、プログラムＩＤ３、ＩＤ４及びＩＤ７の単位プログラムの統廃合処理を行い、処理機能「選択」の物理モデルとして統合し、識別情報として物理モデルＩＤ３を付与する。

また、処理機能統廃合部１２は、処理機能「選択」のプログラムＩＤ５及びＩＤ７の単位プログラムも、第２ルールにおける「連続する”選択”は一つの”選択”にまとめ、制約条件をアンドで繋げる」とするルールに対応することを検出する。
そして、処理機能統廃合部１２は、プログラムＩＤ５（処理機能”選択”）及びＩＤ７の単位プログラムの統廃合処理を行い、処理機能「選択」の物理モデルとして統合し、識別情報として物理モデルＩＤ３を付与する。

次に、処理機能統廃合部１２は、処理機能「和」のプログラムＩＤ５（処理機能”和”）及びＩＤ６が連続していることより、第２ルールにおける「連続する”和”は一つの”和”にまとめる」とするルールに対応することを検出する。
そして、処理機能統廃合部１２は、プログラムＩＤ５（処理機能”和”）及びＩＤ６の単位プログラムの統廃合処理を行い、処理機能「和」の物理モデルとして統合し、識別情報として物理モデルＩＤ５を付与する。

また、処理機能統廃合部１２は、処理機能「集約」のプログラムＩＤ２及びＩＤ８の各々を、それぞれ処理機能「集約」の物理モデルとし、識別情報として物理モデルＩＤ２、ＩＤ６を付与する。
上述したように、処理機能統廃合部１２は、処理機能抽出部１１の抽出した単位プログラムを、図７に示す単位プログラムグラフと図３（ｃ）に示す第１出力テーブルとを参照することにより、第２ルールに従って機能処理の種類とその配列順とにより統廃合して生成した物理モデルを、図８に示す物理モデルの配列を示す物理モデルグラフに対応する第２出力テーブル（図３（ｃ））を生成し、処理記憶部１５に書き込んで記憶させる。

すなわち、処理機能統廃合部１２は、物理モデル毎に、物理モデルを識別する物理モデルＩＤと対応し、物理モデルＩＤの示す物理モデルとして構成された単位プログラムのプログラムＩＤ、物理モデルの処理機能、制約条件、物理モデルに入力されるオブジェクト、物理モデルから出力されるオブジェクトとが対応付けた、図３（ｃ）に示す第２出力テーブルを、処理記憶部１５に書き込んで記憶させる。
また、処理機能統廃合部１２は、統廃合した結果として得られる物理モデルの入力及び出力されるオブジェクトを、統廃合する単位プログラムの入力及び出力されるオブジェクトに対応して、統廃合された物理モデル自身及び前段及び後段の物理モデルの入力及び出力されるオブジェクトを変更する。

＜業務モデル特定処理＞
次に、図１、図３、図４、図５及び図９を用いて、業務モデル特定部１４が行う業務モデル特定処理について説明する。
業務モデル特定部１３は、処理機能統廃合部１２が処理記憶部１５に書き込んで記憶させた図８の物理モデルグラフの構成に対応する図３（ｃ）に示す第２出力テーブルを読み出す。また、処理機能統廃合部１２は、第３ルール記憶部１８に記憶されている図４（ａ）に示す第３ルールテーブルを読み出す。

次に、業務モデル特定部１３は、図３（ｃ）に示す第２出力テーブルから、各物理モデルの処理機能の種類と物理モデルの並び順を、第３ルールテーブルに記述された第３ルールとマッチングすることにより、物理モデルの処理機能の種類とその並び順（配置順）と（第３ルールパラメータ）が一致するルールを検索し、この一致するルールに対応して記憶されている一般業務モデル名を第３ルールから抽出する。
ここで、業務モデル特定部１３は、初期入力オブジェクトが入力される物理モデルから順次処理を開始し、その物理プログラムから出力される出力オブジェクトが、入力オブジェクトとして入力される物理モデルの順に、順次第３ルールパラメータの抽出を行う。
そして、業務モデル特定部１３は、連続する各物理モデルの単位プログラムグラフにおける単位プログラムの配列（並び順）と、第１出力テーブルにおける各単位プログラムの処理機能の記述とから、図８の物理モデルグラフが示すソースプログラムに入力されるオブジェクトから順番に、一般業務モデルの名称である一般業務モデル名の付与を、図９に示す物理モデルグラフに示すように行う。
図９は、物理モデルグラフにおける物理モデルＩＤと、業務モデルＩＤと、各業務モデルの業務モデル名との対応を示す図である。

例えば、図４（ａ）に示す第３ルールテーブルにおいて、物理モデルＩＤ１の物理モデルの処理機能が「選択」であり、物理モデルＩＤ２の物理モデルの処理機能が「集約」であり、物理モデルＩＤ１及びＩＤ２の物理モデルが、処理機能「和」の物理モデルの前段において連続して配置されているため、物理モデルＩＤ１及びＩＤ２の物理モデルは、一般業務モデルの「明細集計」に該当する（第３ルールの一例）。
このため、業務モデル特定部１３は、第３ルールに従い、物理モデルＩＤ１及びＩＤ２の物理モデルを統合し、一つの一般業務モデルとして、「明細集計」を名称として付与するとともに、識別情報として業務モデルＩＤ１を付与する。

また、物理モデルＩＤ３及びＩＤ４の物理モデルは、それぞれ単独で和の前段に配置され、処理内容が「選択」であるため、一般モデルの「情報抽出」に該当する（第３ルールの一例）。
このため、業務モデル特定部１３は、第３ルールに従い、物理モデルＩＤ３及びＩＤ４の物理モデルの各々に対し、一般業務モデルとして、「情報抽出」を名称として付与するとともに、物理モデルＩＤ３及びＩＤ４の物理モデルの各々に対して識別情報として業務モデルＩＤ２、ＩＤ３を付与する。

また、物理モデルＩＤ５及びＩＤ６の物理モデルの各々は、物理モデルの配置が連続しており、かつ処理機能「和」と処理機能「集約」との順番であるため、一般業務モデルの「全集計」に該当する（第３ルールの一例）。
このため、業務モデル特定部１３は、第３ルールに従い、物理モデルＩＤ５及びＩＤ６の物理モデルを統合し、一つの一般業務モデルとして、「全集計」を名称として付与するとともに、物理モデルＩＤ３及びＩＤ４の物理モデルを統合した一般業務モデルに対して識別情報として業務モデルＩＤ４を付与する。

上述したように、業務モデル特定部１３は、各物理モデルの統合等の処理を行い、各物理モデルに対して一般業務モデル名及び業務モデルＩＤを付与し、図３（ｃ）に示す第２出力テーブルの記述に基づいて、図４（ｂ）に示す第３出力テーブルを生成し、生成した第３出力テーブルを処理記憶部１５に書き込み記憶させる。
ここで、第３出力テーブルは、各一般業務モデルの業務モデルＩＤと、この業務モデルＩＤの示す一般業務モデルに対応する物理モデルの物理モデルＩＤ、物理モデルを構成する単位プログラムのプログラムＩＤ、物理モデルの処理機能、物理モデルの制約条件、物理モデルに入力されるオブジェクト、物理モデルが出力するオブジェクトとからなるテーブルである。

次に、業務モデル特定部１３は、自身が処理記憶部１５に書き込んで記憶させた図４に示す第３出力テーブルと、第４ルール記憶部１９に記憶されている図５（ａ）に示す第４ルールテーブルを読み出す。
そして、業務モデル特定部１３は、図５（ａ）に示す第４ルールテーブルに記述された第４ルールに従い、すなわち第４ルールと第３出力テーブルの記述とのマッチングを行い、一般業務モデル名、処理対象及び制約条件との組み合わせとにより、一般業務モデル毎に、ドメイン特化業務名を付与する処理を行う。

図１０は、物理モデルグラフにおける物理モデルＩＤと、業務モデルＩＤと、業務モデルに付与されたドメイン特化業務名との対応を示す図である。
上述したように、業務モデル特定部１３は、この図９に示すように、物理モデルを一般業務モデルである業務モデルに変換し、この一般業務モデルに対して一般業務モデル名を付与する。
また、業務モデル特定部１３は、統合した結果として得られる一般業務モデルの入力及び出力されるオブジェクトを、統廃合する物理モデルの入力及び出力されるオブジェクトに対応して、統合された一般業務モデル自身及び前段及び後段の一般業務モデルの入力及び出力されるオブジェクトを変更する。

次に、業務モデル特定部１３は、付与した一般業務モデル名と、この一般業務モデルの処理対象と、この一般業務モデルの制約条件とにより、第４ルールに従い、各一般業務モデルに対してドメイン特化業務名を付与する処理を行う。
すなわち、業務モデル特定部１３は、第４ルールテーブルから、一般業務モデルの一般業務モデル名と、この一般業務モデルの処理対象と、この一般業務モデルの制約条件と一致するルールを検索し、検索されたルールに対応して記憶されているドメイン特化業務名を、検索対象とした一般業務モデルに付与する。

例えば、業務モデル特定部１３は、第３出力テーブルから、業務モデルＩＤ１の一般業務モデルが一般業務モデル名として「明細集計」であり、処理対象が入荷情報であり、かつ制約条件が「入荷日＝＝本日」であることを検出する。
そして、業務モデル特定部１３は、業務モデルＩＤ１の一般業務モデル名、処理対象及び制約条件の組み合わせと、図５（ａ）に示す第４ルールとのマッチングを行う。
マッチングにおいて、業務モデル特定部１３は、一般業務モデル名が「明細集計」であり、処理対象が入荷情報であり、かつ制約条件に「入荷日＝＝本日」である組み合わせを第４ルールにおいて検出する。
この結果、業務モデル特定部１３は、業務モデルＩＤ１の一般業務モデル名、処理対象及び制約条件の組み合わせと、第４ルールにて一致した組み合わせに対応するドメイン特化業務名である「当日入荷集計」を読み出し、業務モデルＩＤ１に付与する。ここで、処理対象の抽出は、制約条件に用いられているデータの名称から推定、例えば上述の場合、入荷日を示すデータの名称から入荷についての処理であることを推定する。

また、業務モデル特定部１３は、第３出力テーブルから、業務モデルＩＤ２の一般業務モデルが、一般業務モデル名が「情報抽出」であり、処理対象が在庫抽出情報であり、制約条件にα倉庫が含まれていることを検出する。
そして、業務モデル特定部１３は、業務モデルＩＤ２の一般業務モデル名、処理対象及び制約条件の組み合わせと、第４ルールとをマッチングする。
この結果、業務モデル特定部１３は、業務モデルＩＤ２の一般業務モデル名、処理対象及び制約条件の組み合わせと、第４ルールにて一致した組み合わせに対応するドメイン特化業務名である「α倉庫在庫抽出」を読み出し、業務モデルＩＤ２に付与する。

また、業務モデル特定部１３は、第３出力テーブルから、業務モデルＩＤ３の一般業務モデルが、一般業務モデル名が「情報抽出」であり、処理対象が在庫抽出情報であり、制約条件に「入荷日＞本日−１０営業日」が含まれていることを検出する。
そして、業務モデル特定部１３は、業務モデルＩＤ３の一般業務モデル名、処理対象及び制約条件の組み合わせと、第４ルールとをマッチングする。
この結果、業務モデル特定部１３は、業務モデルＩＤ３の一般業務モデル名、処理対象及び制約条件の組み合わせと、第４ルールにて一致した組み合わせに対応するドメイン特化業務名である「最新在庫抽出」を読み出し、業務モデルＩＤ３に付与する。

また、業務モデル特定部１３は、第３出力テーブルから、業務モデルＩＤ４の一般業務モデルが一般業務モデル名として「全集計」であり、処理対象が在庫情報であり、かつ制約条件が「在庫場所、商品コード」であることを検出する。
そして、業務モデル特定部１３は、業務モデルＩＤ４の一般業務モデル名、処理対象及び制約条件の組み合わせと、図５（ａ）に示す第４ルールとのマッチングを行う。
マッチングにおいて、業務モデル特定部１３は、一般業務モデル名が「全集計」であり、処理対象が在庫情報であり、かつ制約条件に「在庫場所、商品コード」である組み合わせを第４ルールにおいて検出する。
この結果、業務モデル特定部１３は、業務モデルＩＤ４の一般業務モデル名、処理対象及び制約条件の組み合わせと、第４ルールにて一致した組み合わせに対応するドメイン特化業務名である「全在庫集計」を読み出し、業務モデルＩＤ４に付与する。

そして、業務モデル特定部１３は、図４における全ての一般業務モデルに対するドメイン特化業務名の付与が終了すると、図４に示す第３出力テーブルに対し、各業務モデルに対して付与したドメイン特化業務名を付加した図５（ｂ）に示す第４出力テーブルを生成し、処理記憶部１５に書き込んで記憶させる。
また、業務モデル特定部１３は、図９の物理モデルグラフに対して、各物理モデル及び業務モデルの対応関係と、業務モデル及び業務モデルに付与されたドメイン特化業務名の対応関係を示す記述を付加した図１０の物理モデルグラフを生成し、処理記憶部１５に書き込んで記憶させる。

＜結果出力処理＞
そして、結果出力部１４は、ソースプログラムからの物理モデル及び業務モデルの抽出処理が終了すると、図５（ｂ）の第４出力テーーブルと、図１０のドメイン特化業務名が付与された物理モデルグラフとを読み出し、図示しない表示装置に対して表示する。

上述したように、本実施形態においては、ソースコードにおけるコードの種類とその組み合わせと配置順等の組み合わせと、その組み合わせにより実現される処理機能との対応を示す第１ルールにより、ソースコードを従来に比較してより細かく一定の粒度の単位プログラムに分割するため、単位プログラムの統廃合処理、すなわちソースコードにおける処理を機能的に整理し、リバースエンジニアリングが行いやすい物理モデルを抽出することができる。

また、本実施形態においては、第２ルールにより、ソースコードを処理機能毎に分割した単位プログラムの配置を、ソースプログラムの動作を変更させない条件下により変更し、かつ連続する同一の処理機能を有する単位プログラムの統合を行う統廃合処理を行い、処理機能に対応した物理モデルの抽出を行うため、ソースコードにおいて異なる位置に無駄に設けられた同一の処理機能の単位プログラムを統合し、全体のソースコードを表現する物理モデルを、ソースコードの機能を整理した状態において抽出することができ、かつ業務的な意味をわかりやすくし、業務モデルを抽出する際に、ドメインモデルである第３ルールとのマッチングが容易に行える。

また、本実施形態においては、第３ルールの物理モデルの種類及び配置順の組み合わせにより、一つあるいは複数の物理モデルを一般業務モデルに変換するため、一般業務モデルが常に一定の条件で抽出することができ、従来のように、物理モデルと業務モデルとの対応が異なることなく、予め設定した第３ルールに従った均一な対応関係にある物理モデルと業務モデルとを、抽出対象のソースコードから抽出させることができる。

また、本実施形態においては、物理モデルに処理機能の名称（選択、集約、和、射影など）を付与し、かつ一般業務モデルの一般業務モデル名と処理対象と制約条件と、第４ルールにおいて一致する一般業務モデル名と処理対象と制約条件とに対応付けられたドメイン特化業務名を読み出し、この一般業務モデル名と処理対象と制約条件一致した一般業務モデルに対して、読み出したドメイン特化業務名を付与するため、従来のように、名称付与の属人性や外部知識の必要性を排除することができ、名称を付与する工程を省くことができ、かつ処理を高速化することができる。
また、本実施形態においては、プログラムを作成する担当者に理解できる物理モデルの名称が付与され、また抽出した業務モデルに対して、システムの改革及び改善を行う作業者に容易に理解できるドメイン特化業務名が付与されるため、業務的な意味を分かり易くし、リバースエンジニアリングの効率を向上させることができる。

また、図１におけるソースコード入力部１０、処理機能抽出部１１、処理機能統廃合部１２、業務モデル特定部１３、結果出力部１４各部の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより物理モデル及び業務モデルの抽出処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。

また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。

以上、この発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

１０…ソースコード入力部
１１…処理機能抽出部
１２…処理機能統廃合部
１３…業務モデル特定部
１４…結果出力部
１５…処理機億部
１６…第１ルール記憶部
１７…第２ルール記憶部
１８…第３ルール記憶部
１９…第４ルール記憶部

Claims (5)

1. 情報処理システムに使用されるソースプログラムに記述された業務仕様の抽出を行い、前記ソースプログラムの解析を支援するリバースエンジニアリング支援装置において、
   前記ソースプログラムのソースコードを構成するコードから、前記コードの種類、コードの組み合わせ及びコードの配置順序と、予め設定した処理機能を示す単位プログラムとの対応関係が予め設定された第１ルールに従い、前記ソースプログラムのソースコードから、前記処理機能に対応する単位プログラムを抽出する処理機能抽出部と、
   前記単位プログラムの処理機能の種類、組み合わせ及び配置の順番と、前記単位プログラムの配置の順番の変更、統合及び廃棄を示す統廃合処理との対応関係を予め設定した第２ルールに従い、前記ソースプログラムにおける前記単位プログラムの配置順の変更、統合及び廃棄の統廃合処理を行い、統廃合処理の結果として得られた単位プログラムを物理モデルとして出力する処理機能統廃合部と
   を有することを特徴とするリバースエンジニアリング支援装置。
2. 前記物理モデルの処理機能の種類、組み合わせ及び配置順序と、前記物理モデルから構成される一般業務モデルとの対応関係を示す予め設定された第３ルールが記述された第３ルールテーブルから、前記処理機能統廃合部から出力される前記物理モデルの処理機能の種類、組み合わせ及び配置順序と一致する前記一般業務モデルを検索し、一致した一般業務モデルを前記物理モデルに対応付ける業務モデル特定部を
   さらに有することを特徴とする請求項１に記載のリバースエンジニアリング支援装置。
3. 前記業務モデル特定部が、前記一般業務モデルの名称、当該一般業務の処理対象及び処理における制約条件の組み合わせと、特定の業務ドメインを示す業務モデルの名称であるドメイン特化業務名との対応関係を示す予め設定された第４ルールが記述された第４ルールテーブルから、前記一般業務モデルと一致する前記組み合わせを検索し、検索された前記ドメイン特化業務名を前記一般業務モデルに付与する
   ことを特徴とする請求項２に記載のリバースエンジニアリング支援装置。
4. 情報処理システムに使用されるソースプログラムに記述された業務仕様の抽出を行い、前記ソースプログラムの解析を支援するリバースエンジニアリング支援装置を動作させるリバースエンジニアリング支援方法において、
   処理機能抽出部が、前記ソースプログラムのソースコードを構成するコードから、前記コードの種類、コードの組み合わせ及びコードの配置順序と、予め設定した処理機能を示す単位プログラムとの対応関係が予め設定された第１ルールに従い、前記ソースプログラムのソースコードから、前記処理機能に対応する単位プログラムを抽出する過程と、
   処理機能統廃合部が、前記単位プログラムの処理機能の種類、組み合わせ及び配置の順番と、前記単位プログラムの配置の順番の変更、統合及び廃棄を示す統廃合処理との対応関係を予め設定した第２ルールに従い、前記ソースプログラムにおける前記単位プログラムの配置順の変更、統合及び廃棄の統廃合処理を行い、統廃合処理の結果として得られた単位プログラムを物理モデルとして出力する過程と
   を有することを特徴とするリバースエンジニアリング支援方法。
5. 情報処理システムに使用されるソースプログラムにおける業務仕様の抽出を行い、前記ソースプログラムの解析を支援するリバースエンジニアリング支援装置としてコンピュータを機能させるプログラムであって、
   前記ソースプログラムのソースコードを構成するコードから、前記コードの種類、コードの組み合わせ及びコードの配置順序と、予め設定した処理機能を示す単位プログラムとの対応関係が予め設定された第１ルールに従い、前記ソースプログラムのソースコードから、前記処理機能に対応する単位プログラムを抽出する処理機能抽出手段、
   前記単位プログラムの処理機能の種類、組み合わせ及び配置の順番と、前記単位プログラムの配置の順番の変更、統合及び廃棄を示す統廃合処理との対応関係を予め設定した第２ルールに従い、前記ソースプログラムにおける前記単位プログラムの配置順の変更、統合及び廃棄の統廃合処理を行い、統廃合処理の結果として得られた単位プログラムを物理モデルとして出力する処理機能統廃合手段、
   として機能させるためのプログラム。

Images