日本ソフトウェア科学会第 30 回大会 (2013 年度) 講演論文集

プログラミングにおけるコメント付与システムの提案〜Orignum〜
下里 祐介, 濱川 礼
本論文では,C/C++で記述されたソースコードに対しコメントブロックの自動付与を行うシステム Origanum(以下本システムと表記) について述べる．本システムでは既存のソースコードを解析し, 関数やクラス, 構造体に対する定型的なコメントブロックを自動生成し, ソースコード中に付与することでユーザのコメント付与への所要時間を短縮させる．コメントブロックはユーザによる生成規則の追加・編集を可能とし, 各々のコーディングルールを考慮したものとなっている. 本システムは 2013 年 7 月、研究室所属の学生 12 名に対し, 各自で用意してもらったソースコードに対し本システムを使用し, 評価を行なった. コメント付与に対する手間を自分で一からつけた場合と比較してもらったところ,5 名から本システムを用いたほうが手間を感じないという回答を得た他, 前研究 [8] 時点での評価と比較し, 解析精度の向上が見られた.

進捗が優先され蔑ろにされがちである. 加えてコメン

1 背景・目的

トは常に正しい内容を記述しなければ意味を成さず,昨今, 技術の発展によりプログラマの負担は増加のプログラムの動作に影響しない為, 例えばアップデー

一途を辿り, 複雑化したソースコードに潜むバグが社トを行う際にコメントの更新を怠り, 動作内容との不会問題となって久しい. 近年では 2005 年に東京証券一致が生じれば結果としてバグの温床となる. これは取引所や 2009 年の日本航空で起きたシステム障害のコメント付与の煩わしさが原因の 1 つと考えられ, 普他, 2012 年にはファーストサーバがデータの消失を遍的に存在する問題であるといえる.

起こし無数のユーザに被害を及ぼした [3].

そこで本研究では, ソースコードへのコメントの自無論「バグのないソフトウェア」を実現は難しい.

動付与を行い, プログラマの負担を軽減させることを従ってバグの発生しにくい開発を心掛けることが最善目的とし, 本来プログラミングの本質ではないコメンであるとされ, その手法の 1 つとしてソースコードへト付与を効率化することをコンセプトに開発を行った.のコメント付与が広く知られている [6]. ソースコード

尚, 本システムは前研究 [8] を発展させたものである.

中にプログラムとは異なる「メモ書き」を残すことを意味するが, 処理内容を解析すれば分かる内容であっ2 システム概要てもコメント読みさえすればソースコードを見るまで本システムでは既存のソースコードを解析し, 自動もなく把握することができる. また, 自然言語で書か生成したコメントブロックを付与する. 関数の引数やれたコメントは理解が容易であり, 後にソースコード

戻り値の型, といったソースコードを見れば分かる,を見返す, 或いは複数人で同じソースコードを共有す

或いはコーディングした当人からすれば自明な情報でる場合に誤った解釈を避ける意味でも一般的にコメンあっても他者への配慮から機械的に記述する場面もトを適宜記述することで可読性を向上させることがで多く存在する. 本システムではこれらを定型的なコメきるが, 納期に追われる実際の製作現場では, 作業のントとして定義し, この自動化に重点を置き, 処理内, 中京大学情報科学研究科, Graduate School of Computer and Cognitive Sciences, Chukyo University.

容についてのコメントはユーザ自身が各々のコーディングルールに従ってパターン定義を追加することによる半自動化, またはコメントの推奨箇所として記述を促すことで対応する.
これはサンプルとして研究室所属の 12 名のソースコードを検証した結果, 処理内容についてのコメントはその多くが 1 行で表記できる文量であること, またその処理に対してワンオフな記述となりがちであることの 2 点から判断した.
解析には並びをパターンとして定義したパターン定義を用いる。パターン定義には予め用意されたデフォルトパターン定義とユーザ自身によって追加したユーザ定義パターンがある. 前述の定型的なコメントはデフォルトパターン定義で対応している. ソースコードの解析を行い, この 2 種のパターン定義に従って対応するコメントブロックがパラメータ情報を含めて自動的に生成され, 処理対象のソースコード中に挿入する. 本システムでは C/C++の文法を手掛かりに解析

図1

処理の流れ処理を行なっており, パターンマッチングは各パターン定義ファイルとの完全一致による比較を基本アルゴを示す.

リズムとしたが, 条件分岐や反復処理はネスト単位で• 処理対象のソースコード → list src

