1 / 109

ソースコードの静的解析による ソフトウェア 保守支援に関する研究

ソースコードの静的解析による ソフトウェア 保守支援に関する研究. 大阪大学大学院情報科学研究科 コンピュータサイエンス専攻 井上研究室 小堀 一雄. ソフトウェア保守とは. ソフトウェア保守とは 納入後，ソフトウェアに対して加えられる，欠陥の修正，性能などの改善，変更された環境に適合させるための修正． [IEEE Std 1219] 保守に関するコスト 全ライフサイクルの 3 分の２を占める 20 年以上も保守を続けているシステムも存在する. ソフトウェア保守を支援したい. ソフトウェア保守の課題. 課題 保守担当者に以下を理解させるのが重要である

olin
Download Presentation

ソースコードの静的解析による ソフトウェア 保守支援に関する研究

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ソースコードの静的解析によるソフトウェア保守支援に関する研究ソースコードの静的解析によるソフトウェア保守支援に関する研究 大阪大学大学院情報科学研究科 コンピュータサイエンス専攻井上研究室 小堀 一雄

  2. ソフトウェア保守とは • ソフトウェア保守とは • 納入後，ソフトウェアに対して加えられる，欠陥の修正，性能などの改善，変更された環境に適合させるための修正．[IEEEStd 1219] • 保守に関するコスト • 全ライフサイクルの3分の２を占める • 20年以上も保守を続けているシステムも存在する • ソフトウェア保守を支援したい

  3. ソフトウェア保守の課題 • 課題 • 保守担当者に以下を理解させるのが重要である • どのように修正すべきか？ • どこを（どこまで）修正すべきか？ • 保守を難しくする要因 • 社会基盤を担う重要なソフトウェアは、大規模化・複雑化・ライフサイクルの長期化が進む • 保守期間中にドキュメント最新化が成されず、実際の動作と乖離が発生 • 保守のアウトソーシングやオフショアが進み、仕様決定時の情報を持たない人が保守を担当

  4. ソフトウェア保守を支援する方法 • 保守支援に関する様々な手段 • リバースエンジニアリング • ソースコードから設計情報を抽出する • 回帰テスト • 修正することでデグレードした箇所を特定する • ソースコード動的分析 • ソースコードの実行結果から振る舞いや特徴を分析 • 動作環境とテストケースが必要 • ソースコード静的解析 • ソースコードの記述を分析して振る舞いや特徴を分析 • 動作環境やテストケースは不要

  5. ソースコード静的解析を用いたソフトウェア保守支援ソースコード静的解析を用いたソフトウェア保守支援 • ソースコード静的解析 ソースコード静的解析技術を利用してプログラムから抽出された情報をもとに，プログラム保守の支援を目的として様々な解析が行われている．代表的な例を以下に示す． • デバッグ支援 • プログラムスライスを用いることで，デバッグ対象を限定する • 影響波及解析 • 再テストすべきテストケースを限定することで，テスト工程を効率化する • ソフトウェア部品の評価 • メトリクス値化された部品の性質から再利用性や品質を評価 • コピー部品の把握 • メトリクス計測された情報を配列化し，解析効率を上げる • 理解支援 • 解析結果情報を選別の基準とし，大量の部品からの選別作業を支援する

  6. 研究の目的 本論文では、下記の2つのソースコード解析技術に着目し、保守や再利用における支援を目的とした以下の解析手法の提案、提案手法を実現したツールの評価を行う． • プログラム保守支援を目的としたソースコード解析手法の提案 • アクセス修飾子過剰性の解析手法 • ソフトウェア類似部品の高速な解析手法 • 手法を実現したツールの評価

  7. 研究対象とする課題①　　　　　　　　　　「アクセス修飾子過剰性の解析」研究対象とする課題①　　　　　　　　　　「アクセス修飾子過剰性の解析」 保守の課題１：「どのように修正すべきか？」 • 課題の具体例 <開発者の想定する正しい手順> public class X { private String str = null; private void setString( ) { // ① str = "hello"; } public int getLength() { // ② return str.length(); } public int getCorrectLength() { this.setString(); return this.getLength(); } } ① 初期値がnullである変数strにStringオブジェクトを代入 ② 変数strの文字列長を取得 public 外部からの呼び出しを想定したメソッドに①→②の呼び出し順序を実装 getLength()のアクセス修飾子がprivateではなくpublic 外部から①を飛ばして②を直接実行可能 NullPointerExceptionの発生

  8. 研究対象とする課題①　　　　　　　　　　「アクセス修飾子過剰性の解析」研究対象とする課題①　　　　　　　　　　「アクセス修飾子過剰性の解析」 • 既存研究の問題 • アクセス修飾子の過剰性に関しての詳細な研究はあまり無い • アクセス修飾子のチェックのみ行い、適切さについて議論していない • アクセス修飾子の修正に関する支援が無い • privateにすべきメソッドやフィールドに関する警告を提示する • privateのみでなく、全アクセス修飾子について過剰性を解析・修正を支援する必要がある アクセス修飾子過剰性の解析・修正を支援する手法を提案する

  9. 研究対象とする課題②　　　　　　　　　　　　　「類似部品の高速な解析」研究対象とする課題②　　　　　　　　　　　　　「類似部品の高速な解析」 保守の課題２：「どこを(どこまで)修正すればよいか？」 • 課題の具体例 • 想定シナリオ 「類似部品に存在する類似バグを修正したい」 • 生産性を上げたい！ • ネットやリポジトリに過去の部品が大量に蓄積されている • 再利用して素早く実装した（コピー＆ペーストによる類似部品作成）． • ～ しばらくして ～ • ある類似部品に修正・デバッグを行った． • 他の類似部品にも同じ修正・デバッグを行う必要がある． • 大量の既存部品から、いますぐ類似部品見つけたい！

  10. 研究対象とする課題②　　　　　　　　　　　　　「類似部品の高速な解析」研究対象とする課題②　　　　　　　　　　　　　「類似部品の高速な解析」 • 既存研究の課題 • 文字列比較による類似測定手法が多い • 解析に時間がかかるため、解析対象が大規模化する場合、バッチ処理的な運用が想定される。 • しかし、類似部品の検索対象は随時作成されていくため、現在のリポジトリに対して即時に類似部品を発見したい。 ソースコード部品類似性の高速な 解析手法を提案する

  11. 博士論文構成と業績一覧の関連 • 博士論文構成 • 第１章　はじめに • 第２章　アクセス修飾子過剰性に関する研究　[1-1], [1-2], [2-1], [2-2] • 第３章　ソフトウェア部品類似性に関する研究 [1-3], [1-4], [2-4] • 第４章　むすび • 業績一覧 主要論文 [1-1] 小堀 一雄, 石居 達也, 松下 誠, 井上 克郎: “Javaプログラムのアクセス修飾子過剰性分析ツールModiCheckerの機能拡張と その応用例”. SEC journal, Vol.33, 2013.（学術論文，採録決定） [1-2] D. Quoc, K. Kobori, N. Yoshida, Y. Higo and K. Inoue,: ModiChecker: Accessibility ExcessivenessAnalysis Tool for Java Program, コンピュータソフトウェア, Vol.29, No.3, pp.212-218, 2012.（学術論文） [1-3] 小堀 一雄, 山本 哲男, 松下 誠, 井上 克郎: “コードの静的特性を利用したJavaソフトウェア部品類似判定手法” ，電子情報通信学会 論文誌D，Vol.J90-D(4) , pp.1158-1160, 2007.（学術論文） [1-4] Kazuo Kobori, Tetsuo Yamamoto, Makoto Matsushita, Katsuro Inoue: “Classification of Java Programs in SPARS-J”, International Workshop on Community-Driven Evolution of Knowledge Artifact, Session 4-3, Irvine, CA, 2003.（国際会議録） 関連論文 [2-1] 石居 達也, 小堀 一雄, 松下 誠, 井上 克郎: “アクセス修飾子過剰性の変遷に着目したJavaプログラム部品の分析”, 情報処理学会研究報告 Vol.2013-SE-180, No.1, pp.1-8, 2013. (国内会議録) [2-2] Dotri Quoc，Kazuo Kobori，Norihiro Yoshida，Yoshiki Higo，Katsuro Inoue: “Modi Checker : Accessibility Excessiveness Analysis Tool for Java Program”日本ソフトウェア科学会大会講演, Vol28, 6C-2, pp.1-7，2011. (国内会議録) [2-3] 小堀 一雄，山本 哲男，松下 誠，井上 克郎: “メソッド間の依存関係を利用した再利用支援システムの実装”, 電子情報通信学会技術研究報告, SS2004-58, Vol.104, No.722, pp.13-18, 2005.（国内会議録） [2-4] 小堀 一雄，山本 哲男，松下 誠，井上 克郎: “類似度メトリクスを用いたJavaソースコード間類似度計測ツールの試作”, 電子情報通信学会技術研究報告, SS2003-2, Vol.103, No.102, pp.7-12, 2003. (国内会議録)

  12. アクセス修飾子過剰性に関する研究 博士論文　第２章

  13. 背景：アクセス修飾子 • アクセス修飾子 • フィールド/メソッドへのアクセスを制限する修飾子(※) • public, protected, default(宣言なし),privateが存在 • 過剰に設定すると不具合の原因となりうる • 過剰：アクセス可能な範囲 > 実際のアクセス範囲 ※本研究ではクラスのアクセス修飾子については考慮しない

  14. アクセス修飾子過剰性を表すメトリクスAE(Accessibility Excessiveness) • フィールド/メソッドのアクセス修飾子を以下の３つに分類 • 適切：実際の被アクセス状況通りのアクセス修飾子が宣言されている（表中緑色） • AE：実際の被アクセス状況に比べて過剰に広いアクセス修飾子が宣言されている状態（表中オレンジ色） • NA(NoAccess)：どこからもアクセスされていない状態（表中黄色） 実際の被アクセス範囲に対応するアクセス修飾子 現在宣言している アクセス修飾子

  15. アクセス修飾子過剰性の解析・自動修正ツールModiCheckerアクセス修飾子過剰性の解析・自動修正ツールModiChecker ModiChecker 入力： MASU（既存のJava解析ツール ソースコードの内容・ 呼び出し関係を解析する AST(抽象構文木) データベース 解析対象の ソースコード群 フィールド/メソッドに宣言している アクセス修飾子を抽出 フィールド/メソッドの 呼び出される範囲を抽出 必要なライブラリ(.jarなど) アクセス修飾子の過剰性（AE）を抽出 MASU - http://sourceforge.net/projects/masu/ 各フィールド/メソッドのAE種別 出力：

  16. ModiCheckerの適用実験 • 目的 • 複数のオープンソースにおける各AEの分布状況を確認する • 考察事項 • AEの原因別の数を確認する • 将来的な利用を想定したことによるAE • 自動生成によるAE • 設定ミスによるAE • 対象ソフトウェア • MASU(519 files, 10200 LOC) • Ant 1.8.2 (1141 files, 127235 LOC) • jEdit 4.4.1(546 files, 109479 LOC)

  17. MASUに対する結果　～各AEの割合～ 35.7% 14.3% JSSST11

  18. MASUに対する結果　～考察～ • AEであるフィールド • 総数（割合） : 280(35.7%) • 将来的な利用を想定 : 20 • 自動生成 : 255 • 設定ミス : 5 • 自動生成ツールによって、一律publicと設定されたフィールドが多かった • AEであるメソッド • 総数（割合） : 253(14.3%) • 将来的な利用を想定 : 181 • 自動生成 : 6 • 設定ミス : 66 • JavaBeanの使用上機械的にpublicと設定されたメソッド(setter/getter)が多かった JSSST11

  19. 応用実験（１）　概要 • 目的： • 先の実験で、ソフトウェアのある時点におけるAEの解析をおこなうことができた • 次に、応用として、ソフトウェアの開発履歴を追ってAEの状態がどのように遷移するか分析することで、AEを解析すべき契機に関する情報を開発者に提案したい • 実験内容： • バージョンアップ時に、アクセス修飾子が適切・AE・NAのうち、どの状態に遷移していくのか可視化する • 計測事項：全バージョンにおける状態遷移総数における、状態遷移の種別ごとの割合を調査する

  20. 応用実験（１）　実験対象 • 実験対象：7つのJavaプロジェクト（バージョン数があり、最近まで開発が行われていて、世の中で利用されているソフトウェア）

  21. バージョン間における状態遷移 • 2バージョン間におけるフィールド/メソッドの状態遷移は以下を状態遷移図で表現する • 状態数：４ • 適切、AE、NA、なし（フィールド/メソッドが削除された状態） • 状態遷移数：18 • a ~ r a,p j 適切 なし m g k d b o l n c f NA AE e,q i,r h

  22. 結果考察-メソッド状態遷移(単位:%)

  23. 応用実験（１）　結果考察 • フィールド/メソッドに共通して得られた知見 • 一度、アクセス修飾子が設定されると、その後アクセス修飾子が変更されるケースは少ない • 用途が変わる場合は、フィールド/メソッド自体を変更する傾向にある • フィールドについて得られた知見 • アクセス範囲を明確にして作成されるものが大半 • メソッドについて得られた知見 • 作成時点ではアクセス範囲が定まっていないもの(NA)が多い

  24. 応用実験（２）　概要 • 目的： • 先の応用実験（１）で、ソフトウェアの開発履歴を追ってアクセス修飾子の状態がどのように遷移するか分析できた • 次に、さらなる応用として、どのようなバージョンアップの際にAEの変化が大きくなるのか分析することで、AE解析を行うべきタイミングを提案したい • 仮説 • Major version up時にAEが大きく変化する • 過剰なアクセス修飾子を設定されたフィールド・メソッドが追加される • Minor version up時にはAEはほとんど変化しない • 一度作成されたAEは修正されることはない（先の応用実験結果）

  25. Antの22バージョンにおけるAE変化量 • 仮説に合致しそうな結果を得たので検定を行う

  26. 応用実験（２）　結果考察 • フィールド：全AE・NAでMajorVU時とMinorVU 時の間で有意差（有意水準0.05）がみられた • メソッド：pub-pri,def-pri,def-na 以外のAE・NAについMajorVU 時とMinorVU 時の間で有意差（有意水準0.05）がみられた • 上記のAEは他のAE・NAに比べて各バージョン間の値の変化量が小さく，順位がタイとなる値が多かったためマン・ホイットニーの U 検定では誤差が出やすい状況下にあった． • 下記仮説を裏付ける結果が得られた • Major version up時にAEが大きく変化する • Minor version up時にはAEはほとんど変化しない

  27. ソフトウェア類似部品に関する研究 博士論文　第３章

  28. 研究対象とする課題②　　　　　　「類似部品（Javaクラス）の高速な解析」研究対象とする課題②　　　　　　「類似部品（Javaクラス）の高速な解析」 • 解決したい課題（その２） 「どこまで修正すればよいか？」 • 課題の具体例 • 想定シナリオ 「類似部品に存在する類似バグを修正したい」 • 生産性を上げたい！ • ネットやリポジトリに過去の部品が大量に蓄積されている • 再利用して素早く実装した（コピー＆ペーストによる類似部品作成）． • ～ しばらくして ～ • ある類似部品に修正・デバッグを行った． • 他の類似部品にも同じ修正・デバッグを行う必要がある． • 大量の既存部品から、いますぐ類似部品見つけたい！

  29. 研究対象とする課題②　　　　　　　　　　　　　「類似部品の高速な解析」研究対象とする課題②　　　　　　　　　　　　　「類似部品の高速な解析」 • 既存研究の課題 • 文字列比較による類似測定手法が多い • 解析に時間がかかるため、解析対象が大規模化する場合、バッチ処理的な運用が想定される。 • しかし、類似部品の検索対象は随時作成されていくため、現在のリポジトリに対して即時に類似部品を発見したい。 ソースコード部品類似性の高速な 解析手法を提案する

  30. 類似度メトリクス • 2つの視点から類似度メトリクスを計測する • トークン構成 • メトリクス ： ソースコードにおける各トークンの出現数 • トークン ＝ 予約語 + 記号 + 演算子 + 識別子 　　　 （96種） （49種） （9種） （37種） （１種） ※ jdk1.3の場合 • 意味：ソフトウェア部品の表層的特徴を表す • 複雑度 • メトリクス ：クラス内のメソッド数, サイクロマチック数（分岐の数）など • 意味：ソフトウェア部品の構造的特徴を表す • 数値比較のため、文字列比較に比べて解析コストの低下が期待できる

  31. 類似判定法 トークン構成に関するメトリクスと複雑度に関するメトリクスの全てにおいて 部品AとBのメトリクス値差分があらかじめ設定した閾値以内になった場合 類似部品と判定する （※今回の実験で経験的に設定した値）

  32. 類似判定の効率化 • メトリクス計測時に、いくつかのメトリクスでハッシュキーを作成する • 新しく類似測定をしたい部品Pが追加される • 部品Pのハッシュキー＝[10.62.125] • メトリクス[A,B,C]の閾値＝[0.0.1] ハッシュキー ＝ 8bit 8bit 8bit (24bit) メトリクスA メトリクスB メトリクスC 残りの全メトリクスを用いた類似判定の計算を行うのは、左下図の部品A，B，Cの3つのみに限定する 部品と、部品の持つメトリクス値から作成したハッシュキーを対応させた表を構築しておく 最終結果を変えずに解析コストを下げることが可能 [ 0. 0. 0]= null [ 10. 62.124]= 部品A [ 10. 62.125]= 部品B，部品C [ 10. 62.126]= null [255.255.255]= 部品Z ・ ・ ・ ・ ・ ・

  33. 適用実験の概要 • 実験目的 • 今回提案したメトリクス値比較による類似判定手法が、　　従来の文字列比較による類似判定手法より解析コストが低くなることを確かめる • 実験内容 • 同じソースコード群に対して、各手法を実装した２ツールによる類似判定を行った際の解析コストを比較する • 比較するツール • 既存の文字列比較を用いた類似度測定ツールSMMT • 今回提案したメトリクス比較を用いた類似度測定ツールLuigi • 実験対象のソースコード • JDK1.3に属する431個のクラス

  34. 考察（解析コスト） 文字列比較を用いた類似度測定ツールSMMTの計算コスト：24.35（sec） メトリクス値比較を用いた類似度測定ツールLuigiの計算コスト 対象 ： JDK1.3 431クラス 解析コストは1/150になった メトリクス値比較だけで1/5に低下 ハッシュキーにより、さらに1/30に低下 C：サイクロマチック数 M：宣言メソッド数 T : トークン構成メトリクス

  35. むすび 博士論文　第４章

  36. まとめ • 下記のソースコード静的解析技術を提案・評価した • アクセス修飾子の解析手法 • AEメトリクスを用いたアクセス修飾子解析手法を提案した • 上記手法をツールModiCheckerに実装した • ModiCheckerの適用実験により、以下を示した • AE・NAの解析・可視化を実現した • AEは一度作り込まれると、version upしても修正されず残る傾向にある • 多くのAE・NAにおいて、major version upの方がminor version upより多くのAEが発生する傾向にある • 高速なソースコード類似度判定手法 • メトリクス比較を用いた類似判定手法を提案した • 上記手法をツールLuigiに実装した • Luigiの適用実験により、以下を示した • 既存の文字列比較を用いた類似度測定ツールSMMTと比べて150倍の速度をもつことを示した

  37. 今後の研究方針 • アクセス修飾子解析手法 • AEが発生した原因をインタビューなどで調査する • AEの発生を防ぐ開発環境を提供する • 外部からの利用を想定したAEを自動判別する • テストケースも合わせてModiCheckerで解析する • 品質（バグ）とAEの関連性を分析する • 類似判定手法 • 現在、類似判定エンジンのみなので、単独のツールとして利用しやすいようにする • 各メトリクスの閾値の設定を簡単にできるようにする • Java以外の言語への対応

  38. 発表おわり ご清聴ありがとうございました．

  39. 以下、補足資料

  40. 業績一覧 主要論文 [1-1] 小堀 一雄, 石居 達也, 松下 誠, 井上 克郎: “Javaプログラムのアクセス修飾子過剰性分析ツールModiCheckerの機能拡張とその応用例”. SEC journal, Vol.33, pp.151-158, 2013.（学術論文） [1-2] D. Quoc, K. Kobori, N. Yoshida, Y. Higo and K. Inoue,: ModiChecker: Accessibility ExcessivenessAnalysis Tool for Java Program, コンピュータソフトウェア, Vol.29, No.3, pp.212-218, 2012.（学術論文） [1-3] 小堀 一雄, 山本 哲男, 松下 誠, 井上 克郎: “コードの静的特性を利用したJavaソフトウェア部品類似判定手法” ，電子情報通信学会論文誌D，Vol.J90-D(4) , pp.1158-1160, 2007.（学術論文） [1-4] Kazuo Kobori, Tetsuo Yamamoto, Makoto Matsushita, Katsuro Inoue: “Classification of Java Programs in SPARS-J”, International Workshop on Community-Driven Evolution of Knowledge Artifact, Session 4-3, Irvine, CA, 2003.（国際会議録） 関連論文 [2-1] 石居 達也, 小堀 一雄, 松下 誠, 井上 克郎: “アクセス修飾子過剰性の変遷に着目したJavaプログラム部品の分析”, 情報処理学会研究報告 Vol.2013-SE-180, No.1, pp.1-8, 2013. (国内会議録) [2-2] Dotri Quoc，Kazuo Kobori，Norihiro Yoshida，Yoshiki Higo，Katsuro Inoue: “Modi Checker : Accessibility Excessiveness Analysis Tool for Java Program”日本ソフトウェア科学会大会講演, Vol28, 6C-2, pp.1-7，2011. (国内会議録) [2-3] 小堀 一雄，山本 哲男，松下 誠，井上 克郎: “メソッド間の依存関係を利用した再利用支援システムの実装”, 電子情報通信学会技術研究報告, SS2004-58, Vol.104, No.722, pp.13-18, 2005.（国内会議録） [2-4] 小堀 一雄，山本 哲男，松下 誠，井上 克郎: “類似度メトリクスを用いたJavaソースコード間類似度計測ツールの試作”, 電子情報通信学会技術研究報告, SS2003-2, Vol.103, No.102, pp.7-12, 2003. (国内会議録)

  41. はじめに

  42. ソフトウェア保守とは • ソフトウェア保守とは • 納入後，ソフトウェアに対して加えられる，欠陥の修正，性能などの改善，変更された環境に適合させるための修正．[IEEEStd 1219] • 「修正」と「ソフトウェア保守」の分類 [JISX0161:2008] 修正の 分類 ソフトウェア保守の 分類 是正保守 緊急保守 訂正 予防保守 適応保守 改良 完全化保守

  43. ソースコード解析 • ソースコード解析の分類 • ソースコード静的解析 • ソースコードを実際に動作することなく解析を行うことで，性質や振る舞い情報を抽出する技術 • ソースコードの中身を扱うため，網羅性の高い解析をすることが可能 • ソースコード動的解析 • ソースコードを動作環境上で実際に動作させ，その動作結果や動作中のログなどを解析することで性質や振る舞い情報を抽出する技術 • マルチスレッド処理など，ソースコード静的解析では発見が難しい　振る舞いを解析することが可能 • 網羅的な振る舞いを調べるには多くのテストケースが必要となる． • 動作環境やテストケースの準備が不要であるため、　現場への適用が容易な「ソースコード静的解析」に　注目する。

  44. 研究対象とする課題①　　　　　　　　　　「アクセス修飾子過剰性の解析」研究対象とする課題①　　　　　　　　　　「アクセス修飾子過剰性の解析」 • 解決したい課題（その１） 「過剰に広いアクセス修飾子をもつフィールド，メソッドに関する理解支援」 • 課題の具体例 • 想定シナリオ：設計時に意図しなかった不正なメソッド呼び出し • 対策の考察： • 対策１：ドキュメントにプログラム内部構造を詳細に書く • 　　　　　　　→作成コスト、メンテナンスコストが大きすぎる • 　　　　　　　→膨大な資料を説明・理解するコストが大きすぎる • 対策２：不正な呼び出しができないようにリファクタリングする • 　　　　　　　→不正な呼び出しの可能性がある箇所の特定が難しい • 　　　　　　　→設計時に想定した範囲より過剰に広い範囲からアクセスされる • 　　　　　　　　フィールド・メソッドの解析・修正を支援したい

  45. 適用実験

  46. ModiChecker適用実験の概要 • 実験の目的 • Validation of our approach • Quantitative analysis of AE Id in some software systems • Reasons for excessive/unused fields/methods (found by interviewing developers) • Reason 1 : Set for future use • Reason 2 : Created by other program(automatic code generators or refactoring tools…) or accessed by other programs(Java bean) • Reason 3 : Carelessness and immaturity • 実験対象のソフトウェア • Industrial Software(341 Java files/ 64455 LOC)

  47. 適用実験結果（フィールド） AEであるフィールドの数 NAであるフィールドの数

  48. 適用実験結果（メソッド） AEであるメソッドの数 NAであるメソッドの数

  49. 適用結果の考察 • AEもしくはNAのフィールド/メソッドの数は以下のとおり • AEであるフィールド : 1027 • AEであるメソッド : 512 • NAであるフィールド: 40 • NAであるメソッド : 1018 • NA(NoAccess)であるフィールド（40個）について内容を確認した結果 • 将来的な利用を想定したもの：8 • 外部からの利用を想定したもの：5 • serialVersionUID（直列化ランタイムからの使用を想定） • 実際に未使用だったもの：27 • その内、潜在バグを伴っていたもの：5

  50. Discussion • Validation of ModiChecker output • Changed all of the excessive access modifier and deleted some unused fields/methods • Modified programs were compiled and executed without any error • Developer should look for the detailed result and make decision to change/delete the unused/excessive fields/methods

More Related