ソースコードの特徴語を用いた Javaソフトウェア部品の 自動分類システム

Slides:



Advertisements
Similar presentations
『わかりやすいパターン認 識』 第 5 章 特徴の評価とベイズ誤り確率 5.4 ベイズ誤り確率と最近傍決定則 発表日: 5 月 23 日(金) 発表者:時田 陽一.
Advertisements

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 1 ソフトウェア部品推薦のための.
LZ符号化 森田 岳史.
パネル型クエリ生成インタフェース画像検索システムの改良
ソースコードの特徴語を用いた Javaソフトウェア部品の 自動分類手法の提案
近似アルゴリズム 第10章 終了時刻最小化スケジューリング
国内線で新千歳空港を利用している航空会社はどこですか?
知識情報演習Ⅲ(後半第1回) 辻 慶太(水)
ソースコードの編集内容を入力とした ソフトウェア部品の自動検索
On the Enumeration of Colored Trees
情報爆発A01支援班 マイサーチエンジン開発環境支援グループ 中村聡史, 大島裕明, 田中克己, 喜連川優
情報伝播によるオブジェクト指向プログラム理解支援の提案
Object Group ANalizer Graduate School of Information Science and Technology, Osaka University OGAN visualizes representative interactions between a pair.
リンク構造を考慮したベクトル空間法によるWebグラフ分割手法に関する研究
プログラムの動作を理解するための技術として
リファクタリングのための 変更波及解析を利用した テスト支援ツールの提案
メソッド名とその周辺の識別子の 相関ルールに基づくメソッド名変更支援手法
Java ソフトウェア部品検索システム SPARS-J のための リポジトリ自動更新機能の実現
Javaソフトウェア部品検索システムのための索引付け手法の提案と実装
プログラム実行履歴を用いたトランザクションファンクション抽出手法
プログラム実行時情報を用いたトランザクションファンクション抽出手法
静的情報と動的情報を用いた プログラムスライス計算法
メソッド間の依存関係を利用した プログラム理解支援手法の提案と実現
Javaクラスの利用関係を用いた ソフトウェア部品のカテゴリ階層構築法
コードクローンに含まれるメソッド呼び出しの 変更度合の分析
コードクローンに含まれるメソッド呼び出しの 変更度合の調査
識別子の命名支援を目的とした動詞-目的語関係の辞書構築
定兼邦彦 今井浩 東京大学理学系研究科 情報科学専攻
グラフアルゴリズムの可視化 数理科学コース 福永研究室 高橋 優子 2018/12/29.
ソースコードの特徴語を用いた Javaソフトウェア部品の 自動分類システム
動的情報を利用したソフトウェア 部品評価手法
利用関係に基づく類似度を用いたJavaコンポーネント分類ツールの作成
環境リスクマネジメントに関する 検索システム
コードクローン検出ツールを用いた ソースコード分析システムの試作と プログラミング演習への適用
利用実績に基づくソフトウェア部品検索システムSPARS-J
リファクタリング支援のための コードクローンに含まれる識別子の対応関係分析
プログラム動作理解支援を目的とした オブジェクトの振舞いの同値分割手法
ソースコードの特徴量を用いた機械学習による メソッド抽出リファクタリング推薦手法
オープンソース開発支援のための リビジョン情報と電子メールの検索システム
コードクローンの動作を比較するためのコードクローン周辺コードの解析
ソースコードの静的特性を用いた Javaプログラム間類似度測定ツールの試作
類似度を用いた WWW のリンク構造の解析 谷 研究室    栗原 伸行.
Webコミュニティ概念を用いた Webマイニングについての研究 A study on Web Mining Based on Web Communities 清水 洋志.
Parallel Setsによるライブラリの 組み合わせと利用状況の可視化
プログラム理解におけるThin sliceの 統計的調査による有用性評価
バイトコードを単位とするJavaスライスシステムの試作
Javaソフトウェア部品検索システムSPARS-Jの実験的評価
○ 後藤 祥1,吉田 則裕2 ,井岡 正和1 ,井上 克郎1 1大阪大学 2奈良先端科学技術大学院大学
ソフトウェア保守のための コードクローン情報検索ツール
コードクローンの理解支援を目的としたコードクローン周辺コードの解析
コーディングパターンの あいまい検索の提案と実装
コードクローン間の依存関係に基づく リファクタリング支援環境の実装
オブジェクトの協調動作を用いた オブジェクト指向プログラム実行履歴分割手法
構造的類似性を持つ半構造化文書における頻度分析
情報の集約 記述統計 記述統計とは、収集したデータの分布を明らかにする事により、データの示す傾向や性質を要約することです。データを収集してもそこから情報を読み取らなければ意味はありません。特に膨大な量のデータになれば読みやすい形にまとめて要約する必要があります。
プログラムスライスを用いた凝集度メトリクスに基づく 類似メソッド集約候補の順位付け手法
設計情報の再利用を目的とした UML図の自動推薦ツール
保守請負時を対象とした 労力見積のためのメトリクスの提案
コードクローン間の依存関係に基づく リファクタリング支援手法の提案と実現
クローン検出ツールを用いた ソフトウェアシステムの類似度調査
メソッドの同時更新履歴を用いたクラスの機能別分類法
ソースコードの編集状況に応じた ソフトウェア部品の自動推薦システム
UMLモデルを対象とした リファクタリング候補検出手法の提案と実現
ソフトウェア理解支援を目的とした 辞書の作成法
エイリアス関係を考慮した Javaプログラム用静的スライシングツール
プログラムの一時停止時に 将来の実行情報を提供するデバッガ
コードクローン解析に基づく デザインパターン適用候補の検出手法
オブジェクト指向言語における セキュリティ解析アルゴリズムの提案と実現
識別子の読解を目的とした名詞辞書の作成方法の一試案
Presentation transcript:

