Simulink モデルベース開発の派生開発を支援するプロダクトライン開発・モデル検査・テスト自動生成ツールの統合
MATLAB EXPO 09 12月2日［水］パートナートラック K2 13:10-14:00
キーワード： 派生開発、プロダクトライン開発 (SPL)、フォーマルメソッド（形式手法）、テストベクタ自動生成、モデル検証（Model Based Verification）、要件からテストへのトレーサビリティ・マトリクス
ソフトウエア開発は基本的な変換と検証作業の積重ねです。要求の仕様化、仕様実現のための設計、設計に基づいたコンピュータ言語への変換。そしてこれら変換のレビューや、実装が仕様や設計を満たすことを確認するためのテストケース生成。多くの成果物が人手によって開発されています。そして成果物間の一貫性を保証するトレーサビリティが求められます。そこに開発規模が大きくなると利害関係者も増えることになり、成果物間のトレーサビリティは、より困難になってきます。また一般に開発中であっても仕様は頻繁に変更され、それに伴う設計、コード、テストケースへのインパクトや、その結果変更されるコードやテストケースが変更されていない要件も実装していることに注意を払わなくてはなりません。そして最近の組込みシステムは大規模・複雑化しており、一から製品を開発することは少なくなり、既存モジュールの組み合わせや、過去の製品をベースにして新たな製品を開発する「差分開発（あるいは派生開発）」が主流となっています。この場合、派生製品間で正しく変更修正できていることを確認できないと、共通利用される個々のコンポーネントは独自に進化してしまい、バージョン地獄に陥ってしまうことになります。
そこで形式手法やプロダクトライン開発など開発速度向上・工数削減や高信頼性確保を目的に期待されるが、産業界で実践的に採用される例は少ない。その理由を明らかにし、課題を克服できた成功事例と適用されたツールを紹介します。
＜形式手法（フォーマルメソッド）の課題＞
開発の75％以上にもなる検証作業を一貫して自動化支援モデル検査が仕様・設計の正しさの証明だけに限られる場合、上流工程での不具合混入を防ぐことには役立つが、下流のＶ＆Ｖ作業が無くなる訳ではない。
産業界で実践的に採用されている T-VEC なら、モデル検査の成果物として得られるテストベクタを用いて検証作業とトレーサビリティの自動化を支援することにより、多くの開発工数が削減できるようになる。生成されるテストベクタは、以下の要件を満たしていることが求められる。
＊境界値分析、同値分割などテスト技法を融合
＊フローティング、ダブルなど、あらゆるデータタイプに対応
（インテジャー、ブーリアンのみでは無い）
＊組込みターゲットなどあらゆる環境に適用される
産業界からの教訓：良いツールの採用で開発工数を削減できる
テストエンジニアが数百、数千行ものテストスクリプトを書く代わりに、Simulinkモデルからテストベクタとテストドライバーが自動生成される。 イテレーティブな開発において、コンポーネントの振舞いや、インターフェイス、あるいは要件の変更に応じて、モデルは修正されテストベクタやテストドライバーを再生成し、再実行できる。
形式手法（フォーマルメソッド）によるモデル検証・テストベクタ生成ツール製品情報・各種資料
追記：ソースコードの解析から形式手法
近年 IEC61508やISO26262などのスタンダードで形式手法（フォーマルメソッド）が推奨され混乱を招いている。しかしながら一部のソースコードベースのツールに形式手法が組込まれ、知らないうちに活用されていることはあまり知られていない。これはシステムワイドなコントロールフローモデルとデータフローモデルをソースコードをリバースして自動生成し、以下の解析を行う。
- データフロー/ ファイルハンドリング/ ポインター、ヌルポインター/ ゼロ割/ 配列境界/ メモリアロケーション/ デッドコード/ LCSAJ パス/ インフォメーションフロー/ アサーションによる Exact Semantic/ サイドエフェクト/ データカップリング/ MCDC テストケースプランナー
Formal Methods by Stealth:静的解析に活用される形式手法
LDRA tool suite IEC 61508 に対するテスト支援機能
形式手法（フォーマルメソッド）が組込まれたテスト支援ツール製品情報・各種資料
＜プロダクトライン開発 (SPL) の課題＞
組織ごとで再利用への取組みは行われているが、あまり上手くいっていない。課題は、変更をケアするべき多くの製品があること。変更のインパクトが増加すること（製品内だけでなく製品間に渡る）。そして既存のツールは製品間に渡って使用されることの配慮が無いこと。
バリアント管理ツールと既存ツールの統合 SPLを支援するために求められるバリアントの管理ツールで求められる機能は、
・既存のプロジェクトの構成、成果物をベースに、それらをツールやその手法に合わせることなく、インクリメンタルにバリアント管理を、安全に取り入れることが出来る
こと。 （ツールにプロジェクトを合わせるのではなく、プロジェクトにツールを合わせること）既存のビルドやその他プロセスの変更は最小限に
・追加のフィーチャにより取り得るバリアントは簡単に倍増することを考慮に入れて、単純なデモ例だけでなく、複雑で規模の大きいバライアビリティのモデリングにも対応できること
・差分開発を念頭に入れ、資産・プラットフォームなどの変更・修正・進化に順応できること
・Eclipse のような共通のツールプラットフォーム、ユーザインターフェイスをサポートすること。バグ管理・追跡ツールのようなツールとは、リアルタイムな協調が取れることも重要。
・APIを介して、あらゆるツールとの統合が誰にでも出来るようにすること。
画像クリックで pure::variants for Simulink の情報へ
バリアント間のバグ管理： バグの影響を受ける製品を抽出
プロダクトライン開発 バリアント・バライアビリティ管理ツール製品情報・各種資料
Dr.Danilo さんのプロダクトライン・ブログ日本語版
HOME