T-VEC Tablular Modeler Examples
From T-VEC Wiki (Japanese)
このセクションのはじめに、TTMによって拡張されたSCRモデリングアプローチを紹介します。
Contents |
Example Links
TTMでサポートされるSCR手法
このセクションは、TTMツールを介してSCRモデリングコンセプトやルールについて詳細に記載しています。
SCR Basics
簡単に言うと、SCR手法は、デシジョンテーブルやステートマシンの使用をベースにし、コンポーネントの振る舞いの要件を記述します。テーブルに基づいて、SCRモデル要素を編成し、関連を取る、仕組みです。テーブルは、課題のデータ型や変数を定義するためにも使用されます。変数は、元の型（integer,float,boolean,enumeration）やユーザ定義型によって定義されます。振る舞いは、ステートマシン（Mode Tables）、コンディション、イベントテーブルの形式を使って、課題の状態を定義するテーブルの組合せ、によりモデル化されます。
モデルは、システムのコンポーネントが、何を実現するか、どのように実現するか、に関して開発されます。そして、モデル化された要件を、ターゲットの実装が満たしていることを確認するための尺度が、モデルからのテスト生成により、提供されます。 どのように実現するか、と言った“how”の要素は、モデル変数と、それらのデータ型で記述されるインタフェースの組み合せで、定義されます。 上位層（what）では、モデルは、入力変数から出力変数への関連を記述することで、振る舞いを指定します。 モデルは、モードまたはタームとして参照される変数の経緯から、振る舞いを表すこともできます。
TTM拡張の概要
要件管理
TTMは、階層として分解すること(アウトライン形式)で、要件を管理します。ここで、各要件は、以下のように構成される。
- Tag：要件ごとのユニークな識別子、文字、数字、アンダーライン、ピリオドで構成。
- Description：要件を記述する1行のテキスト
- Comment：追加の本文
要件の階層状態は、モデルビューを介して管理されます。要件は、子となる要件を作成することで分解され、モデルビュー内で、親の配下に表示されます。
要件－テスト トレーサビリティ
このセクションでは、TTM要求モデルにDOORsの要件をリンクするプロセスを、例を用いて説明します。要件からテストへ至るトレーサビリティを、ツールでサポートするために、モデルに対して、様々なソースで提供される要件、とのリンクをとる必要があります。T-VECによる、モデル変換、テストベクタ生成、テストドライバ生成は、テストベクタ、テストドライバ、テストレポートに対して、要件をリンクすることができます。このプロセスには、3つの基本ステップがあります。
- DOORSモジュールは、TTMにインポートされます。更新された時、TTMへDOORSモジュールを追加、削除することや、更新された時にDOORSモジュールを同期させるオプションがあります。DOORS のID と TTM のrequirement ID は、一対のペアです。
- インポートされた要件は、DOORS環境内のアウトライン構造を、保持します。1つ以上のDOORS要件は、TTMモデルの要素（例えば、コンディション/アサインメント）にリンク、またはコンディション、イベント、モードテーブルのような上位のTTMモデルにリンクされます。
- モデル変換時に、要件ID間のリンクは維持され、テスト生成において、要件のリンクはテストベクタの属性となります。テストドライバ生成では、要件IDは実行されるテストケースの詳細なトレーサビリティを取るための、アウトプットとなります。
TTMは、DOORSと同様の、要件管理機能を提供します。インポートされたDOORSモジュールは、リードオンリーとしてTTMにリンクされます。要件への変更は、DOORSで行われる必要が有り、その後、TTMと同期されます。DOORSの中にない、あるいはDOORSのような要件管理システムに管理されていない要件は、TTMに直接記述することも できます。要件をモデルにリンクするプロセスは同じです。
Model Includes
TTMモデルは、既存のモデルを包括することが出来ます。他の要件、インタフェース、機能的振る舞い、などのモデルです。 結果として、複数のモデルに共通する振る舞いを、単一モデルに集約することができ、それを必要とするモデルに包括させることができます。 この機能はまた、モデルを分割し、複数のエンジニアが並行して開発するためにも、用いられます。これに関して、以下に説明します。
Modular Organization
多くの組織は、モデルベース開発を、小さな機能スレッドから始めて、その後に、チーム開発されるレベルに移行します。また、一部では、プロダクトラインを展開しています。これには、デザインチーム、製品技術仕様を書くシステムエンジニアリングチーム、テストチーム、品質保証組織の連携が必要です。
ここでは、Check機能（複数のタイプの、フィルタリング<Filter>、マッチング<Match>や、それらの組合せを持つ）を例示します。この例で、Filter, Match, Select への影響を伴う、Checkコンポーネントの機能を開発するときの、組織や、プロセスへのインパクトを議論します。
完全なモデルベース手法の導入は、企業内の多様な組織に影響を与える為、この例では、時間的経緯を視野に入れています。モデルベース開発以前は、Check機能の構成は、明確なインタフェースで分割されていませんでした。機能は連結され、各サブコンポーネント(i.e. Filter, Match, and Select)の機能をテストすることは、困難でした。しかしながら、検証要件（コンポーネント、またはサブコンポーネントを介する、あらゆるスレッドが、完全にテストされていることを証明する）が、ありました。 そのためチームは、インタフェース・ドリブンな要求モデリングを、要求とデザインの設計段階から用いることにしました。そして、早期段階からのモデリングにより、テストが容易なデザイン、要求とインタフェース仕様の改善、ができるようになります。
前の図に表される、既存のシステムの機能は、メモリスペースの制限など、多くの既存の制約と、密接に関わっていました。また、Filter、Match、Select間のインタフェースは、明確に定義されていませんでした。そのため、テストプロセスは複雑でした。多くのテストは、Checkのようなサブシステムに対して、上位層レベルから実行される必要が有りました。なぜなら、入力のいくつかは、Checkコンポーネントから上流へセットされるからです。さらに、Matchなど機能からの出力は、可視的では有りません。そのため、これら下位層レベルにあるコンポーネントの体系的、かつ包括的なテストは、困難になります。それゆえ、実装を介して、これら下位層レベルのコンポーネントの、各スレッドに対するテストのカバレッジを満たすためには、上位層レベルのコンポーネントからのテストが増大することになります。時には、テストの数量が大規模になってしまいます。
要求モデリングを行うことで、早期段階から入出力間のインタフェースは明らかになり、内部ステート情報を得ることも相まって、テストの容易性が飛躍的に向上しました。デザインチームにより改善されたインタフェースへの対応により、おおよそ80％の機能がテストされるようになりました。これにより、モデルとテストの複雑さを飛躍的に軽減し、より少ないテストで工数とコストを削減しながら、最大限のカバレッジを得るようになりました。 ちなみに、残りの20%は、性能や、コストへのインパクト、リソース、再テストのスケジュールなど、改善できない要素に関わるコンポーネントです。
