JP5725623B2 - プログラム分析装置及び方法及びプログラム - Google Patents

Description

本発明は、プログラム分析装置及び方法及びプログラムに係り、特に、形式概念分析を適用した情報処理システムを構成する電子計算機向けのプログラムのソースコードのリバースエンジニアリングにおけるプログラム分析装置及び方法及びプログラムに関する。

様々な業務が電子計算機を利用した情報処理システムとして実現されている。これらの情報処理システムの動作は、プログラミング言語を使用したプログラムとして記述されている。プログラム言語で記述されたプログラムはソースコードと呼ばれる。

プログラミング言語は、電子計算機が解釈し実行することを目的としたものであるが、プログラムの保守や機能追加のための開発を実施する場合には、人間が既存のソースコードを読解し、プログラムの構造や処理の内容を理解する必要がある。かかるプログラムを理解するための行為がリバースエンジニアリングである。

リバースエンジニアリングには様々な手法が存在するが、その中に形式概念分析を用いた手法が存在する。

形式概念分析（Formal Concept Analysis）は、数学的な束論（Lattice Theory）を応用した一分野である。オブジェクトの集合Gと、Gに属するオブジェクトが保有する属性の集合Mが有り、どのオブジェクトがどの属性を保有するのかを記述した対応表（形式文脈：Formal Context）が存在する場合に、Gの部分集合であるAとMの部分集合Bについて、Bの要素である属性の全てが、それぞれAの要素であるオブジェクトに保有され、かつAの要素以外のオブジェクトからは保有されない、という規則を満たすAとBの組み合わせ（形式概念：Formal Concept）に分類する方法である。形式概念の分類にあたっては、ある形式概念（A1、B1）と別の形式概念（A2、B2）において、A2がA1の部分集合になっている場合には、B2もB1の部分集合になっており、（A1、B1）と（A2、B2）の間に半順序関係が定義できる。このような順序により関係づけられた形式概念の集合は、束の公理を満たすことから、数学的な束論の手法を適用することが可能になる。形式概念の集合を束として表現したものを、概念束（Concept Latitce）と呼ぶ。意味のわかりにくい形式文脈から、形式概念を抽出し、概念束を形成することで形式概念同士の関係を発見することが形式概念分析と呼ばれる手法である。

係る形式概念分析の手法により、ソースコードに含まれるプログラムの部品を分類することで、プログラムの構造や処理の内容を理解するリバースエンジニアリングを実施することが本発明が属する技術分野である。

当該リバースエンジニアリングを実施することの従来の技術としては、非特許文献１に示す技術が存在する。

当該技術では、プログラムを幾つかのシナリオに沿って起動した場合に、シナリオの起動により実行されるプログラムの部品「モジュール」を特定する。モジュールとは、例えば手続き型言語における手続き（Procedure）や、オブジェクト指向言語におけるメソッド（Method）などである。各々のシナリオをオブジェクトとし、シナリオを起動した場合に実行されるプログラムのモジュールを属性とみなして形式文脈を形成し、形式概念分析の手法を適用することを提案している。すなわち、オブジェクトであるシナリオと、属性であるプログラムモジュールとの間で形式概念を抽出し、概念束を形成することで、プログラムの特徴（Feature）を見つけ出せるとしている。

図１に、従来技術の処理のフローを示す。

ステップ１） プログラムを実行すると、実行されるモジュールが判別できるようなトレース手段を用意する。トレース手段としては例えば、gdb等がある。

ステップ２） プログラムの機能を起動する入力操作の集合（シナリオ）を、プログラムの典型的な機能を網羅するように用意し、実行してトレース群を取得する。ここでシナリオの例としては、登録処理、参照処理、削除処理等がある。

ステップ３） シナリオをオブジェクトとし、実行されるモジュールの出現を「属性」として、形式概念分析の入力である「形式文脈」とする。

