成果物の構造を考慮したテキスト埋め込みによるトレーサビリティリンク回復手法の提案

電子情報通信学会知能ソフトウェア工学研究会（IEICE KBSE）2024年1月研究会発表．
開発者が必要なソースコードやドキュメントを効率的に特定できるようにするためのトレーサ ビリティリンク回復手法について，成果物の構造を考慮した木構造の包含関係によるフィルタリングと逆ランキング ペナルティと名付けたランキングのためのメトリックを提案する．提案手法を OSS のプロダクトにて適用する実験 により評価する．

Transcript

1. 成果物の構造を考慮した テキスト埋め込みによる トレーサビリティリンク回復手法の提案 神谷年洋 (島根大学総合理工学部) KBSE 2024年1月研究会 @ 宝山ホール（鹿児島県文化センター） 1
2. 要求仕様 設計 ソースコード トレーサビリティとは ソフトウェア開発で利用される成果物間の関連（トレーサビリティリンク）を特定 （回復）し追跡すること 目的: プロダクトを修正する際に、関連する成果物を特定する 例: 要求仕様が変更される→影響を受ける 設計やソースコードを特定する . 2
3. 要求仕様 設計 ソースコード トレーサビリティとは ソフトウェア開発で利用される成果物間の関連（トレーサビリティリンク）を特定 （回復）し追跡すること 目的: プロダクトを修正する際に関連する成果物を特定する 例: 要求仕様が変更される→影響を受ける 設計やソースコードを特定する . 3
4. 対象となる成果物[12] 要求仕様、設計、テスト、ソースコ ード等 非形式的なドキュメント、リリース ノート、イシュー（問題の報告）等 解析方法(IRに限定して)[12] キーワード(TFIDF等) 埋め込みベクトル DNN 表現 グラフ（前ページ） 表 縦軸と横軸に成果物を並べる s1 s2 s3 s4 r1 ✓ ✓ ✓ r2 ✓ r3 ✓ 列が進むにつれ詳細化する 要求 テスト ステータス 課題 [12] Zaki Pauzi, Andrea Capiluppi, Applications of natural language processing in software traceability: A systematic mapping study, Journal of Systems and Software, vol. 198 (2023) 111616, 2023. トレーサビリティリンクの対象となる成果物・表現は様々 4
5. (1) 類似度を計測 (1-1) 成果物（ソースコードやドキュメ ント）を単語の列とみなす → 含まれる単語の類似度を計算する （TF-IDF等） (1-2) 成果物をテキスト埋め込みにより ベクトルにする → ベクトルの類似度を計算する (1-2') 埋め込みのための専用の埋め 込みモデルを、追加学習などにより 開発する [9] Jinfeng Lin, et al., Traceability Transformed: Generating More Accurate Links with Pre-Trained BERT Models, ICSE 2021, pp. 324–335, 2021. (2) 関連を出力するDNNモデル 2種類の成果物を入力して関連の有無を 出力するDNNモデルを作成する 例: イシューとソースコードの断片 のペアを学習データとする[9] 情報検索技術(IR)を利用した トレーサビリティリンクの回復手法 5
6. d1 c1 v d2 v d3 v v c2 v c3 v c4 v 0.21 0.34 0.05 0.58 ドキュメント ソースコード 距離 テキスト埋め込みによるトレーサビリティリンクの回復 (1) ドキュメントやソースコードを離散表現 （意味を表現するベクトル）へと埋め込む (2) 距離が近いベクトルをトレーサビリティリ ンクとする 距離 = 1.0 - ベクトルがなす角度のcos値 0.0（意味が近い） 〜 2.0 （遠い） 意味が近い 意味が遠い ⻑さ1 に正規化したベクトルで考える 1.0 -1.0 0.0 2.0 cos 値 距離 6
7. 解析対象のプロジェクトの特徴・特性 解析対象のプロジェクトを学習データと してモデルをファインチューニング、追 加学習する → 開発や保守が進むにつれてモデルを 更新する？生成したモデルの安定性？ 対話的に分析を進める（分析者がキーワ ードを選別するなど） → 分析者の知識に依存？ 成果物の（半）構造 ドキュメントは、章・節・段落とい った入れ子の構造を持つ（ものもあ る） ソースコードは、モジュール、関 数、コード断片といった入れ子の構 造を持つ → 構造をトレーサビリティリンクの回 復に利用できないか？ 問題（個人的にもやもやした感じがするところ） 7
8. ドキュメントやソースコードに次の特徴 があると仮定する 木構造の包含関係 . 凝集度の高い記述 汎用のモデルを利用する 自然言語テキスト向けの埋め込みモ デルを利用する （Sentence Transformers、all- MiniLM-L6-v2） ソースコードの場合はDocstring やコメントに頼る 解析対象のプロジェクトを学習データと してファインチューニングするなどは行 わない 提案手法 8
9. (例) あるトイプログラム（Todoアプリ）のマニュアル 9
10. (例) あるトイプログラム（Todoアプリ）のソースコード 10
11. ドキュメントやソースコードに次の特徴 があると仮定する 木構造の包含関係 凝集度の高い記述 単一の機能についてはまとめて書い てある → 異なる節として書かれている内容 は（言葉は似ていても）異なる機能 だろう 汎用のモデルを利用する 自然言語テキスト向けの埋め込みモ デルを利用する （Sentence Transformers、all- MiniLM-L6-v2） ソースコードの場合はDocstring やコメントに頼る 解析対象のプロジェクトを学習データと してファインチューニングするなどは行 わない 提案手法 11
12. 外側の記述のトレーサビリティリンク (TL)が、内側の記述のTLと類似度が同じ か高い場合には、外側の方を優先する 出力されるTLの数を減らして整理し 分析を容易にする 外側の記述で見たほうが類似度が高 いなら、内側の記述を見る際にその 周りの記述も見たほうが理解しやす いであろう (1) 距離の計算は包含関係を考慮せず、 すべての記述のペアについて行う。 その上で、距離が近いペアをTLの候補 とする (2) TLの各候補 について、より外側の 記述の間の候補に距離が同じかより近い ものが存在した場合には、候補 を除外 d2 d2.1 d2.2 v v v c3 c3.1 c3.2 v v v 0.05 0.07 0.03 木構造の包含関係によるトレーサビリティリンクのフィル タリング 12
13. 逆ランキングペナルティ 凝集度が高い → 同じ内容は単一の節に記述される → ドキュメントのある節の内容と、別 の節の内容は異なる → ソースファイルのあるコード断片 がドキュメントの節 とトレーサビリテ ィリンク(TL)を持つなら、別の節 とは TLを持たない 逆ランキングペナルティ ドキュメントのある節 に対してコード 断片を距離の近い順にランキングする際 に、 逆にコード断片から見て節 が最も距離 が近い節ではなければ、距離の値にペナ ルティを加算する (1) ドキュメントの各節 と、ソースコ ードの各コード断片 との距離を求め とする (2) と の距離の逆ランキングペナル ティ を とする ここで、 はコード断片 から見て距 離が最も近い節との距離。 より 。 (3) 節 とコード断片 との距離を とする 「安定マッチング」やTF-IDFの「IDF」のよ うな仕掛けをcos類似度に導入したい 13
14. 逆ランキングペナルティの計算の例 d1 d2 v v c1 c2 v v 0.3 0.1 0.4 0.5 距離 Dij d1 d2 v v c1 c2 v v 0.3 0.1 0.4 0.5 逆ランキングペナルティ(RRP) を⽤いない場合のTL d1 d2 v v c1 v 0.3 0.2 (= 0.3 - 0.1) 0 (= 0.1 - 0.1) 0.1 d1 d2 v v c2 v 0.4 0.5 0 (= 0.4 - 0.4) 0.1 (= 0.5 - 0.4) c1 に関するRRP c2 に関するRRP d1 d2 v v c1 c2 v v 0.3 + 0.2 0.1 0.4 0.5 + 0.1 RRP を⽤いた場合のTL 14
15. ツールの実装 ツールはインデックス生成とリンク抽出により構成されている インデックス生成は、コード断片やドキュメントの節を、木構造の階層を保存し つつ抽出し、テキスト埋め込みモデルによりベクトルに変換する リンク抽出は、トレーサビリティリンクの候補を生成し、RRP付きの距離を計 算し、木構造の包含関係によるフィルタリングを行う インデックス⽣成 リンク抽出 HTML Python GFM ⽊構造抽出 (AST) ⽊構造抽出 ( タグ) ⽊構造抽出 ( ⾒出し等) TL 候補の⽣成 RRP の計算 ⽊構造の 包含関係による フィルタリング TL GFM ベクトルDB HTML ベクトルDB Python ベクトルDB コード断⽚ Docstring 等 テキスト 埋め込み 15
16. インデックス生成 (1) 木構造の包含関係に基づいて成果物を分割したテキスト（ドキュメントの節やソ ースコードのコード断片）を作成 (2) それぞれに対してテキスト埋め込みを行ってベクトルDBに格納 ファイルの 種類 木構造の特定 加工 GFM ファイル 見出し、リストアイテム、 空白行によるパラグラフ Python スクリプト AST コード断片そのまま + Docstringやリテ ラル（ただし文字列リテラル中の SQL文は取り除く）、コメントを 抽出したもの HTML ファイル タグの入れ子構造 GUIの記述とみなしてタグを意味を表す テキストに置き換え 16
17. リンク抽出機能 それぞれのベクトルDBに格納されているドキュメントの節やコード断片の各ペア （TL候補）に対して、 (1) 逆ランキングペナルティによる距離の計算を行う (2) 木構造の包含関係によるTL候補のフィルタリングを行いつつ、距離の近いものか ら順に出力する オプション 長さの下限 ドキュメントの節やコード断片の文字数の下限 距離の上限 （cos類似度による距離のため 〜 ） フィルタリングやペナルティの利用の有無 17
18. 実験1 180行程度のトイプログラム ソースコードをテキスト埋め込みす る際のDocstringの有無の影響を確 認する実験 Docstring: 関数やクラスの最初 に、文字列リテラルとして、自 然言語による説明文をつけるも の（Java言語ならJavaDocとし て記述するもの） マニュアルからアプリの画面へのTL 回復の実験 実験2 34k行程度のOSSアプリ 数万行規模のプログラムに対する適 用実験 RRP利用の有無の影響を調べる実験 実験 マニュアルとソースコードとの間のTL回復の実験 18
19. 実験1: トイプログラム - 対象プロダクト ChatGPTにより生成したTodo管理のためのWebアプリ WebフレームワークとしてFlaskを、RDBとしてSQLiteを利用 プロダクションコード180行、ユーザーマニュアル71行 言語 ファイル数 行数 コード行 コメント行 空白行 GFM 1 71 0 46 25 Python 2 129 107 6 16 HTML 1 51 47 2 2 ※ 行数の計測はtokeiによるためGFMの記述はコメント行と数えられているが、通常 のテキスト ※ 「あるトイプログラム」として前述したもの 19
20. ドキュメントの節 行数 結果(P) # Todo Application 3 N/2 ## Installation 21 N/3, N/3 ## Usage 18 N/0 ### Detailed Usage Instructions 1 N/0 **Viewing Todos** 1 1/3 **Adding a New Todo** 5 2/3 **Updating Todo Status** 4 1/1 **Editing a Todo** 4 1/1 **Deleting a Todo** 3 1/1 結果: TLをすべて回復できていたが、正解の順位が1位で はないものもあった 実験1: トイプログラム - TL回復の結果 分母: 出力されたトレーサ ビリティリンクの数 分子: そのうち最初に現れ た正解の順位 ただし、Nのものは正解が ないと期待されるもの 分数が複数あるものは、節 が複数のパラグラフで構成 されてていて、入れ子の階 層でTLが出力されている 20
21. 実験1: トイプログラム - Docstringを利用しない場合 ドキュメントの節 行数 結果(P) 結果(-D) # Todo Application 3 N/2 N/2 ## Installation 21 N/3, N/3 N/3, N/3 ## Usage 18 N/0 N/0 ### Detailed Usage Instructions 1 N/0 N/0 **Viewing Todos** 1 1/3 ↓ X/1 **Adding a New Todo** 5 2/3 ↑ 1/2 **Updating Todo Status** 4 1/1 ↓ X/0 **Editing a Todo** 4 1/1 ↓ X/1 **Deleting a Todo** 3 1/1 1/2 Docstringを利用しないと、3個の節についてTLが回復できなくなった → 利用したテキスト埋め込みモデルは自然言語のテキストを対象とするものである ため、TLの回復にはDocstringなどの記述が必要 21
22. 実験1: トイプログラム - GUIの記述へのTL回復 ドキュメントの節 行数 結果(P) 結果(H) # Todo Application 3 N/2 N/0 ## Installation 21 N/3, N/3 N/0 ## Usage 18 N/0 N/0 ### Detailed Usage Instructions 1 N/0 N/0 **Viewing Todos** 1 1/3 ↓ X/3 **Adding a New Todo** 5 2/3 ↑ 1/1 **Updating Todo Status** 4 1/1 1/1 **Editing a Todo** 4 1/1 ↓ X/0 **Deleting a Todo** 3 1/1 1/1 ※ HTMLファイルは、Pythonスクリプトと比べて半分以下の行数なので、数字以上 に精度が悪い印象 マニュアルからHTMLによるGUIの記述へのTL回復は、マニュアルからソースコード へのTL回復より難しい（難しそう） 22
23. 実験2: OSSアプリ - 対象プロダクト novelWriter (https://novelwriter.io/) 小説の執筆に特化したテキストエディタ Markdownによるフォーマッティング、タグ、コメント、クロスリファレン スなど多くの機能を備える プロダクションコード34k行、ユーザーマニュアル3.7k行 テスト、セットアップ、i18nに関するソースファイルは除外 言語 ファイル数 行数 コード行 コメント行 空白行 GFM 22 3,744 0 2,743 1,001 Python 70 34,360 26,137 2,264 5,959 ユーザーマニュアルの節（見出しと箇条書）は250個 → 12個毎に1個選択して20個を対象とした → そのうち7個は正解がないと期待されるもの。残りの13個について示す 23
24. ドキュメントの節 行数 結果(P) ## Spell Check Dictionaries 5 3/18 Project Notes 7 2/4 ## Build Settings 22 1/21, 1/9 ## Print and PDF 20 1/3, 1/2 ### Archived Documents 11 X/2, 1/2 # Tags and References 31 1/6 @entity 4 1/1 # File Locations 6 1/8 ### Novel Outline View 14 1/3, X/1, 1/1 # Title Text 4 1/20 **text** 3 3/8 **Column 1** 9 X/1 ### Project Tree Drag & Drop 26 3/3, 1/1, X/3, 1/1 分子が「X」の ものは、正解 のTLが主力に 含まれなかっ たもの 結果 1位: 7個 2位以下: 5個 回復できなか った: 1個 実験2: OSSアプリ - TL回復の結果 24
25. TLを回復できなかったもの（表中の「X」） ドキュメントの節 行数 結果(P) **Column 1** 9 X/1 記述のひとつ上の階層でアプリのメインウィンドウの説明であることが示されてい て、この節は、その一部（最初のカラム）の表示内容に関するもの → ひとつ上の階層の記述が、その節を理解するのに必要な「文脈」となっていた ドキュメントの節 行数 結果(P) ### Archived Documents 11 X/2, 1/2 記述が「ドキュメントを削除したくなければ、トラッシュフォルダに」という書き 方だった。「トラッシュフォルダ」機能ではなく「削除」機能にTLを回復してしま った 25
26. TLの正解がないと期待されるもの（表中の「N」） アプリの機能の概略の説明でありリンクを付けるには向かない 実質的に続く節の目次であるもの インストール方法に関する内容のため、対象となったソースコードの範囲外 ビルド方法に関する内容のため（以下同文 古いバージョンのファイルフォーマットに関する記述であるため（以下同文 26
27. 実験2: OSSアプリ - RRPを利用しない場合 ドキュメントの節 行数 結果(P) 結果(-RRP) ## Spell Check Dictionaries 5 3/18 3/77 Project Notes 7 2/4 2/8 ## Build Settings 22 1/21, 1/9 1/33, 1/15 ## Print and PDF 20 1/3, 1/2 1/5, 1/2 ### Archived Documents 11 X/2, 1/2 ↓ X/4, 1/6 # Tags and References 31 1/6 ↓ X/8, 1/28, 2/6 @entity 4 1/1 1/1 # File Locations 6 1/8 ↓ 5X/60 ### Novel Outline View 14 1/3, X/1, 1/1 1/7, 1/2, 1/1 # Title Text 4 1/20 1/32 **text** 3 3/8 3/9 **Column 1** 9 X/1 X/2 ### Project Tree Drag & Drop 26 3/3, 1/1, X/3, 1/1 ↓ 7/7, 1/2, X/4, 4/9 RRPを利用しないと、4個の節について正解の順位が低下（あるいは回復できない）27
28. まとめと展望 テキスト埋め込みモデルを利用したTLの回復において、成果物の構造に着目して精 度を高める手法を提案 木構造の包含関係によるトレーサビリティリンクのフィルタリング 逆ランキングペナルティ(RRP) 180行程度のトイプログラムと、3.4k行のOSSアプリに適用する実験 RRPを用いることで精度が向上した 現在の実装は自然言語のテキスト埋め込みモデルを利用しているため、 Docstringの記述に大きく影響される 展望 ソースコードの埋め込みも行えるモデルを利用するなど、手法を拡張することで Docstringの記述に影響される問題を解決する 関連研究[9]で利用されているデータセットなどに適用できるような実装を用意 して比較実験を行う 28