モデルベースソフトウェア開発における総合的な検証手法

モデルベースソフトウェア開発に
おける総合的な検証手法
¾第三回システム検証の科学技術シンポジウム
¾2006年10月30日∼11月1日
株式会社シーディー・アダプコ・ジャパン
複合解析技術室小西晃輔
[email protected]
発表内容
z
z
モデルベース開発と課題
総合的な検証手法 Combined Testing Process
¾
¾
¾
¾
z
ソフトウェア設計工程での検証
要件ベーステストによる検証(モデルテストカバレッジ解析)
ソフトウェア設計からコード生成(ユニットテストの省略)
ソースコードとオブジェクト間のトレーサビリティの検証
まとめ
1
モデルベース開発と課題
実行可能なモデルを中心としたソフトウェア開発
z
モデル
モデルベース開発
システム
要求分析・設計
妥当性確認
ソフトウェア
アーキテクチャー
Validation
総合テスト
結合
テスト
ソフトウェア
設計
モデル
モジュール
設計
モジュール
テスト
コーディング
出力
検証
ターゲット実装へ
モデルベース開発と課題
z
モデルベースの利点
V字型ソフトウェアライフサイクルにおけるウォーターフォ
ル型からモデルベース型への移項
利点：
¾ 要求/仕様を共通認識するためのコミュニケーション手段
¾ 各プロセスでのモデルシミュレーション実行による検証活動
¾ モデルの修正＝要求/仕様の修正
¾ 仕様の容易な再利用
¾ 自動コード生成による人的コーディングエラーの排除
¾
¾
¾
開発効率の改善
開発時間の短縮
ソフトウェア品質改善
2
モデルベース開発と課題
z
モデル
ガイドラ
インによ
る運用
モデルベースの課題
実行可能なモデルを中心としたソフトウェア開発
システム
要求分析・設計
妥当性確認
ソフトウェア
アーキテクチャー
Validation
総合テスト
結合
テスト
ソフトウェア
設計
検証工程が信頼性
・品質に影響
モデル
モジュール
設計
モデルとＣコードの
対応の検証(
対応の検証(レビュー等)
レビュー等)
モジュール
テスト
コーディング
ターゲット実装へ
モデルベース開発と課題
z
出力
検証
モデルベースの課題
モデルベースソフトウェア開発における現在の課題
¾
モデル（仕様）の持つ曖昧さ

システムエンジニアリングとソフトウェアエンジニアリングのギャップ

小規模なモデルは振舞いが予測可能であるが，大規模なモデルになると振舞いが予測できな
い

¾
モデルの検証手法

¾
ガイドラインとルール付けによる曖昧さの吸収
シミュレーションベースのテストだけでテストのもれ・抜けがないのか？
コードを中心に検証を行う(下流にしわ寄せ)
モデルと自動生成Cコードとの対応

モデルと生成Cコードとの一致性確保は？
安全な形でCコードが生成されるか？
モデル記述
モデル表記
形式検証
形式言語
Cコード
変換
変換
ドメイン特定/システムの特性に合った形式言語をモデル表記に対応させる
ことで１つの解となる(形式言語のメリットを活かす)
¾
¾
¾
¾
モデルの振舞いが確定的に記述できる（ソフトウェアでは重要：モデルの大きさ，複雑さに関係なく）
シミュレーション以外の検証手法が適用可能(従来のテストを補う)
言語から言語への変換がより容易＆明確に定義できる
設計と検証プロセスを総合的に構築可能
3
モデルベース開発と課題
SCADE言語
SCADE言語
アプリケーション層
対象は？（ドメイン/システムの特性）
z
¾
ミドルウェア
リアクティブシステム

入力−応答型のシステム(入力がシステムに入ると，
入力−応答型
一定時間内に応答を返し，これが繰り返し実行されるシステム)
アプリケーション層を対象
アプリケーション層
同期的な枠組みで記述可能なアプリケーション
同期的な枠組み
OS
ドライバー
ハードウェア
モデル記述言語は？
z
¾
SCADE言語
SCADE言語((グラフィカルな言語)
グラフィカルな言語)：上位

LUSTRE言語
/Esterel言語をカーネル：下位
LUSTRE言語/
Esterel言語をカーネル：下位

同期性(Synchronicity)
同期性

SCADE表記
形式検証
LUSTRE/
Esterel
同期型言語の仲間
変換
変換
Cコード
入力獲得，演算・データ処理・状態遷移，出力更新の一連の処理が１ロジカル時間内に
実行される(１ロジカル時間内で，入力値は固定される)
サイクルベースとして解釈
確定性(Determinism)
確定性

