T-VEC Tablular Modeler Examples

提供: T-VEC Wiki
移動: 案内検索

このセクションのはじめに、TTMによって拡張されたSCRモデリングアプローチを紹介します。

実例リンク集

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に直接記述することも できます。要件をモデルにリンクするプロセスは同じです。

モデルのインクルード

TTMモデルは、既存のモデルをインクルードすることが出来ます。他の要件、インタフェース、機能的振る舞い、などのモデルです。 結果として、複数のモデルに共通する振る舞いを、単一モデルに集約することができ、それを必要とするモデルにインクルードさせることができます。 この機能はまた、モデルを分割し、複数のエンジニアが並行して開発するためにも、用いられます。これに関して、以下に説明します。

構造体

構造体型の定義

構造体型は階層的に表現されます。下図に示すように、各フィールド名に対して任意のスカラー型あるいはあらかじめ定義された構造体型を定義します。

Structure Type

構造体の条件式

条件判断やイベントにおいて、構造体変数は = や != 等の演算子を使って他の構造体変数との関係性を記述できます。ドット形式を使えば構造体の各フィールドを参照できますが、関係演算子がフィールドの型と符合していなければなりません。

structure_name.field1 = scalar
structure1.field1 = structure2.field_n
structure1 = structure2
structure_name.field1 = function(param,…);
structure1.field_integer < structure2.field_integer

構造体への代入

項や関数の出力が構造体であれば、セミコロンで区切って一つまたは複数のフィールドへ値を代入することができます。たとえば TTM に付属のサンプル vertical tracker3 では、tState と tStatus という2個のフィールドを持つ構造体型への代入を例に説明しています。

tState = FAIL;
tStatus = currentStatus;

代入式の左側にはフィールド名のみを書きます。入力値は下記の例の sensorData.trk1 のように完全修飾名で指定します。

関数

関数とはパラメータ化された条件テーブルです。たとえばサンプル tracking avoidance は関数の使用例をこのように示しています。

  • trackAttributes(sensorData.trk1)
  • advisoryStatus(sensorData)
Function reference

advisoryStatus への参照と関連付けられた戻り値は、INTERM という中間値に関連付けられていることに注意してください。変数 INTERMは関数の戻り値が代入可能な一時ローカル変数です。変数 INTERMへの参照は代入時あるいは次のような条件参照の際に発生します。

INTERM_x := function(a, b, c)

INTERM の代入演算子 := は関係演算子の等号 =: と逆向きであることに注意してください。変数 INTERMは条件によっては制約されますが、上記の例のようにさらに制約が課される前に関数から代入されなけらばなりません。変数 INTERMはテーブルに関連付けられた出力変数に代入できます。

配列

構造体およびスカラーで1次元配列がどのようにサポートされているかを以下に説明します。下図は配列の定義の例です。Name に配列名を入力、Type で型を選択。Type is an Array にチェックを入れ、Array Size に正の整数でサイズを指定します。

Array Types

配列の参照は構造体やスカラーと同様ですが、特定の要素を読み出す場合は[]を使います。サイズ4の配列は添字0から始まる4個の要素を持ちます。

a[0], a[1], a[2] and a[3]

配列全体または各要素は条件式や代入に使用できます。配列の添字に変数が使われている場合、その変数は配列のサイズに制約されます。以下は配列の情報を構造体の配列に代入する3通りの例です。

  • 例1では出力配列に入力配列 inArray が代入されます。
  • 例2では配列の先頭の要素の2個のフィールド status と value に値が代入されます。
  • 例3では index に対応する要素に inArray の要素が代入されます。
Array Reference

テストを容易にするモジュール構成

多くの組織ではモデルベース開発への取り組みを、小さな機能スレッドから始めてから、チーム開発のレベルに移行します。 一部では、プロダクトライン開発にまで進化させています。これには、デザインチーム、製品技術仕様書を担当するシステムエンジニアリングチーム、テストチーム、品質保証組織の連携が必要です。

ここでは、Check機能(複数のタイプの、フィルタリング<Filter>、マッチング<Match>や、それらの組合せからなる)を例示して、これらFilter, Match, Select への影響を伴う、Checkコンポーネントの機能を開発するときの、組織やプロセスへのインパクトを議論します。

Conceptual Components Example

完全なモデルベース手法の導入には、企業内の多様な組織に影響を与える為、時間的経緯を視野に入れる必要があります。モデルベース開発以前は、Check機能の構成は、明確なインターフェイスで分割されていませんでした。機能は結合され、各サブコンポーネント(Filter, Match, Select)の機能をテストすることは困難でした。しかしながら検証要件として、“コンポーネント、またはサブコンポーネントを介する、あらゆるスレッドが、完全にテストされていることを証明する” ことが求められました。 そのためチームは、インターフェイス・ドリブンな要求仕様モデリングを、要求仕様化とデザイン設計の早期段階から用いることにしました。そして、早期段階からのモデリングによって、テストが容易なデザイン、要求とインターフェイス仕様の改善ができるようになります。

上の図に示される既存システムの機能は、メモリスペースの制限など、過去から引き継いできた多くの制約と密接に関わっていました。また、Filter、Match、Select間のインターフェイスは、明確に定義されていませんでした。そのため、テストプロセスは複雑でした。多くのテストは、Checkのようなサブシステムに対して、上位層レベルから実行される必要が有りました。なぜなら、入力のいくつかは、Checkコンポーネントから上流へセットされるからです。さらに、Matchなど機能からの出力は、可視的では有りませんでした。そのため、これら下位層レベルにあるコンポーネントの体系的、かつ包括的なテストは、困難でした。それゆえ、実装を介して、これら下位層レベルのコンポーネントの、各スレッドに対するテストのカバレッジを満たすためには、上位層レベルのコンポーネントからのテスト実行が増大することになります。時にはテストの数量が大規模になってしまいます。

要求仕様のモデリングを行うことで、早期段階から入出力間のインターフェイスは明らかになり、内部ステート情報を得ることも相まって、テストの容易性が飛躍的に向上しました。デザインチームにより改善されたインターフェイスへの対応により、おおよそ80%の機能がテストされるようになりました。これにより、モデルとテストの複雑さを飛躍的に軽減し、より少ないテストで工数とコストを削減しながら、最大限のカバレッジが得られるようになりました。 ちなみに、残りの20%は、性能や、コストへのインパクト、リソース、再テストのスケジュールなど、改善できない要素に関わるコンポーネントです。