ソースコードの特徴語を用いた Javaソフトウェア部品の 自動分類システム 大阪大学の仁井谷です. ソースコードの特徴語に着目して,Javaソフトウェア部品を 自動分類し,カテゴリ検索に利用する手法を考案しましたので, それについて発表をさせていただきます. 大阪大学 井上研究室 仁井谷 竜介

背景 ソフトウェア部品検索システムの必要性 様々なソフトウェア部品検索システム ソフトウェア開発の大規模化・複雑化 ソフトウェアを再利用したり,管理する機会の増加 様々なソフトウェア部品検索システム まず,背景ですが, 現在ソフトウェア部品検索システムの必要性が言われています. その背景として,ソフトウェア開発の大規模化・複雑化や, ソフトウェアを再利用したり,管理する機会が増えた, ということがあります. そして実際に,様々なソフトウェア部品検索システムが提案・実現されています. # 以降メモ その多くは検索者にクエリを入力させ,そのクエリとの適合度の高い部品を表示する形式をとっています. 言い換えれば,多くの検索システムはクエリを入力する必要があります. 2005/03/10 名阪和合同研究会

検索システム クエリ検索システム カテゴリ検索システム クエリ(検索語・検索文)を入力として与える 適切なクエリを与えれば意図通りの文書が得られる カテゴリ検索システム あらかじめ用意されたカテゴリから文書を探す カテゴリはツリー状に構成されていることが多い クエリを入力しなくてよい 段階的に絞り込むことができる コンピュータ → ソフトウェア → 表計算 ソフトウェア部品に限らず検索システムを大きく分けたとき, クエリ検索システムと,カテゴリ検索システムに分けられます. クエリ検索システムは,検索語あるいは検索文を与えることにより,それに適合するもの検索するシステムです. その利点としては,適切なクエリを与えれば,意図通りの検索結果が得られる点です. また,カテゴリ検索システムは,あらかじめ用意されたカテゴリの中から文書を探す,というシステムです. 用意されたカテゴリは,大抵はツリー状に構成されており,検索者は段階的に自分の意図するものにカテゴリを絞り込んでいけます. 例えば,ここにあるように,コンピュータからソフトウェア,ソフトウェアからセキュリティ, というような絞り込みができます. 本研究では,カテゴリ検索に着目したいと思います. # 以降メモ 他の利点としては,文書中に出現する単語の中から検索する,全文検索のようなものと異なり, 文書中の単語に頼らない検索ができます 本研究では,カテゴリ検索に着目し, ソフトウェア部品検索システムに適用するとどうなるかについて考えたいと思います. 本研究ではこちらに着目 2005/03/10 名阪和合同研究会