扱う他, 部分的な繰り返しとして定義可能なトークン• 区切り文字の定義 → list del

列の検出及びパターン否定の条件定義を加えること• 抽象トークンの定義 → list abs

で精度を高めた.

• パターンの定義 → list ptn

本システムではコーディング段階での使用を想定• コメントブロックの定義 → list cmt

し, 総合開発環境『Microsoft Visual Studio』のアド

2. 1. 2 トークン分割インとして開発した. 尚, 前研究においては使用場面

2. 1. 1 で生成したリスト list del に格納されたトークをコーディング終了後としていたが, 本来コーディンンの区切り文字を元に list src に行単位で格納されたグ中に適宜付与するものであることを考慮した.

ソースコードを細分化し, 別のリスト Origanum Listに格納する. Origanum List にはトークン, 抽象トー

2. 1 システム構成

クン, トークンの付加的情報を示すメタデータがそれ本システムの処理の流れを以下の図 1 に示す.

ぞれ紐付けられて格納され, この時点では分割された

2. 1. 1 データ読込み

トークン列とそのメタデータとして元の行番号を格処理対象のソースコード (またはその一部), および納する. これらをすべての行に対して行う.

トークン分割時の区切り文字, トークン抽象化処理,尚, 区切り文字は予め「’,’」
「’ ’」
「’(’」
「’)’」
「’ { ’」

解析処理, コメント付与処理に用いる各定義ファイル「’ }’」「’;’」「’<’」「’ >’」「’ !’」
「’=’」
「’+’」
「’-’」
「’/’」

を読み込み, 対応するリストに格納する. 定義ファイの 14 種類の文字を設定してあるが, 必要に応じて追ルについては対応するディレクトリ配下のすべての加可能とした. トークン分割の例とそのアルゴリズム

ファイルを読み込む (定義データの書式については後を図 2, 図 3 に示す.

述). ソースコードは行単位で分割し, これもリストに

2. 1. 3 トークン抽象化格納する. 全ての処理を終えた後, トークン分割処理

解析処理を簡易化する為, Origanum List に格納に移る. 読み込むファイルと格納先のリストとの対応したトークンを型名であれば「TYPE」, 変数/関数名

図2

図3

図4

トークンの抽象化

図5

抽象トークンの種類

トークンの分割例

トークン分割のアルゴリズム

る. 尚, 各抽象トークンの定義における候補となるトー等プログラマが任意に定義した文字列は「NAMED」のクンは任意に追加可能である. トークン抽象化のアルように抽象的な文字列への変換を行う (図 4).

ゴリズムを図 6 に示す.

この抽象的な文字列は list abs に格納され,7 種類の抽象トークンと全ての演算子が定義されている (図5).

2. 1. 3. 1 トークン抽象化の変換条件
1TYPE... 候補となるトークンの場合のみ「TYPE」として抽象化する

各抽象トークン定義には候補となるトークンが設定されており, 基本的には Origanum List に格納2されているトークンとの完全一致を以って変換され「COMMAND」として抽象化する

る. ただし, いくつかの例外がある為, 変換の条件を次3節で述べる.

「VALUE」として抽象化する

Origanum List に変換後の抽象トークンを格納す

4るが, トークンと抽象トークンは多対一の対応であり,非可逆的な変換となる為, 変換前のトークンも保持す

COMMAND... 候 補 と な る ト ー ク ン の 場 合 の み
VALUE... 整数型へのキャストが可能であればSTRING…トークンの頭文字が文字列を示す「 」の場合,「STRING」として抽象化する

5

NAMED... 候補となるトークンの他, クラス, 構造

「&」-「&」,「+」-「=」のように本来 1 つのトークンが処理の都合上分割されてしまったものである. ポ
インタ変数の宣言である「*」やアドレスを示す「&」も同様で, それぞれ TYPE, NAMED として再結合している (図 7).

図6

トークン抽象化のアルゴリズム

体等のユーザ定義型の型名, 定数は文脈情報がなければ区別不能の為, 全て「NAMED」として抽象化する
6

UNKNOWN... 全角スペースを含む等トークン自図7

体に異常がある場合は「UNKNOWN」として抽象化トークンの再結合する

1 〜 6 は順次判定され, 条件に該当した時点で対2. 1. 4 パターンマッチング

応する抽象トークンに変換される為,1 つのトークン