ステップ４） 形式概念分析の手法を適用し、「概念束」を得る。ここで、形式概念分析の手法としては、Concept Explorer、Toscana-J等がある。

ステップ５） 概念束のノードに含まれるモジュールより、機能とそれを実現するモジュールを得る。

例えば、図２に示すようなプログラム１に対し、適当なシナリオ（登録、参照、削除）を定義すると、図３に示すような形式文脈が抽出される。これに対し、形式概念分析の手法を適用すると、図４に示す形式概念が抽出され、これに対する概念束を形成すると、図５が得られる。図５の概念束に対し、各ノードの概念間の差分を示す形で表現の変換を行なうと、希薄（sparse）な概念束として図６が得られる。この結果、
シナリオ１だけが有する特徴：｛ｍ_２、ｍ_５｝
シナリオ２だけが有する特徴：｛ｍ_３｝
シナリオ３だけが有する特徴：｛ｍ_４、ｍ_７｝
シナリオ２と３が共通に有する特徴：｛ｍ_６｝
シナリオ１、２、３が共通に有する特徴：｛ｍ_１、ｍ_８、ｍ_９｝
が抽出される。これにより、各モジュールがどのような状況において実行されるかを理解することができる。

Locating features in source code, Eisenbarth, T.; Koschke, R.; Simon, D.; IEEE Transactions on Software Engineering, Volume: 29 , Issue: 3, Digital Object Identifier: 10.1109/TSE.2003.1183929, Publication Year: 2003 , Page(s): 210 - 224

しかしながら、非特許文献１により開示された従来技術では、プログラムを幾つかのシナリオに沿って起動した場合に、シナリオの起動により実行されるプログラムの部品「モジュール」を属性としており、形式概念分析を行なうことにより、モジュールの部分集合が概念として抽出される。

ここで抽出される概念の中では、シナリオの起動により個々のモジュールが実行されることだけしかわからない。例えば、シナリオ１、２、３に共通する特徴：｛ｍ_１、ｍ_８、ｍ_９｝が抽出されるが、特徴を構成する各々の属性であるモジュールのｍ_１、ｍ_８、ｍ_９がどのような関係にあるのかは判らない。このため、形式概念分析の手法を適用する目的である、プログラムの構造や処理の内容の理解に向けては限定的な情報が得られるに留まっている。したがって、抽出された特徴に含まれるモジュールについてそれぞれソースコードを読解し、関係を紐解く必要があった。

本発明は、上記の点に鑑みなされたもので、形式概念分析に得られる特徴から得られる情報をより複雑なものとするとともに、抽出された特徴に関わるソースコード読解の手間を軽減することが可能なプログラム分析装置及び方法及びプログラムを提供することを目的とする。

上記の課題を解決するため、本発明のプログラムの構造や処理の理解を支援するためのプログラム分析装置は、
プログラムへの入力操作の集合であり、該プログラムの典型的な機能を網羅するシナリオ群の実行に関するトレース情報が格納されているトレースファイル記憶手段と、
理解の対象となるソースコードが入力されると、前記トレースファイル記憶手段からトレース情報を読み出し、前記シナリオを起動した際に実行されるモジュールと該モジュールの依存関係を特定する依存関係特定手段と、
前記シナリオをオブジェクトとし、前記モジュールの依存関係を属性とする形式文脈を抽出する形式文脈抽出手段と、
前記形式文脈を形式概念分析の手法で分析し、概念束を生成する概念分析手段と、
を有する。

上記のように本発明によれば、特徴に含まれるモジュールについてソースコードを読み解き、モジュールの関係を対応付けることなく、形式概念分析で得られる特徴からの情報をより複雑・高度なものとするとともに、抽出された特徴に関わるソースコード読解の手間を軽減することが可能となる。

