ソースコードの特徴語を用いた Javaソフトウェア部品の 自動分類手法の提案 # 残しては置きますがノートは適当です。 # 半分ぐらいしか一致しません。 # 読もうと思う方はあらかじめご了承下さい。 大阪大学の仁井谷です． ソースコードの特徴語に着目して，Javaソフトウェア部品を 自動分類し，カテゴリ検索に利用する手法を考案しましたので， それについて発表をさせていただきます． 大阪大学 井上研究室 仁井谷 竜介

背景 ソフトウェア部品検索システムの必要性 様々なソフトウェア部品検索システム ソフトウェア開発の大規模化・複雑化 ソフトウェアを再利用したり，管理する機会の増加 まず，背景ですが， 現在ソフトウェア部品検索システムの必要性が言われています． その背景として，ソフトウェア開発の大規模化・複雑化や， ソフトウェアを再利用したり，管理する機会が増えた， ということがあります． そして実際に，様々なソフトウェア部品検索システムが提案・実現されています． 以下に挙げているのが全てが検索のためのシステム、というわけではありませんが、 その様な機能を持っているものを挙げています。 全文検索なものや、ソフトウェアの分類をしているものや、コード片の抽出、 再利用可能な単位の取得をするものなどです。 # 以降メモ その多くは検索者にクエリを入力させ，そのクエリとの適合度の高い部品を表示する形式をとっています． 言い換えれば，多くの検索システムはクエリを入力する必要があります． 様々なソフトウェア部品検索システム SPARS-J MUDABlue gonzui Jarhoo Koders Prospector JcomponentSearch など 2005/07/29 SIGSE-149-7

検索システム クエリ検索システム カテゴリ検索システム クエリ（検索語・検索文）を入力として与える 適切なクエリを与えれば意図通りの文書が得られる カテゴリ検索システム あらかじめ用意されたカテゴリから文書を探す カテゴリはツリー状に構成されていることが多い クエリを入力しなくてよい 段階的に絞り込むことができる コンピュータ → ソフトウェア → 表計算 ソフトウェア部品に限らず検索システムを大きく分けたとき， クエリ検索システムと，カテゴリ検索システムに分けられます． クエリ検索システムは，検索語あるいは検索文を与えることにより，それに適合するもの検索するシステムです． その利点としては，適切なクエリを与えれば，意図通りの検索結果が得られる点です． また，カテゴリ検索システムは，あらかじめ用意されたカテゴリの中から文書を探す，というシステムです． 用意されたカテゴリは，大抵はツリー状に構成されており，検索者は段階的に自分の意図するものにカテゴリを絞り込んでいけます． 例えば，ここにあるように，コンピュータからソフトウェア，ソフトウェアからセキュリティ， というような絞り込みができます． 本研究では，カテゴリ検索に着目したいと思います． # 以降メモ 他の利点としては，文書中に出現する単語の中から検索する，全文検索のようなものと異なり， 文書中の単語に頼らない検索ができます 本研究では，カテゴリ検索に着目し， ソフトウェア部品検索システムに適用するとどうなるかについて考えたいと思います． # 何でカテゴリ？ クエリとカテゴリは一長一短。方式自体に優劣はつけられないが、 クエリものが多いので別のアプローチをしたかった。 本研究ではこちらに着目 2005/07/29 SIGSE-149-7

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

研究の目的 ソフトウェア部品を対象としたカテゴリ検索用の自動分類 カテゴリのツリー(カテゴリ間の関係)の自動生成 低コストで分類ができる Javaのクラスをソフトウェア部品とみなす 入力としてソースコードを用いる 低コストで分類ができる そこで，本研究ではJavaソフトウェア部品を対象としたカテゴリ検索を行うための 分類とカテゴリのツリーの生成を，ソースコードを入力として自動で行いたいと思います． それにより，手作業に比べ低いコストで分類が行えます． # 以降メモ それにより，手作業に比べ低いコストで先ほど挙げたカテゴリ検索の利点が得られると考えられます． なお，対象言語はJavaにしたいと思います． 2005/07/29 SIGSE-149-7

提案手法 ソースコードの特徴語に着目した分類 ソースコードを入力として部品をカテゴリに分類 カテゴリ間に関係を生成 特徴語の決定 以上の目的を達成するため，ソースコードの特徴語に着目し， ソフトウェア部品を分類する手法を提案します． ↓クリック まず，部品のソースコードを入力として与えます． このソースコードの特徴語を決定します． この例では，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/07/29 SIGSE-149-7