list src に格納されたトークン, および抽象トークが複数の抽象トークンを持つことはない. また上記ンの並びを元にパターンマッチングを行う. C/C++

6 種類の抽象トークンに 7 種類目の抽象トークンとの文法上, 関数, クラス/構造体の定義は容易に抽出可して「COMMENT」を追加した. これはソースコードに能であるが, それ以外の処理内容について汎用性を高既に含まれている「//」で始まる 1 行, 或いは「/*」める為, 各パターン定義ファイルとの完全一致による〜「*/」で囲まれた複数行のコメント全体を集約す

比較を基本アルゴリズム (後述) とし, 条件分岐や反復る. この抽象化は上記 1 〜 6 の処理すべてに優先す

処理はネスト単位で扱い, 入れ子構造となっている場る必要がある為, トークン抽象化の始めに実行され合はネスト毎に再帰的解析を行う他, 任意数の繰り返る. 「COMMENT」はパターンマッチング時に対象の抽しとして定義可能な部分的なトークン列の検出処理

象トークン列からは除外され, 存在しないものとしてとパターン定義に含まれるパターン否定条件の検証扱うが, コメントを付与する際に既存コメント有無のを加えている. コメント推奨位置の検出についても同判定に使用される. また本研究では C++の文法に対様である.

応する為, const や static, inline といった修飾子パターンマッチングを行う候補トークン列は, パや private, public, protected のアクセス指定子はタ ー ン デ ー タ の 先 頭 の ト ー ク ン を 検 索 キ ー と し,修飾するトークンのメタデータに含め, パターンマッ

Origanum List の抽象トークン列を走査する. 一

チング時には存在しないものとして扱う.

致した箇所からパターン長と同範囲の抽象トークンを

2. 1. 3. 2 トークンの最適化切り出したものを対象トークン列とし, パターンマッ抽象化処理を終えた後, Origanum List に格納されチングを行う. ただし, パターン定義に任意数の繰り返たトークン列の最適化を行う. 対象となるトークンはしを含む場合は, 一致したトークン以降の全てのトークンを対象に取る (図 8).

パターンの一致が認めら生のトークンを対象とし, 比較を行う. アルゴリズムは共通である.

図 10

基本アルゴリズム2. 1. 4. 2 ネスト単位で扱うアルゴリズム
図8

対象トークン列の検出

if や for 等の制御構文はネスト単位で扱う方がパターンマッチングの際に都合が良い為, このアルゴリ

れたトークン列は, コメント付与対象として, タスクズムを用いてネストを検出する. また制御構文を示すに登録される. タスクにはコメント挿入位置を示す行

抽象トークン COMMAND が検出された場合は付随する番号とコメントの種類, および引数や戻り値等コメン

ネスト全体を COMMAND に集約する. 実現にあたり下トブロックを生成する際に必要な情報を付加する (図記のアルゴリズムを用いている (図 11).

尚, パター

9).

図9

タスクの登録2. 1. 4. 1 基本アルゴリズム
基本アルゴリズムとしては Origanum List に格納されている抽象トークン列とファイルから読み込んだパターン定義との完全一致による比較を行う (図 10).
ただし,「@」を含むトークンがパターンとして定義されている場合, Origanum List に格納されている

図 11

ネスト単位で扱うアルゴリズム

ンを検証する範囲をネスト単位で設定するが, この際との一致を以ってパターンとして認定するが, パターにネストの直前にある抽象トークンに属するものとンデータが否定条件を含む場合, 再度検証を行う. 否して扱うよう変更を加えた他, ネストの範囲を集約し定条件としては対象の抽象トークン列に特定のトーた場合と集約せずに通常のトークン列として扱う場

クン/抽象トークンを含む場合と特定のパターンを含合の 2 パターンの比較を行うよう改良した. これによむ場合とがあるが, いずれの場合も対象のトークン列り複数のネストを含む処理全体に対するコメントをと否定条件とで通常の比較を行う. 否定条件と一致す定義することが可能となった.

るならば, そのパターンには該当しないものとし, 他

2. 1. 4. 3 任意数の繰り返しを扱うアルゴリズムのパターンデータとの比較を続行する.

パターンデータ内に任意数の繰り返しの記述を含む場合は, 下記のアルゴリズムを使用する (図 12).

パ尚, この処理は前研究では複数のパターンデータに該当し, 誤ったコメントを付与するケースが見受けられた為, 精度と汎用性向上を目的として追加した.

