研究グループ/コードクローン の履歴(No.65)

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

---

研究グループ

コードクローン研究グループ†

Missions†

• コードクローンの作成と利用がソフトウェア品質に与える影響の解明
• コードクローンの作成と利用における属人性の影響の解明

Projects†

• Projects/CodeClone：ECTECの使い方等の資料
• [[Projects/]]：研究テーマ1（To be updated）
• [[Projects/]]：研究テーマ2（To be updated）

CC班コアタイム†

• 13:30〜16:30
  • 来れない場合は連絡

Members†

• 大平
• 久木田
• 片桐
• 上西

資料†

• 2016/01/27: 久木田大ゼミ資料
  • 60160037_久木田 雄亮_ver3.key
  • 60160037_久木田 雄亮_ver3.pdf
• 日付：資料名
  • [添付]
  • [添付]

ミーティング議事録†

2017年01月25日†

久木田†

• DONE
  • 評価実験
    • クローン追跡ツールの処理時間計測
• TODO
  • 評価実験
    • クローン追跡精度（1年間の新規・削除クローンの目視）
  • 評価実験結果を論文に乗せる表にする
  • 分析例で使うプロジェクト選定
• MEMO

2017年01月19日†

久木田†

• DONE
  • 大ゼミ発表向けのポスター作成
• TODO
  • 評価実験
    • クローン追跡精度（1年間の新規・削除クローンの目視）
    • クローン追跡ツールの処理時間集計
• MEMO

上西†

• DONE
  • 出力をCSV形式を使ってとりあえず見やすくした
  • アプリ間類似度スコアが1にならない問題について、アルゴリズムのため1にできないことを理解した
  • 論文タイトル「標準API呼び出しの共起関係を利用したアプリ検索手法の提案（仮）」
  • 論理展開を見直し中
• TODO
  • 実験の設計を考えてまとめる（アルゴリズムを複数決めてどのアルゴリズムがいいかを調べる方向で）
  • 複数のジャンルからシンプルなアプリを2、3個取ってきて入れてみる（メモ帳など単機能っぽい系、音楽やPDFなどメディア系、カメラ系、メールやSNSなどインターネット系、などを想定）
  • 一部のクラスを追加したアプリを比べる
  • 読み込ませるアプリやクラス、メソッドの種類、数についての考察
  • トピック数、評価方法についての考察

2017年01月12日†

久木田†

• DONE
  • 論文に乗せる表の作成
  • クローンAuthorShip（回数Ver，変更行数Ver）の計測
• TODO
  • 大ゼミ発表向けのポスター作成
• MEMO

上西†

• DONE
  • 動くもの↓を作成
  • 同じアプリに含まれるクラス間の類似度を計算しないように実装を変更
  • 2アプリ間の差分クラス（と類似クラス）を計算するアルゴリズム（以下）を実装

    クラス間類似度群 = calc_class_sim(アプリ1の各クラス, アプリ2の各クラス)
    類似クラス群 = filter(類似度 >= 閾値, クラス間類似度群)
    差分クラス群 = filter(類似度 < 閾値 and not in 類似クラス群, クラス間類似度群)

    • 差分クラスとは類似したクラスが1つもないクラスのこと
    • ここで類似するとは閾値以上の類似度を持つことをいう
  • アプリ間類似度スコアを計算するアルゴリズム（以下）を実装

    入力アプリ = アプリ間類似度計算の中心にするアプリ
    被検索対象アプリ群 = 入力アプリ以外のアプリ群
    for 対象アプリ in 被検索対象アプリ群:
        クラス間類似度群 = calc_class_sim(入力アプリの各クラス, 対象アプリの各クラス)
        filter(入力側クラスが重複ならmax値のもの, クラス間類似度群)
        filter(対象側クラスが重複ならmax値のもの, クラス間類似度群)
        # ↓そこまで類似していないくせに中途半端に高い類似度などを無効にする
        filter(類似度 >= 閾値, クラス間類似度群)
        # ↓類似したクラス以外に関係ないクラスをたくさん持つアプリはスコアが減る
        対象アプリのスコア = sum(クラス間類似度群) / 対象アプリの全クラス数

    • スコアに使う類似度は両アプリの各クラスにとってmaxのものだけ
  • どのメソッドが類似度に影響したかなどは出力できない
• TODO
  • 実験の設計を考えてまとめる（アルゴリズムを複数決めてどのアルゴリズムがいいかを調べる方向で）
  • 複数のジャンルからシンプルなアプリを2、3個取ってきて入れてみる（メモ帳など単機能っぽい系、音楽やPDFなどメディア系、カメラ系、メールやSNSなどインターネット系、などを想定）
  • 一部のクラスを追加したアプリを比べる
  • 読み込ませるアプリやクラス、メソッドの種類、数についての考察
  • トピック数、評価方法についての考察

2016年12月22日†

久木田†

• DONE
  • FindBugsからの撤退（ソースをbuildする際のJavaバージョン切り替えが困難なため）