カテゴリ検索を部品に適用したときの問題点 部品をカテゴリに分類する必要がある 追加・更新する部品をどのカテゴリに入れるか判断しなければいけない 対象数が多い カテゴリを再構成・維持する必要がある 分類・カテゴリ維持は手作業では困難 自動化が不可欠 カテゴリ検索システムの問題点として,分類する作業が必要となります. そのためには,追加あるいは更新される部品が,どのカテゴリに入れるのが適切か判断しなければいけません さらに,対象数が多いのでそのための手間は非常に大きなものとなります. また,今までにない機能の部品の追加や,カテゴリ内の部品数の増加などが起こった場合に, 新しいカテゴリの追加や,巨大なカテゴリの分割といった,カテゴリの再構成・維持作業も必要となります. これらの分類に関わる作業量は非常に大きくなるため、手作業では困難であるといえ, 実際にソフトウェア部品にカテゴリ検索システムを適用するには自動化は不可欠だといえます. # 以降メモ 自動化したい 低コスト 検索を必要とするぐらいは対象数があるはず 開発者が分類 追加時にどのカテゴリにするか決める必要がある 更新する度にカテゴリを見直すコストがある 検索システム管理者が分類 追加・更新するソースコードを理解しないといけない 対象数が多い 手作業では困難 ソースコードに対する理解が必要 そして,カテゴリ検索をするための準備作業も自然言語などの場合と同様にあると言えます. その一番の(他には収集とか)問題となるのが,検索対象となるソフトウェア部品の分類作業です. 部品数が少なくても困難な作業ではありますが,検索システムを必要とするぐらいは部品が数あるはずなので, その作業量は非常に大きくなります. そのためには,追加あるいは更新される部品の内容について理解していないといけません. 2005/03/10 名阪和合同研究会

研究の目的 ソフトウェア部品を対象としたカテゴリ検索用の自動分類 カテゴリのツリー(カテゴリ間の関係)の自動作成 Javaのクラスをソフトウェア部品とみなす 入力としてソースコードを用いる 低コストでカテゴリ検索の利点が得られる クエリを入力しなくてよい 段階的に絞り込むことができる そこで,本研究ではJavaソフトウェア部品を対象としたカテゴリ検索を行うための 分類とカテゴリのツリーの生成を,ソースコードを入力として自動で行いたいと思います. それにより,手作業に比べ低いコストで先ほど挙げたカテゴリ検索の利点が得られると考えられます. # 以降メモ なお,対象言語はJavaにしたいと思います. 2005/03/10 名阪和合同研究会

提案手法 ソースコードの特徴語に着目した分類 ソースコードを入力として部品をカテゴリに分類 カテゴリ間に関係を作成 特徴語=カテゴリ 以上の目的を達成するため,ソースコードの特徴語に着目し, ソフトウェア部品を分類する手法を提案します. ↓クリック まず,部品のソースコードを入力として与えます. このソースコードの特徴語を決定します. この例では,input, read, fileがこのソースコードの特徴語となります. 次に,先ほど決定した特徴語をそれぞれ1つのカテゴリとして部品を分類します. この部品は,input, read, fileの3つのカテゴリに分類されます. このままではカテゴリがたくさん並ぶだけになるので, カテゴリ間に関係を与え,このようにツリーのような関係を作成します. この発表では分類のところを説明します. # 以降メモ 特徴語は,ソースコードを特徴づける重要な語 →後で説明する(特徴語決定のページで) 特徴語を元にカテゴリを決定 inputを特徴語とする部品の集合をカテゴリinputとする *処理の流れ ソースコード 特徴語決定 カテゴリ カテゴリ木 *処理の流れのうちのどこか重要なところをこの後説明 特徴語=カテゴリ として部品を分類 特徴語の決定 カテゴリ間の関係を作成 input read file write input read file write read file input 部品(=Javaクラス) のソースコード write file 2005/03/10 名阪和合同研究会

分類の手順 解析 出現重み 計算 利用関係 計算 LSA 計算 単語一覧(特徴語の候補) 特徴語 決定 ソースコードを解析 単語重み計算 (2) (1) (2.1) (2.2) (2.3) 単語の出現情報 解析 出現重み 計算 利用関係 計算 LSA 計算 では,分類の流れについて説明したいと思います ↓クリック ソースコードを解析し,特徴語の候補となる単語一覧の取得と、ソースコード中での単語の出現情報を取得します. 次に,単語の出現情報を用いて特徴語を決定するための重みである「単語重み」を求めます. 中で3つの手法を用いて,重みの計算をしていますが,後で説明するのでここでは省きます. 次に,部品ごとに単語を重みでソートし,それぞれ上位10個の語を特徴語と決定します. 最後に,特徴語をそれぞれ1つのカテゴリとして部品を分類します. 最終的には,部品とカテゴリの組が得られます. 重み 重み 単語 重み (3) 単語一覧(特徴語の候補) 特徴語 決定 ソースコードを解析 単語重み計算 出現重み計算 利用関係による重み加算 LSA(潜在的意味解析法) 単語重みの高い語を特徴語とする 1つの特徴語をそれぞれ1つのカテゴリとして部品を分類 部品と特徴語の組 (4) カテゴリ 生成 2005/03/10 名阪和合同研究会

