HOME | products | LDRA | TBreq_RTM_MDD


Using requirements traceability with model-driven development

John Thomas and Jared Fry, LDRA  6/11/2012 12:44 AM EDT

モデル駆動型開発/要件トレーサビリティの課題

 

 モデル駆動型開発はセーフティクリティカルなアプリケーションにとって新たな課題となっている。要件トレーサビリティに対してどう向き合うか。MDDでは設計、要件、および実装間の境界が曖昧になるので、トレーサビリティプロセスでモデルの位置付けを誤り易い。

 
モデル駆動型開発(MDD)は、防衛、アビオニクスなどのセーフティクリティカルな組込みシステムコンピューティングの世界で成長傾向にある。
もちろんある種のモデリング作業はソフトウェア開発プロセスで頻繁に伴うが、主な違いは専用のモデリングツールが使用され、結果として得られるモデルは、直接コードがどのように実装されるかを決定することである。
 
この資料で話を進めるにあたって2段階のプロセスとしてMDDを定義する。まず、ソフトウェアとその機能のグラフィカルな表現が作成される。そして、このモデルから、ソースコードは手動、自動的、またはこれら両方の組み合わせによって生成される。
 
過去MDDは、手動で生成されたコードの信頼性、あるいは効率性のいずれかに於いて比較にはならなかった。しかしモデリングツールの進歩によって、手動で生成されたコードとモデルから生成されるコードの間のギャップは減少し、場合によっては解消されている。加えてMDDの推奨者は、利点として視覚的なアプローチ、複雑なシステムの簡素化、コンポーネントの再利用の可能性、および全体的な柔軟性を挙げる。
 
セーフティクリティカルな業界におけるMDDの評判にもかかわらず、それを使用する企業は安全認証を達成する上での課題に直面している。その一部はセーフティスタンダードが古く、MDDについて言及されていないことがある。
 
たとえばDO-178B(航空業界の安全認証規格)は、アビオニクス業界においてMDDが良く知られていない頃に発行されていた。 ただMDDプロセスに対処するためのDO-178Cの改正にもかかわらず、依然としてユーザーは検証のユニークな課題に直面している。特に要件のトレーサビリティに関して。
これらの課題は、いくつかの重要な質問を提示する: モデルベースデザインで安全検証のための要件トレーサビリティの課題は何なのか? そしてどのようにして最新の要件トレーサビリティツールはこれらの課題克服に役立つのか?
 

テストのトレーサビリティ

要件トレーサビリティは航空宇宙、防衛、輸送、原子力、医療など様々なクリティカルソフトウエア開発市場において安全検証プロセスの重要な要素となっているが、ソフトウェア障害が高いリスクを及ぼしかねない場合に特に顕著になる。
 
要件トレーサビリティは、プロジェクトの最上位レベルの記述と、ローレベルの記述や設計とを連携させる。そして設計が実装されるコードおよび関連するテストにリンクされる。
これによって全ての要件は実装されて、検証可能でなければならないという考えが執行される。さらに、DO-178や他の規格では、トレーサビリティは双方向でなければならない。
 
このトレーサビリティによって、要件(コードの基になる)とコードを検証するテストとがリンクされる。
上手く出来た場合、双方向のトレーサビリティは、システムの要件、要件を実装するコード、要件が満たされていることを証明するテスト、など様々成果物間の関係性に対するビューを提供する。
 
要件トレーサビリティの価値は、ソフトウェアの生産者がクライアントに "証明"できる手段を提供することである。要件が理解されていること、製品は完全に要件を遵守すること、製品は不要な機能や機能性が無いことなど。
 
セーフティクリティカルなソフトウェアにおいて要件トレーサビリティは、ソフトウェアのリスクが最小化されており、必要なすべての検証活動が行われてきたことを証明する追加要因になる。例えば、飛行機のフライトコントローラまたはミサイルランチャー用のソフトウェアに障害が発生すると致命的な影響を及ぼしかねない。それゆえ要件の実装が、明確かつ検証可能な証拠で立証されることが重要になる。二十年以上にわたって、要件トレーサビリティは、エビデンスを収集、整理し、結合するための重要な手段であることが認められている。
 

モデルと要件の課題

要件トレーサビリティは、そもそも要件のデータベース•ツールまたはテキスト文書のいずれかを用いる、従来のソフトウェアライフサイクルを想定していた。またトレーサビリティベースのワークフローにMDDを統合することは比較的新しい課題である。セーフティクリティカルなアプリケーション開発のこれら複雑な複合の課題については、安全認証規格のガイダンスで言及されてこなかった。
 