• TODO
  • 論文に乗せる表の作成
  • クローンAuthorShipの計測
  • 似たプロジェクトでの比較（クローン含有率など）
• MEMO
  • 追跡している感じを表の上で表現する

上西†

• DONE
  • 横森先生とSkypeミーティング
  • とりあえずそれっぽく動くものは作成（正しく動作するとは言ってない）
    • ↑正しくなかったことが判明
• TODO
  • 動くものを作成
  • 共通部分、差分を出して見やすいように
  • 論文を書く
  • 一部のクラスを削除したアプリを比べるのは？
  • 同じアプリに含まれるクラス間の類似度を計算しないように実装を変更
  • 少数のアプリなどでLSI部分テスト
  • 検索部分の仕組み(LSIの結果を見る部分)実装
  • 読み込ませるアプリやクラス、メソッドの種類、数についての考察
  • トピック数、評価方法についての考察

2016年12月15日†

久木田†

• DONE
  • Issue作成者，割り当て者，クローン変更者を紐づけて目視調査を行う
    • Derby目視確認.pdf
    • Derbyの修正漏れの例のように修正漏れが起きないように事前に発見する必要がある
    • 全く変更がないコードがバグ修正の過程で削除されるのであれば，事前に見つけることができるはず
    • strutsでは良い例が見つからなかった（対象としているコンポーネントが悪い？DERBYよりクローンとBugIssueの紐づいている数が少ないからか？）
• TODO
  • FindBugsとSZZを比較するために，FindBugsをかけてみる

上西†

• DONE
  • 研究発表会
  • 標準APIも難読化されているアプリを見つけて顔面蒼白（https://fossdroid.com/a/ldto-companion.html）
    • 「コードとリソースの圧縮」（https://developer.android.com/studio/build/shrink-code.html）
    • そもそもAndroidアプリの難読化はProGuardというツールで行われるらしい
    • リソースまで圧縮する機能はshrinkResourcesプロパティで設定可能だがデフォルトでは無効化されているらしい（圧縮がバグを起こしやすいから）
    • ProGuardは難読化結果との対応を示したmapping.txtも出力するらしい
  • アプリをノード、類似度をエッジの重みに利用したネットワーク図を作成すれば視覚的に評価しやすい？
• TODO
  • とりあえず動くものを実装中（DONE : データの保存形式をSQLiteに変更した）
  • 同じアプリに含まれるクラス間の類似度を計算しないように実装を変更
  • 少数のアプリなどでLSI部分テスト
  • 検索部分の仕組み(LSIの結果を見る部分)実装
  • 読み込ませるアプリやクラス、メソッドの種類、数についての考察
  • トピック数、評価方法についての考察

2016年12月08日†

久木田†

• DONE
  • struts(Component)の目視調査
    • struts目視確認.pdf
    • メソッド単位のクローンが存在していた
    • マージによるクローンの変更が多い
    • Derbyと同じくメソッドの呼び出し方法の変更も見ることができた
    • クローンが別のところに再利用されているものが見ることができた
  • CCTの追跡機能のバグ修正（間違った追跡を行っていた）
• TODO
  • Issue作成者，割り当て者，クローン変更者を紐づけて目視調査を行う
• MEMO
  • なぜIssueとクローンが紐づいているのか
  • クローンとIssueが紐づいたのであれば，どのように修正すれば良いのか，はじめからクローンを作らなければよいのかなどを考えながら目視しないと解決方法を見つけることができない

上西†

• DONE
  • アプリをビルドしてみた → 確かにソースにない.classが生成された
  • 今回の手法は「似ているアプリを検索する段階」と「差分の機能を示す段階」の2段階に分けて考える必要があるのでは？
  • 「似ているアプリを検索する段階」
    • とにかく似ているアプリを検索する（差分のことは気にしない）
    • クラス間ではなくきちんとアプリ間の類似度を測りたい？
    • クラスがベクトルなのでアプリはベクトル空間になる...
    • 相互部分空間法を使えばできる？
    • 最近の技術動向： 相互部分空間法への拡張と その応用事例.pdf
    • 部分空間法と識別器.pdf
  • 「差分の機能を示す段階」
    • 特定の2アプリ間（もしくは前の段階で挙げられた各アプリ間）における差分を探す
    • クラス間類似度（今までやってきたやつ）がより小さいものを提示すればいい？（メソッド数の少ないクラスの扱いが重要になりそう）
  • 実験ではそれぞれの段階を評価する？
    • 1段階目について、目視でアプリを確認しておいて、出力を見て考察する？
    • 1段階目について、F-Droidにおけるアプリのカテゴリは正解集合として使える？（使うべきではなさそう）
    • 2段階目について、目視でアプリの機能を確認しておいて、出力を見て考察する？
