野口 の履歴(No.75)

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• 野口 へ行く。
  • 1 (2018-03-23 (金) 04:33:43)
  • 2 (2018-03-23 (金) 10:28:33)
  • 3 (2018-03-23 (金) 10:28:33)
  • 4 (2018-03-29 (木) 04:34:26)
  • 5 (2018-04-02 (月) 04:21:44)
  • 6 (2018-04-03 (火) 01:38:58)
  • 7 (2018-04-09 (月) 05:10:03)
  • 8 (2018-04-16 (月) 04:38:42)
  • 9 (2018-04-17 (火) 02:29:58)
  • 10 (2018-04-23 (月) 06:22:40)
  • 11 (2018-05-07 (月) 05:48:36)
  • 12 (2018-05-14 (月) 04:09:38)
  • 13 (2018-05-21 (月) 04:10:24)
  • 14 (2018-05-28 (月) 04:45:40)
  • 15 (2018-06-04 (月) 02:51:08)
  • 16 (2018-06-04 (月) 05:45:16)
  • 17 (2018-06-11 (月) 05:35:04)
  • 18 (2018-06-19 (火) 01:57:45)
  • 19 (2018-06-19 (火) 06:34:23)
  • 20 (2018-06-25 (月) 00:58:01)
  • 21 (2018-06-25 (月) 04:22:08)
  • 22 (2018-07-02 (月) 00:46:18)
  • 23 (2018-07-02 (月) 04:11:06)
  • 24 (2018-07-11 (水) 03:30:29)
  • 25 (2018-07-11 (水) 05:16:46)
  • 26 (2018-07-23 (月) 04:24:49)
  • 27 (2018-07-30 (月) 00:42:23)
  • 28 (2018-07-30 (月) 04:34:57)
  • 29 (2018-08-06 (月) 05:19:37)
  • 30 (2018-08-20 (月) 02:46:17)
  • 31 (2018-08-28 (火) 06:03:03)
  • 32 (2018-09-11 (火) 04:05:56)
  • 33 (2018-09-18 (火) 04:43:06)
  • 34 (2018-10-04 (木) 04:11:00)
  • 35 (2018-10-11 (木) 05:31:57)
  • 36 (2018-10-18 (木) 02:15:18)
  • 37 (2018-10-18 (木) 05:23:21)
  • 38 (2018-10-25 (木) 06:00:19)
  • 39 (2018-11-01 (木) 02:10:48)
  • 40 (2018-11-01 (木) 05:38:15)
  • 41 (2018-11-06 (火) 06:14:37)
  • 42 (2018-11-08 (木) 01:50:38)
  • 43 (2018-11-28 (水) 10:46:14)
  • 44 (2018-11-29 (木) 06:08:21)
  • 45 (2018-12-05 (水) 15:31:28)
  • 46 (2018-12-06 (木) 11:33:42)
  • 47 (2018-12-10 (月) 08:25:00)
  • 48 (2018-12-18 (火) 08:58:39)
  • 49 (2019-03-14 (木) 03:53:40)
  • 50 (2019-03-27 (水) 01:56:27)
  • 51 (2019-04-03 (水) 02:31:13)
  • 52 (2019-04-11 (木) 01:15:05)
  • 53 (2019-04-18 (木) 05:43:28)
  • 54 (2019-04-19 (金) 05:34:24)
  • 55 (2019-05-07 (火) 04:11:12)
  • 56 (2019-05-23 (木) 01:38:00)
  • 57 (2019-05-23 (木) 05:56:45)
  • 58 (2019-05-30 (木) 03:29:46)
  • 59 (2019-06-10 (月) 01:25:56)
  • 60 (2019-06-18 (火) 02:24:29)
  • 61 (2019-07-11 (木) 03:58:34)
  • 62 (2019-07-25 (木) 02:59:07)
  • 63 (2019-08-01 (木) 05:25:13)
  • 64 (2019-08-07 (水) 02:46:47)
  • 65 (2019-08-20 (火) 04:27:06)
  • 66 (2019-09-05 (木) 02:41:55)
  • 67 (2019-09-12 (木) 04:51:51)
  • 68 (2019-10-15 (火) 01:23:48)
  • 69 (2019-10-24 (木) 01:44:06)
  • 70 (2019-10-28 (月) 10:52:06)
  • 71 (2019-10-29 (火) 02:08:59)
  • 72 (2019-11-05 (火) 00:35:31)
  • 73 (2019-11-08 (金) 04:31:36)
  • 74 (2019-11-12 (火) 00:35:52)
  • 75 (2019-11-19 (火) 00:57:28)
  • 76 (2019-12-17 (火) 09:27:00)