特徴語の候補となる単語の抽出 全ソースコード中に出現する単語の一覧を取得 語の記法統一を行う 複合語分割を行う 大文字、小文字、’_’の有無などの違いを統一する 例: XMLParser, XML_Parser, xmlParser → XmlParser 複合語分割を行う 複数で構成されている語を一部または全部に分割 例: XmlParser→ Xml, Parser, XmlParser # メモ 対象のソースコード中に出現するかには関わらない 大文字小文字の使い方や,アンダースコアを挟む,挟まないなどの記法の統一と, 複数の語が組み合わさってできている語から,その一部あるいは全部で構成される語を切り出しを行います. 2005/03/10 名阪和合同研究会

ソースコードの出現場所による重み計算 出現した場所を考慮した重要度を求める クラス定義 100×log(1+出現回数) ・・・ の和を求める 先ほど省略した特徴語を決定するときの重み計算の説明を行いたいと思います. まず,1番ですが,これは単語が出現した場所が クラス定義か,変数名かという情報を考慮した重要度の計算を行います. 次に,2番ですが, まず,利用関係とは,継承や・・・を指します. この計算は,利用している部品に存在する語の重みを,対象の部品の語の重みに加算します. これにより,差分しかかかれていない子クラスに親クラスの語の重みが加えられる,などの変化があります. 最後にLSAですが,これは出現の傾向が類似する語には似たような重みがつくような補正をかけます. # 以降メモ 次に2番ですが, ここでは,大文字小文字の使い方や,アンダースコアを挟む,挟まないなどの記法の統一と, 複数の語が組み合わさってできている語から,その一部あるいは全部で構成される語を切り出しを行います. 単語の一覧が処理前と変化するので,それにあわせた重みの再計算を行います. 対象語の削減 分類に影響のない語を削除 最後にLSAですが,これは統計的な処理により,先ほどの「fileとreadに関係するinputの重みが高くなる」 というような変化が得られます. 2005/03/10 名阪和合同研究会

利用関係による重み加算 利用している部品中の語の重みを加算する 利用関係に応じて加算時の割合を変える 継承 ×0.5 継承 ×0.5 メソッド呼び出し ×0.01 インスタンス化 ×0.05 など 先ほど省略した特徴語を決定するときの重み計算の説明を行いたいと思います. まず,1番ですが,これは単語が出現した場所が クラス定義か,変数名かという情報を考慮した重要度の計算を行います. 次に,2番ですが, まず,利用関係とは,継承や・・・を指します. この計算は,利用している部品に存在する語の重みを,対象の部品の語の重みに加算します. これにより,差分しかかかれていない子クラスに親クラスの語の重みが加えられる,などの変化があります. 最後にLSAですが,これは出現の傾向が類似する語には似たような重みがつくような補正をかけます. # 以降メモ 次に2番ですが, ここでは,大文字小文字の使い方や,アンダースコアを挟む,挟まないなどの記法の統一と, 複数の語が組み合わさってできている語から,その一部あるいは全部で構成される語を切り出しを行います. 単語の一覧が処理前と変化するので,それにあわせた重みの再計算を行います. 対象語の削減 分類に影響のない語を削除 最後にLSAですが,これは統計的な処理により,先ほどの「fileとreadに関係するinputの重みが高くなる」 というような変化が得られます. 継承関係での例 \語 file read binary 親クラス 5 3 0 子クラス 1 0 2 \語 file read binary 親クラス 5 3 0 子クラス 3.5 1.5 2 2005/03/10 名阪和合同研究会

LSA*(潜在的意味解析法) 重みが類似するものに近い重み与える補正 \語 input read file write print 先ほど省略した特徴語を決定するときの重み計算の説明を行いたいと思います. まず,1番ですが,これは単語が出現した場所が クラス定義か,変数名かという情報を考慮した重要度の計算を行います. 次に,2番ですが, まず,利用関係とは,継承や・・・を指します. この計算は,利用している部品に存在する語の重みを,対象の部品の語の重みに加算します. これにより,差分しかかかれていない子クラスに親クラスの語の重みが加えられる,などの変化があります. 最後にLSAですが,これは出現の傾向が類似する語には似たような重みがつくような補正をかけます. # 以降メモ 次に2番ですが, ここでは,大文字小文字の使い方や,アンダースコアを挟む,挟まないなどの記法の統一と, 複数の語が組み合わさってできている語から,その一部あるいは全部で構成される語を切り出しを行います. 単語の一覧が処理前と変化するので,それにあわせた重みの再計算を行います. 対象語の削減 分類に影響のない語を削除 最後にLSAですが,これは統計的な処理により,先ほどの「fileとreadに関係するinputの重みが高くなる」 というような変化が得られます. \語 input read file write print A 10 12 8 0 0 B 8 0 9 0 0 C 0 1 0 8 40 D 0 0 2 30 20 \語 input read file write print A 11 8 9 0 0 B 6 5 6 0 0 C 0 1 0 8 39 D 0 0 2 29 20 * Landauer, T. K., Foltz, P. W., & Laham, D. (1998). Introduction to Latent Semantic Analysis.  Discourse Processes, 25, 259-284. 2005/03/10 名阪和合同研究会