• TODO
  • とりあえず前回の手法を進める
  • 同じアプリに含まれるクラス間の類似度を計算しないように実装を変更
  • 少数のアプリなどでLSI部分テスト
  • 検索部分の仕組み(LSIの結果を見る部分)実装
  • 読み込ませるアプリやクラス、メソッドの種類、数についての考察
  • トピック数、評価方法についての考察

2016年11月29日†

久木田†

• DONE
  • どのクローンを見るのか観点を決める（変更ありとなし，一人の開発者と複数の開発者，Issueありとなし）
  • クローンの作成・変更がなぜ起きたのかを理解するために
    • コメント，コード，Issue Reportを見る
    • 特定のモジュールでどんなソースコードがクローンとして作成されているのかを見る
    • クローンに紐づいているIssueはどんなIssueなのかIssue Reportを見る
  • コードクローン内の処理自体の変更は確認できず，メソッドの呼び出し方法や型キャストの方法の変更が多く，他のコード（メソッド）などの変更に伴うものが多い
• TODO
  • strutsプロジェクトで目視を行う

上西†

• DONE
  • enum型は内部では特殊なクラスとして表現されているらしい（別の.classファイルとして生成される）
  • 単語数が極端に少ない文書の扱いについて（除去していいのか？）
  • 内部クラスが含む標準API呼び出しの数を調べてみた
    • 内部クラス（$マーク付きクラス）
      (161個, 平均値=3.987578)
      [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 5, 5, 5, 6, 6, 6, 6, 7, 7, 7, 8, 8, 8, 8, 9, 10, 14, 16, 16, 22, 28, 30, 37, 37, 41, 104]
    • 普通のクラス
      (55個, 平均値=28.527273)
      [0, 0, 1, 1, 1, 1, 1, 2, 3, 4, 4, 4, 5, 5, 5, 6, 6, 8, 8, 9, 10, 11, 12, 14, 16, 16, 19, 22, 23, 25, 27, 27, 27, 28, 29, 31, 32, 37, 38, 38, 40, 42, 42, 57, 57, 58, 61, 70, 74, 79, 79, 79, 82, 90, 103]
  • Android Studioでビルドできずに困っている
• TODO
  • 引き続き2つのアプリに含まれるクラスをソースなどと比較して確認する
    • アプリをビルドしたときに生成されるファイル（APK化前のファイル群）を確認する
  • 少数のアプリなどでLSI部分テスト
  • 検索部分の仕組み(LSIの結果を見る部分)実装
  • 読み込ませるアプリやクラス、メソッドの種類、数についての考察
  • トピック数、評価方法についての考察
• MEMO
  • ビルドシステムを確認してからビルドすること(笑)

2016年11月24日†

久木田†

• DONE
  • １つのクローンの追跡調査
    • 作成されてから削除されるまで一度も変更がないものがいくつかある
    • 削除されたクローンは長い間変更されていないものが多い
    • 一人の開発者のみが変更に関わっているクローンは比較的短い期間での変更が多い
    • クローンの作成・変更によってIssueが埋め込まれ，クローンの変更・削除によってIssueがFixされているものがあまり見られなかった
• TODO
  • どのクローンを見るのか観点を決める（変更ありとなし，一人の開発者と複数の開発者，Issueありとなし）
  • クローンの作成・変更がなぜ起きたのかを理解するために
    • コメント，コード，Issue Reportを見る
    • 特定のモジュールでどんなソースコードがクローンとして作成されているのかを見る
    • クローンに紐づいているIssueはどんなIssueなのかIssue Reportを見る

上西†

• DONE
  • 2つのアプリに含まれる全クラス同士の組み合わせのうち類似度の大きいものを順に出力。上位をソースなどと比較して確認した
    • クラスがネストされていることがある（$マーク）
    • たった1つ（ごく少数）の標準APIしか呼んでいないクラスが含まれている？
• TODO
  • 引き続き2つのアプリに含まれるクラスをソースなどと比較して確認する
    • アプリをビルドしたときに生成されるファイル（APK化前のファイル群）を確認する
  • 少数のアプリなどでLSI部分テスト
  • 検索部分の仕組み(LSIの結果を見る部分)実装
  • 読み込ませるアプリやクラス、メソッドの種類、数についての考察
  • トピック数、評価方法についての考察

2016年11月16日†

久木田†

• DONE
  • モジュール（クローンを含む）毎に分けて追跡，バグがあるものとないものの比較(derbyのjava/engine/org/apache/derby/impl/storeを調査)
  • issueがどこで，だれによって埋め込まれたか
• TODO
  • １つのクローンの追跡調査
  • pajekでクローンと開発者のグラフで，クローンの変更回数とクローンノードの大きさを比例させる
• MEMO
  • １つのクローンにおいて，だれが作成・変更し，いつだれがBugを埋め込み，修正していったのかを見ることによって，
  • 複数人が1か月に変更が行われていれば，共同のownerであるかもしれない

上西†

• DONE
  • 1116class_id.csv
  • 1116sim_all_0.txt
  • [添付]