特徴語 自然言語で書かれた文書を対象とした分類，検索，データマイニング関連で使われる言葉 文書を特徴づける重要な語 求める手法は様々 統計的な特徴を利用 辞書を利用 確立された手法はない テキストマイニングツール では独自の手法が多い まず、特徴語というものについてですが、 これは自然言語で書かれた文書を対象とした分類，検索，データマイニング関連で使われる言葉で、 文書を特徴づける重要な語を指します。 右下の例ですが、Googleのヘルプの一部でPageRankの説明の前振りの部分です。 横の特徴語は私がでっち上げたものですが、 特徴語を見るだけで、この文章がGoogleの、外から見たPageRankの概要について触れていそうなことがわかります。 実際にはPageRankという単語はこの文章には出てきていないのですが、 PageRankの説明に入る導入部分なので内容はおさえています。 このような特徴語を求める手法は色々ありますが、 多くはTF-IDFやLSA t-score 対数尤度比 MI-score カイ二乗値といった統計的な特徴を利用するものや 辞書を利用するものの組み合わせからなっています。 ただ「これ」というような確立された手法があるわけではなく、 テキストマイニングツールでは独自の手法が用いられることが多いようです。 # memo TF-IDFやLSA t-score 対数尤度比 MI-score カイ二乗値を利用 辞書を利用 テキストマイニングツール では独自の手法が用いら れることが多い ESC keyness (WordSmith) 特徴語 * Google Web 順位 PageRank リンク 高度な次世代テクノロジーを利用したGoogleは、すべての問い合わせに対し的確な検索結果を迅速に出します。その秘密は、インターネットのリンク構造そのものに基づいて、関連あるWebサイトを自動的に順位付ける方式を用いてる点にもあります。 *http://www.google.co.jp/intl/ja/why_use.html 2005/07/29 SIGSE-149-7

ソースコードの特徴語 文書の特徴語 ソースコードの特徴語 出現した語だけに縛られない 文書を特徴づける重要な語 文書中に出現したかどうかは問わない ソースコードの特徴語 ソースコードを特徴づける重要な語 ソースコード中に出現したかどうかは問わない 出現した語だけに縛られない 本研究では、この特徴語をもとにソースコードの特徴語を定義します。 文書を対象とするいくつかの手法では、特徴語は文書中に出現したかどうかを問わないので、 本手法もそちらに倣っています。 これによりソースコード中に出現した語だけに縛られることなく特徴語の決定が行えます。 先ほどの例だとPageRankという語が文書に出てきていない特徴語でしたが、 文書中に出てこなくても内容を的確に表せる語がある場合、 出現した語だけに縛られないのは有益だと言えます。 ソースコードに適用して定義 2005/07/29 SIGSE-149-7

文書にない特徴の利用 対象言語(Java)の構文を利用 利用関係の利用 クラス名と変数名で語の重みを変える 出現した場所によって特徴を表す度合いは違う 利用関係の利用 継承やインスタンス化といったクラス間の関係をリンクとする リンク先のクラスに含まれる語も関連ある語だとみなす 関係のある部品の特徴もその部品の特徴 先ほどの説明では単に文書をソースコードに置き換えただけですが、 文書にないソースコードだけの特徴も特徴語の決定に利用しています。 まず対象言語、この研究ではJavaですが、これの構文を利用して、 出現した語の重みを変えています。 また利用関係を利用しています。 この利用関係は継承やインスタンス生成、メソッド呼び出しといったクラス間の関係です。 これらの関係があるクラス間にリンクがあるとし、 このリンクのあるクラスの語も、そのリンク元のクラスに関連のある語だとみなします。 2005/07/29 SIGSE-149-7

特徴語の決定 部品のソースコードをもとに特徴語を決定 特徴語の決定 カテゴリの生成 カテゴリ間の関係を生成 input read file では、手法を順に追って説明していきます。 まず部品のソースコードをもとに特徴語を決定します。 特徴語の決定 カテゴリの生成 カテゴリ間の関係を生成 input read file write input read file write read file input 部品(=Javaクラス) のソースコード write file 2005/07/29 SIGSE-149-7