特徴語の決定 … 部品のソースコードから単語重みを求める 本手法では上位10語を部品の特徴語とする 次に,ソースコードの特徴語決定,について説明したいと思います. ↓クリック まず,ソースコードに出現する単語について調べます. ↓クリック(上段四角) 上の語の一覧ですが,これは全ソースコードの語を表しています. この例では,input, output, writeという語はこの部品のソースコード中には出現していませんが, 別の部品のソースコード中には出現しています. ↓クリック(下段四角) 下の情報ですが,ソースコード中にreadという語がメソッド定義で3回出現し,メソッド呼出で2回出現した, というような情報を表しています. この情報を元に ↓クリック(なし)  クリック(出現重み)  クリック(・・・)  クリック(単語重み)  クリック(省略部分消去) 単語重みを求めます. 次に,この単語重みから特徴語を決定します. ↓クリック(特徴語) 実際は,上位10個の語ですが この例では,重みが上からfile, read, inputの3語がこのソースコードの特徴語と決定されました. ↓クリック(input) ここで注目していただきたいのは,ソースコード中に出現しないinputが特徴語になっている点です. この手法ではソースコードに出現しない語も, 部品との関連が強いと特徴語になり得ます. # 以降メモ 10個に根拠はない が,ソースコードの語数や,重みに合わせて部品ごとに特徴語の数を決める としても,その指標がわからないので10語で評価してみた まず,このソースコードの情報から,ソースコード中の出現重みを求めます. ↓クリック(出現重み) これは,この(ソースコードの行を指して)情報を実数の重みに変えたものです. ↓クリック(・・・) その後途中の計算は(時間の都合で)省きますが,いくつかの計算を経て特徴語を決定する重みを求めます ↓クリック(単語重み) 省略した計算も含めて,ここまでの流れで,ソースコードから特徴語を決定するための単語重みを求める計算が終わります. この手法ではソースコードに出現しない語も特徴語になり得ます. readやfileに高い重みがあることから,この部品はinputにも関連深いと考えられますが, この手法はその関連深い語を特徴語とすることを実現します. 全ソースコードから得られた単語(特徴語の候補) input output read write get set file ・・・ 単語の出現情報 なし なし なし クラス定義 1 メソッド定義 2 メソッド定義2 メソッド呼出10 メソッド定義7 メソッド呼出8 メソッド定義3 メソッド呼出2 対象部品ソースコード中に出現する単語の出現箇所と出現回数 部品と関連が強いと ソースコードに出現しない語も特徴語になり得る … 単語重み 62.1 0 90.7 0 35.6 18.1 113.9 特徴語 ○ ○ ○ 2005/03/10 名阪和合同研究会

カテゴリの作成 得られた特徴語をそれぞれカテゴリとする 部品の特徴語をもとにカテゴリに部品を分類 特徴語=カテゴリ 特徴語の決定 以上の手法で部品の特徴語が決定されたので、 ↓(クリック) その特徴語をそれぞれカテゴリとします。 そのカテゴリに部品を分類します。 そして、カテゴリ間に関係を作成します。 カテゴリ、つまり特徴語に関係を作るわけですが、 このとき辞書は用いません。 次に、どのようにこの関係を作成するか説明を行います。 # メモ 前のページの特徴語をカテゴリにする図 次に続けるようにする 特徴語=カテゴリ として部品を分類 特徴語の決定 input read file write input read file 部品 write file 2005/03/10 名阪和合同研究会

カテゴリ間の関係の作成手順 親子関係 作成 集合類似関係 作成 特徴語類似関係 作成 カテゴリを入力とする ↓ 親子関係・集合類似関係・類似関係 の作成 カテゴリ、カテゴリで総当たりで調べる カテゴリ間の関係 親子関係 作成 集合類似関係 作成 特徴語類似関係 作成 カテゴリを入力とする 全てのカテゴリの組に対し3つの関係が成り立っているか調べる 成り立っていればその関係をグラフの辺として出力とする 複数成り立っている場合は優先順位に従って1つだけ決まる 2005/03/10 名阪和合同研究会