• TODO
  • 2つのアプリに含まれる全クラス同士の組み合わせのうち類似度の大きいものを順に出力。上位をソースなどと比較して確認する
  • 少数のアプリなどでLSI部分テスト
  • 検索部分の仕組み(LSIの結果を見る部分)実装
  • 読み込ませるアプリやクラス、メソッドの種類、数についての考察
  • トピック数、評価方法についての考察

2016年11月10日†

久木田†

• DONE
  • プロジェクトのissue混入率ランキング
  • クローンの増減に関わった開発者の調査

• TODO
  • issueがどこで，だれによって埋め込まれたか
  • モジュール（クローンを含む）毎に分けて追跡，バグがあるものとないものの比較(derbyのjava/engineを調査)

• MEMO
  • クローンに関係のあるIssue数／全Issue数
  • Issueの分類
  • IssueでBugだったものと紐づいたクローンはあるのか derbyとstrutsをまず見る

上西†

• DONE
  • 研究発表会
  • コードがカオスだったので少しだけリファクタリング？
• TODO
  • 少数のアプリなどでLSI部分テスト
  • 検索部分の仕組み(LSIの結果を見る部分)実装
  • 読み込ませるアプリやクラス、メソッドの種類、数についての考察
  • トピック数、評価方法についての考察

2016年11月04日†

久木田†

• DONE
  • LOCとクローンLOCの時系列データのスムージング
  • バグ有・無クローンの比較（検定）

• TODO
  • クローンの増減に関わった開発者の調査
  • issueがどこで，だれによって埋め込まれたか
  • モジュール（クローンを含む）毎に分けて追跡，バグがあるものとないものの比較
  • プロジェクトのissue混入率ランキング

• MEMO
  • 古くから存在するクローンにissueが埋め込まれた場合，作成者と埋め込んだ人が違う開発者であれば，管理者が変わったことで発生した事象かも
  • バグが埋め込まれたクローンは誰が作成者・利用者・管理者か

上西†

• DONE
  • 前回実装完了部分を改良
  • 検索部分の仕組みを思いついた
• TODO
  • 検索部分の仕組み(LSIの結果を見る部分)実装中
  • 読み込ませるアプリやクラス、メソッドの種類、数についての考察
  • トピック数、評価方法についての考察

2016年10月27日†

久木田†

• DONE
  • 修論目次案
  • LOCとクローンLOCの時系列データ作成
• TODO
  • 修論目次修正
  • バグ有・無クローンの比較（検定）
  • プロジェクトごとの運用の違いは？

上西†

• DONE
  • StigmataCSV→コーパス変換部分実装完了
  • tfidf、LSI部分実装完了
  • アプリ収集用スクレイパー実装完了
• TODO
  • LSIの結果を見る部分実装
  • 読み込ませるアプリやクラス、メソッドの種類、数についての考察
  • なぜLSIなのか

2016年10月20日†

久木田†

• DONE
  • 大ゼミ質疑回答（今日中）
• TODO
  • 修論目次
  • バグ有・無クローンの比較（検定）
  • 共同作業を多くしている開発者グループの抽出
  • 分析・ケーススタディ・RQの設定
• MEMO
  • コードクローンを安全に管理するはGoalにならない
  • プロセスを見るとは
  • バグでなくIssueで
  • ユニーククローン数（累積クローン数）とは
  • クローン含有率＝クローン行数/全体コード行数（今日中）
  • プロジェクトごとにリビジョン系列でクローン含有率計算してグラフを書く

上西†

• DONE
  • ガントチャートらしきものを作成
  • 目次らしきものを作成
  • StigmataCSV取得部分実装
• TODO
  • LSIで実装（さすがに今週中）
  • （アプリ収集）

2016年10月13日†

久木田†

• DONE
  • 大ゼミスライド
• TODO
  • 大ゼミ質疑回答（今日中）
  • 分析・ケーススタディ・RQの設定

上西†

• DONE
  • 簡易版ガントチャート作成
    
    • 2016/10/
      
    • Python、Gensim理解（13,14,15）
      
    • コーパス作成部分実装（13,14,15）
      
    • LSI部分実装（15,16,17）
      
    • アプリ収集（17,18）
  • PythonやGensimの理解を進めている
• TODO
  • LSIで実装
  • （アプリ収集）

2016年10月6日†

久木田†

• DONE
• TODO
  • 大ゼミスライド

上西†

• DONE
  • 環境構築完了
• TODO
  • LSIで実装
  • （アプリ収集）
  • ガントチャート作成

2016年9月29日†

久木田†

• DONE
  • 関西支部大会発表
  • コードクローンの作成・利用過程の分析が必要な理由についてのスライド
  • Research Questions のスライド
  • Apache Strutsのクローン変更回数と変更間隔の集計（バグありとバグなしの比較）
• TODO
  • 大ゼミスライド

上西†