特徴語決定の手順 解析 出現重み 計算 利用関係 計算 LSA 計算 単語一覧（特徴語の候補） 特徴語 決定 ソースコードを解析 (2) (1) (2.1) (2.2) (2.3) 単語の出現情報 解析 出現重み 計算 利用関係 計算 LSA 計算 その特徴語決定の手順を説明します ↓クリック ソースコードを解析し，特徴語の候補となる単語一覧の取得と、ソースコード中での単語の出現情報を取得します． 次に，単語の出現情報を用いて特徴語を決定するための特徴をどれだけ表しているかの重みである「単語重み」を求めます． 中で3つの手法を用いて，重みの計算をしていますが，後で説明するのでここでは省きます． 次に，部品ごとに単語を重みでソートし，それぞれ上位10個の語を特徴語と決定します． 最後に，特徴語をそれぞれ1つのカテゴリとして部品を分類します． 最終的には，部品とカテゴリの組が得られます． 重み 重み 単語 重み (3) 単語一覧（特徴語の候補） 特徴語 決定 ソースコードを解析 単語重み計算 出現重み計算 利用関係による重み加算 LSA（潜在的意味解析法） 単語重みの高い語を特徴語とする 部品と特徴語の組 input read file write file 2005/07/29 SIGSE-149-7

(1)特徴語の候補となる単語の抽出 全ソースコード中に出現する単語の一覧を取得 語の記法統一を行う 複合語分割を行う SPARS-Jに依存 大文字、小文字、’_’の有無などの違いを統一 例: XMLParser, XML_Parser, xmlParser → XmlParser 複合語分割を行う 複数で構成される語を一部または全部に分割 例: XmlParser→ Xml, Parser, XmlParser では、今の手順についてもう少し詳しく説明していきたいと思います。 SPARS-Jについて一言 # メモ 対象のソースコード中に出現するかには関わらない 大文字小文字の使い方や，アンダースコアを挟む，挟まないなどの記法の統一と， 複数の語が組み合わさってできている語から，その一部あるいは全部で構成される語を切り出しを行います． 2005/07/29 SIGSE-149-7

(2.1)ソースコードの出現場所による重み計算 各部品中の各語に対し、出現した場所を考慮した重み（特徴を表す度合い）を求める クラス定義 100×log(1+出現回数) 変数名 10×log(1+出現回数) ドキュメントコメント 15×log(1+出現回数) コメント 2×log(1+出現回数) ・・・ の和を求める 先ほど省略した特徴語を決定するときの重み計算の説明を行いたいと思います． 掛けている定数は出現した場所によってどれだけ特徴を表しているかの、 私の主観で決めた値です。 # 以降メモ まず，1番ですが，これは単語が出現した場所が クラス定義か，変数名かという情報を考慮した重要度の計算を行います． 2005/07/29 SIGSE-149-7

(2.2)利用関係による重み加算 部品間の重み加算 利用している部品中の語の重みを加算する 利用関係に応じて加算時の割合を変える 関係ある部品の特徴はその部品の特徴 利用関係に応じて加算時の割合を変える 継承 ×0.5 メソッド呼び出し ×0.01 インスタンス化 ×0.05 など # 以降メモ 次に，2番ですが， まず，利用関係とは，継承や・・・を指します． この計算は，利用している部品に存在する語の重みを，対象の部品の語の重みに加算します． これにより，差分しかかかれていない子クラスに親クラスの語の重みが加えられる，などの変化があります． 継承関係での例 ＼語 file read binary 親クラス 5 3 0 子クラス 1 0 2 ＼語 file read binary 親クラス 5 3 0 子クラス 3.5 1.5 2 2005/07/29 SIGSE-149-7

(2.3)LSA*（潜在的意味解析法） 全体に対する補正 重みが類似するものに近い重み与える 統計的に見て特徴を表していそうな語に重みを与える（表していないものは減らす） # 以降メモ 最後にLSAですが，これは出現の傾向が類似する語には似たような重みがつくような補正をかけます． ＼語 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/07/29 SIGSE-149-7

(3)特徴語の決定 各部品に対し、単語重みの高い上位10語を特徴語と決める input output read write get set 最後に、得られた単語重みをもとに特徴語を決定します。 単語重みの高い上位10語を特徴語とします。 input output read write get set file … 62.1 90.7 35.6 18.1 113.9 … input read file … 特徴語 2005/07/29 SIGSE-149-7

特徴語の決定の例 … 1つの部品に注目した特徴語決定の流れ 全ソースコードから得られた単語（特徴語の候補） 1つの部品に注目した特徴語決定の流れの例を示します。 ↓クリック まず，ソースコードに出現する単語について調べます． ↓クリック（上段四角） 上の語の一覧ですが，これは全ソースコードの語を表しています． この例では，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/07/29 SIGSE-149-7

カテゴリの生成 各部品から得られた特徴語をもとにカテゴリを作る 各カテゴリに、それを特徴語とする部品を分類 カテゴリの生成 特徴語の決定 以上の手法で部品の特徴語が決定されたので、 ↓（クリック） その特徴語をそれぞれカテゴリとします。 そのカテゴリに部品を分類します。 特徴語の決定 カテゴリの生成 カテゴリ間の関係の生成 input read file write input read file write read file input 部品(=Javaクラス) のソースコード write file 2005/07/29 SIGSE-149-7