2. 1. 5 コメント付与
ソースコード全体の解析を終えた後, コメント付与を行う. まず, 上述のタスクを行番号により降順にソートする. 以後先頭に積まれたタスクから順次処理を行う. これにより挿入の際, タスクに登録された行番号の位置がずれることを回避している.
挿入するコメントブロックは, パターン名に対応する定義ファイルから読み込み, 関数名等の情報を文字列として埋め込む. 埋め込む位置はコメントブロック
図 12

任意数の繰り返しを扱うアルゴリズム

定義ファイル中に解析前に予め記述する. 以上の処理を全てのタスクについて実行し, 結果を Visual Studio

ターンマッチング中, 比較対象のトークンとして繰りへ出力する.

返しを示す「<*>」が出現した際に図のアルゴリズ

2. 1. 5. 1 コメントブロック生成

ムを用いている. ここではパターンデータ全体ではな

コメントブロック定義ファイルからソースコードにく任意数の繰り返しとして定義されているトークン実際に挿入するコメントブロックの生成を行う. コメ

列との完全比較を行い, パターンの終端に到達した際

ントブロック定義ファイルはパターン定義ファイルとには比較対象を先頭のトークンへと戻している. また,リンクしており, 対応するパターンと同名のテキスト

この処理は一致が認められないトークンが出現したファイルに記述する. またパターン定義ファイルに記時点で終了するが, 比較の過程で繰り返された回数を述したメタデータを埋め込みデータとして利用する

記憶し, 繰り返し開始位置から通常のパターンマッチことが可能である.

ングを再開するべきインデックスを算出している.

コメントブロックの生成例を以下に示す (図 13).

以上を行うことで, 関数の引数やクラス/構造体のメンバのように基本アルゴリズムだけではパラメータの数毎にパターンを定義する必要があるものを任
意数の繰り返しを容認する 1 つのパターンに集約することが可能となる.

2. 1. 4. 4 パターンの否定を扱うアルゴリズム
Origanum List から切り出した抽象トークン列とパターンデータとして定義された抽象トークンの並び

図 13

コメントブロックの生成例

トークンは行単位で記述し「|」で区切ることで複2. 1. 5. 2 コメントブロック挿入
生成されたコメントブロックは, タスクに登録された数の候補を定義可能. また半角スペースの後に, 関数行番号の位置へと挿入される (図 14). 尚, 同じ行ないの名前を表すのであれば「FUNC_NAME」のように, そし直前の行に抽象トークン COMMENT が存在する場合,のトークンが持つ文脈上の意味をメタデータのラベルすでにコメントが記述されていると判断し, 処理を行として記述する. このラベルは任意の半角英数字でのわない.

