野口
の履歴(No.72)
[
トップ
] [
新規
|
一覧
|
検索
|
最終更新
|
ヘルプ
]
履歴一覧
差分
を表示
現在との差分
を表示
ソース
を表示
野口
へ行く。
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
†
Mon
Tue
Wed
Thu
Fri
1
MT
2
生態
全M
情ネ
3
ソ特
TA
大ゼ
4
ソ特
TA
環境
5
↑
査読結果
†
↑
ミーティング
†
↑
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の使い方を覚える
コードクローン関係の論文を読む