HOME | イベント | ET2009 設計・検証ツールトラック  "間違いだらけの MDD、形式手法、プロダクトライン開発"

間違いだらけの MDD、形式手法、ソフトウエアプロダクトライン開発

~ モノづくりを支える真似のできない生産技術を得る設計ツール活用法 ~

   ET2009 設計・検証ツールトラック 11月20日 (金) 10:00~10:45 アネックスホール[F203]

 

キーワード: MDD、ドメインスペシフィックモデリング (DSM)、プロダクトライン開発 (SPL)、フォーマルメソッド(形式手法)、テストベクタ自動生成、要件からテストへのトレーサビリティ・マトリクス

 
 ソフトウエア開発は基本的な変換と検証作業の積重ねです。要求の仕様化、仕様実現のための設計、設計に基づいたコンピュータ言語への変換。そしてこれら変換のレビューや、実装が仕様や設計を満たすことを確認するためのテストケース生成。多くの成果物が人手によって開発されています。そして成果物間の一貫性を保証するトレーサビリティが求められます。そこに開発規模が大きくなると利害関係者も増えることになり、成果物間のトレーサビリティは、より困難になってきます。また一般に開発中であっても仕様は頻繁に変更され、それに伴う設計、コード、テストケースへのインパクトや、その結果変更されるコードやテストケースが変更されていない要件も実装していることに注意を払わなくてはなりません。そして最近の組込みシステムは大規模・複雑化しており、一から製品を開発することは少なくなり、既存モジュールの組み合わせや、過去の製品をベースにして新たな製品を開発する「差分開発(あるいは派生開発)」が主流となっています。この場合、派生製品間で正しく変更修正できていることを確認できないと、共通利用される個々のコンポーネントは独自に進化してしまい、バージョン地獄に陥ってしまうことになります。
 
 そこで変換や検証の作業を自動化することで、開発の速度向上・工数削減や高信頼性確保を目的にMDDや形式手法に、また開発した成果物を再利用して効率化させるという工業化策であるSPLに多くの期待が寄せられ、研究成果が提供されていますが、産業界で実践的に採用される例は少ない。その理由を明らかにし、課題を克服できた成功事例と適用されたツールを紹介します。


<形式手法(フォーマルメソッド)の課題>

 
・形式的仕様記述は難しい
・一般にモデル検査は仕様・設計の正しさの証明だけ
 
上流工程での不具合混入を防ぐことで下流のデバッグや、仕様・設計改訂削減には役立つが、下流のV&V作業が無くなる訳ではない。
 
産業界で実践的に採用されている形式手法なら、表形式で仕様記述が簡単に行えて、モデル検査を通して正確な振舞いの要件やインターフェイス情報の形式化が、開発早期段階で得られる。そのため実装担当者は、詳細設計、コード実装に集中できる。そしてモデル検査の成果物として得られるテストベクタを用いて検証作業とトレーサビリティの自動化を支援することにより、多くの開発工数が削減できるようになります。
 
産業界からの教訓:良いツールの採用で開発工数を削減できる

テストエンジニアが数百、数千行ものテストスクリプトを書く代わりに仕様・設計をモデル化して正しさを証明し(モデル検査)、テストベクタとテストドライバーが自動生成される。 イテレーティブな開発において、コンポーネントの振舞いや、インターフェイス、あるいは要件の変更に応じて、モデルは修正されテストベクタやテストドライバーを再生成し、再実行できる。

 

追記:ソースコードの解析から形式手法

近年 IEC61508やISO26262などのスタンダードで形式手法(フォーマルメソッド)が推奨され混乱を招いている。しかしながら一部のソースコードベースのツールに形式手法が組込まれ、知らないうちに活用されていることはあまり知られていない。これはシステムワイドなコントロールフローモデルとデータフローモデルをソースコードをリバースして自動生成し、以下の解析を行う。
 

  • データフロー/ ファイルハンドリング/ ポインター、ヌルポインター/ ゼロ割/ 配列境界/ メモリアロケーション/ デッドコード/ LCSAJ パス/ インフォメーションフロー/ アサーションによる Exact Semantic/ サイドエフェクト/ データカップリング/ MCDC テストケースプランナー

 