従来技術の形式概念分析のフローチャートである。 分析対象となるプログラム１と、モジュール（ｍ_ｉ）の呼び出し関係の例である。 図２のプログラム１により抽出された形式文脈１の例である。 抽出された形式文脈１に対する形式概念１の例である。 形式概念から形成された概念束１の例である。 希薄な概念束１の例である。 本発明の一実施の形態におけるプログラム分析装置の構成図である。 本発明の一実施の形態におけるデータの流れを示す図である。 本発明の一実施の形態におけるプログラム分析装置の概要動作のフローチャートである。 本発明の一実施の形態における図９のＳ２００の依存関係特定部１２０の詳細動作のフローチャートである。 本発明の一実施の形態における図１０のアルゴリズムの例である。 本発明の一実施の形態における図９のＳ３００の詳細動作のフローチャートである。 本発明の一実施の形態における図１２のフローのアルゴリズムの例である。 本発明の一実施の形態における抽出された形式文脈２の例である。 本発明の一実施の形態における形式文脈２に対する形式概念２の例である。 本発明の一実施の形態における概念束２の例である。 本発明の一実施の形態における希薄な概念束２の例である。

以下、図面と共に本発明の実施の形態を説明する。

本願発明では、非特許文献１により開示された従来技術と同様、プログラムを幾つかのシナリオに沿って起動した場合に、シナリオの起動により実行されるモジュールを特定するとともに、そのモジュールの依存関係も特定する。非特許文献１の手法ではシナリオをオブジェクト、実行されるモジュールを属性としたのに対し、本願発明では、シナリオをオブジェクト、実行されるモジュールとその依存関係を属性とし、形式文脈とすることを特徴とする。この形式文脈に対し、形式概念分析の手法を適用し、形式概念を抽出し、概念束および希薄な概念束を形成することで、プログラムの特徴として、モジュールの実行に加え、モジュール間の依存関係の集合を見つけ出すことを特徴とする。

最初に本明細書で用いる用語について説明する。

・形式概念分析（Formal Concept Analysis）：数学の束論を応用した一分野（例えば、http://www.upriss.org.uk/fca/，http://en.wikipedia.org/wiki/Formal_concept_analysis参照）。

・オブジェクト：形式概念分析が分析の対象とする物事。非特許文献１、本実施の形態では、プログラムの機能を起動する入出力の集合（シナリオ）。

・属性：形式概念分析の対象であるオブジェクトが必ず保有する性質。本発明では、シナリオにより起動されるモジュールと、モジュールの依存関係。トレースに出現した依存関係をオブジェクト（シナリオ）の属性として扱う。従来技術では、シナリオにより起動されるモジュールであり、トレースに出現したモジュールを、オブジェクト（シナリオ）との属性として扱う。

・形式文脈：どのオブジェクトが、どの属性を保有するのかを記述した対応表。

・形式概念：形式概念分析により発見される、オブジェクトの部分集合が保有する属性の部分集合。本発明では、プログラムの機能を実現するモジュールとモジュール間の依存関係を、形式概念として発見する。従来技術では、プログラムの機能を実現するモジュールを形式概念として発見する。

・概念束：形式概念を数学の束（そく）として表現したもの。

・希薄な概念束：概念束を、下位ノードとの属性の差分のみを記述する形で表現したもの。

・モジュール：プログラムを構成する部品。サブルーチンや、ブラウザに送信されるHTML文書などが代表例だが、これに限定されない。

・シナリオ：プログラムの入力装置の集合。本発明や従来技術では、プログラムの機能を起動し、モジュールのトレースを取得するために使用する。取得したシナリオによるトレース情報を形式概念分析のオブジェクトとして扱う。

・依存関係：あるモジュールが起動されるために、必要な別モジュールが存在する場合、あるモジュールは別モジュールとの間に依存関係があると呼ぶ。あるモジュールの呼び出し元（Caller）は、典型的な依存元である。

・出現：シナリオのトレースに、あるモジュールが起動された事実や、依存関係が存在した事実が記録されている場合、そのモジュールや、依存関係が出現したと呼ぶ。