---

野口

Memo†

研究テンプレート
研究室タスク管理
ガントチャート

• 野口/査読結果

Schedule†

査読結果†

ミーティング†

11/19†

DONE†

• 変更箇所の特定には2つのファイルの差分をASTのノード単位で取得するツールGumTreeを用いるようにする
  • GumTree:Fine-grained and Accurate Source Code Differencing ASE'14 Pages 313-324
  • Javaプログラム上でGumTreeを実行できるようになった
• 先行研究のデータセットにContext Bugのデータがあると思っていたが，クローンやクローン系譜のデータしか存在していなかった
• Context Bugを取得するにはContext Bugの研究で配布されているプログラムを実行することで得られるが，そのままではうまく実行できない
• Context Bugを取得するプログラムを実行できるように変更する必要があるが，まだ変更が完了していない

11/12†

• 先行研究ではContext Bugはどの部分が適切に変更されなかったことで発生するのかを明らかにしていない
  • Context Bugを修正する際にどの部分に変更が加えられたかを分析
  • コード複製時に複製先で変更すべき箇所の候補を特定するアルゴリズムを構築
    • 複製するコード片の外部と関連がある部分を特定し，要変更箇所の候補とする
    • アルゴリズムでは分析結果をもとに，特に変更に気をつけるべき部分の特定を行う
  • アルゴリズムが特定した変更すべき箇所の候補とコード複製時に加えられた適切な変更がどれだけ一致しているかを評価

DONE†

• 先行研究のContext Bugのデータセットを使えることがわかった

11/5†

DONE†

• 欠陥修正箇所が重複したコードに含まれる場合の修正の難しさを明らかにするための分析内容を考えた
  • 欠陥修正箇所が重複したコードに含まれる不具合票とそうでない不具合票との間で以下のメトリクスを比較
    • Maintainability Index(保守のし易さを示すメトリクス)
    • 不具合が報告されてからクローズされるまでの時間