• DONE
  • やはりStigmataを使う方針に決めた
  • 実際のアプリにStigmataを適用して、出力をソースコードと比較した
    • smcモードは、各「クラス」の中に書かれているAPI呼び出しの順列を取るだけだった（メソッド単位ではなかった）
    • クラス単位ではAPI呼び出しの「順列」に意味はないと考えられる
  • オープンラボ用ポスターの作成にあたってざっくりと手順を書いた
    • ポスター : （上西_2016年度オープンラボ用ポスター.pdf）
    • LSIやLDAあたりを使う予定のため、久木田さんから頂いた資料も使って勉強中
• TODO
  • とりあえずLSIで実装してみる

2016年9月9日†

久木田†

• DONE
  • データリストで未完了の解析を行う（28プロジェクト完了）
  • Birdのmissing linksの論文を読む
  • 分析方法・結果のスライド作成
• TODO
  • 共同ファイル変更数の調査
  • 共同変更を多く行っている開発者が関わっているクローンの中身を見る
• MEMO
  • クローンサイズの分布をみることで大きなクローン，小さなクローンを定義する
  • インデントなどのバグに直接影響を与えることがないものは省きたい
  • Pajekのデータを使ってクローンまたはバグを介してつながりが太い開発者を見つけ出す
  • Birdの論文からサブグループとは何かを読む

上西†

• DONE
  • 玉田先生にStigmataについてメールで質問した
  • 今回はStigmataを使わない方針に決めた（ソースコードを解析する）
  • 既存の手法を意識して考えることにした
    • 阪大のアプリ比較ツール（Androidアプリケーション比較ツールの試作.pdf）
    • 連続して呼び出されている標準API呼び出しの順列を調べていた
    • この手法では順列を完全一致で調べていた？（もう少しゆるくていい？）
  • 機能抽出過程
    • 標準API呼び出しの順列は機能を表すはず
    • メソッドごとに標準API呼び出し順列を取得
    • tf-idf的フィルタリング？
    • BoW化？
    • いい感じにゆるめな手法を探している...
  • ラベル付け過程
    • エンドユーザーにもわかる抽象度の機能名は、クラス名やメソッド名にも表れているはず
    • 識別子名に対する自然言語処理（tf-idf的フィルタリング？）
• TODO
  • 実際の簡単なアプリの標準API呼び出し順列を確認、比較する

2016年8月31日†

久木田†

• DONE
  • データリストで未完了の解析を行う
  • スライドの分析の内容の枠組みを考える
• TODO
  • データリストで未完了の解析を行う（残り19プロジェクト）
  • Birdのmissing linksの論文を読む
  • 分析方法・結果のスライド作成

上西†

• DONE
  • feature locationは実装位置を特定するが、今回は実装位置の情報はいらないことを認識
  • LSIが何なのかを（なんとなくだが）理解
  • Marcus et al.の論文の1つ（Feature location using probabilistic ranking of methods.pdf）の一部を読んだ
    • 各メソッドの識別子名やコメントを1つのドキュメントとしてコーパスを作成する
• TODO
  • Stigmataの詳細を聞く

2016年8月26日†

久木田†

• DONE
  • 現状集まっているデータと集めているデータ（リポジトリとバグと解析完了か否か）
  • ファイルとクローンで違いがあるかどうか（ファイルバージョンのPajekデータ作成）
• TODO
  • データリストで未完了の解析を行う
  • Birdのmissing linksの論文を読む
  • スライドの分析の内容の枠組みを考える

上西†

• DONE
  • 全体MTGのスライド→研究発表_0.pdf
  • Chen et al.の手法はCVSの各リビジョンのdiff結果とコミットメッセージを紐付ける。アプリ検索には重い？
  • Marcus et al.の手法はソースコード内の識別子名やコメントを基にLSI（潜在意味解析）を行う。
• TODO
  • 手法の決定

2016年8月10日†

久木田†

• DONE
  • 複数プロジェクトのPajekデータ作成
  • Pajekのデータからクローン同士，バグ同士の2モードネットワーク構築
  • 媒介中心性の高いバグ票の目視(Ant,Struts)
• TODO
  • 現状集まっているデータと集めているデータ（リポジトリとバグと解析完了か否か）
  • ファイルとクローンで違いがあるかどうか
  • Birdのmissing linksの論文を読む
• MEMO
  • 3年寝太郎：クローンの平均変更期間を出して
  • クローンのミッシングリンクをネットワーク分析で繋げれそう

上西†

• DONE
  • 研究の背景、動機の、自分なりに納得のいく説明ができた
    • 研究発表（仮）0810.pdf
• TODO
  • 手法の決定、実験？

2016年8月4日†

久木田†

• DONE
  • SZZデータの利用方法変更
  • Pajekデータ作成：（人(fixした人) - バグID - クローンID）
  • 関西支部大会原稿作成
• TODO
  • 複数プロジェクトのPajekデータ作成
  • Pajekのデータからクローン同士，バグ同士の2モードネットワーク構築
  • ファイルとクローンで違いがあるか