カテゴリ間の関係の生成 カテゴリ間にある関係を分析してグラフとする カテゴリ間の関係の生成 特徴語の決定 カテゴリの生成 input そして、カテゴリ間に関係を生成します。 カテゴリ、つまり特徴語に関係を作るわけですが、 このとき辞書は用いません。 ↓（クリック） 次に、どのようにこの関係を生成するか説明を行います。 # メモ 前のページの特徴語をカテゴリにする図 次に続けるようにする 特徴語の決定 カテゴリの生成 カテゴリ間の関係の生成 input read file write input read file write read file input 部品(=Javaクラス) のソースコード write file 2005/07/29 SIGSE-149-7

カテゴリ間の関係の生成手順 親子関係 生成 集合類似関係 生成 類似関係 生成 カテゴリを入力とする ↓ 親子関係・集合類似関係・類似関係 の生成 カテゴリ、カテゴリで総当たりで調べる カテゴリ間の関係 親子関係 生成 集合類似関係 生成 類似関係 生成 カテゴリを入力とする 全てのカテゴリの組に対し3つの関係が成り立っているか調べる 成り立っていればその関係をグラフの辺として出力とする 複数成り立っている場合は優先順位に従って1つだけ決まる 2005/07/29 SIGSE-149-7

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

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

類似関係 カテゴリに対応する特徴語間の類似度（コサイン尺度）が一定値以上のカテゴリ間に作られる関係 ＼語 input read A 11 8 次に、親子関係以外の関係について説明します。 # めも 類似度はコサイン尺度で求める ＼語 input read A 11 8 B 6 5 C 0 1 D 0 0 input read θ cosθ = 類似度 2005/07/29 SIGSE-149-7

カテゴリ間の関係の例 カテゴリを作るまでに 用いた情報 Io Output Input File Input Output Read 親子関係 集合類似関係 類似関係 Io Output Input File Input Output Read Write Print Println Io File Write Read Print Println カテゴリを作るまでに 用いた情報 2005/07/29 SIGSE-149-7

実装 DB SPARS DB 入力 登録 読込 カテゴリ間の関係 生成部 カテゴリ間の関係 検索結果 読込 SPARS-J 検索部 特徴語 単語重み 計算部 特徴語 決定部 カテゴリ間の関係 生成部 次に，実現したシステムについて説明したいと思います． 本システムは，大きく分類部，検索部の2に分かれており，先ほど説明した手法は， （指し示して）分類部で実現されています． # 以降メモ 説明してない部分ばっさり切った方がいいかも（でも説明付け足したし カテゴリ DB カテゴリ間の関係 入力 検索部 検索結果 読込 カテゴリ 検索 登録 検索者 読込 分類部 2005/07/29 SIGSE-149-7

評価 実際に分類を行い，検索結果を評価する 評価したもの 適合率 ＝ 入力はロボットシステム部品254クラス(35システム) 評価には適合率を用いた 適合の判断はソースコードを見て行った 評価したもの カテゴリ適合率 部品適合率 特徴語の検証 次に実際に分類を行い，検索結果を評価した結果について説明したいと思います． 入力はロボットシステム部品254クラス(35システム) 検索結果の評価として，今回は適合率を用いました． 適合率はこの式で与えられる，検索結果にどれだけ適合部品が含まれているかの割合です． 本発表では，この2つの適合率について述べたいと思います． # 以降メモ カテゴリ間の関係の評価 については省略 |検索結果 ∩ 適合| |検索結果| 適合率 ＝ 2005/07/29 SIGSE-149-7

カテゴリ適合率の結果の例 部品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/07/29 SIGSE-149-7

カテゴリ適合率の結果 高い適合率が得られた 縦軸が各部品に対するカテゴリ適合率 横軸は部品（適合率でソートしている） 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/07/29 SIGSE-149-7

部品適合率の結果の例 カテゴリ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/07/29 SIGSE-149-7

部品適合率の結果 適合率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/07/29 SIGSE-149-7

特徴語の検証 ソースコード中に出現する特徴語が多い 不適当な特徴語が存在 Javadocタグ(@param, @returnなど) HTMLタグ(br, li) 前置詞，助詞，代名詞(to, in, this) Javaの予約語(this) 2005/07/29 SIGSE-149-7

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

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

以上で発表を終わります． 質問をどうぞ 終 2005/07/29 SIGSE-149-7