たとえば、DO-178Bがアビオニクス業界向けに制定されたとき、MDD技術は対象外でガイダンスが提供されなかった。このドキュメントへの最新のアップデートでは、この課題に対処するために特別に考察された方法が含まれている。 こうなるまでにMDDが要件トレーサビリティに、どう統合されるべきかについて多くの教訓があった。最新のアップデートにはこれらを考慮し、誤った統合に潜在する障害のいくつかを回避するためのガイダンスを提供している。
 

要件の骨組み(型枠)にモデルを当てはめる

アビオニクス業界内の多くの企業で発生した問題、そしてDO-178Cで明らかにしたものは、設計モデルはどのようにして要件のトレーサビリティの方法論に収まるのかであった。モデルはプロジェクトの高レベルな概要を表すことができることから、一部の企業では高レベルの要件として扱かった。他方では実際の実装を生成するために使用することができるので、ソース•コードとしてモデルを扱っていた。 
 
DO-178Cで認められ、要件トレーサビリティの観点から最も理にかなっているとみなされるアプローチは、設計モデルはローレベルの要件であるということ。これはモデルが、実装がどのように機能するかを示す、設計ドキュメントとして扱われるべきであることを意味する。より正確な検証を可能にするために、このように設計モデルを扱うことが重要である。(下記図1) 
 
システムの高レベルの定義を確立することなく、モデルが望ましいことを確認することは困難である。
また実装としてモデルを扱わないようにすることも大切。さもないとコード生成プロセスで展開される可能性のある欠陥が明らかにならない。外部のコード(手動生成)が生成されるコードに追加されることや、ターゲット環境での検証など。
 

 

図1 - 要件トレーサビリティツールでは、要件から設計モデルが、トレーサビリティプロセスを通じて統合できるのでDO-178Cなどの規格を満たすことが容易になる

 
ローレベルの要件セットとしてMDDによって生成されたモデルの扱いは、要件トレーサビリティプロセスにとって重要な意味を持つ。完全な要件のトレーサビリティが満たされるためには、すべての高レベル要件は、ローレベルの要件で実装されなければならず、双方向のトレーサビリティのために、すべてのローレベルの要件は、高レベルの要件に関連付けられなければならない。
 
またトレーサビリティを意味のあるものにするため、リンクは実際のモデルエレメントと、分解された要件の間でなければない。すべての高レベルの要件を不透明なモデルにリンクさせてしまうと(トップレベルのモデルがトレーサビリティのプロセスに目に見える要素を持たない)、トレーサビリティの目的はないがしろになる。(図2)
 
与えられた一要件を表現するモデルの一部によってのみ、要件が設計で実現されているという証拠を提供することができる。もし一要件が認識されない場合は、そのモデル要素を問題として分離することが重要。
 

 

図2 - 要件からあいまいなモデルへのリンクでは、個々の設計要素、要件とプロシジャ―の実際のリンクに何の洞察も与えない

 
モデルと高レベルの要件間とのトレーサビリティの実現は厄介。とりわけ、これら2つの保存と表示は、通常全く異なっているので。 ほとんどのモデリング•ツールは設計のためのグラフィックインターフェイスを提供しているが、高レベルの要件は主にテキストである。これに対して最新の要件トレーサビリティ•ツールは、それぞれのリポジトリから、高レベルの要件とモデル要素を引っ張って、このギャップを埋めることができる。そして、これらのコンポーネントは、要件と機能テスト間の連携など他のトレーサビリティリンクと合わせて管理することができる。 
 

並行してトレースされる課題

MDDの中心的な技術革新は、開発とコーディングプロセスの間の分離である。この分離は、しかし、要件トレーサビリティに問題を引き起こす可能性がある。開発とコーディングプロセスが独立して存在する場合、両方のトレーサビリティを確立することは複雑でエラーが発生しやすくなる。要件のトレーサビリティは、全ソフトウェア開発ライフサイクルに渡る継続的な取り組みである。もし実装と設計がリンクされていない場合、設計時に行われるトレーサビリティの作業は、実装時にも繰り返される必要がある。
 
最高クラスのモデリング•ツールは、この障害を多少緩和できる。多くのモデリングツールは、モデル要素とそれらに対応するコードの間のマップを自動化する手段を提供する。その自動マッピングは理論的に動作するものの、多くの場合モデリングツールはカスタマイズされたビルドプロセスや、追加の手書きのコード、カスタムコードジェネレータなどと組み合わされて、コードとモデル間のマップは次第に曖昧になっていく。
 
コードとモデル間のトレーサビリティが活用されていても、モデル内でのテストと、ターゲット環境でのソースコードのテストの間でマップされないであろう。
MDDのパラダイムでは、高レベルの要件に従ってモデルの振る舞いを確認し、そのモデルの実行を証明するためのテストを確保しなければならない。
 