あるシステム状態に対して，一連の入力を与えた時，計算された出力は，同じ条件下で
は，常に同じ入力に対して同じ出力結果になる
モデルベース開発と課題
z
モデル記述
SCADE言語
SCADE言語
例：Yn = Yn-1 + U，Y(0) = 0.0を表現
する
Lustre表記
Lustre表記
node Dataflow2(
U : real)
returns (
Y : real) ;
var
_L1 : real ;
_L2 : real ;
_L3 : real ;
_L4 : real ;
初期値指定演算子
グラフィカル表記
let equa eq_Dataflow2_1[ , ]
_L1 = U ;
Y = _L2 ;
_L2 = (0.0) -> (_L3) ;
_L3 = _L1 + _L4 ;
_L4 = pre (_L2) ;
tel ;
/* End of blocks of node : Dataflow2 */
遅延演算子(
遅延演算子(１サイ
クル前)
クル前)
4
発表内容
z
z
モデルベース開発と課題
総合的な検証手法 Combined Testing Process
¾
¾
¾
¾
z
ソフトウェア設計工程での検証
要件ベーステストによる検証(モデルテストカバレッジ解析)
ソフトウェア設計からコード生成(ユニットテストの省略)
ソースコードとオブジェクト間のトレーサビリティの検証
まとめ
Combined Testing Processの背景
z
航空電子システムのソフトウェア開発に関するガイドライン(RTCA発
行のDO-178B)
¾
¾
¾
ソフトウェアライフサイクルプロセスの目的を定義，
目的を達成するためのアクティビティや設計で考慮すべき点を記述，
目的が達成されたことを示す証拠(ドキュメント)
ARP-4754
システム要件
ソフトウェアに割り当て
られたシステム要件
プロセス
DO-178B
SW要件
変更
要求
ハイレベル要件
プロセス
DO-178B Table A-3
SW設計
変更
要求
ローレベル要件＆
アーキテクチャー
プロセス
DO-178B Table A-4
検証活動の検証：
検証活動の検証
DO-178B Table A-7
変更
要求
SWコーディング
プロセス
ソース&オブジェクト
コード
DO-178B Table A-5
(テストの検証)
実行形式
変更
要求
SW統合
DO-178B Table A-6
プロセス
5
Combined Testing Processの背景
z
検証プロセス：ソフトウェア開発プロセスの中で発生す
るエラーの検出と報告を行うこと
¾
¾
“検証(Verification)”は，“ソフトウェア開発プロセス”と“検証プロセス”の
結果の技術的な評価(アセスメント)
レビュー，解析(アナリシス)，テスト
テストの組合せによる検証アクティビティ
総合的な検証手法 Combined Testing ProcessTM
要件
設計
コーディング
②要件ベーステストによる検証
モデルのカバレッジ解析(妥当性確認)
①ソフトウェア設計工程での検証
1：整合性・シンタックス・セマンティックチェック(未
定義検出，未使用警告，データタイプ，クロック一
貫性，)
2：ゼロ割/オーバーフローの形式検証
③ソフトウェア設計からコード生成
1： Lustre キーワードの Cサブセット対応付け
2：MC/DCカバレッジ100%による対応付け検証
ターゲットインテグ
レーション
④ソースコードとオブジェクト間のトレーサビリテ
ィ検証
1：サンプルコード(Cサブセット)とテストセットによるコ
ンパイラの検証
6
①ソフトウェア設計工程での検証
z
SW設計段階でのエラーを削除する事が狙い(整合性，セマンティッ
ク，シンタックス)
¾
¾
¾
¾
未定義の検出(型，変数など)
未使用の警告(変数など)
データタイプとインターフェース(入出力)定義の一貫性
クロックの一貫性(データの生成と消費)
int
int
a
c
real
b
どちらの解釈？
a
b
z
5
×
4.3
R→I
a 5
c
b
20
4
I→R
5.0
21.5
×
R→I
21
c
4.3
SW設計におけるゼロ割/オーバーフロー発生検出
¾
形式検証によるゼロ割/オーバーフロー発生の検証(コードを生成する前に
チェックする事が重要⇒モデルベースだからモデルで確認できる)
②要件ベーステストによる検証モデルテストカバレッジ：MTC
z
要件に対する SW設計間の検証活動を計測(DO178Bガイドライン参照)
¾
要件と SW設計間の静的な解析(要件管理ツールによるレビューな
ど)を裏付けるための検証活動(Verification of Verification activity)

