最終発表

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

Download Report