以下に、本実施の形態を詳細に説明する。

本発明では、
１） 理解の対象となるソースコード；
２） プログラムへの入力操作の集合であり、プログラムの典型的な機能を網羅するシナリオ群；
３） シナリオを起動した際に、実行されるモジュールとモジュールの依存関係を特定する手段；
４） シナリオをオブジェクトとし、シナリオにより実行されるモジュールとモジュールの依存関係を属性とする形式文脈を抽出する手段、
５） 形式文脈を形式概念分析の手法で分析する手段；
を使用することが最良の形態である。１）に対し、２）を定義し、３）により依存関係を特定する。さらに依存関係を用いて、４）としてシナリオをオブジェクト、実行されるモジュールとその依存関係を属性とする形式文脈を構成する。これに対し５）により分析を行なうことで、本願発明が実施可能となる。

１）の理解の対象となるソースコードとして、例えば、Cなどのプログラミング言語で記述されたソースコードが該当する。

２）のシナリオ群として、例えば、１）のプログラムの操作説明書などを元に、プログラムが実現する機能を起動するための操作手順が該当する。

３）の依存関係を特定する手段としては、例えば、プログラムの実行を追跡（トレース）することにより、モジュールの実行と、モジュールの呼び出し関係などの依存関係を特定することが可能な、デバッガと呼ばれるツールが利用可能である。デバッガには様々なものが存在するが、例えば広く普及しているＵＮＩＸ（登録商標）−ＯＳの上で使用可能なものとして、ｇｄｂ、ｄｂｘなどが知られている。

５）の形式概念分析の手法の例としては、形式概念分析を実施するためのツールが複数存在し、Concept Explorer（http://conexp.sourceforge.net/）、ToscanaJ（http://toscanaj.sourceforge.net/）はオープンソースプログラムとして公開されている。

図７は、本発明の一実施の形態におけるプログラム分析装置の構成を示す。

同図に示す形式概念分析装置は、図８に示すトレース部１１０、依存関係特定部１２０、形式文脈抽出部１３０、概念分析部１４０を有するＣＰＵ１００、トレースファイルを格納した実行トレース記憶部２１０を有する磁気ディスク２００、依存元記憶部３１０と依存性記憶部３２０と属性記憶部３３０と形式文脈記憶部３４０を格納したメモリ３００から構成される。

実行トレース記憶部２１０のトレースファイルＡ[i]には、トレースコードの列Ｂ_ｉ[j]が格納されており、トレースファイルA[i]のｊ番目のトレースレコードB_ｉ[j]にはｊ番目に実行されたモジュールの識別情報が記録されているものとする。なお、本実施の形態では、モジュールの識別情報を１…ｎの整数値について表すものとする。

メモリ３００の依存元記憶部３１０は、モジュールの識別情報を１つ記憶するための変数Ｃを有するものとする。

依存性記憶部３２０には、依存性記録レコードＤ[i][j][k]が記録されるものとする。ここで、iは実行トレース記録ファイル２１０を指し示すために使用され（ｉは１…ａ）、j、kはモジュールを指し示すために使用される（j，kは０…ｍ、値０は基点を意味する特殊な値とする）。依存性記録レコードＤ[i][j][k]はトレースファイルA[i]中に識別情報jで表されるモジュールの識別情報kで表されるモジュールへの依存関係の有無を表すために使用され、依存関係があれば値１、依存関係がなければ値０をとるものとする。

属性記録部３３０には、属性レコードE[i]が記録されるものとする。属性レコードE[i]はモジュール間の依存関係を形式概念分析の入力となる属性として管理するために使用する。各々が１つの文字列を記録し、例えば識別情報ｊで表されるモジュールの識別情報ｋで表される依存関係のためには、"ｋ→ｊ"のような文字列を格納する。