要件に対して用意したテストシナリオを SW設計(モデル) 上で再生し，カバ
カバ
レッジを計測する．(機能レベルでの構造カバレッジ解析が目的)
レッジ
意図していない機能の検出
テストの不足，要件の不十分さを検出
F1
F1
F2
F2
設計者
意図していな
い機能
F3
自動コード生成
SW設計
(モデル)
要件
コード
f1a
f1b
f2
f3
意図していない機
能のコード
7
②要件ベーステストによる検証モデルテストカバレッジ：MTC
z
カバレッジ基準の定義(コード構造カバレッジ基準を採用)
¾
デシジョンカバレッジ (DC)
各ステートメントが少なくとも１度は，呼び出された
⇒ サイクルベースの概念上，毎サイクル呼び出されるため，言語上で保証済み
全てのデシジョンが，可能性のある結果を少なくとも１度は出力した
9
¾
モディファイドコンディション/デシジョンカバレッジ (MC/DC)
各ステートメントが少なくとも１度は，呼び出された
⇒ サイクルベースの概念上，毎サイクル呼び出されるため，言語上で保証済み
全てのデシジョンが，可能性のある結果を少なくとも１度は出力した
デシジョンにおける条件が個別に，それぞれの結果に影響している
9
カバレッジ(DC)
カバレッジ(DC)
例：論理演算子ANDの場合
In1
In2
AND
Out
In1 In2
Out
f
f
f
f
t
f
t
f
t
t
カバレッジ(MC/DC)
カバレッジ(MC/DC)
In1 In2
Out
f
f
f
f
t
f
１ケース
f
t
f
f
１ケース
t
t
t
t
１ケース
１ケース
１ケース
②要件ベーステストによる検証モデルテストカバレッジ：MTC
z
カバレッジ計測＆解析＆レポート
カバレッジ結果
オペレータへのトレース
8
③ソフトウェア設計からコード生成
z
Lustre仕様言語からCコードへの自動変換
¾
Lustreキーワードと Cサブセットの対応(Cサブセット導入が重要)

強い型，強いセマンティックを持つ言語LustreからC言語への変換は，サブ
セットを導入することで，安全なCコードへ変換する(サブセットの適用は，機
能安全規格でも推奨)
更に，サブセット＋コーディング規約をスタイルガイドに採用

Cサブセット：

¾
コーディング規約：MISRA-C 2004
再帰呼出しがない&無限ループがない
低レベルの複雑さ
副作用がない(例：a[i] = i++;など)
関数を引数に持たない
対応付けの検証

MC/DCカバレッジ
MC/DCカバレッジ100％による対応付けの検証(DO-178Bガイドラインで定
義されているコード構造カバレッジ計測基準の１つ)
モデルベース開発における V 字から Y 字プロセスへ

生成Cコードのユニットテスト(コードレビュー，コードの構造カバレッジ解析)の削
減を狙い，自動的に信頼性の高いCコードを生成するプロセス
④ソースコードとオブジェクト間のトレーサビリティ
検証
z
ソースコードとオブジェクト間のトレーサビリティと検
証活動
¾
¾
Cソースコードから，コンパイラによって正しくオブジェクトが生成された
かを検証する
CAST-12：Guidelines for Approving Source Code to Object Code
Traceabilityを参考

ソースコードに対して直接トレースできないオブジェクトをコンパイラーが
生成するケース(例：配列境界のチェック，エラーハンドリングなど)があるた
め，コンパイラーによって追加されたオブジェクトの検出＆識別することが狙
い

レビューによる検証
Cサンプルによる検証

プログラムに適用されている全サブセットに対して検証を行う．
（プログラムが，コーディング規約に完全に従っている場合に有効な手法）
Cサブセットに対して，MC/DC
カバレッジ
サブセットに対して，MC/DCカバレッジ
100%のテストケースを用いて検証する
100%のテストケースを用いて検証する
9
④ソースコードとオブジェクト間のトレーサビ
リティ検証
z
Ｃサンプルの構成
¾
コードジェネレータによって生成される全てのＣ構文を含む(Cサブセット)

基本C構文と型の組合せ(Int＋Int，Real+Realなど)
基本C構文の複数項(最大10項まで)

¾
(a+b)*c-dなど
C構文の組合せ：

入力数800のノード
１ノード内に100メモリー(遅延演算子)
階層の深さが100であるノード
入力数32のブール演算子
データ構造の深さ20のタプル
100項の算術演算式
32項の論理式
動作環境のチェック
コード生成
サンプル
モデル
サンプルC
サンプルCソ
ース(
ース(生成)
生成)
Cサブセット，サンプルの検証
入力テスト
ベクトル
比較
参照出力
ベクトル
サンプルC
サンプルCソー
ス(参照)
参照)
比較
出力ベクトル
10
発表内容
z
z
モデルベース開発と課題
総合的な検証手法 Combined Testing Process
¾
¾
¾
¾
z
ソフトウェア設計工程での検証
要件ベーステストによる検証(モデルテストカバレッジ解析)
ソフトウェア設計からコード生成(ユニットテストの省略)
ソースコードとオブジェクト間のトレーサビリティの検証
まとめ
まとめ
z
モデルベース開発における総合的な検証手法の提案
¾
¾
ドメイン特定(リアクティブシステム)で形式言語をモデルに対応付けるこ
とで形式言語の利点を生かした，ソフトウェア設計・検証環境
航空システムのソフトウェア開発におけるガイドラインに適応した一連
の検証活動

z
Combined Testing Processのコンセプトは，航空システム以外にも適用可
能なアイデア
今後について
¾
Lustre言語の拡張

オートマトン追加定義(状態遷移とデータフローのネスト構造実現⇒直感的
なモデリングが重要)

モデリングの簡潔さは重要
生成コードもコンパクトになる
複雑なデータ処理のキーワード追加(行列演算など)
11
12

Download Report