• MEMO
  • Birdの研究との違いをどうするか
  • CCの管理においてよくないこととは？
    • CCの問題？
    • バグの内容の問題？（媒介中心性が高いやつ？）
    • 人の問題？

上西†

• DONE
  • word2vecをインストールした
  • webで見つけたサンプル的なものを動かしてみた
• TODO
  • word2vecの詳しい使い方を調べて実践
  • サーベイ論文を途中までしか読んでないので続きを読む
• 今後の方針？
  • stigmataで取得できるクラス名、メソッド名をword2vecしてみて、どんな類似語が出るか確かめる？
• ひとまずの機能の定義
  • 機能はメソッドの集合で構成される
  • それを一定のルールでまとめたものがクラスであり、機能と関連する

2016年7月28日†

久木田†

• DONE
  • FOSEに向けたデータ作成
    • SZZ出力確認
    • Pajekデータ作成：5プロジェクト分
    • クローンサイズ：行数＋ブロック（トークン数）
• TODO
  • SZZデータの利用方法変更
  • Pajekデータ作成：（人(fixした人) - バグID - クローンID）
  • 関西支部大会原稿作成

上西†

• DONE
  • word2vecの論文を読んだ
    • ショートメッセージの部分空間表現と宛先推定.pdf
  • 実験の方法をいろいろ考えてメモしていた
  • さらに読むべき論文を昨日教えてもらった
    • 動的機能捜索における関連度と探索戦略.pdf
    • The Role of Concepts in Program Comprehension.pdf
    • Feature location in source code a taxonomy and survey.pdf
• TODO
  • 教えてもらった論文を読む

2016年7月21日†

久木田†

• DONE
  • SIGSEのデータ作成
• TODO
  • FOSEに向けたデータ作成
    • SZZ出力確認
    • Pajekデータ作成：5プロジェクト分
    • クローンサイズ：行数＋ブロック（トークン数）

上西†

• DONE
  • 論文を読んだ
  • Stigmataの出力の意味など詳しい使い方を調べたが、わからなかった
  • Stigmata以外の指標も考えてみたが、するならまずはStigmataからしてみよう
  • birthmarkそのままだと量が多いので、無駄なものを減らす工夫が必要
• TODO
  • 玉田先生に聞く？
    • Stigmataの機能、出力、各birthmarkの意味
  • word2vecも見てみる

2016年6月30日†

久木田†

• DONE
  • プロジェクトのデータ取得(残りはeclipseとant)
  • コードクローン集計プログラム作成
• TODO
  • 取得したGitHubIssuesの整形

上西†

• DONE
  • CyberAgent内定
• TODO
  • 具体的な実験方法を考える
  • 論文読む
  • 簡単なAndroidアプリを作ってみる

2016年6月23日†

久木田†

• DONE
  • クローンの類似性を用いて追跡できていないクローンを減らす
  • プロジェクトのデータ取得（Spring Framework）
  • GitHub API を使ったIssue取得プログラム
• TODO
  • プロジェクトのデータ取得

上西†

• DONE
  • Stigmataで実際のアプリを解析してみた
  • Stigmataの出力を整形してソートしてみた（が、現時点では意味不明）
• TODO
  • 具体的な実験方法を考える
  • 論文を読む

2016年6月16日†

久木田†

• DONE
  • Ant分析のテーブルを埋める
  • SIGSE投稿
  • 削除されたコードクローンの確認
• TODO
  • プロジェクトのデータ取得
  • クローンの類似性を用いて追跡できていないクローンを減らす

上西†

• DONE
  • Stigmataの使い方を理解した
  • 前田さんから読むべき論文をもらった
• TODO
  • Stigmataで実際のアプリを解析してみる
  • 論文を読む

2016年6月9日†

久木田†

• DONE
  • クローンを変更した人，クローンを増やした人の調査
• TODO
  • 　テーブルを埋める

上西†

• DONE
  • 論文を1つ読んだ
  • データベース演習をがんばった
  • 輪講資料を作った
  • 考えた
    • 検索するには、各アプリが使用しているクラスを見て機能を取得し、その機能ごとに重みを付けておく必要がある
    • ---- 機能の取り出し方はどうする？
    • ---- 機能を自動で取得するには？
    • -------- 機械学習する？
    • ------------ 何を正解にする？
    • -------- ラベルを参考にする？
    • ---- 最適な重みは機械学習する？
• TODO
  • さらに論文を読む
  • 研究の進め方を確定させて、それに伴う何かをする

2016年5月30日†

久木田†

• DONE
  • クローン統計量調査
• TODO
  • クローンを変更した人，クローンを増やした人の調査

上西†

• DONE
  • 論文を2つ読んだ
• TODO
  • さらに論文を読む
  • 研究の進め方？を考える

2016年5月26日†

久木田†