形式文脈記憶部３４０には、形式文脈記録レコードF[i][j]が記録されるものとする。ここで、iはトレースファイルを指し示すために使用され（iは１…ａ）、jは属性レコードを指し示すために使用される。形式文脈記録レコードF[i][j]は、トレースファイルＡ[i]中に、属性レコードE[j]に記録されたモジュールの依存関係の有無を表すために使用され、依存関係があれば値１、依存関係になければ値０をとるものとする。

以下に、形式概念分析装置の動作を説明する。

図９は、本発明の一実施の形態におけるプログラム分析装置の概要動作のフローチャートである。

ステップ１００） ＣＰＵ１００のトレース部１１０において、解析対象プログラムの典型的な機能を網羅するシナリオ群（入力操作の集合）が解析対象プログラムに与えられることで、プログラムを実行すると実行されるモジュールとそのモジュールの依存元を判別し、シナリオ群の実行に関するトレース情報を実行トレース記録ファイル２１０に出力する。なお、トレース部１１０として、gdbやdbx等のデバッガを用いるものとする。また、本明細書におけるシナリオとは、登録処理、参照処理、削除処理を想定する。

ステップ２００） 依存関係特定部１２０では、実行トレース記憶部２１０のトレースファイルを入力とし、シナリオを実行することにより実行されるモジュールとそのモジュールに関する依存関係を特定し、依存性記憶部３２０に格納する。

ステップ３００） 形式文脈抽出部１３０において、シナリオを「オブジェクト」とし、モジュール間の依存関係の出現を「属性」として、形式概念分析の入力である「形式文脈」を抽出し、形式文脈記憶部３４０に出力する。

ステップ４００） 概念分析部１４０は、ステップ３００で形式文脈記憶部３４０に出力された形式文脈を入力とし、「概念束」を得る。ここで、概念分析部１４０として具体的には、Concept Explorer、ToscanaJ等を用いる。

ステップ５００） 概念分析部１４０は、「概念束」のノードに含まれるモジュールと、その依存関係により、機能とそれを実現するモジュールの依存関係を出力する。

次に、上記のステップ３００の処理を詳細に説明する。

図１０は、本発明の一実施の形態における図９のステップ２００の依存関係特定部１２０の詳細動作のフローチャートである。また、図１１に当該フローのアルゴリズムの例を示す。

ステップ２１０） 依存性記憶部３２０の依存性記録レコードＤを０に初期化する。

ステップ２２０） 実行トレース記憶部２１０の全トレースファイル（A[i]）に対し、以下を繰り返す。

ステップ２３０） 全てのトレースレコードBi[j]に対し、以下を繰り返す。

ステップ２４０） トレースレコードB_i[j]の値がｂで、トレースレコードB_i [j-1]の値がａの場合、依存性記憶部３２０の依存性記録レコードＤ[i][a][b]を１にする。

図１２は、本発明の一実施の形態における図９のステップ３００の形式文脈抽出部１３０の詳細動作のフローチャートである。また、図１３に当該フローのアルゴリズムの例を示す。

ステップ３１０） 形式文脈記憶部３４０の全ての形式文脈レコードF[i][j]を０に初期化する。

ステップ３２０） カウンタｘを１にする。

ステップ３３０） 全てのｊ＝１…ｎに対し、以下を繰り返す。

ステップ３４０） 全てのｋ＝１…ｎに対し、以下を繰り返す。

ステップ３５０） 全てのｉ＝１…ｍに対し、以下を繰り返す。

ステップ３６０） 依存性記憶部３２０の依存性記録レコードＤ[i][j][k]から、値が１であるもののみ抽出する。ｊ，ｋの組み合わせが新たに発生する度に、
・カウンタｘを１加算し、
・属性記憶部３３０の属性レコードE[x]を文字列"ｊ→ｋ"とし、
・形式文脈記憶部３４０の形式文脈レコードF[i][x]を１とする。

以下に具体的な例を示す。

モジュール間の依存関係として、モジュールの呼び出し関係を使用した例を示す。