親子関係 カテゴリを部品の集合としてみたときの包含関係があるものの間に作られる関係 Aの要素の8割⊂B → Aが子 Bが親 部品の集合 まず、ツリー上の親子関係ですが、 カテゴリは部品の集合と見なせるので、 集合の包含関係を利用します。 このように包含される赤いカテゴリを子、包含している水色のカテゴリを親とします。 これらのカテゴリからはこのような木が作成されます。 また、完全に包含していない状態でもある程度の範囲に収まっていれば、親子関係があるとします。 部品の集合 カテゴリ 2005/03/10 名阪和合同研究会

集合類似関係 カテゴリを部品の集合としてみたとき類似するものの間に作られる関係 A∩Bが両方の8割を超えていたら類似 A B A B 次に、親子関係以外の関係について説明します。 # めも 類似度はコサイン尺度で求める A B A B 2005/03/10 名阪和合同研究会

特徴語類似関係 カテゴリに対応する特徴語間の類似度(コサイン尺度)が一定値以上のカテゴリ間に作られる関係 \語 input read 次に、親子関係以外の関係について説明します。 # めも 類似度はコサイン尺度で求める \語 input read A 11 8 B 6 5 C 0 1 D 0 0 input read θ cosθ = 類似度 2005/03/10 名阪和合同研究会

カテゴリ間の関係の優先順位 集合として同一 → 集合類似関係 包含関係 → 親子関係 成り立っていれば → 集合類似関係 集合として同一 → 集合類似関係 包含関係 → 親子関係 成り立っていれば → 集合類似関係 成り立っていれば → 親子関係 成り立っていれば → 特徴語類似関係 2005/03/10 名阪和合同研究会

カテゴリ間の関係の例 File Input Output Read Write Print Println Io 親子関係 集合類似関係 get set 親子関係 集合類似関係 特徴語類似関係 File Input Output Read Write Print Println Io 2005/03/10 名阪和合同研究会

実装 分類部 検索部 単語重み計算部 カテゴリ名 クラス名 検索部 利用関係 計算部 部品情報 表示部 SPARS-J 出現重み 計算部 ソースコード 次に,実現したシステムについて説明したいと思います. 本システムは,大きく分類部,検索部の2に分かれており,先ほど説明した手法は, (指し示して)単語重み計算部と特徴語決定部で実現されています. また,特徴語をカテゴリとしてみなしてDBに登録する部分はカテゴリ生成部の一部として実現されています. # 以降メモ 説明してない部分ばっさり切った方がいいかも(でも説明付け足したし 単語重み計算部 カテゴリ名 クラス名 検索部 利用関係 計算部 入力 部品情報 表示部 検索 SPARS-J 読込 出現重み 計算部 LSA 計算部 検索結果 カテゴリ DB カテゴリ情報 表示部 登録 カテゴリ木 表示部 SPARS DB SPARS-DB 読込部 特徴語 決定部 カテゴリ 生成部 登録 読込 2005/03/10 名阪和合同研究会

評価 実際に分類を行い,検索結果を評価する 適合率 = 入力はロボットシステム部品254クラス(35システム) 評価には適合率を用いた 適合の判断はソースコードを見て行った 次に実際に分類を行い,検索結果を評価した結果について説明したいと思います. 入力はRobocodeのロボット35体としました. 検索結果の評価として,今回は適合率を用いました. 適合率はこの式で与えられる,検索結果にどれだけ適合部品が含まれているかの割合です. 本発表では,この2つの適合率について述べたいと思います. # 以降メモ カテゴリ間の関係の評価 については省略 |検索結果 ∩ 適合部品| |検索結果| 適合率 = 2005/03/10 名阪和合同研究会

評価した適合率 カテゴリと部品の間の評価 SPARS-J (全文検索)との検索結果の比較 各部品が属するカテゴリの適合率 各カテゴリに属する部品の適合率 SPARS-J (全文検索)との検索結果の比較 SPARS-Jで検索されず本システムで検索されたものの中での適合率 次に実際に分類を行い,検索結果を評価した結果について説明したいと思います. 入力はRobocodeのロボット35体としました. 検索結果の評価として,今回は適合率を用いました. 適合率はこの式で与えられる,検索結果にどれだけ適合部品が含まれているかの割合です. 本発表では,この2つの適合率について述べたいと思います. # 以降メモ カテゴリ間の関係の評価 については省略 2005/03/10 名阪和合同研究会