Formal Methods by Stealth:静的解析に活用される形式手法
LDRA tool suite IEC 61508 に対するテスト支援機能
 


<MDDの課題>

汎用ツールでは成果を上げられない

 
・抽象度を上げないと生産性は上がらない。
UMLなど汎用モデリング言語によるコード生成ではコードを絵で描くに等しい
 
・完全なコードを自動生成させないと効率が悪い
変更・追加・派生開発でモデルとコードの両方をメンテナンスすることは厄介で、結果モデルはただのドキュメントと化してしまう
 
ドメインスペシフィック・モデリング言語(DSM)を構築すること。汎用ではなく、狭いドメインに特化すること。汎用ツールにプロジェクトを合わせるのではなく、プロジェクトに合わせた専用ツールを作る
 
・抽象度を上げる(しかも十二分な正確性を持って)
・製品プラットフォーム専用の完全なコードを生成させる
・変更・追加はモデル言語やコード生成ツールに対して (コンパイラが生成したコードを変更しないのと同じ)


UMLやEclipse ベースのDSMは実践的ではない

 
・UMLは意味的に不正確で限定的
オブジェクト指向設計の基本概念を表現するための共通手段としては良いが、DSL、DSMの基盤としては向いていない。相当な費用をかければ作れなくないが、非常に複雑なシステムとなり工数・費用がかさむ。しかも課題は、メンテナンスコスト。派生開発で起こる 変更・修正・進化への対処
 
・EclipseベースのDSLも相当な工数・費用が掛かる
例えば IDEツールの制限として、モデリング言語の修正・変更による、既存モデルへのインパクトをメンテナンスすることは尋常ではない
 
DSL、DSM構築ツールに必要な機能は?
 
・モデリング環境、メタモデリング、コード生成機能が完全に融合され、既存ツールチェインと統合できること
・進化を支援できること。DSM言語の修正、拡張が容易で、既存アプリモデルが破壊されることなく
・マルチユーザ(異なるプラットフォーム、アクセス権限)
・標準ファイル形式によるインポート・エクスポート
・あらゆる言語、ドキュメントを自動生成できる仕組み
 


<プロダクトライン開発 (SPL) の課題>

 
組織ごとで再利用への取組みは行われているが、あまり上手くいっていない。課題は、変更をケアするべき多くの製品があること。変更のインパクトが増加すること(製品内だけでなく製品間に渡る)。そして既存のツールは製品間に渡って使用されることの配慮が無いこと。
 
SPLを支援するために求められるバリアントの管理ツールで求められる機能は、
 
・既存のプロジェクトの構成、成果物をベースに、それらをツールやその手法に合わせることなく、インクリメンタルにバリアント管理を、安全に取り入れることが出来る
こと。 (ツールにプロジェクトを合わせるのではなく、プロジェクトにツールを合わせること)既存のビルドやその他プロセスの変更は最小限に
・追加のフィーチャにより取り得るバリアントは簡単に倍増することを考慮に入れて、単純なデモ例だけでなく、複雑で規模の大きいバライアビリティのモデリングにも対応できること
・差分開発を念頭に入れ、資産・プラットフォームなどの変更・修正・進化に順応できること
・Eclipse のような共通のツールプラットフォーム、ユーザインターフェイスをサポートすること。バグ管理・追跡ツールのようなツールとは、リアルタイムな協調が取れることも重要。
・APIを介して、あらゆるツールとの統合が誰にでも出来るようにすること。
 
プロダクトライン開発 バリアント・バライアビリティ管理ツール製品情報・各種資料
Dr.Danilo さんのプロダクトライン・ブログ日本語版