従来技術の例示として、図２に示した「プログラム１」に対し、従来技術を示すために使用したのと同一のシナリオ（登録、参照、削除）を定義すると、モジュールの実行及び、その依存関係により、形式文脈抽出部１３０により、図１４に示すような形式文脈２が抽出される。従来技術が実行されるモジュールのみを属性としているのに対し、本願発明ではその依存関係を組み合わせて属性とすることにより、図２に示したプログラム１の形式文脈は、従来技術においては図３に示すとおり９種類の属性が存在したが、図１４では１２種類の属性が存在する。これは図３において、モジュールｍ₆の実行は属性ａ₆として管理されていたのに対し、図１４においてはモジュールｍ₆の実行は呼び出し元との依存関係により属性ａ₆とａ₇の２つに分別され、同様に図３において、モジュールｍ_８の実行は属性ａ_８として管理されていたのに対し、図１４においてはモジュールｍ_８の実行は呼び出し元との依存関係により属性ａ_９とａ₁₀、ａ₁₁の３つに分別されることに起因する。このように本願発明によると形式文脈は従来技術による形式文脈より詳細化されることになる。図１４の形式文脈２に対し、概念分析部１４０において、形式概念分析の手法を適用すると、図１５に示す形式概念が抽出され、これに対する概念束を形成すると、図１６が得られ、これに対し希薄な概念束を形成すると図１７が得られる。この結果、
シナリオ１だけが有する特徴：｛ｍ_１→ｍ_２、ｍ_２→ｍ_５、ｍ_５→ｍ_８｝
シナリオ２だけが有する特徴：｛ｍ_１→ｍ_３、ｍ_３→ｍ_６｝、
シナリオ３だけが有する特徴：｛ｍ_１→ｍ_４、ｍ_４→ｍ_６、ｍ_４→ｍ_７、ｍ_７→ｍ_８｝
シナリオ２と３に共通する特徴：｛ｍ_６→ｍ_８｝
シナリオ１、２、３に共通する特徴：｛ｓ→ｍ_１、ｍ_８→ｍ_９｝
が抽出される。各特徴に含まれる属性は、依存関係をもとにグループ化することができ、グループ化を行なうと、
シナリオ１だけが有する特徴：｛ｍ_１→ｍ_２→ｍ_５→ｍ_８｝
シナリオ２だけが有する特徴：｛ｍ_１→ｍ_３→ｍ_６｝
シナリオ３だけが有する特徴：｛ｍ_１→ｍ_４→ｍ_６、ｍ_１→ｍ_４→ｍ_７→ｍ_８｝
シナリオ２と３に共通する特徴：｛ｍ_６→ｍ_８｝
シナリオ１、２、３に共通する特徴：｛ｓ→ｍ_１、ｍ_８→ｍ_９｝、
のような、モジュールの実行と、実行されるモジュール間の依存関係を、モジュールのソースコードを読解すること無く得ることが出来る。

上記の図８に示すＣＰＵ１００の各構成要素の動作をプログラムとして構築し、形式概念分析装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。

本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において種々変更・応用が可能である。

情報処理システムを構成するプログラムの開発においては、保守等において人間が使用するためにプログラムの処理内容を自然言語で記述した設計ドキュメントが作成されることが多い。しかしながら、情報処理システムの保守などによりプログラムが変更されても、設計ドキュメントが同期して変更されない場合も多く、後になって別の保守者が保守を実施する場合には不完全な設計ドキュメントを参照しながら、プログラムの構造や処理内容を理解することが求められることになる。このような場合に、保守者によるプログラムの構造や処理内容の理解を支援するために従来技術や、本発明を使用することが、産業上の利用方法として想定される。

最初に不完全な設計ドキュメントの記載や、それまで当該情報処理システムを使用していた利用者へのヒアリングなどを通じて、当該情報処理システムが有するであろう機能を利用するためのシナリオ群を作成する。