結果一例:部品が属するカテゴリの適合率 riu.parts.EnemyStatusが属するカテゴリの適合率 適合率 0.7 カテゴリ 適合 ではここで,分類結果の一例を示したいと思います 左はPointというカテゴリに属する部品の一部. 右はEnemyStatusという部品の属するカテゴリの一覧です. 適合率はPointはここにあるものだけだと9/10で0.9ですが 全て合わせると0.93 EnemyStatusは7/10で0.7です カテゴリ 適合 理由 Point ○ 座標を扱う EnemyStatus 敵の状態を表す Get 状態取得メソッドが多い Time 時間を扱う Riu パッケージ名 Set × 状態設定は行わない Distance 距離を扱う This Java予約語 Param Javadocタグ(@param) Move 移動に関わる情報を持つ 2005/03/10 名阪和合同研究会

各部品が属するカテゴリの適合率 高い適合率が得られた 縦軸が各部品の適合率 横軸は部品(適合率でソートしている) avg. 0.86 これは,分類結果の全体です 左の図はカテゴリの中に属している部品がどれだけ適切なものかを表しています. 横の例ではオレンジが適合として, 4/7です. 右の図は部品がどれだけ適切なカテゴリに属しているかを表しています. 横の例では,2/3です. 縦棒がそれぞれの適合率になっています. ↓クリック 適合率はそれぞれ0.85と0.86と高い値が得られましたが, このようにいくつか適合率が0のカテゴリがあることも確認されました. # 以降メモ より正確な適合率 0.8460 0.8633 下のグラフは,縦軸が適合率を表し,縦線の1つ1つが1つの(左を指して)カテゴリと (右を指して)部品に対応します. 横軸はカテゴリと部品をそれぞれ適合率でソートして並べています. 横軸の数はカテゴリの数. 0から10手前の空白は適合率0のカテゴリである. 横軸に平行な点線は適合率の平均. ドキュメントコメント中の@paramのparamやBRタグのBR,thisのようなJavaであるために出現する語 がありました. 例:適合率 2/3 の部品 部品 高い適合率が得られた 適合するカテゴリ 適合しないカテゴリ 2005/03/10 名阪和合同研究会

結果一例:カテゴリに属する部品の適合率 Pointに属する部品(実際は108クラス)の適合率 適合率 0.93 ... 部品 適合 理由 ではここで,分類結果の一例を示したいと思います 左はPointというカテゴリに属する部品の一部. 右はEnemyStatusという部品の属するカテゴリの一覧です. 適合率はPointはここにあるものだけだと9/10で0.9ですが 全て合わせると0.93 EnemyStatusは7/10で0.7です 部品 適合 理由 teamZero.Point ○ 座標を扱う mirror.Calc 座標計算クラス mirror.posPredict.WaveEstimation 位置予測 kuro.Point riu.parts.EnemyStatus riu.Geometry.Geometry mt.GravPoint heg.Vector2D 座標クラス pbl3.BulletData riu.NotSerializable × 空のクラス 2005/03/10 ... 名阪和合同研究会

各カテゴリに属する部品の適合率 適合率0のカテゴリも存在した 高い適合率が得られた 縦軸が各カテゴリの適合率 avg. 0.85 これは,分類結果の全体です 左の図はカテゴリの中に属している部品がどれだけ適切なものかを表しています. 横の例ではオレンジが適合として, 4/7です. 右の図は部品がどれだけ適切なカテゴリに属しているかを表しています. 横の例では,2/3です. 縦棒がそれぞれの適合率になっています. ↓クリック 適合率はそれぞれ0.85と0.86と高い値が得られましたが, このようにいくつか適合率が0のカテゴリがあることも確認されました. # 以降メモ より正確な適合率 0.8460 0.8633 下のグラフは,縦軸が適合率を表し,縦線の1つ1つが1つの(左を指して)カテゴリと (右を指して)部品に対応します. 横軸はカテゴリと部品をそれぞれ適合率でソートして並べています. 横軸の数はカテゴリの数. 0から10手前の空白は適合率0のカテゴリである. 横軸に平行な点線は適合率の平均. ドキュメントコメント中の@paramのparamやBRタグのBR,thisのようなJavaであるために出現する語 がありました. 例:適合率 4/7 のカテゴリ カテゴリ 適合率0のカテゴリも存在した 高い適合率が得られた 適合する部品 適合しない部品 2005/03/10 名阪和合同研究会