• DONE
  • クローンセットがどのように追跡できなくなったかの目視確認
  • jEditに対してECTECとCCTをかける

• TODO
  • jEditのECTECバージョンとCCTバージョンの比較
  • 追跡ツール試作の章を書く

上西†

• DONE
  • バースマークというものを教えていただいた
• TODO
  • バースマークや深層学習について調べる

2016年5月19日†

久木田†

• DONE
  • SZZ(verGitHub)の実装
  • 取得したプロジェクトに対してSZZの適用

• TODO
  • クローン追跡がどの程度できているかの調査
  • 対象外にすべきディレクトリの特定

松浦†

• DONE
  • 東先輩からいただいた本の一章を読み終えた

• TODO
  • いただいた本を読み進めライセンスがどういうものなのか理解していく

上西†

• DONE
  • 輪講で発表した
• TODO
  • 進路について本気出して考えてみる（やっと）

2016年5月12日†

松浦†

• DONE
  • 論文を読んだ
• TODO
  • 東先輩が提案してくれた研究テーマを進めていく

久木田†

• DONE
  • いろんなプロジェクトに対してCCTをかける(JUnit,struts,jabref,Ant)
  • 取得したデータの確認
• TODO
  • SZZ(verGitHub)の実装
  • 取得したプロジェクトに対してSZZの適用

上西†

• DONE
  • 自動バグ修正に興味を持った
• TODO
  • 論文読む

2016年4月28日†

久木田†

• DONE
  • 大ゼミ発表
• TODO
  • いろんなプロジェクトに対してCCTをかける（現状あるのはstruts）
  • 取得したデータの確認

松浦†

• DONE
  • 研究テーマを考える
  • 修正忘れが起きるコードの.pptx

• TODO
  • 生データをみていく
  • 修正漏れの論文を調べていく

上西†

• DONE
  • リファクタリングに関することも考えることにしてみた
• TODO
  • 一貫性のある変更とは？を考える
  • 最低限読むべき論文がたくさんあるので読む

2016年4月21日†

松浦†

• DONE
  • 研究テーマを考える
  • 消滅をみてなにがわかるか.pptx

• TODO
  • ソフトウェアエンジニアリング基礎知識体系を読んで勉強する

久木田†

• DONE
  • nokogiri動作確認(特にマージコミット部分)
  • nokogiriバグ修正
  • スライド（ツール説明）

• TODO
  • 大ゼミ発表

上西†

• DONE
• TODO
  • 一貫性のある変更とは？を考える

2016年4月14日†

久木田†

• DONE
  • 全メソッドのつなぎ合わせ

• TODO
  • nokogiri動作確認(特にマージコミット部分)
  • 大ゼミ資料作りはじめ

松浦†

• DONE
  • 実装希望報告

• TODO
  • 論文を読み研究

2016年4月8日†

上西†

• DONE
  • ついさっきDB.getParentsCommitInfo()を実装
  • 全体MTGの輪講とデータベース演習を頑張ってました
• TODO
  • もっと論文を読む

松浦†

• DONE
• TODO

片桐†

久木田†

• DONE
  • Diffを用いたコード片特定

• TODO
  • 全メソッドのつなぎ合わせ
  • 大ゼミ資料作りはじめ

2016年4月1日†

上西・松浦†

• DONE
  • Nokogiri担当分（CommitInfoExtractor）完成
• TODO
  • 論文を読む

松尾大典†

• DONE
  • 自宅に環境構築
  • 全然進んでないです、むしろ後退
• TODO

片桐†

• DONE
  • CodeFragmentDetector, CloneDetectorの移行

• TODO
  • DBの仕様に合わせた変更

久木田†

• DONE
  • コード片特定，クローン特定
  • コードクローンの追跡（まだバグあり）

• TODO
  • 実装：マージ発生時のコード片，コードクローンの処理

2016年3月24日†

松尾大典†

• DONE
  • コード片変更箇所の特定フロー（進捗５割？）
    • DiffやDB接続は他から拝借するので独自部分は後はほぼ無い
    • DIffのとり方の変更に対応
• TODO
  • DB接続、確認クエリ、格納クエリ
  • 動作確認
  • コーディング規約を周りに合わせる

久木田†

• DONE
  • データベース設計・実装(クローン部分のみ)
• TODO
  • 実装：マージ発生時のコード片，コードクローンの処理
    • コードクローンの追跡

1. Diffに含まれるファイルからコード片抽出
2. DBに格納されている前のリビジョンでのコード片と比較
3. 一致するコード片があればコードクローンとして追跡する
   • クローンのマージ
   • クローン情報のデータベースへの格納
   • 動作確認

片桐†

• DONE
  • フローの1, 2番目まで
    • コミットIDの取得
    • 任意のコミットIDのスナップショット中に存在するファイルリストの取得
  • コード片特定に必要なライブラリの移動
• TODO
  • コード片特定
  • クローンの組特定
• MEMO

上西・松浦†