定義が可能である. 尚, 複数のパターンを定義する際は各パターンの間に空白行を挟むこととする. 拡張書式として「@」の後に文字列を続けることで抽象トークンでなく生のトークンと比較することができる他,任意数の連続する抽象トークンを「<*>〜</*>」で括ることでその範囲のトークンをクリーネ閉包として定義可能とした.
クリーネ閉包とはオートマトンにおける, ある演算の繰り返しが生成するシンボル, あるいは文字列の集合を意味する. 本来, 関数の引数や構造体のメンバ等,可変長の記述をパターンとして定義する為には, 引数やメンバの数に応じたあらゆるパターンの記述が必要となるが, 任意数繰り返されるトークン列をクリー
図 14

コメントブロック挿入

ネ閉包とし, パターン定義を記述する際に使用可能とすることで対応した. 前研究時点では, クリーネ閉包の中にクリーネ閉包を含むことはできなかったが, 本

3 パターン定義

研究では任意数含むことができるよう改良を行った.

デフォルトで組み込まれているパターン定義は関数

以下デフォルトのパターン定義を例として挙げる.の定義とプロトタイプ宣言, 構造体の定義とプロトタ

3. 1. 1 関数定義の例

イプ宣言, 署名の 5 種類がある. また対象となる処理

NAMED|TYPE RETURN_TYPEがトークン列としてパターン化できる場合に限られNAMED FUNC_NAME

るが, ユーザ自身によるパターン定義の追加が可能で(ある. 各パターン定義ファイルは対象となるトークン)

列とメタデータで構成されている. メタデータはコメ{

ントブロック生成の際に埋め込まれる文字列についての情報であり, 関数名であれば「FUNC_NAME」のよう

NAMED|TYPE RETURN_TYPEに各抽象トークンの持つプログラミングにおける意NAMED FUNC_NAME

味を記述する.

(<*>3. 1 パターン定義ファイルの書式

NAMED|TYPE PARM_TYPE

各パターン定義ファイルは, 拡張子を除いたファイ

NAMED PARM_NAME

ル名をパターン名とし, 対象となるトークン列とメタ,データのラベルで構成されている. 尚, ここでのメタ</*>

データとはコメントブロックを生成する際に変数名等

NAMED|TYPE PARM_TYPEのパラメータ情報である.

NAMED PARM_NAME

3. 1. 5 ユーザ定義パターンの例)

対象となる処理をパターン化できる場合に限られ{るが, デフォルトのパターン定義の他に, ユーザ自身

3. 1. 2 関数プロトタイプの例によるパターン定義追加が可能である. ただし, 本シ

NAMED|TYPE RETURN_TYPE

ステムではパターン定義のチェックを行わない為, 曖

NAMED FUNC_NAME

昧な定義は避け, 出来る限りユニークなパターンを定(義することが推奨される.
以下はカウンタ変数をインクリメントまたはデク)リメントしつつ反復を行う for 文の定義例である.

;

COMMAND
NAMED|TYPE RETURN_TYPE(NAMED FUNC_NAME

NAMED INIT_NAME(=<*>

NAMED|VALUE INIT_VALUENAMED|TYPE PARM_TYPE;

NAMED PARM_NAME

NAMED|VALUE

,<|>

</*>

NAMED|VALUENAMED|TYPE PARM_TYPE;

NAMED PARM_NAME

NAMED)+|-;+|)
3. 1. 3 構造体定義の例@struct
NAMED STRUCT_TAG_NAME

3. 2 コメントブロック定義ファイルの書式{

各コメントブロック定義ファイルは同名のパターン<*>
TYPE|NAMED MENBER_TYPE
NAMED MEMBER_NAME

定義ファイルに対応する.
その場合, パターン定義ファイル中に定義したメタデータのラベルの先頭に「$」を付けて記述する.
「- ->」を記述することでコメント推奨位置として;</*>登録が可能である. また定義中に記述したメタデータ}

ラベルは対応するトークンの文字列で置換される.
メタデータラベルの内, ”PARM_NAME”, ”MEMBER_NAME”,

3. 1. 4 構造体プロトタイプの例”PARM_TYPE", ”MEMBER_TYPE”は特殊な振る舞いと@structなっており, データの数に応じて, 行が複製される. 故NAMED STRUCT_TAG_NAMEに, 図 15 のように同一行に記述することを推奨する.

;

図 15

コメントブロック定義の例

図 17

for 文への付与例

3. 3 コメント推奨位置の定義
コメント推奨位置として記憶し, ユーザにコメント記述を促す. デフォルトでは, 下記の箇所を検出する.
この基準はサンプルとして検証した 12 名のソースコードに見られた傾向をもとに設定した.

• 5 行以上の連続した空白行 (シークエンスの切れ目と判断)• 10 トークン以上を含む行 (複雑な処理と判断)
また, パターン定義の 1 種として, ユーザ自身による追加が可能である.

4 出力結果の例

図 18関数への付与例 (ユーザ定義)

図 16 は関数への付与例である. 引数や戻り値の情報が正常に反映されている.

できるコメント書式として定義した.
図 19 は C++のコードにおけるクラスへの付与例である. ここでは STL の使用についてのコメント及び data という変数, Load 関数に対してユーザ定義を使用した. 関数の宣言についてはデフォルトで既にパターン定義されているが, ユーザ定義パターンが存在する場合はこちらが優先される. 図 18 の例では Load関数がユーザ定義, Exists 関数の宣言がデフォルト

図 16関数への付与例

図 17 はユーザ定義を用いた付与例である. 定数

NUM_MAX の数値はメタデータとして保持されたものを利用している.の定義に基いてコメントブロックが生成されている.

5 評価
前研究では, 研究室に所属する学生 12 名に対し, 評価者が各自用意したソースコードを本システムで解図 18 はユーザ定義を用いた関数への付与例であ析し評価を行なった. 評価の中で「コメントを付けるる. ここでは, 自身のコーディングルールを反映させ,際, 全て手動で付けることと本システムを使用して付「pBuf」や「OutputDebugString」というような頻繁けること, どちらが手間を感じないか」という問いにに使用する変数名や関数名をパターンとして登録し,対して 5 名から本システムを使用するほうが手間を処理内容についてのコメントを付与している他, ド感じないという回答を得た. また付加されたコメント

キュメント生成ツールである『Doxygen』 [2] で利用量については「適量」7 名に対し「やや不足」5 名となり, 概ね良好な評価となった. 「コメントの種類はわれているが, これもソースコードの解析を行う点では近いといえる.

7 考察
本システムでは前研究を発展させ解析精度を向上の向上及び Visual Studio のアドインとし, コーディング段階ですることを主軸に開発を行ったが, 精度と付与量については前研究よりも好評価を得た一方で使いやすさという面では後退したという結果となった.
評価後に使用したソースコードとコメント付与後のソースコードとを比較検証したところ, 評価に用いたソースコードの量や質に極端な差異が目立っていた.
最も長いもので 1000 行規模のソースコードに対し,短いものは僅か 10 数行程度のものであり評価を行うには不適切であった.
プログラムの質についても同様で, クラス化/関数化が適切に行われているソースコードに対しては適切な付与が確認できた一方, そもそもエラーで正常に動かないプログラムや main 関数に全ての処理を集約
図 19

クラスへの付与例 (ユーザ定義含む)したいわゆるスパゲティコードとなっているものが存在した. 以上の点からソースコードの条件をある程度適切か」という問いに対しては「適切」6 名に対し,「やや不適切」6 名と評価が分かれた.

揃えた上で再度評価を行う予定である.
また, 正常に動作したソースコードを検証した結果,パターン定義の追加による自動化では定型的なコメ

6 関連研究ントを付加するという用途については十分対応可能関連研究としてソースコードからコメントを生成であるが, 処理内容についてのコメントとなるとパするものとして『C/C++ 関数コメントジェネレー

ターン追加による対応ではやはり限界があることがタ Boss』がある [4]. 戻り値の型, 関数名, 引数, 関数分かった. よって今後のアプローチとして, ユーザのについての説明を入力すると整形されたコメントブ

コーディングやコメント記述における癖を収集し, 蓄ロックとしてクリップボードにコピーされ, それを手積した学習データを元に処理内容についてのコメン動で貼り付けるというものであり, 本システムとは自トを提案することを考えている.

動化を行う点において異なる.

尚, 本 シ ス テ ム を Windows7-64bit,AMD Phe-

また, 関連技術として NTTDATA の「TERASOL-

nomII 1100T, MEM16GB の計算機を用いて 1182

UNA Reengineering」がある [5]. 既存システムのソー行のソースコードに対して解析を行った結果, 処理スコードを分析し, モジュール構成図やサブルーチン時間が平均 1.18 秒で, 192 行のコメントが付与され一覧、データ定義書といった各種設計書を自動生成す1374 行となった.

る. これは「システム開発の自動化」を目指したもので目的は異なるがアプローチ自体は似たものとなって

参 考 文 献いる.

[1] Balachandran, V.: Reducing human eﬀort andimproving quality in peer code reviews using auto-

同様にリファクタリング手法の研究 [7] [1] が広く行

matic static analysis and reviewer recommendation,
Proceedings of the 2013 International Conference
on Software Engineering, ICSE ’13, IEEE Press,
2013, pp. 931–940.
[2] Doxygen: http://www.doxygen.jp/, 2009.
[3] ITpro: 相 次 ぐ シ ス テ ム 障 害, http://itpro.
nikkeibp.co.jp/trouble/, 2012.
[4] nakka:
コメントでソースコードを見やすく, http://www.forest.impress.co.jp/article/2000/08/02/sundayprog5.html, 2000.
[5] NTT DATA: TERASOLUNA Reengineering,

http://www.terasoluna.jp/product/tool/reengineering.
html, 2013.
[6] ロベール: ロベールの C++入門講座, 毎日コミュニ
ケーションズ, 2007.
[7] 譜久島 亮 吉田 則裕 松下 誠 井上克郎: ソースコー
ドに対して適用可能な編集手順を探索するリファクタ
リング支援手法の提案, SS2009-44, Vol. 109, No. 343,2009, pp. 55–60.
[8] 杉浦稜介, 下里祐介, 中島将之, 濱川礼: ソースコードへ自然言語による注釈の自動付与を行う手法の提案, 情報処理学会 第 75 回全国大会 予稿集, 2013.