(57)【要約】【課題】プログラム資産内で自立した部品を適切に分類することを課題とする。【解決手段】分析装置は、複数のプログラムと複数のデータを含むプログラム資産における複数のプログラム間の呼出関係に基づいて、複数のプログラムを各プログラム群に分類し、各プログラム群に含まれるプログラムがアクセスするデータを基に、各プログラム群とデータとを関連付ける複数のサービス部品候補を生成する。分析装置は、複数のサービス部品候補に関連付けられるデータのうち、他のサービス部品候補から更新されるデータを共通データとして抽出し、共通データを除く複数のサービス部品候補および共通データを、プログラム資産のサービス部品として生成する。【選択図】図２
2018181005.tif 000002
【特許請求の範囲】
【請求項１】
複数のプログラムと複数のデータを含むプログラム資産における前記複数のプログラム間の呼出関係に基づいて、前記複数のプログラムを各プログラム群に分類する分類部と、
前記各プログラム群に含まれるプログラムがアクセスするデータを基に、前記各プログラム群とデータとを関連付ける複数のサービス部品候補を生成する候補生成部と、
前記複数のサービス部品候補に関連付けられるデータのうち、他のサービス部品候補から更新されるデータを共通データとして抽出し、前記共通データを除く前記複数のサービス部品候補および前記共通データを、前記プログラム資産のサービス部品として生成する部品生成部と
を有することを特徴とするプログラム分析装置。
【請求項２】
前記部品生成部は、前記複数のサービス部品候補に関連付けられるデータのうち、当該データが含まれるサービス部品候補内のプログラム群および他のサービス部品候補内のプログラム群から参照のみされるデータを前記共通データとして抽出することを特徴とする請求項１に記載のプログラム分析装置。
【請求項３】
前記部品生成部は、前記共通データが外部に分類された第１のサービス部品候補について、前記第１のサービス部品候補に含まれるプログラム群が前記第１のサービス部品候補に含まれるデータへアクセスしない場合、当該プログラム群を前記第１のサービス部品候補から抽出して、別の第２のサービス部品候補に再分類することを特徴とする請求項１または２に記載のプログラム分析装置。
【請求項４】
前記候補生成部は、前記データに参照するプログラム群よりも、前記データを更新するプログラム群の方が強い関係性があると判定して、前記各プログラム群とデータとを関連付ける複数のサービス部品候補を生成することを特徴とする請求項１から３のいずれか一つに記載のプログラム分析装置。
【請求項５】
コンピュータが
複数のプログラムと複数のデータを含むプログラム資産における前記複数のプログラム間の呼出関係に基づいて、前記複数のプログラムを各プログラム群に分類し、
前記各プログラム群に含まれるプログラムがアクセスするデータを基に、前記各プログラム群とデータとを関連付ける複数のサービス部品候補を生成し、
前記複数のサービス部品候補に関連付けられるデータのうち、他のサービス部品候補から更新されるデータを共通データとして抽出し、前記共通データを除く前記複数のサービス部品候補および前記共通データを、前記プログラム資産のサービス部品として生成すると
処理を実行することを特徴とするプログラム分析方法。
【請求項６】
コンピュータに
複数のプログラムと複数のデータを含むプログラム資産における前記複数のプログラム間の呼出関係に基づいて、前記複数のプログラムを各プログラム群に分類し、
前記各プログラム群に含まれるプログラムがアクセスするデータを基に、前記各プログラム群とデータとを関連付ける複数のサービス部品候補を生成し、
前記複数のサービス部品候補に関連付けられるデータのうち、他のサービス部品候補から更新されるデータを共通データとして抽出し、前記共通データを除く前記複数のサービス部品候補および前記共通データを、前記プログラム資産のサービス部品として生成すると
処理を実行させることを特徴とする分析プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラム分析装置、プログラム分析方法および分析プログラムに関する。
【背景技術】
【０００２】
従来から、コンピュータシステムの発達により、世の中の様々な場面でコンピュータシステムが活用されている。一度構築したコンピュータシステムでも歳月を経ることで、改良を行う必要性あるいはシステム全体を見直す必要性が生じることがある。このとき、既に作成したプログラムの一部に修正を行うことがあり、既存のシステムの仕様を理解する必要がある。しかし、ソフトウェアは大規模になるとその仕様は複雑なものとなり、仕様の把握や変更は容易ではない。また、膨大なプログラムを対象とした時、プログラム間の関係やデータとの関係数も膨大になるため、全ての関係を基にソフトウェアを分割することは容易ではない。
【０００３】
近年では、大規模システムを対象に、ソフトウェアなどの要素を理解可能な部分集合（サービス部品）に分割する技術として、プログラムの呼び出し関係から、自動的に部分集合を抽出する技術が知られている。例えば、部分集合が意味する役割を表すための本筋となる重要なエンティティとエンティティ間の依存関係とがその部分集合に含まれること、ソフトウェアの本筋の理解の妨げとなる枝葉末節のエンティティやエンティティ間の依存関係がその部分集合を形成する際に軽視されることを要件として部分集合が抽出される。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１３−１４８９８７号公報
【特許文献２】特開２００５−１７３６４５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記技術では、他のサービス部品にも含めることのできる要素が特定のサービス部品に含まれる形で分類されるので、サービス部品間の関係性を正確に表した分類ができない場合がある。具体的には、サービス部品内部の要素であるデータに対して、サービス部品外部の処理との強い関係が残ったままの部品単位が抽出されてしまうことで、サービスを提供する自立した部品として抽出できない。
【０００６】
例えば、上記技術は、一見軽視されるようなエンティティであっても、分割されたグループを特徴付けるようなエンティティならば、当該グループに包含させるように、ソフトウェア分割を実行する。このように、他の関係との相対的な比較によって、グループ化するかを判断しているので、分割された部分集合に含まれるデータを外部から更新する処理が残っている場合がある。
【０００７】
一つの側面では、プログラム資産内で自立した部品を適切に分類することができるプログラム分析装置、プログラム分析方法および分析プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
第１の案では、プログラム分析装置は、複数のプログラムと複数のデータを含むプログラム資産における前記複数のプログラム間の呼出関係に基づいて、前記複数のプログラムを各プログラム群に分類する分類部を有する。プログラム分析装置は、前記各プログラム群に含まれるプログラムがアクセスするデータを基に、前記各プログラム群とデータとを関連付ける複数のサービス部品候補を生成する候補生成部を有する。プログラム解析装置は、前記複数のサービス部品候補に関連付けられるデータのうち、他のサービス部品候補から更新されるデータを共通データとして抽出し、前記共通データを除く前記複数のサービス部品候補および前記共通データを、前記プログラム資産のサービス部品として生成する部品生成部を有する。
【発明の効果】
【０００９】
一つの側面では、プログラム資産内で他の部品との関係性が小さい部品を適切に分類することができる。
【図面の簡単な説明】
【００１０】
【図１】図１は、実施例１にかかる分析装置を説明する図である。
【図２】図２は、実施例１にかかる分析装置の機能構成を示す機能ブロック図である。
【図３】図３は、プログラム資産ＤＢに記憶されるプログラム全体の例を示す図である。
【図４】図４は、プログラムの呼出構造および分類を説明する図である。
【図５】図５は、サービス部品候補の生成を説明する図である。
【図６】図６は、サービス部品候補の生成結果を示す図である。
【図７】図７は、サービス部品の生成結果を説明する図である。
【図８】図８は、全体的な処理の流れを示すフローチャートである。
【図９】図９は、解析処理の流れを示すフローチャートである。
【図１０】図１０は、共通データ抽出処理の流れを示すフローチャートである。
【図１１】図１１は、従来との比較を説明する図である。
【図１２】図１２は、起点情報が外部から指定されているときの分類を説明する図である。
【図１３】図１３は、サービス部品候補の再分類例を説明する図である。
【図１４】図１４は、ハードウェア構成例を示す図である。
【発明を実施するための形態】
【００１１】
以下に、本願の開示するプログラム分析装置、プログラム分析方法および分析プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。また、各実施例は、矛盾のない範囲内で適宜組み合わせることができる。
【実施例１】
【００１２】
［分析装置の説明］
図１は、実施例１にかかる分析装置を説明する図である。分析装置１０は、複数のプログラムと複数のデータとを含むプログラム資産に対して疎結合分析を実行する。つまり、分析装置１０は、プログラム資産の内部構造の把握と機能やデータをサービスとして切出しやすい形への再構造化を行う。
【００１３】
一般的に、あるシステムへ適用されたプログラム資産は、システムの改変、増築、ネットワークなどの周辺環境の変化に伴い、更新されていく。つまり、システムが長年使用されることにより、プログラム資産へプログラムやデータベースなどの部品（要素）の追加、プログラム資産内の部品の変更などが経年的に実行される。このように経年的に更新されるプログラム資産は、複数人によって更新されることから、正確な管理資料（更新資料）などがないことも珍しくない。このため、リバースエンジニアリングやプログラム構造の分析などを行う場合に、プログラム資産の全体を参照して、プログラム資産内に部品が他の部品とどのように関係しているのか、ある部品を更新するとどの部品に影響を与えるのかを分析して把握することは、システムエンジニアやプログラマーであっても簡単ではない。
【００１４】
このような場合に、分析装置１０は、プログラム資産における複数のプログラム間の呼出関係に基づいて、複数のプログラムを各プログラム群に分類する。続いて、分析装置１０は、各プログラム群に含まれるプログラムがアクセスするデータを基に、各プログラム群とデータとを関連付ける複数のサービス部品候補を生成する。そして、分析装置１０は、複数のサービス部品候補に関連付けられるデータのうち、他のサービス部品候補から更新されるデータを共通データとして抽出し、共通データを含まない複数のサービス部品候補および共通データを、プログラム資産のサービス部品（処理）として生成する。
【００１５】
つまり、分析装置１０は、プログラムとデータにそれぞれ異なるアプローチで部品化する。ここで想定するプログラムは、ライブラリのようにコピーして利用できるものとして複製を認めるのに対し、データは、具体的な値を内部に持つので、データは一か所に配置するようにして部品化する。分析装置１０は、ソフトウェア分割技術等のクラスタリング技術を使って部品化を実行して、部品とするプログラムやデータを定義した後、部品の外部から更新されるデータ、および更新がないデータだが、複数の部品から参照されるデータは、外部に「共通データ」として定義し、「共通データ」を除いた上で、互いに疎な関係である部品を定義する。
【００１６】
具体的には、図１に示すように、分析装置１０は、プログラムＡからＦと、データＡと、データＢとから構成されるプログラム資産において、プログラムの呼出関係から、プログラムＡ、Ｂ、Ｃ、Ｄを含むプログラム群Ａと、プログラムＥ、Ｄ、Ｆを含むプログラム群Ｅとを生成する。また、分析装置１０は、プログラム群に含まれるプログラムが参照または更新するデータを特定することで、各プログラム群と各データとの関係を特定する。そして、分析装置１０は、分類した各プログラム群と各データとの関係性を示す情報を出力する。
【００１７】
この結果、分析装置１０は、外部から更新されるデータを外部に「共通データ」として定義し、「共通データ」を除いたことで、新たに切り出しの単位を定義することで、自立した「部品」の要素として抽出できるので、プログラム資産内で他の部品との関係性が小さい部品を適切に分類することができる。
【００１８】
［機能構成］
図２は、実施例１にかかる分析装置１０の機能構成を示す機能ブロック図である。図２に示すように、分析装置１０は、通信部１１、記憶部１２、制御部２０を有する。
【００１９】
通信部１１は、他の装置との間の通信を制御する処理部であり、例えば通信インタフェースなどである。例えば、通信部１１は、管理者端末から、処理開始の指示や分析対象のプログラム資産の入力を受け付ける。また、通信部１１は、管理者端末などに、分析結果を送信する。
【００２０】
記憶部１２は、プログラムやデータを記憶する記憶装置の一例であり、例えばメモリやハードディスクなどである。この記憶部１２は、プログラム資産ＤＢ１３と分析結果ＤＢ１４を記憶する。
【００２１】
プログラム資産ＤＢ１３は、分析対象のプログラム資産を記憶するデータベースである。ここで記憶されるプログラム資産は、管理者等によって格納される。図３は、プログラム資産ＤＢ１３に記憶されるプログラム全体の例を示す図である。図３に示すように、プログラム資産は、プログラムＡ、プログラムＢ、プログラムＣ、プログラムＤ、プログラムＥ、プログラムＦを含む。図３は、６つのプログラムの記述例を模式的に示した例で、プログラム呼出部分およびデータアクセスのみを記述している。
【００２２】
図３に示すように、プログラムＡは、プログラムＢおよびプログラムＤを呼び出して処理を実行する。同様に、プログラムＢは、プログラムＣを呼び出し、プログラムＣは、データＡを読み込むあるいは参照する処理する。プログラムＤは、プログラムＦを呼び出し、データＢに書き出す。プログラムＥは、プログラムＤを呼び出し、プログラムＦは、呼び出し関係やデータ参照関係がない。なお、図３に示すプログラム資産は、本実施例で分析対象とするプログラム資産の一部であり、図示しない他のプログラムも含む。
【００２３】
分析結果ＤＢ１４は、後述する制御部２０によるプログラム資産の分析結果を記憶するデータベースである。例えば、分析結果ＤＢ１４は、プログラム資産を示す識別子、分析結果、分析日時などを対応付けて記憶する。
【００２４】
制御部２０は、分析装置１０全体を司る処理部であり、例えばプロセッサなどである。この制御部２０は、分類部２１、候補生成部２２、分析部２３を有する。なお、分類部２１、候補生成部２２、分析部２３は、プロセッサが有する電子回路の一例やプロセッサが実行するプロセスの一例などである。
【００２５】
分類部２１は、プログラム資産内のプログラム間の呼出関係に基づいて、プログラムを各プログラム群に分類する処理部である。具体的には、分類部２１は、プログラム資産を入力として、プログラムの呼び出し関係およびプログラムとデータの関係を取得する。分類部２１は、一つの処理が実行されるときに関係するプログラムを取得する。分類部２１は、プログラム内でどこからも呼び出されていないものを起点として決定し、起点のプログラムから呼び出し関係を追跡して、処理で関係するプログラムとからプログラムの呼び出し構造全体を作成し、「プログラム群」として定義する。その後、分類部２１は、プログラムとデータの関係から、プログラム群とデータの関係を作成する。
【００２６】
例えば、分類部２１は、図３に示すプログラム資産に対して、プログラムの呼出構造を作成する。プログラムの呼出構造は、プログラムの起点を決定するところから決定する。分類部２１は、プログラムＡについて、他のプログラムから呼び出されていないため起点として取得し、プログラムＢについては、プログラムＡから呼び出されるため他のプログラムから呼び出されるものとなり、起点ではないとする。同様に、分類部２１は、プログラムＣについては、プログラムＢから呼ばれるため、起点ではないと判定し、プログラムＤについては、プログラムＡから呼ばれるため起点ではないと判定する。しかし、分類部２１は、プログラムＥについては、他のプログラムから呼んでいるものがないため、起点と判定する。また、分類部２１は、プログラムＦについて、プログラムＤから呼び出されるため、起点ではないと判定する。この結果、分類部２１は、プログラムＡとプログラムＥを起点と特定する。
【００２７】
続いて、分類部２１は、プログラムＡを起点に呼出構造を作成する。プログラムＡは、プログラムＢとプログラムＤを呼び出す。プログラムＢはプログラムＣを呼び出し、プログラムＤは、プログラムＦを呼び出す。このことから、プログラムＡは、プログラムＢ、Ｃ、Ｄ、Ｆと合わせて呼び出し構造を保持すると判定できる。したがって、分類部２１は、プログラムＡを起点として、プログラムＡから追跡できるプログラムＢ、プログラムＣ、プログラムＤ、プログラムＦをプログラム群Ａに分類する。
【００２８】
同様に、プログラムＥは、プログラムＤを呼び出し、プログラムＤは、プログラムＦを呼び出すので、プログラムＥは、プログラムＤ、Ｆと合わせて呼び出し構造を保持すると判定できる。したがって、分類部２１は、プログラムＥを起点として、プログラムＥから追跡できるプログラムＤ、プログラムＦをプログラム群Ｅに分類する。
【００２９】
続いて、分類部２１は、各プログラム群がアクセスするデータを対応付ける。具体的には、プログラムＣは、データＡを参照し、プログラムＤは、データＢを更新し、プログラムＣおよびプログラムＤはプログラム群Ａの一部である。このため、分類部２１は、プログラム群ＡがデータＡを参照しデータＢを更新するという関係を定義する。また、分類部２１は、プログラム群Ｅに対しては、プログラムＤのみを内部に含むので、データＢを更新する関係のみを定義する。
【００３０】
これらの結果を図４に示す。図４は、プログラムの呼出構造および分類を説明する図である。分類部２１は、図４の（ａ）に示す呼出関係を基に、図４の（ｂ）に示すように、プログラム群ＡがデータＡを参照しデータＢを更新する関係、プログラム群ＥがデータＢを更新する関係を生成して、記憶部１２や候補生成部２２に出力する。なお、出力形式は、これに限定されず、出力先のツール等にあわせて様々な形式を採用できる。例えば、図４の（ｃ）に示すように、カンマ区切りで関係形成を定義し、プログラム群とデータおよび参照関係を＃read、更新関係を＃writeと言う形で追記することで関係を記述することもできる。例えば、図４の（ｃ）の１行目は、プログラム群ＡがデータＡを参照（read）していることを記述している。
【００３１】
候補生成部２２は、分類部２１によって分類された各プログラム群とデータとの関係性から、プログラム群とデータの関係で特に近いものをグループ化した部分集合であるサービス部品候補を生成する処理部である。具体的には、候補生成部２２は、特開２０１３−１４８９８７号公報などのクラスタリング技術を用いて、サービス部品候補を生成する。この技術では、部分集合が意味する役割を表すための本筋となる重要なエンティティとエンティティ間の依存関係とが、その部分集合に含まれることとし、ソフトウェアの本筋の理解の妨げとなる枝葉末節のエンティティやエンティティ間の依存関係が、その部分集合を形成する際に軽視されることとする。重要か枝葉末節かの判断は、依存関係の数で判断される。
【００３２】
例えば、候補生成部２２は、各データへの入力数が多いほど関係性が強いと判断して、関係性が強いプログラム群とデータとを同一グループとなるように、サービス部品候補を生成することもできる。また、候補生成部２２は、例えばWriteの場合は２倍にするなど、各入力数のうちReadよりもWriteの重みを大きくして、関係性を判断して、サービス部品候補を生成することもできる。
【００３３】
ここで、分類部２１から出力された結果が図５に示す場合を例にして説明する。図５は、サービス部品候補の生成を説明する図である。この例では、図５に示すように、候補生成部２２に、プログラム群Ａ、プログラム群Ｅ、データＡ、データＢと合わせて、プログラム群１、プログラム群２、データＣ、データＤの関係もあるものが入力されたとする。
【００３４】
そして、候補生成部２２は、式（１）を用いて、各プログラム群とデータとの関係性を生成する。なお、式（１）におけるＥ（Ａ，Ｂ）は、エンティティＡからエンティティＢへの依存関係の本質度（重み）であり、ｄ＿ｉｎ（Ｂ）は、エンティティＢへの入次数であり、ｎは、データが参照の場合は２、データが更新の場合は１とする。
【００３５】
【数１】
2018181005.tif 000003
【００３６】
すなわち、多くのプログラムから読み出されているデータは関係が弱いと判断されるとともに、データを更新プログラムと更新されるデータとの関係は強いと判断されて、多くのプログラムからアクセスされるデータは、いずれかの部分集合（サービス部品候補）に含まれる形で出力される。例えば、プログラム群Ａおよびプログラム群Ｅは、データＢを更新することから、他のデータと比べてデータＢとの関係性が強く、プログラム群１は、データＡを更新するが他のデータへのアクセスも多いことから、各データとの関係性がそこまで強くなく、プログラム群２は、データＤを更新することから他のデータと比べてデータＤとの関係性が強いなどと判断される。
【００３７】
そして、候補生成部２２によってクラスタリングされた結果を図６に示す。図６は、サービス部品候補の生成結果を示す図である。図６に示すように、候補生成部２２は、プログラム群Ａとプログラム群ＥとデータＡとデータＢとを含むサービス部品候補（ＩＤ＝１）、プログラム群１とデータＣとを含むサービス部品候補（ＩＤ＝２）、プログラム群２とデータＤを含むービス部品候補（ＩＤ＝３）の３つのサービス部品候補を生成する。また、候補生成部２２は、サービス部品候補ＩＤと部品とを対応付けた一覧として、「（１，プログラム群Ａ）、（１，データＡ）、（１，データＢ）、（１，プログラム群Ｅ）、（２，データＣ）、（２，プログラム群１）、（３，データＤ）、（３，プログラム群２）」なども生成できる。その後、候補生成部２２は、生成したサービス部品候補を記憶部や分析部２３に出力する。
【００３８】
分析部２３は、複数のサービス部品候補に関連付けられるデータのうち、他のサービス部品候補から更新されるデータを共通データとして抽出し、共通データを含まない複数のサービス部品候補および共通データを、プログラム資産のサービス部品として生成する処理部である。また、分析部２３は、複数のサービス部品候補に関連付けられるデータのうち、当該データが含まれるサービス部品候補内のプログラム群および他のサービス部品候補内のプログラム群から更新されないデータを共通データとして抽出する処理部である。すなわち、分析部２３は、得られたサービス部品候補とプログラム群とデータの参照・更新関係を入力として、共通データと最終的なサービス部品を出力する。
【００３９】
図６を例にして具体的に説明する。まず、分析部２３は、サービス部品候補を取得し、サービス候補部品内部のデータに対する更新処理を取得する。例えば、分析部２３は、サービス部品候補（ＩＤ＝１）の内部のデータを取得して、データＡとデータＢを検出し、データＡがプログラム群Ａ、プログラム群Ｅ、プログラム群１から更新されることを特定する。このとき、分析部２３は、プログラム群Ａおよびプログラム群ＥがデータＡと同じサービス部品内部の処理であるが、プログラム群１が他のサービス部品候補であるサービス部品候補（ＩＤ＝２）の内部に含まれる処理であると特定する。したがって、分析部２３は、データＡが外部から更新されるデータと判定して共通データに分類し、サービス部品候補（ＩＤ＝１）の外部に定義する。ここで、データＡは、各サービス部品候補から更新されるデータであることから、グローバルアクセスデータと定義される。
【００４０】
次に、分析部２３は、サービス部品候補（ＩＤ＝１）に他にデータがないかを調査し、サービス部品候補（ＩＤ＝１）にはデータＢが内部に含まれているのでデータＢへの参照や更新関係を調査する。例えば、分析部２３は、データＢについて、プログラム群Ａおよびプログラム群Ｅから更新されるが、他の処理（サービス部品候補）からの更新はない。また、分析部２３は、プログラム群Ａとプログラム群Ｅはいずれもサービス部品候補（ＩＤ＝１）内部の処理であり、データＢに対する外部からのアクセスがない。また、分析部２１は、このデータＢに対しては参照のみではないため、外部に出すデータには該当しないと判定する。
【００４１】
したがって、分析部２３は、サービス部品候補（ＩＤ＝１）に対しては、データＡのみ、共通データとして外部に定義する。なお、分析部２３は、データＡがサービス部品候補（ＩＤ＝１）のデータではなくなったことで、サービス部品候補（ＩＤ＝１の内部で関係がなくなるかどうかを確認する。ここでは、分析部２３は、プログラム群Ａとプログラム群ＥとデータＢが要素として残っているが、プログラム群ＡとＥはいずれもデータＢと更新関係にあるため、３つの要素は関連があると言えるので、残りのサービス部品を分割しいと判断する。
【００４２】
続いて、分析部２３は、サービス部品候補（ＩＤ＝２）について調査する。分析部２３は、サービス部品候補（ＩＤ＝２）内にデータＣを検出し、データＣに対するプログラム群からのアクセスを調査する。ここで、分析部２３は、データＣに対して、プログラム群Ｅおよびプログラム群１から参照のみされ、プログラム群Ｅが外部のサービス部品候補であることを特定する。この結果、分析部２３は、データＣを共通データとして外部に定義する。ここで、データＣは、各サービス部品候補から参照のみが実行されるデータであることから、マスターデータと定義される。その後、分析部２３は、サービス部品候補（ＩＤ＝２）に残った要素がプログラム群１のみであるので、プログラム群１のみでサービス部品候補（ＩＤ＝２）を定義する。
【００４３】
最後に、分析部２３は、サービス部品候補（ＩＤ＝３）に対して各データを調査する。分析部２３は、サービス部品候補（ＩＤ＝３）内にデータＤを検出する。そして、分析部２３は、データＤがプログラム群２から更新され、プログラム群１から参照されることを特定する。さらに、分析部２３は、プログラム群２とデータＤとが同じサービス部品候補（ＩＤ＝３）内部の要素であるため、外部からの更新はなく、プログラム群２のみがデータＤを更新するため、外部からの更新もないと判定する。また、分析部２３は、データＤに対して更新処理があるので、参照処理のみではないと判定する。したがって、分析部２３は、データＤを共通データに分類しないと決定する。
【００４４】
上述した処理によって生成された結果を図７に示す。図７は、サービス部品の生成結果を説明する図である。図７に示すように、分析部２３は、サービス部品候補（ＩＤ＝１）に含まれていたデータＡについて、外部のサービス部品候補（ＩＤ＝２）のプログラム群１からも更新されることから、共通データとして外部に分類し直す。同様に、分析部２３は、サービス部品候補（ＩＤ＝２）に含まれていたデータＢについて、外部のサービス部品候補（ＩＤ＝１）のプログラム群Ｅからも参照されることから、共通データとして外部に分類し直す。
【００４５】
この結果、分析部２３は、「サービス部品ＩＤ，部品名」として「１，プログラム群Ａ」、「１，データＢ」、「１，プログラム群Ｅ」、「２，プログラム群１」、「３，データＤ」、「３，プログラム群２」を生成する。また、分析部２３は、「共通データＩＤ，部品名」として「ｃ１，データＡ」と「ｃ２，データＢ」を生成する。そして、分析部２３は、生成したサービス部品および共通データを分析結果ＤＢ１４に格納する。
【００４６】
［全体処理の流れ］
図８は、全体的な処理の流れを示すフローチャートである。図８に示すように、分析装置１０は、解析処理を実行し（Ｓ１０１）、解析処理による解析結果に基づいてプログラム群とデータの関係性を生成する（Ｓ１０２）。
【００４７】
続いて、分析装置１０は、分割処理を実行して（Ｓ１０３）、分割処理の結果に基づいてサービス部品候補を抽出する（Ｓ１０４）。なお、分割処理は、特開２０１３−１４８９８７号公報などのクラスタリング技術などを用いた公知の処理なので、詳細な説明は省略する。
【００４８】
その後、分析装置１０は、サービス部品候補を解析して共通データの抽出処理を実行し（Ｓ１０５）、抽出結果に基づいて、サービス部品と共通データを生成する（Ｓ１０６）。
【００４９】
［解析処理の流れ］
次に、図８のＳ１０１で実行される解析処理について説明する。図９は、解析処理の流れを示すフローチャートである。図９に示すように、分類部２１は、プログラムの呼出関係を取得する（Ｓ２０１）。例えば、分類部２１は、各プログラムのソースコードを参照し、ＣＡＬＬ文などの他のプログラムを呼び出す命令を検索して、プログラムの呼出関係を取得する。
【００５０】
そして、分類部２１は、どのプログラムからも呼び出されていないプログラムを取得し（Ｓ２０２）、呼び出されていないプログラムを起点として定義する（Ｓ２０３）。
【００５１】
続いて、分類部２１は、起点から呼出構造を取得し（Ｓ２０４）、全ての起点に対して呼出構造を生成する（Ｓ２０５）。そして、分類部２１は、全ての起点に対して呼出構造を生成するまで（Ｓ２０５：Ｎｏ）、Ｓ２０４以降を繰り返す。
【００５２】
そして、分類部２１は、全ての起点に対して呼出構造を生成すると（Ｓ２０５：Ｙｅｓ）、プログラムがアクセスするデータを取得する（Ｓ２０６）。続いて、分類部２１は、プログラム群内にデータにアクセスするプログラムがあるか否かを判定する（Ｓ２０７）。
【００５３】
ここで、分類部２１は、プログラム群内にデータにアクセスするプログラムがある場合（Ｓ２０７：Ｙｅｓ）、プログラム群とデータの関係を定義し（Ｓ２０８）、すべてのプログラム群に対してデータを確認したか否かを判定する（Ｓ２０９）。なお、分類部２１は、プログラム群内にデータにアクセスするプログラムがない場合（Ｓ２０７：Ｎｏ）、Ｓ２０８を実行することなく、Ｓ２０９を実行する。
【００５４】
そして、分類部２１は、すべてのプログラム群に対してデータを確認した場合（Ｓ２０９：Ｙｅｓ）、すべてのデータに対してプログラムとの関係を確認したか否かを判定する（Ｓ２１０）。
【００５５】
ここで、分類部２１は、すべてのデータに対してプログラムとの関係を確認すると（Ｓ２１０：Ｙｅｓ）、プログラム群とデータの関係を候補生成部２２等に出力する（Ｓ２１１）。なお、Ｓ２０９において、分類部２１は、データとの関係を確認していないプログラム群がある場合（Ｓ２０９：Ｎｏ）、Ｓ２０７以降を繰り返す。同様に、Ｓ２１０において、分類部２１は、プログラムとの関係を確認していないデータがある場合（Ｓ２１０：Ｎｏ）、Ｓ２０６以降を繰り返す。
【００５６】
［共通データ抽出処理の流れ］
次に、図８のＳ１０５で実行される解析処理について説明する。図１０は、共通データ抽出処理の流れを示すフローチャートである。図１０に示すように、分析部２３は、サービス部品候補を取得し（Ｓ３０１）、サービス部品候補内のデータへの更新処理を取得する（Ｓ３０２）。例えば、分析部２３は、サービス部品候補内の各データに対して、更新を行うプログラム群があるかないかを検出する。
【００５７】
そして、分析部２３は、サービス部品候補内のデータが外部のサービス部品候補から更新されない場合（Ｓ３０３：Ｎｏ）、サービス部品候補内のデータへの参照処理を取得する（Ｓ３０４）。例えば、分析部２３は、サービス部品候補内の各データに対して、参照を行うプログラム群があるかないかを検出する。
【００５８】
ここで、分析部２３は、サービス部品候補内のデータを参照するのみかつ部品外部から参照のみのデータがある場合（Ｓ３０５：Ｙｅｓ）、該当のデータを共通データとして外部に定義する（Ｓ３０６）。
【００５９】
一方、Ｓ３０３において、分析部２３は、サービス部品候補内のデータが外部のサービス部品候補から更新される場合（Ｓ３０３：Ｙｅｓ）、該当のデータを共通データとして外部に定義する（Ｓ３０７）。
【００６０】
そして、サービス部品候補内のデータを参照するのみかつ部品外部から参照のみされるデータに該当するデータがない場合（Ｓ３０５：Ｎｏ）、または、Ｓ３０６が実行された後、または、Ｓ３０７が実行された後、分析部２３は、サービス部品候補内の全てのデータの関係を取得したか否かを判定する（Ｓ３０８）。
【００６１】
ここで、分析部２３は、サービス部品候補内で未判定のデータが存在する場合（Ｓ３０８：Ｎｏ）、Ｓ３０２以降を繰り返す。一方で、分析部２３は、サービス部品候補内で未判定のデータが存在しない場合、すなわち、サービス部品候補内の全てのデータの関係を取得した場合（Ｓ３０８：Ｙｅｓ）、サービス部品候補内で関係がないものが存在するか否かを判定する（Ｓ３０９）。
【００６２】
ここで、分析部２３は、サービス部品候補内で関係がないものが存在する場合（Ｓ３０９：Ｙｅｓ）、関係がある範囲で部品を分割する（Ｓ３１０）。その後、分析部２３は、全てのサービス部品を取得した場合、すなわち、サービス候補部品に分類された各部品についての判定が終了した場合（Ｓ３１１：Ｙｅｓ）、得られたサービス部品および共通データを出力する（Ｓ３１２）。
【００６３】
なお、分析部２３は、未判定のサービス部品が存在する場合（Ｓ３１１：Ｎｏ）、Ｓ３０１以降を繰り返す。また、Ｓ３０９において、分析部２３は、サービス部品候補内で関係がないものが存在しない場合（Ｓ３０９：Ｎｏ）、Ｓ３１０を実行することなく、Ｓ３１１を実行する。
【００６４】
［効果］
上述したように、分析装置１０は、部分的にシステムを切り出した部品間で、共通に使われる「共通データ」を自動的に抽出できる。このことで、共通データが自動的に明確になり、共通サービスの中心となるデータが定義できる。従来技術では、外部からデータを更新される関係等が残ってしまい、他の部品との強い関係が残ったままの部品が抽出されてしまうことでサービスを提供する自立した「部品」の要素として抽出できない。また、従来技術では、あらかじめ、omnipresent  module（多くの箇所からアクセスされるモジュール）を除外してから、クラスタリングすることや重みづけすることを推奨しているが、これを実現するためには多くの調査作業が発生するので、現実的ではない。
【００６５】
図１１は、従来との比較を説明する図である。図１１ではプログラムをＰ、データをＤで表すこととする。従来手法では、各要素（部品）がいずれかのサービス部品に分類されるので、図１１の（ａ）に示すように、他のサービス部品であるＰ１、Ｐ２、Ｐ３、Ｐ４からアクセスされるＤ３がサービス部品（ＩＤ＝３）に分類される。つまり、データの更新を行う処理は、データの内容・状態を変更する処理で影響が大きいので、データに対して大きな影響を与える「データに対するオーナー」と言える。したがって、Ｄ３は、どこかに分類されずに、自立した１つの部品として定義される方が好ましい。
【００６６】
一方で、図１１の（ｂ）に示すように、実施例１による手法では、Ｄ３は、他のサービス部品であるＰ１、Ｐ２、Ｐ３、Ｐ４からアクセスされることから、サービス部品（ＩＤ＝３）の外部に定義される。この結果、Ｄ３についても、自立した１つの部品として定義することができる。つまり、分析装置１０は、データを中心にして関係するプログラム群をクラスタリングし、活用したい機能やデータの影響範囲を分析して疎結合化を支援することができる。
【００６７】
このように、分析装置１０は、部分的にシステムを切り出した単位間で、共通に使われる「共通データ」を自動的に抽出できる。したがって、従来では、サービス部品の要素に分類されていたマスターデータやログデータ等を、１つの部品として抽出することができる。また、同時に外部からデータを更新されることがないサービスの候補（サービス部品）を提示できるため、実際にシステムを切り出す上で参考となる部品で表されるプログラム群とデータの部分集合を取得できる。
【実施例２】
【００６８】
ところで、実施例１では、プログラム構造から起点となるプログラムを探索する例を説明したが、これに限定されるものではない。例えば、管理者等によって起点情報を外部から指定することもできる。
【００６９】
図１２は、起点情報が外部から指定されているときの分類を説明する図である。図１２に示すように、分析装置１０は、図４の（ａ）と同様のプログラム構造を有する状態で、起点情報として「プログラムＢ，プログラムＤ」が指定された場合、指定された起点から呼出構造を追跡することができる。
【００７０】
図１２の例では、分析装置１０は、プログラムＢを起点として呼出構造を追跡することで、プログラムＢ、プログラムＣおよびデータＡへの参照で１つの処理と判定することができる。したがって、分析装置１０は、プログラムＢおよびプログラムＣをプログラム群Ｂとして定義し、プログラム群ＢがデータＡを参照する関係が得られる。
【００７１】
また、分析装置１０は、プログラムＤを起点として呼出構造を追跡することで、プログラムＤ、プログラムＦおよびデータＢへの参照で１つの処理と判定することができる。したがって、分析装置１０は、プログラムＤおよびプログラムＦをプログラム群Ｄとして定義し、プログラム群ＤがデータＢを参照する関係が得られる。
【００７２】
このようにすることで、プログラム資産のすべてではなく一部を解析した場合に、起点以降のプログラム構造およびデータとの関係性を抽出することができる。したがって、管理者による解析範囲の設定が可能となり、利便性が向上する。
【実施例３】
【００７３】
ところで、実施例１では、共通データをプログラム群が分離する例を説明したが、これに限定されるものではない。例えば、共通データが分離されたプログラム群について再分類を実行することもできる。
【００７４】
図１３は、サービス部品候補の再分類例を説明する図である。図１３の（ａ）に示すように、この例では、サービス部品候補としては、プログラム群１０とプログラム群２０とプログラム群３０とデータＡＡとデータＢＢを含むサービス部品候補（Ｘ）と、プログラム群４０とプログラム群５０とデータＣＣを含むサービス部品候補（Ｙ）の２つが得られているとする。
【００７５】
そして、分析部２３は、ここで得られたサービス部品候補に対して、共通データおよびサービス部品を調査する。まず、分析部２３は、サービス部品候補として１つ目のサービス部品候補（Ｘ）を調査する。このサービス部品候補（Ｘ）には、データＡＡ、データＢＢが存在する。データＡＡは、プログラム群１０、プログラム群２０、プログラム群３０、プログラム群４０の４つからアクセスされていて、プログラム群２０を除く３つから更新される。また、プログラム群４０は、データＡＡとは異なるサービス部品候補（Ｙ）から更新を実行する。この結果、分析部２３は、データＡＡを共通データとして分類する。また、他のデータとしてデータＢＢに関しては、プログラム群３０が参照するのみで、サービス部品候補（Ｘ）の外部からの参照はない。したがって、分析部２３は、データＢＢを共通データには分類しない。
【００７６】
次に、分析部２３は、データＡＡを共通データとして外部に定義することとした場合、サービス部品候（Ｘ）補内部の関係を確認する。このとき、分析部２３は、サービス部品候補内部（Ｘ）の関係において、データＡＡの関係を除いた上でデータやプログラム群でデータアクセス関係があるかを確認する。例えば、プログラム３０は、データＢＢにアクセスするため、プログラム３０とデータＢＢはアクセス関係があると判定される。
【００７７】
データＡＡを除いた場合、プログラム群１０およびプログラム群２０は、他のデータに対してアクセス関係がない。したがって、サービス部品候補（Ｘ）内部のデータＢＢやプログラム群３０とは関係がない。したがって、分析部２３は、プログラム群１０、プログラム２０、プログラム群３０とデータＢＢの３つの部品に分割する。
【００７８】
なお、対象の部品が分割できるかどうかは、データアクセス関係でつながりがあるかどうかで判断している。この判断にはプログラム群とデータの関係をノードとエッジのグラフと見た場合に到達不可能なノードがないかどうかで判断する方法を利用することが出来る。
【００７９】
次に、分析部２３は、データＣＣを含むサービス部品候補（Ｙ）について、データＣＣは、プログラム群４０とプログラム群５０からアクセスされるだけで共通データではないとして分類する。ここで特に共通データとして外部に出すデータがないため、プログラム群とデータの関係は変化がない。
【００８０】
このようにして得られたサービス部品と共通データを図１３の（ｂ）に示す。分析部２３は、プログラム群１０をサービス部品（Ｘ−１）、プログラム群２０をサービス部品（Ｘ−２）、プログラム群３０およびデータＢＢをサービス部品（Ｘ−３）、プログラム群４０およびプログラム群５０およびデータＣＣをサービス部品（Ｙ）に再分類することができる。したがって、分析装置１０は、共通データを外部に抽出後のサービス部品候補を再分類することができ、関係性の弱い部品を正確に抽出することができる。
【実施例４】
【００８１】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。
【００８２】
［プログラム解析］
上記実施例で説明した呼び出し関係やデータへの読み出し関係を取得する手法としては、パーサなどの公知のプログラム解析技術を採用することができる。
【００８３】
［システム］
記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【００８４】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【００８５】
［ハードウェア構成］
図１４は、ハードウェア構成例を示す図である。図１４に示すように、分析装置１０は、通信インタフェース１０ａ、ＨＤＤ（Hard  Disk  Drive）１０ｂ、メモリ１０ｃ、プロセッサ１０ｄを有する。
【００８６】
通信インタフェース１０ａは、他の装置の通信を制御するネットワークインタフェースカードなどである。ＨＤＤ１０ｂは、プログラムやデータなどを記憶する記憶装置の一例である。
【００８７】
メモリ１０ｃの一例としては、ＳＤＲＡＭ（Synchronous  Dynamic  Random  Access  Memory）等のＲＡＭ（Random  Access  Memory）、ＲＯＭ（Read  Only  Memory）、フラッシュメモリ等が挙げられる。プロセッサ１０ｄの一例としては、ＣＰＵ（Central  Processing  Unit）、ＤＳＰ（Digital  Signal  Processor）、ＦＰＧＡ（Field  Programmable  Gate  Array）、ＰＬＤ（Programmable  Logic  Device）等が挙げられる。
【００８８】
また、分析装置１０は、プログラムを読み出して実行することでプログラム分析方法を実行する情報処理装置として動作する。つまり、分析装置１０は、分類部２１、候補生成部２２、分析部２３と同様の機能を実行するプログラムを実行する。この結果、分析装置１０は、分類部２１、候補生成部２２、分析部２３と同様の機能を実行するプロセスを実行することができる。なお、この他の実施例でいうプログラムは、分析装置１０によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。
【００８９】
このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ（Magneto−Optical  disk）、ＤＶＤ（Digital  Versatile  Disc）などのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することができる。
【符号の説明】
【００９０】
１０  分析装置
１１  通信部
１２  記憶部
１３  プログラム資産ＤＢ
１４  分析結果ＤＢ
２０  制御部
２１  分類部
２２  候補生成部
２３  分析部
【図１】
2018181005.tif 000004
【図２】
2018181005.tif 000005
【図３】
2018181005.tif 000006
【図４】
2018181005.tif 000007
【図５】
2018181005.tif 000008
【図６】
2018181005.tif 000009
【図７】
2018181005.tif 000010
【図８】
2018181005.tif 000011
【図９】
2018181005.tif 000012
【図１０】
2018181005.tif 000013
【図１１】
2018181005.tif 000014
【図１２】
2018181005.tif 000015
【図１３】
2018181005.tif 000016
【図１４】
2018181005.tif 000017