• DONE
  • DB関連（ダミーデータは挿入できる）
• TODO
  • JGitを使ってデータを取得する部分の実装

2016年3月17日†

久木田†

• DONE
  • 実装：マージ発生時のコード片，コードクローンの処理
    • Diff取得（ファイル，行数，属性）
    • Diff比較
  • クローンのデータベース設計
• TODO
  • 実装：マージ発生時のコード片，コードクローンの処理
    • Diffに含まれるクローンの比較
    • クローンのマージ
  • データベース設計・実装

片桐†

• DONE
  • フローの1, 2番目まで
• TODO
  • codeFragmentの特定部分作成中です
• MEMO

上西・松浦†

• DONE
• TODO
  • 実装

大典†

• DONE
  • 既存コードを読んだ
  • 火曜に久木田さんと簡易MTGでDBを決定
• TODO
  • 担当フロー部分の実装（久木田さん作のDiffを流用）
• MEMO
  • 用事で午前中居ないかもしれないです

2016年3月11日†

久木田†

• DONE
  • 動作手順フローチャート作成
    • マージ発生時のコード片，コードクローンの処理（久木田）
• TODO
  • 実装
    • マージ発生時のコード片，コードクローンの処理

片桐†

• DONE
• TODO
  • 　フローチャート作成後，実装
• MEMO
• フローチャート
  • あるリビジョンのすべてのファイルをスキャンし，コード片とコードクローンを特定し，データベースに挿入
  • できたら，確認してもらった後，実装開始．

上西・松浦†

• DONE
  • 大まかな流れ図を作成
• TODO
  • 実装

2016年3月3日†

CC班コアタイム†

13:30〜16:30

久木田†

• DONE
  • コードクローンの追跡方法のスライド
    • KCTECドキュメント.pptx
• TODO
  • 動作手順フローチャート作成
    • リビジョン情報・関係を取り出す（松浦・上西）
    • コードクローンの特定（最初のリビジョンのスキャン）（片桐）
    • コードクローン変更箇所（コミット）の特定（大典）
    • マージ発生時のコード片，コードクローンの処理（久木田）

• データベースの再設計（一人ではできないので手伝ってほしいです）

上西†

• DONE
  • 複数の論文のアブストを読んだ
• TODO
  • 論文を読む

2016年2月26日†

久木田†

• DONE
  • この設計のままでは，計算量が膨大になり，クローンを追跡できないことが判明
• TODO
  • データベースの再設計

片桐†

• TODO
  • FileDetector作成中です
  • JGitの実装でモタついてます･･･。

上西†

• DONE
  • 久木田さんにCommitDetector作成を依頼→完成
• TODO
  • 論文を読む

2016年2月17日†

久木田†

• DONE
  • ECTEC(ver.kukita)作成
    • コード片特定機能作成
    • コードクローン特定機能作成
• TODO
  • コミット親子関係取得機能作成

片桐†

• DONE
  • 無いです・・・
• TODO
  • FileDetector作成中です

上西†

• TODO
  • CommitDetectorの作成

2016年2月10日†

大平†

• TODO
  • ひとつのバグに対して同時修正を必要としたクローンを含むファイルの割合はどうか

久木田†

• DONE
  • ECTEC(ver.kukita)機能の書き出し

• TODO
  • ECTEC(ver.kukita)作成
    • コード片特定機能作成

2016年2月5日†

久木田†

• DONE
  • ECTEC(ver.kukita)作成
    • データベース作成機能
  • 大ゼミ回答提出

• TODO
  • ECTEC(ver.kukita)機能の書き出し

2016年1月29日†

大平†

• DONE
  • コードクローン班用wikiページ作成
  • 研究テーマ２件のラフ設定
    • コードクローン作成パターンの時系列分析（プロジェクト開始から現在までのクローン作成の特徴を開発者別に時系列分析しパターン化する）
    • コードクローンの作成／利用における人間関係の分析（第三者のコードクローンを利用する際の人間関係とコード品質との関係を分析する）
• TODO
  • 疑問を解消する（サーベイ？）：研究する意味あるのかを再度確認するため．
    • 不具合修正に占めるコードクローンの修正割合は？ (modified clones/modified bugs)
    • 不具合修正とは無関係な変更に占めるクローンの変更割合は？(modified clones/changes)

久木田†

• DONE
  • ECTEC(ver.kukita)のデータベース設計
  • 大ゼミ発表

• TODO
  • ECTEC(ver.kukita)作成
    • データベース作成機能
  • 大ゼミ回答提出
  • コードクローンの作成理由の調査

片桐†

• DONE
• TODO
  • 来週のMTGに参加
  • エントリーシート作成
  • 大家さんに会いに行く
• ResearchQuestions
  • 開発者によってコードの再利用を行いやすい・されやすい傾向があるか
  • プロジェクトに長く携わることで再利用傾向に変化があるか
  • 他者の書いたコードを再利用することは不具合の混入に起因するか