SHINSHU UNIVERSITY 組み込みソフトウェアにおけるインパクト分析支援ツールの実現と評価海海研Ｍ２ 07TA519H 川平航介 2009-02-07 目次        背景目的組み込みソフトウェア手法についてツールの概要評価実験まとめ，今後の予定 2 背景(1/3)  組込みソフトウェアは大規模・複雑化している  既存ソフトウェアの再利用が不可欠  再利用のため，変更箇所を予測することが重要  仕様書の変更箇所からソースコードの該当箇所を調べる必要がある 3 背景(2/3) ★問題点  組込みソフトウェアでは，機能ごとにモジュール化されずに散在している場合もある  実際の開発では仕様書とソースコードの関連の記述が不十分な場合も多い どこを変更すれば良いのか分かりにくい 4 背景(3/3) ★解決策  仕様書とソースコードのトレーサビリティが必要しかし…  新たな開発手法の導入は開発者への負担が大きい  今ある資源を使って開発をサポートすることが重要 5 目的  組み込みソフトウェアへの変更要求に対して，ソースコード上の変更箇所を絞り込むことをサポートする  既存のソースコード，仕様書などの資源を活用して，効率よく変更箇所を絞り込むためのツールを開発し，評価を行う 6 組込みソフトウェアとは機器に組み込まれてその制御を行うもの  組み込みソフトウェアが使われる場所   情報機器…カーナビ，携帯電話，テレビ  家電…電子レンジ，炊飯器  PC関連…プリンタ，ネットワーク機器  他…自動車，ゲーム機，エレベータ  etc...  ほとんどの電子機器に使われている 7 組込みソフトウェアとは  品質に対する要求が高い  機能を実装するだけでは駄目  ハードウェアとの同時開発  開発開始時には動作する環境が存在しない  技術レベルの変化に敏感  すぐに新しい技術が投入される  動作条件が多様  OSの有無，極端にメモリの少ない環境等 8 手法について  入力(あるもの)  要求「○○を変更・追加したい」  旧バージョンのソースコード  新，旧バージョンの仕様書（今回はハードウェアのもの）  既存ソフトウェアに関する知識  出力(欲しいもの)  変更が予測される箇所(関数)の一覧これらの入力から出力を得るのが目標 9 手法について  仕様とソースコードを結びつける方法  IR手法・・・情報検索  アスペクト指向・・・ソースコードに埋め込む  動作シナリオを用いる・・・シナリオを書いて動作をみる  デザインパターンを用いる・・・設計から管理 10 手法について  条件  現在の開発手法を維持  既存のリソースを使う  (半)自動的にやりたい ⇒IR手法が有望  単純なキーワード検索を組み合わせ，変更予測をする  11 最近->関数の特徴キーワード以外に使えるものは無いのか？  実際に変更があった関数の特徴について   ＬｏＣ  呼び出される回数  含まれる単語  あまり期待できないが，一応調査した 12 最近->LoC  関数のLoC  変更された関数と全体の分布を比べる全体変更された関数 1000 100 10 1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 13 最近->呼び出される回数  呼び出される回数全体変更 100 10 1 2 1 4 3 6 5 8 7 10 12 14 16 18 20 22 24 26 28 30 9 11 13 15 17 19 21 23 25 27 29 14 最近->含まれる単語  単語  全関数(300)中の単語らしき文字列 1445  変更された関数(13)にのみ現れる単語 160  この160語に含まれる単語を使えば精度の高い検索ができる  特徴的な単語は少ない  これらの単語を前もって選ぶのは非現実的  特徴的な語が全く含まれない関数もある 15 ツールの概要  目的  変更要求から，ソースコード上の変更すべき箇所を見つける  機能  仕様書上で変更要求に関連するキーワードを検索  キーワードからソースコード中の関数を検索  ２回の検索の前後に人間の補正を入れることで，まともな検索結果を得られるように 16 ツールの概要変更要求 -------------------------------------------- 仕様書検索条件検索 #include < stdio.h> int main(){ int n,sum,min,max,i,p; F ILE * fp = fopen(" A" ," r" ); while(fscanf(fp," % d" ,&n),n) { min = 9999, max = 0, sum = 0; for(i= 0;i< n;i+ + ) { fscanf(fp," % d" ,&p); if (p> max) max= p; if (p< min) min= p; sum+ = p; } printf(" % d\n" ,(sum-max-min)/(n-2)); } return 0; } ソースコードキーワード検索検索条件変更する関数の候補 17 ツールの概要  検索に使う単語の抽出  仕様書から，変更要求によって追加・変更された機能に関連が深い単語を検索する  ソースコード上に現れそうな単語をキーワードとする  単語の形をソースコード中で使われているものに合わせる(いまのところ手作業)  例：status，control ⇒ stat，ctrl 18 ツールの概要  ソースコードからキーワードを検索  関数ごとにキーワードの出現回数をカウントする  識別子は単語ごとに分解  FUNC_TYPE，getName ⇒ func, type, get, name  閾値と検索条件の調整  検索結果に現れる関数を見て，検索条件を調節し，検索を繰り返す 19 ツールの概要  構成  GUIはJava (長田さん)  内部の検索処理はいくつかのPerlスクリプトで実現  ソースコードの関数ごとの検索  仕様書の章ごとの検索  再現率や精度等の計算 20 評価実験->分析対象  分析対象  組込みシステムのうちの，ハードウェアを制御するドライバ  ソースコードはC言語で書かれている  結果を評価するために，実製品の２つのバージョンの開発データを使用した  実製品のデータなので，数値などは精度を低くして示してある 21 評価実験->評価方法  評価方法  結果を評価するため，２つのバージョンの差異をあらかじめ抜き出しておく  ２つのバージョン間の差違変更ありファイル数関数行数(LOC) 10 20 1000 全体 20 300 30～40k 22 評価実験->評価方法  用語の説明１  recall (再現率)  正しく見つけられた数／見つけるべき物の数  見つけられなかったものが多いと値が小さくなる  precision (精度)  正しく見つけられた数／見つかった数  見つけたものに不要なものが多く入っているほど小さい 23 評価実験->評価方法  用語の説明２  candidate  ソースコード全体のうち，どれだけが候補に含まれるか  小さいほど確認する範囲が少なくて済む  閾値  一定の個数以上キーワードを含む関数を列挙するための閾値 24 評価実験->評価方法閾値ごとに，キーワード数と再現率と精度の関係を調べた  全ての変更箇所を見つけることが目的であるため，再現率が１になる条件に注目する  25 評価実験->結果  キーワードの検索については省略  適当な単語を使って仕様書からキーワードを検索  50個程度のキーワードが候補に挙がった  そのうち使えそうな8個のキーワードを選んだ 26 評価実験->結果  キーワードが１回以上現れる関数 Threshold:1 recall precision candidate 検索の閾値：これ以上キーワードを含む関数を見つける(複数回現れてもカウント) 1.2 1 0.8 0.6 0.4 0.2 検索に使うキーワードの数 0 1 2 再現率(recall)と精度(precision)の値 3 4 5 6 7 8 keywords 27 評価実験->結果キーワードが１回以上現れる関数  キーワード数を４個にした時点で再現率が１に  必要な関数が全て見つかった  再現率が１になった時点での精度は約0.15  低い・・・８５％は変更の必要が無い関数 28 評価実験->結果  キーワードが５回以上現れる関数 Threshold:5 recall precision candidate 1.2 1 0.8 0.6 0.4 0.2 0 1 2 3 4 5 6 7 8 keywords 29 評価実験->結果キーワード数を５にした時点で再現率が１になる  再現率が１になった時の精度は0.28   閾値を上げたことで多少良くなった  このときのCandidate が0.2…  確認する範囲は全体の２割でよい 30 評価実験->結果  キーワードが６回以上現れる関数 Threshold:6 recall precision candidate 1 0.8 0.6 0.4 0.2 0 1 2 3 4 5 6 7 8 keywords 31 評価実験->結果  出現回数を６回にした場合，キーワード数を増やしてもrecallが１にはならなかった  ６以上の閾値では検索から漏れる関数が出てくる  ６未満に設定しなければならない 32 評価実験->考察今回の分析対象の場合，検索の閾値は５あたりが最適  それほど多くないキーワードで大抵の変更箇所は見つけられる   閾値を変更しても，必要なキーワード数はあまり変化しない  検索結果として得られた関数は全関数のうち20% 33 評価実験->考察  今回は，本当に変更すべき関数が分かる状態で評価した  実際の開発では，recallもprecisionも出せない  答えを知らない状態での評価も行った  多少精度が落ちるが，それなりの結果が得られた 34 まとめ変更要求からソースコードの変更箇所の絞り込みをサポートするツールを開発した  実際の組み込みソフトウェア開発のデータを用いてツールの有用性を評価した   今回の事例では，変更箇所として確認すべき部分は全体のうち20％に抑えることができた 35 今後の予定  他の言語(C++等)にも対応  gccの中間コードを用いることも考えている  コンパイルが通ることが前提  機能追加以外の変更要求も考慮する  そろそろ修論を書く… 36