グラフモデルを用いた OSS バグの影響分析方法の提案と評価
2017SE015 広岡 伸之甫 2017SE020 今堀 由唯 2017SE111 吉田 隆佑
指導教員 青山 幹雄
1. 研究背景と課題
1.1 研究背景
OSS(Open Source Software)開発では，参画する人数や規 模が大きいことが多い．OSS 開発では，様々な人が変更を加 えたり，バグの報告や修正，機能追加や変更を要求したりする ことが可能だからである．参画する開発者全員が自由に変更 を加えられるのが OSS 開発の大きなメリットである． OSS 開発の参画者の多くはバグの報告や修正を行っている． 中途参画者はバグの修正をする際に規模が大きいとバグの修 正を効率よくするのは難しい．開発に初めから携わっている参 画者の場合，バグが報告された段階で開発の全貌を把握して いるため，迅速に対応できる．しかし中途参画者では全貌を把 握していないため，修正に時間がかかると考える．1 つのバグ を修正するのに初期参画者に比べて中途参画者のほうがバ グ修正へのコストが高いとわかる． 1.2 研究課題 本稿では研究背景を踏まえ以下の3 点を研究課題とする． RQ1: バグとファイルの関係を可視化 RQ2: バグ影響の分析方法の提案 RQ3: 提案方法の有効性，妥当性評価
2. 関連研究
2.1 グラフデータベース(Graph DB) Graph DB はグラフ構造を管理できるデータベース管理 システムである．「ノード」，「エッジ」，「プロパティ」 の 3 要素によってノード間の関係を表現する「グラフ型の データモデル」を持つデータベースである． 2.2 プログラム内におけるバグと修正の偏り Hata らは Java プログラム内におけるバグの予測方法を提 案している．この中で変更履歴からバグの偏りについても 議論している[1]． 研究にて開発された予測モデルにて大規模なバグの発 見に成功した．分析対象は Java プログラムのため，プログ ラムに応じてバグの量に偏りがあることを明らかにした． 2.3 グラフモデル OSS コミュニティ構造の特徴量分析 Kato らは OSS コミュニティの開発者の行動に関する特徴 量を獲得し，その進化構造の分析を提案している[2]． 目的として，開発者に着目し，行動履歴から成長パターン を分類，３層で構成されるコミュニティ進化モデルを明らか にした．3. アプローチ
OSS バグの影響を分析するためにはバグとそれを修正し たファイルとの関係を含む大局的な分析が必要である．バ グと修正されたファイルをプロパティグラフ[3]でモデル化し， 開発期間ごとにバグのファイル修正への影響を分析するこ とを可能とする(図 1)． 図1 アプローチ4. 提案方法
提案方法は次の6 つのプロセスから成る．(図 2) (1) グラフモデル定義 ノード，エッジ，それぞれのプロパティを定義する． (2) 仮説，分析内容設定 設定した仮説に基づいて仮説ごとに明らかにする分 析項目を設定する． (3) Graph DB の実装Graph DB 実装は (3-a) GitHub からデータ収集， (3-b) Graph DB インスタンス生成の２つのプロセスか ら成る． (4) バグ影響分析 バグ影響分析は(4-a)サブグラフ抽出，(4-b)ファイルに おけるバグの数を抽出，(4-c)バグの影響を可視化の 3 つのプロセスから成る． (5) バグ影響分析の評価 可視化結果を評価する． (6) 仮説検証 分析で得られた結果から，設定した仮説を検証する． 必要に応じ，得られた結果に基づいて，仮説の追加 や変更を行い，一連のプロセスを繰り返す． 図2 提案方法 4.1 グラフモデル定義 分析対象は OSS 機械学習フレームワークとする．バグ， ファイル，ディレクトリをグラフモデルとして定義する． Graph DB生成 データ収集 グラフモデル 可視化プロセス ファイルとバグ報告の 関係を抽出 １つのバグで多くの ファイルが修正 →バグが与える影響大 ファイルとバグの関係を可視化バグとファイルの関係を分析 ファイルにおける バグ報告の数を抽出 開発期間毎に 分類 バグ影響分析 サブグラフ バグ影響定義 GitHub上のデータ (1)グラフモデル定義 (2)仮説,分析内容設定 (3)Graph DBの実装 (4)バグ影響分析 (5)バグ影響分析の評価 (6)仮説検証 (4-a)サブグラフ抽出 (3-a)GitHubからデータ収集 (3-b)Graph DBインスタンス生成 (4-b)ファイルにおけるバグの数を抽出 (4-c)バグの影響を可視化
4.1.1 ノード定義 バグ，ファイル，ディレクトリをノードとする．ノードのプロ パティ定義を表 1 に示す． 表 1 ノードのプロパティ定義 名称 定義 name ファイル名 or ディレクトリ名 num バグの番号 created バグが報告された日時 closed バグが解決された日時 finder バグの報告者 4.1.2 エッジ定義 エッジ定義を以下の表 2 に示す． 表 2 エッジ定義 名称 定義 has ファイルの所属関係 modified ファイルの修正関係 added ファイルの追加関係 removed ファイルの削除関係 renamed ファイルの名称変更関係 4.1 バグ影響定義 バグの影響をバグ影響度の偏りとファイルの修正集中とし て定義する． 4.1.1 バグ影響度の評価方法 バグの影響度をバグによって修正されたファイル数の割 合をとして，式(1)で定義する．パレートの法則をもとにバグ 影響度の偏りを表3 に示す２つの基準で評価する． バグN の 影響度 = バグN によって修正したファイル数 (1) 開発期間に修正したファイルの総数 表3 バグ影響度の偏り分類基準 基準 意味 80/20 8 割以上のファイル数が 2 割未満のバグ数で修正 60/40 6 割以上のファイル数が 4 割未満のバグ数で修正 4.1.2 ファイルの修正集中評価方法 ファイルが修正された回数が偏っていることは特定のモ ジュールがバグの原因となっている．時系列に沿って開発 期間毎のファイルの修正回数を分析する．
5. プロトタイプの実装
5.1 実装環境 プロトタイプの実装環境を以下の表 4 に示す． 表 4 実装環境 コンポーネント 名前 バージョン OS macOS Catalina 10.15.7 Graph DBMS Neo4j Desktop 1.3.4クエリ Cypher -
データ取得，変換 Python 3.9.1 利用する外部 API GitHub API V3 データ可視化ツール Excel 15.33 5.1 プロトタイプの構成 本稿の提案方法がGitHub 上の OSS で有効であるか評価 するためにプロトタイプを実装する(図 2)． 図2 プロトタイプの構成 (1) データ収集 GitHub から GitHubAPI を用いてバグとファイルに関す るデータを収集する．データ収集に用いるプログラム はPython で実装する． (2) Graph DB 実装 収集したデータをPython で成型する．成型したデー タからGraph DB インスタンスを生成し，Graph DB に 格納する． (3) バグの影響分析 サブグラフからバグ，修正ファイル数を獲得しExcel を 用いて可視化，分析をする．
6. OSS 機械学習フレームワークへの適用
提案方法をOSS 機械学習フレームワークである Chainer とPyTorch Geometric に適用した(図 3, 図 4,図 5)．各グラフ の構成要素を表5 に示す． 表5 グラフの構成要素適用対象 Chainer PyTorch Geometric ノード数(blob) 1,752 557 ノード数(tree) 233 56 ノード数(bug) 1,305 1,973 エッジ数 3,981 3,175 図3 Chiner GraphDB 作成結果 Graph DB GitHub開発データ バグ報告 データ収集 (GitHub API, Python)
可視化(Excel) バグ，修正ファイル数獲得
(Python, Cypher) Graph DB インスタンス生成
(Python, Neo4j, Cypher) (2)Graph DB実装 (3)バグの影響分析 リリース期間で分類(Cypher) サブグラフ (1)データ収集 ファイルデータ
図４ PyTorch Geometric GraphDB 作成結果
図5 PyTorch Geometric GraphDB 作成結果 （関係のあるノードのみ） 期間ごとにChainer のサブグラフを生成した(図 6)．多くの ファイルを修正しているバグや修正が集中しているファイ ルを確認することができた．4 期目は開発が終了しているた めバグの報告が他の期間と比較して少なかった． 期間1(2018/4/17〜10/24) 期間2(2018/10/25〜2019/5/15） 期間3(2019/5/16〜12/4) 期間4(2019/12/5〜2020/7/30) 図6 Chainer のバグと修正ファイルの関係 期間毎にPyTorch Geometric のサブグラフを作成した(図 7)． 期間1(2017/10/06~2018/05/24) 期間2(2018/05/25~2018/08/13） 期間3(2018/08/13~2018/12/18) 期間4(2018/12/18~2019/04/01) 期間5(2019/04/01~2019/04/29) 期間6(2019/04/29~2019/06/29） 期間7(2019/06/29~2020/02/04) 期間8(2020/02/04~2020/05/25) 期間9(2020/05/25~2020/07/07) 期間10(2020/07/07~2020/12/02） 図7 Chainer のバグと修正ファイルの関係 修正が集中して いるファイル 影響度の 大きいバグ 修正が集中して いるファイル 影響度の 大きいバグ 影響度の 大きいバグ 影響度の 大きいバグ 影響度の 大きいバグ 修正が集中して いるファイル
Chainer のバグ影響分析結果を示す(図 8, 図 9)．期間 4 はデータが少ないため対象外とした． 図8 Chainer のバグ影響度の偏り分布 図9 Chainer のファイル修正回数の分布 PyTorch Geometric のバグ影響分析結果を示す(図 10, 図 11)． 図10 PyTorch Geometric のバグ影響度の偏り分布 図11 PyTorch Geometric のファイル修正回数の分布
7. 評価
7.1 Chainer 全ての期間でバグ影響度は80/20 の基準を満たすことは なかったが60/40 の基準は全ての期間が満たしていた．全 ての期間で影響度は類似した曲線を描いている．このこと から修正したファイル数が同じバグの分布が各期間を通し て 類 似 し て い る こ と が 推 測 で き る ． ま た ， batch_normalization.py のファイルに修正が集中しているこ とが明らかとなり，期間2 と期間 3 では修正回数が共に最 多であった．ファイル名からバッチ正規化の機能であると思 われる．したがって期間2 からバッチ正規化に関する修正 が多く加えられていることが推測できる．また Chainer では 機能テスト用のファイルがあり，テスト対象ファイルと同頻度 で修正されていることも明らかとなった． 7.2 PyTorch Geometric 期間 1，2 ではバグ影響度 80/20 の基準を満たした.期間 4，5，7，8，9，10 では 80/20 の基準は満たさなかったが 60/40 の基準を満たした．期間 3，6 は基準を満たさなかった.多くの 期間でファイルに与える影響が大きいバグが存在することが 確認できた． 期間ごとのバグ番号を確認すると初期から中期ではバグ番 号が連続していないことが確認できる．またバグに繋がってい るファイルの数も少ない．このことからグラフデータベース作成 結果のときに確認できたグレーのノードである消されたファイ ルと繋がっていたバグが多数あることが推測できる． 全ての期間でファイルの修正集中の偏りを確認することは できなかった． ファイル修正回数の分布図では__init_.py のファイルの変 更回数が最多であるという結果が確認できた．異なるディレクト リに同じ名前のファイルが存在する．そのため，サブグラフで はファイルの修正集中の偏りは確認できなかったがファイル修 正回数の分布図では修正が集中しているファイルが存在する ことが確認できる結果となった．8. 考察
本稿の提案方法が有効であるか考察する． (1) バグ影響分析方法 グラフモデルを用いたことによりバグとファイルの関係を グラフとして可視化可能となった．さらに，特定の期間でス ライスしたサブグラフを作成することで関係の時間的変化 の分析が可能となった．分析結果よりバグ影響度に偏りが あることや修正が特定のファイルに集中していることが明ら かとなった．このことから，特定のファイルに着目してバグ 修正の効率化が期待できる． (2) グラフを用いたバグ分析 バグ分析にグラフモデルを用いたことによりファイル構造 やバグと修正ファイルの関係の分析が可能となった．また， サブグラフを作成することにより局所的な特徴を分析するこ とが可能である． (3) 関連研究[2]との比較 関連研究[2]ではプログラム内のバグと修正の偏りを明ら かにした．本稿はシステム全体でのバグと修正ファイルの 偏りを明らかとした点で意義がある．9. まとめ
本稿ではバグとファイルの関係をグラフモデルを用いて バグの影響を分析する方法を提案した．バグとファイルの 関係を可視化，分析することによりバグの影響度や修正す るファイルの偏りが明らかとなった．10. 参考文献
.[1]. H. Hata, et al., Bug Prediction Based on Fine-Grained Module Histories, Proc. of ICSE 2012, IEEE Computer Society, Jun. 2012, pp. 200-210.
[2]. S. Kato, et al., A Structural Analysis Method of OSS Development Community Evolution Based on A Semantic Graph Model, Proc. of COMPSAC 2018, IEEE Computer Society, Jul. 2018, pp. 292-297.
[3]. I. Robinson, et al., Graph Databases: New Opportunities for Connected Data, 2nd ed., O’Reilly, 2015. 0 2 4 6 8 10 12 lin k.p y _ _ in it_ _.p y g e t_ ite m .p y tr a in _im a ge ne t_ d a ta _p ara lle l.p y s o ftm a x_ cr o ss_ e ntr o py. p y te st _fo rg et. p y hu be r_ lo ss. p y te st _ so ftm ax. p y ca ff e_ fu nc tio n.p y te st _ n pz. p y b la c k_ o ut. p y te st _ lo g su m e xp .p y ro i_ po olin g _2 d.p y s ig m o id _ cro ss _ e ntr op y.p y ro lla x is.p y te st _ m e an _a bs o lu te _e rr or. p y c on fig ura tio n.r s t ste p 2 _d ata se ts _e va lu a to rs .r s t tra in .p y in s ta ll. rs t te st _ pe rm u ta te .p y no rm a l.p y s pa rs e_ m atm u l.p y re s ne t.p y 修 正 回 数 ファイル名 修正回数 0 2 4 6 8 10 12 ba tc h _n orm aliz ati on .p y fu nct io n_ no de .p y _ _in it __ .p y re d uc tio n .c u te st _se q ue nti al.p y te st _ co nv ert .p y lo g _ re p ort .p y cu dn n.c c te st _ do ub le _ bu ffe rin g_ o ptim iz… m o m e ntu m _s gd .p y te st _le a ky _re lu .p y te st _ ca st. p y te st _ ne ga tiv e_ sa m p lin g .p y cu dn n .h s oft m ax _ cr os s_ en tr op y. p y arr a y_ te st. cc s oft m ax .p y n orm al.p y p oo lin g .c c de v ice .c c te st _ o rth og on al. p y in sta ll. rs t 修 正 回 数 ファイル名 修正回数 0 1 2 3 4 5 6 7 8 9 10 b atc h_ n o rm a liz a tio n .p y te st _ cr e ate _ m n b n_ m o de l.p y gro u p_ n o rm a liz a tio n .p y te st _ pic kle _d a ta s e t.p y te st _ b ack en d .p y p ure _ n ccl _ c o m m un ic a to r.p y te st _ a rr a ys .p y te st _ d ou b le _ b uff e rin g _ op ti… te st _ np z. p y te st _ fu nc tio n _n o d e.p y u nif o rm .p y te st _ d ro po u t.p y b a tc h _re n o rm a liz a tio n .p y fill. c u flo a t1 6 _ te st .c c d e v ic e.p y b a ckw a rd _b u ild e r.c c c u da _ de vi c e .c c te st _ o bse rv a tio n _a g g re g a t… te st _ a llr e du ce _ p ers is te n t.p y ls tm .p y n u m e ri c. h m p i_ co m m u n ic a to r_ b as e .p y te st _ g ra d ie n t_ la rs .p y te st _ m u lt ip ro ce s s_ ite ra to r. p y c up y_ m e m o ry _ p ro fil e.p y be rn o ulli .p y c on fig u ra tio n .p y 修 正 回 数 ファイル名 修正回数