シナリオ群を実行し、形式概念分析の手法により、互いに関連するモジュールの集合をプログラムの特徴（Feature）として発見する。

不完全な設計ドキュメントに記載されていた機能に関わるモジュールの集合が発見された場合には、ドキュメントに記載された機能の実装箇所が特定される、という効果が生じる。

モジュールの集合が発見されたが、不完全な設計ドキュメントに記載された機能とは無関係な場合は、新規に追加された機能であるため、設計ドキュメントへの追加を行なう。

このように、既存プログラムの保守にむけて形式概念分析の手法を利用することは、
１） 設計ドキュメントに記載された機能の、プログラムによる実装箇所を特定する；
２） 特徴として得られたモジュールの実装状況の分析にもとづき、設計ドキュメントを修正に資することができる；
という効果を求める産業上の利用可能性がある。

１００ ＣＰＵ
１１０ トレース部
１２０ 依存関係特定部
１３０ 形式文脈抽出部
１４０ 概念分析部
２００ 磁気ディスク
２１０ 実行トレース記憶部
３００ メモリ
３１０ 依存元記憶部
３２０ 依存性記憶部
３３０ 属性記憶部
３４０ 形式文脈記憶部

Claims (8)

1. プログラムの構造や処理の理解を支援するためのプログラム分析装置であって、
   プログラムへの入力操作の集合であり、該プログラムの典型的な機能を網羅するシナリオ群の実行に関するトレース情報が格納されているトレースファイル記憶手段と、
   理解の対象となるソースコードが入力されると、前記トレースファイル記憶手段からトレース情報を読み出し、前記シナリオを起動した際に実行されるモジュールと該モジュールの依存関係を特定する依存関係特定手段と、
   前記シナリオをオブジェクトとし、前記モジュールの依存関係を属性とする形式文脈を抽出する形式文脈抽出手段と、
   前記形式文脈を形式概念分析の手法で分析し、概念束を生成する概念分析手段と、
   を有することを特徴とするプログラム分析装置。
2. 前記概念分析手段は、
   前記概念束を、各ノードの概念間の差分を示す形の表現変換を行うことにより希薄な概念束を生成する手段を含む
   請求項１記載のプログラム分析装置。
3. 前記概念分析手段は、
   前記シナリオの特徴に含まれる属性を、依存関係に基づいてグループ化する手段を含む
   請求項１または２記載のプログラム分析装置。
4. 前記シナリオが入力されると、該シナリオに関するトレース情報をトレースファイル記憶手段に格納するトレース手段を
   更に有する請求項１記載のプログラム分析装置。
5. プログラムの構造や処理の理解を支援するためのプログラム分析方法であって、
   依存関係特定手段が、理解の対象となるソースコードが入力されると、プログラムへの入力操作の集合であり、該プログラムの典型的な機能を網羅するシナリオ群の実行に関するトレース情報が格納されているトレースファイル記憶手段からトレース情報を読み出し、前記シナリオを起動した際に実行されるモジュールと該モジュールの依存関係を特定する依存関係特定ステップと、
   形式文脈抽出手段が、前記シナリオをオブジェクトとし、前記モジュールの依存関係を属性とする形式文脈を抽出する形式文脈抽出ステップと、
   概念分析手段が、前記形式文脈を形式概念分析の手法で分析し、概念束を生成する概念分析ステップと、
   を行うことを特徴とするプログラム分析方法。
6. 前記概念分析ステップにおいて、
   前記概念束を、各ノードの概念間の差分を示す形の表現変換を行うことにより希薄な概念束を生成する
   請求項５記載のプログラム分析方法。
7. 前記シナリオが入力されると、該シナリオに関するトレース情報をトレースファイル記憶手段に格納するトレースステップを
   更に行う請求項５記載のプログラム分析方法。
8. コンピュータを、
   請求項１乃至４のいずれか１項に記載のプログラム分析装置の各手段として機能させるためのプログラム分析プログラム。

Images