DO-178C のMDDサプリメントによって、全体的なソフトウェア検証プロセスの一環としてモデル検証の必要性が明記された。このレベルの検証を達成するには、モデリング環境内でモデルをテストする仕組みがモデリング•ツールに必要。
 
このテストは、設計を検証するために便利であるが、それは必ずしも実際の実行可能なオブジェクトコードの検証をするものではない。ソースコード•レベルのテストと、モデル•レベルのテスト間のこの違いは、要件とモデルテスト間のトレーサビリティのマップが、ソースコードのテストと要件間のトレーサビリティには相当しないことを意味する。そして、これに対する一般的な対処策は、ソースコードのテストとモデルベーステスト用に並行してトレーサビリティチェーンを構築することで、これは冗長なテストと、手動でテスト結果を統合するといった、追加の複雑さを招くことになる。
 
しかしながらモデルベースの設計とソースコード検証の間の未結合を軽減することは可能。要件やトレーサビリティのエビデンスを、様々な成果物から引き出せる要件トレーサビリティ•ツールを利用することで。 外部ドキュメントまたはデータベースからの高レベルの要件と、モデル要素で表現される ローレベルの要件を一つにまとめて、ソースコードにリンクされている設計要素にトレーサビリティ•リンクを張ることができる。
 
また、ソースコードのテストとモデルベースのテストの両方の結果も一緒に提示することができる。要件トレーサビリティ•ツールは、要件、ローレベルの要件、設計、ソースコード、テストをまとめて、トレーサビリティのエビデンスを1つのシームレスなフローとして整理することができる。これは2つの独立したトレーサビリティへの取り組みを維持することや、統合することの複雑さを回避することに役立てられる。(図3)
 

 

図3 -モデル要素への直接のリンクで、リンクの重複を回避し、トレーサビリティプロセスを簡素化

 
さらに、それぞれで実施されるテスト要件は、テストケースの再利用を活用して削減することができる。モデルベースのテストで使用される入力および出力情報を抜き出して、ソースコードのテストツールで読み取り可能な形式にエクスポートすることで。適切な検証ツールとモデリングツールの組合せで、このプロセスはさらに自動化される
 
トレーサビリティにおいて重要なことは、トレーサビリティのエビデンスを再利用できること。特定のテストケースのパラメータが既に要件にトレーサブルであることが示された場合、これらのパラメータはソースコードレベルで再適用させることで、モデルのテストと要件のリンケージの成果物とその判断は、要件からソースコードのテストリンケージとしても活用できる。
 

まとめ

MDDはその人気にもかかわらず、セーフティクリティカルなアプリケーションにいくつかの新しい課題を突き付けている。特に重要な問題の一つは、モデル駆動型開発アプローチでの要件トレーサビリティ。 MDDでは、設計、要件、およびインプリメンテーション間に従来あった境界がぼけるので、トレーサビリティプロセスでモデルの位置付けを誤ることが起こりやすい。
 
さらに、モデルベースの設計ではソースコードレベルでのテストプロセスから設計プロセスが削除され、トレーサビリティ上の誤解や重複など障害を引き起こしかねない。
これらの新たな課題は、クリティカルなソフトウェア開発プラクティスにソフトウェア開発の新しい手法をいかに統合できるかについての問いかけとなるが、イノベーションを活用してベストプラクティスを実践することがその答えである。
 
DO-178Cでのモデルベースの開発と検証についてのサプリメントの追加は、ライフサイクルのトレーサビリティにモデルを組み込むベストプラクティスを展開することを提示する。そしてモダンなトレーサビリティツールとテストツールは、このプロセスの簡素化および自動化を推し進めている。
 
トレーサビリティプロセスのあいまいな理解で要件トレーサビリティが遂行される場合、大きな痛みを伴うことになる。
 
正しく要件のトレーサビリティを遂行すれば、ソフトウェア開発ライフサイクルのすべてのレベルでの検証を提供することができる。
 
モデルベース設計で安全性を犠牲にすることはできないが、適切なツールを使用することで、トレードオフは必要なくなる。
 

About the author

 
John Thomas is a Field Application Engineer for LDRA Ltd. He graduated from Rutgers University. Before working for LDRA, John worked as a developer for several companies and was previously Project Manager for Castel Enterprises, Ltd. He joined LDRA in 2011 and has worked with LDRA clients on coverage testing, target integration and requirements traceability.

Jared Fry is a Field Application Engineer for LDRA Ltd. He graduated from Western New Mexico University with degrees in mathematics and computer science. His career began in the defense industry working for Lockheed Martin. There, Jared served as a software engineer working on various projects ranging from missile and radar systems, training simulations, and software testing. With LDRA he leverages these experiences as a consultant, assisting clients throughout the development process to produce a quality and certifiable product.