考察 有効な分類が得られた 不適当な特徴語がある Javadocタグ(@param, @returnなど) HTMLタグ(br, li) 前置詞,助詞,代名詞(to, in, this) Javaの予約語(this) 以上の結果から得られた考察として, まずは,高い適合率から有効な分類が得られたと言えます. 特徴語として適さないが,重みが高い特徴語がある,と言う問題点が確認されました. それは,ドキュメントコメント中で頻繁に出る内容を表さないような語や, Thisといったものです. # 以降メモ 次に,特徴語が部品につき10個固定なのが問題であることがわかりました. 複雑な部品だと,特徴語が10個では足りず,その部品が属しているカテゴリに対し高い適合率を出しているものの, 特徴語のほとんどあるいは全てがソースコード中に出現しているため, SPARS-Jで検索ができていました. 逆に単純な部品だと,特徴語は10個では多すぎ,無関係な特徴語が含まれていました. そのため適合率は低くなっています. paramやbrやthisといった特徴語として適さないが重みが高く,特徴語になってしまうものがあることも確認されました. 2005/03/10 名阪和合同研究会

SPARS-Jとの比較 SPARS-Jで検索されず本システムで検索された部品の中でのカテゴリの適合率 SPARS-Jでは得られない部品 が検索できたカテゴリは43% avg. 0.49 次に,SPARS-Jとの比較ですが, SPARS-Jで検索できなかった部品がどれだけ正しく検索できているかの評価をします. 本システムで検索される部分をこのオレンジの○ SPARS-Jで検索される部分をこの青の○として, この薄いオレンジで塗られている部分の中での適合率を求めました. 検索結果によっては,このように本システムでの検索結果が SPARS-Jによる検索結果に含まれる場合があります. この場合は適合率は計算できません. それが適合率がマイナスでかかれている,この赤枠の部分です. 適合率が0のカテゴリや,適合率が計算できないカテゴリが多くありました. 本システム SPARS-J この部分での適合率 検索結果がSPARS-Jの検索 結果に含まれたカテゴリの場合 適合率が定義できない 2005/03/10 名阪和合同研究会

考察(1/2) 適合率の平均が低い 適合率が定義できないカテゴリが多い ソースコード中に出現しない特徴語は適合しないものが多くある カテゴリが減ったため、適合率の低いカテゴリ(特徴を表さない特徴語)の割合が相対的に増えた 適合率が定義できないカテゴリが多い ソースコード中に出現する特徴語が多い 適合率が計算できないカテゴリが多いため、適合率の低いカテゴリ(特徴を表さない特徴語)の割合が相対的に増えた 2005/03/10 名阪和合同研究会

考察(2/2) 特徴語が部品につき10個固定なのが問題 10個では足りないような複雑な部品 10個では多すぎるような単純な部品 その部品が属するカテゴリの適合率:高い 特徴語のほとんどあるいは全てがソースコード中に出現するため,SPARS-Jで検索可能 特徴を表すが、ソースコード中に出現しない語が特徴語にならない 10個では多すぎるような単純な部品 その部品が属するカテゴリの適合率:低い 無関係な特徴語が幾つも含まれる 以上の結果から得られた考察として, まずは,高い適合率から有効な分類が得られたと言えます. 特徴語として適さないが,重みが高い特徴語がある,と言う問題点が確認されました. それは,ドキュメントコメント中で頻繁に出る内容を表さないような語や, Thisといったものです. # 以降メモ 次に,特徴語が部品につき10個固定なのが問題であることがわかりました. 複雑な部品だと,特徴語が10個では足りず,その部品が属しているカテゴリに対し高い適合率を出しているものの, 特徴語のほとんどあるいは全てがソースコード中に出現しているため, SPARS-Jで検索ができていました. 逆に単純な部品だと,特徴語は10個では多すぎ,無関係な特徴語が含まれていました. そのため適合率は低くなっています. paramやbrやthisといった特徴語として適さないが重みが高く,特徴語になってしまうものがあることも確認されました. 2005/03/10 名阪和合同研究会

まとめと今後の課題 まとめ 今後の課題 ソースコードの特徴語に着目した分類手法 提案手法による分類の有効性を確認 部品ごとの適切な特徴語の数の調査 特徴語として適さない語の排除方法の考案 カテゴリ間の関係の評価 本研究では,ソースコードの特徴語に着目した分類手法を提案・実現し, 有効な分類が可能であることを確認しました. また,今後の課題としては,部品ごとの適切な特徴語の数の調査, 特徴語として適さない語の排除方法の考案が考えられます. 2005/03/10 名阪和合同研究会

以上で発表を終わります. 質問をどうぞ 終 2005/03/10 名阪和合同研究会