• Maintainability Indexの調査
  • 以下の式で求められる
    • Maintainability Index = 171 - 5.2 * ln(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * ln(Lines of Code)
  • JavaのプロジェクトのMaintainability Indexを計測するフリーソフトを発見
    • https://github.com/rasioatmaja29/MaintainabilityIndex

10/29†

DONE†

• 2章（背景目的の部分）だけ書いた
  • クローン片を変更することで同じクローン集合に属するクローン片や関連するコード片に加えるべき変更を特定する手法を構築
  • クローンに加えるべき変更の調査手順を減らしつつ安全に変更を加える作業を進めることができる．
• 大まかな特定手順
  • 変更を加える部分がクローン片かどうかをチェック
  • クローン片ならばクローン片とペアを成すクローン集合を検出
  • クローン集合内で変更が必要なクローン片を特定
  • 同時に変更が必要なクローン片の内部で変更が必要な箇所を特定
  • クローン片と関連する部分で変更が必要な箇所を特定
• 気になること
  • 影響波及解析の手法が使えるかどうか
• 「クローンに限らず変更予測は必要では？」という疑問に対して
  • 変更範囲が広くなると考えられることからどの部分を変更すべきか把握しきれなくなるためクローン変更時の変更予測の必要性が増す

TODO†

• Maintainability Indexの調査
  • 欠陥混入クローンの修正の難しさを測定したい
• Maintainability Indexが使えるかの調査
• 使える場合はMaintainability Index用いて欠陥混入クローンの

10/24†

DONE†

• どのようなクローンにどのような変更を加えるとBTSで報告されるような欠陥が混入するかを分析
  • クローンのブロックの種類（for文，if文など）
  • 加えた変更（メソッド呼び出しを追加，宣言文を削除など）
  • 扱う不具合票は「Bug」とカテゴライズされたものに絞る
• 変更を加えるクローンの内部の状態やクローン周辺の状態によってコードクローンに欠陥が混入しやすくなるか
  • 内部の状態（クローンの複雑度，規模）
  • 周辺（データフローや制御フローに関連がある部分，同じファイルのクローン以外の部分）

10/15†

DONE†

• 分析方法
  • クローンにどのような変更が加えられたかを調査し、クローンに特有の欠陥混入の原因となるような変更を明らかにする

9/12†

DONE†

• Antlr4で構文木を作るところまではできた
• コード片をCRD形式に出力する方法を模索中

9/5†

DONE†

• ツール実装のために必要な技術を勉強中

8/20†

DONE†

• ツールは一通り完成
• 処理の並列化の途中

TODO†

• ツールの欠陥混入クローン特定方法の厳密さに難あり
• 見直す必要あり
• 変更追加リビジョンで変更されたクローンが修正リビジョンで壊れていないかを確認する処理を追加する

8/7†

DONE†

• ECTECのCRD生成部分のコード理解の途中

TODO†

• クローンの位置特定の別の方法も考えてみる
• なければCRD生成部分理解，移植続行

8/1†

DONE†

• AST生成方法の調査
  • ECTECではASTの生成はJavaのみに対応している（ライブラリはJDTを使用）
  • C/C++やPythonなどの言語を用いたプロジェクトも分析対象としたいためそれらの言語のASTを生成する方法を調査
  • antlr4を用いてCとPythonの構文木を抽出するところまではできた
• CRDの理解
  • ECTECのCRD生成部分のソースコードを読んだ
  • CRDを生成するためにASTを生成することができるライブラリを正しく理解する必要がある

TODO†

• とにかくECTECのCRD生成機能を使う

7/25†

DONE†

• 欠陥混入クローンが修正されたことを確認するためにCRDを使おうか検討中
  • 欠陥混入リビジョンで変更が加えられたクローンが修正リビジョンのどこにあるのかを特定する際にCRDを使いたい
  • リビジョンをまたいだクローンの位置特定ができていないので欠陥混入クローン収集ツールを動かせるところまで行けていない

7/11†

DONE†

• NiCadとCP-Minerの比較

6/18†

DONE†

• CP-Minerの入手方法の調査
  • CP-Minerを参照している論文を50本ほど見たが，使用している可能性がある論文が1本だけ
    • Scenario-Based Comparison of Clone Detection Techniques ICPC '08
  • ある論文では，「CP-Minerの代わりにオープンかつ広く使われているCCFinderとNiCadを使用」という記述があった
    • How Often Do Unintended Inconsistencies Happen? — Deriving Modification Patterns and Detecting Overlooked Code Fragments — ICSM '12
• ツールのクローン取り出す部分の修正が完了
• ツールの修正されたクローンの特定する部分の修正中

TODO†

• NICadとCP-Minerの比較
  • 出力するクローンに違いがあるかなどに注目しながら比較

6/10†

DONE†

• ツールを動かしてみてもまだ思うように動かない状態

5/30†

DONE†

• もう少しで実装完了
  • 修正クローンの特定の実装がほぼ完了

TODO†

5/23†

DONE†

• ツール実装中
  • クローンの収集部分は実装できた
  • 修正クローンの特定の実装に悩んでる途中

TODO†

• Javaのみで実装してみる

5/7†

DONE†

• ツール実装中

TODO†

• SZZアルゴリズム関連の理解
• ツールの実装
• commit guruの調査

TODO†

4/18†

DONE†

• 修正クローン検出ツール設計書
  • 修正クローン検出ツール設計.pdf

TODO†

• 引き続きRepo Toolsのコード理解
• ツール実装に入る

4/11†

• 研究計画
  • 研究計画.pdf

4/3†

• コードクローン検出ツール調査
  • クローン検出ツール調査.pdf

3/14(進捗報告)†

• 以下の論文を読んだ
  • Clone Region Descriptors: Representing and Tracking Duplication in Source Code
  • Enhancement of CRD-Based Clone Tracking
• ECTECのソースコード理解途中
• 目標はECTECに以下の機能を追加し，欠陥混入クローンの分析を行えるようになること
  • 欠陥混入クローンの特定
  • タイプ3のクローンの検出（できれば）

1日の活動報告†

12/11〜12/18†

• 卒論の2章，3章の執筆
  • RQを設定した理由などを書いた

12/10†

• クローンとメトリクスの情報を結びつける処理の記述中(メトリクス集計の一歩手前)
  • Understandが取得したメトリクスの情報で，オーバーロードした関数の識別ができていないことが分かった
  • オーバーロードした関数を含むクローンは正しくメトリクスを持ってこれない場合がある

12/6†

• クローンIDからクローンのコードの情報を得る処理を行うプログラムの大体完成

12/5†

• クローンIDからクローンのコードの情報を得る処理を行うプログラムの作成途中

12/4†

• 欠陥修正クローンを欠陥混入リビジョンまで遡る処理を行った
• 欠陥混入クローンがどのリビジョンに存在するかを判別する処理を行った

11/29†

• クローンセットの親子関係を始点と終点を指定してその範囲内の親子関係のあるクローンセットIDを取ってくるプログラムが完成

11/28†

• 久木田さんの修論を再び読んだ
• クローンセットの親子関係の情報から欠陥混入クローンの追跡が可能かも知れない
  • クローンセットの親子関係はCCTで取得済

ミーティング†

11/8†

DONE†

• メトリクス計測完了
• RQ1分析途中

11/1†

DONE†

• RQ1の分析の下準備中

TODO†

• 分析の続き
  • メトリクス結果：11/4（日曜日）まで　済
  • RQ1結果：11/7（水曜日）まで
  • RQ2-2，3：11/9（金曜日）まで
  • RQ2-1：11/10（土曜日）から

10/25†

DONE†

• 分析手順を考えた:分析手順.pdf
• 質問内容
  • メソッドに欠陥がある場合，その影響が及ぶのはそのメソッドを呼び出した側と考えていいのか

TODO†

• 分析開始

10/18†

DONE†

• RQについては先週考えたものの他に思いつくものがなかった
• Understandについて少しだけ調べた
  • brainで使えることを確認
  • コマンドラインで使えることがわかった

TODO†

• 分析設計を完了する

10/11†

DONE†

• RQを考えた

TODO†

• RQをもうすこし熟考する
• 実験方法を考える

10/4†

DONE†

• 背景，目的の整理

TODO†

• RQを再び決める
• 決まって実験が出来るようであればする

9/18†

DONE†

• RQ1の実験の途中

TODO†

• RQ1の実験
• RQ2の実験の用意

9/11†

DONE†

• 2，3章の修正，bibtexの導入

TODO†

• RQ1の実験を行う
• できればRQ2の実験も行う

8/28†

論文注意点†

• 「かなり」，「手軽な」などの主観がこもった表現を使わない
• 2章のタイトルがまずい
• 論文参照の部分を作る（bibtexを使う）
• 一度全体を箇条書きで書きなおす
• 何を解決するか決めるためにRQを設定する

その他問題点†

• 静的解析ツールで検出されなかったクローンは動的解析ツールでないと検出できないのでは？
• 目視は何を知りたいかでどのようなことに注目して行うかを決める．闇雲にやると時間を大きく浪費する

8/20†

DONE†

• 2章書いた

8/6†

DONE†

• Texで卒論を書けるようになるまで準備を整えた
• クローンのメトリクスを分析した論文を見つけた
  • Comparing Quality Metrics for Cloned and Non Cloned Java Methods

TODO†

• 先に目次を作る．次に実験→分析→アプローチなどの順番で卒論を書く
• 分析を進める

7/30†

DONE†

• UnderstandがOSS-BRAINにインストールされていることがわかった
• どのようなソースコードメトリクスを使うべきか論文を読むなどして考えたが，これといったものは見つからなかった

TODO†

• 卒論を書いてみる（先輩の論文を参考にする，先輩に見せる）
• Texを使ってみる

7/23†

DONE†

• 久木田さんに疑問点について質問し，szzClones.csvからバグ票に結びついたクローンを問題なく探し出すことが出来ることが分かった
• 不具合修正コミットで変更があったクローンの情報を収集した（csvファイルにまとめた）

TODO†

• ソースコードメトリクスを測るためのツール「Understand」をどうすれば使えるかを聞く
• どのようなメトリクスを使うべきかを考える（論文を読む）

7/11†

DONE†

• 今までCCTのDBにあるSZZテーブルはバグ票に結びついたクローンを集めたものと思い込んでいたが、そうでは無いことが判明
• バグ票に結びついたクローンはszzClones.csvというファイルにまとめられていることが分かった。しかし、バグ票に結びついたクローンを探す処理の部分が怪しい

TODO†

• 久木田さんにメール

7/2†

DONE†

• 片桐さんのツールの出力結果が正しいことを確かめた

TODO†

• 片桐さんが出したクローン数などのデータが正しいかどうかを確かめる

6/25†

DONE†

• RQ1を調べた:fb_szz.xlsx
  • 片桐さんのFindBugsのデータの中からBugラベルが付いたクローンのsource_commit_idに該当する部分を抽出した

TODO†

• 片桐さんが出したデータを再現できるかどうかを調べる
• 再現できそうなら再現してみる

6/19†

DONE†

• RQを考えてきた
  • RQ1:バグが混入しているクローンに頻出するFindBugsのバグカテゴリーはあるか
  • RQ2:バグが混入しているクローンの中でFindBugsでは見つけられなかったバグはどれだけ存在するか
  • RQ3:バグが混入しているクローンの内FindBugsでは見つけることが出来なかったもののソースコードにはどのような特徴があるか
  • RQ4:クローンに結びついていてFindBugsでは見つけられなかったバグの不具合票にはどのような特徴があるか

TODO†

• RQ1について調べてくる

6/11†

DONE†

• 久木田さんにメールで質問をした
  • rootCloneIdは追跡の起点となるクローン集合のIDのこと
  • cloneTraceStatus.csvはクローンの追跡の助けになるもの
• RQはまだ思いついていない

TODO†

• 片桐さんのRQの差分を考える
• findbugsの結果が実際のバグとどう関係があるかを調べる
• findbugsで見つけられなかったバグでクローンに結びついているものにはどのような特徴があるか

6/4†

DONE†

• 目視完了：bug_labbeld_clone.xlsx
  • 「observable、observer」、「競合」、「backpressure」、「onNext」という語が比較的頻繁に出現
  • 例外処理によるバグはプロジェクトの初期から少し経った辺りまでに頻出
  • まだ調べるべきことがないか少し不安
• 不具合票に結びついたクローン系譜を見るためのプログラムを作成途中
• RxJavaの勉強をしたが、難しい部分があるため十分に理解できていない

TODO†

• RQを4つほど考えて卒論を書いてみる
• CCTの動作が正しいかどうか確かめる（久木田さんにメールする）

5/28†

DONE†

• 30個ほど目視した
  • オペレータ以外の目立った特徴は見られなかったが、見落としている可能性がある。

TODO†

• RxJavaについてより詳しく理解する
• 残りの目視を行う
• クローン系譜を見る

DOING†

5/21†

DONE†

• bugラベルがついたクローンに特徴があるかどうかを目視で分析
  • operatorというディレクトリの下にあるソースコードに不具合混入クローンが集中していることがわかった
  • しかし、bugラベルがついたissue全体でoperatorの下のソースコードにバグが集中している
• ちなみに、RxJavaでのoperatorとはデータの流れを操作したりするために重要なものであるため、この部分にバグが混入するするとRxJavaのユーザに大きな損失を被る

TODO†

• 残りissueを目視
• クローン系譜も見てみる

DOING†

5/14†

DONE†

• bugラベルがついたgithubのissueとクローンが結びついたものをcsvファイルで出力した
  • issueのみに結びついたものは142個中、19個(片桐さんが調べた期間範囲)
  • プルリクエストを含むissueに結びついたものは351個中、108個(片桐さんが調べた期間範囲)

TODO†

• bugラベルがついたissueを目視する(例外処理があれば見ないようにする)
• 特徴があれば続行、なければ相談

DOING†

• Bug Propagation/FindBugsの論文で使っているプロジェクトとツールを使って野口卒業研究を実施する

5/7†

DONE†

• RxJavaのCCTのデータからクローンと結びついた不具合票をいくつか見た
  • バグに関することだけでなくリファクタリングを行うなどの内容も多かった
  • あるリビジョンでクローンに多くの不具合が混入した
    • 変更を加えられたファイルの数は1032個
    • 挿入された行数は134671行
    • 削除された行数は134674行
  • 実際は不具合票に対してどのような分析を行うべきかまだ決まっていない

TODO†

• ラベルが「bug」であるissueの内、クローンと結びついているものを検出する
• 不具合票に対してどのような分析を行うべきかを考える

DOING†

• Bug Propagation/FindBugsの論文で使っているプロジェクトとツールを使って野口卒業研究を実施する

4/23†

DONE†

• RxJavaのクローンとバグの分析を少しだけ行った
  • RxJavaのクローンとバグの分析（途中）.pdf

TODO†

• CCTのデータを使って分析を開始する

DOING†

• Bug Propagation/FindBugsの論文で使っているプロジェクトとツールを使って野口卒業研究を実施する

4/16†

DONE†

• 既存研究と自分がしたい研究の差分を考えた
  • 研究テーマ案.pdf

TODO†

• RxJavaのデータで分析開始
• 

DOING†

• Bug Propagation/FindBugsの論文で使っているプロジェクトとツールを使って野口卒業研究を実施する

DOING†

• CCTのソースコード読解，テーブル理解
• 大石さんの卒論を読む
• 研究テーマを具体的に絞り込む

4/9†

DONE†

• 森脇さんのクローン系譜の論文を読んだ
  • メモ：クローン系譜_森脇_修論(メモ).pdf
• CCTのソースコードを少しだけ読んだ
  • メモ：cct_source_understand.pdf
• 研究テンプレートに必要事項を記入した
  • 研究テンプレート.pdf

TODO†

• 研究テーマスライド作成：既存研究（片桐先輩）との差分をみんなが理解できるように

DOING†

• CCTのソースコード読解，テーブル理解
• 大石さんの卒論を読む
• 研究テーマを具体的に絞り込む

4/2†

DONE†

• 以下の論文を読んだ
  • A Comparative Study of Bug Patterns...の残り
    • メモ：A Comparative Study of Bug Patterns in Java Cloned and Non-cloned Code.txt
  • Bug Propagation through Code Cloning:...
    • メモ：Bug Propagation through Code Cloning: An Empirical Study.txt

TODO†

• コードクローンの系譜：http://sel.ist.osaka-u.ac.jp/lab-db/Mthesis/archive/121/121.pdf

DOING†

• CCTのソースコード読解，テーブル理解
• 大石さんの卒論を読む
• 研究テーマを具体的に絞り込む

3/29†

DONE†

• 以下の論文を読んだ
  • 片桐さんの卒論
  • A Comparative Study of Bug Patterns...の7ページまで

TODO†

• 読解が難しかったところを報告する（読んでもらう）
• A Comparative Study of Bug Patterns in Java Cloned and Non-cloned Codeの続き
• Bug Propagation through Code Cloning: AnEmpirical Study

DOING†

• CCTのソースコード読解，テーブル理解
• 大石さんの卒論を読む
• 研究テーマを具体的に絞り込む

3/23†

DONE†

• CCTの使い方を不具合の紐付けのやり方以外覚えた
• コードクローンの論文を5つほど読んだ
  • 久木田さんの論文
  • 生成抑止,分析効率化,不具合検出を中心としたコードクローン管理支援技術に関する研究動向
  • An Empirical Study of the Impacts of Clones
  • Evaluating Code Clone Genealogies at Release Level
  • Frequency and Risks of Changes to Clones

TODO†

• 片桐さんの卒論を読む
• A Comparative Study of Bug Patterns in Java Cloned and Non-cloned Code
  • http://ieeexplore.ieee.org/document/6975632/
  • 論文（A Comparative Study of Bug Patterns in Java Cloned and Non-cloned Code.pdf）
• Bug Propagation through Code Cloning: AnEmpirical Study
  • 論文（Bug_Propagation_through_Code_Cloning.pdf）

DOING†

• CCTのソースコード読解，テーブル理解
• 大石さんの卒論を読む
• 研究テーマを具体的に絞り込む

3/8†

DONE†

TODO†

• 大石さんと片桐さんの研究の引き継ぎ
• CCTの使い方を覚える
• コードクローン関係の論文を読む