ディシジョン テーブル。 ソフトウェアの動作をデシジョンテーブルで視覚化する

ソフトウェアの動作をデシジョンテーブルで視覚化する

ディシジョン テーブル

テストを実施する際には、システムの仕様を正確に把握する必要があります。 しかし、仕様が複雑になると、条件の考慮漏れが起きやすくなります。 そのようなときに活用したいのがデシジョンテーブルです。 今回は、複雑な仕様を整理して条件漏れを防ぐ、デシジョンテーブルについてご紹介します。 「デシジョンテーブル」の概要 デシジョンテーブルは、さまざまな条件(入力)で、どのようにソフトウェアが動作(出力)するのかを、表形式で整理したもので、ソフトウェアの機能仕様を表すのに用いるものです。 例を見てみましょう。 タクシーの割増料金の仕様が、以下のように定義されていたとします。 ・月曜~金曜は通常料金、土日および祝祭日は割増料金 ・7:00~21:59は通常料金、それ以外(深夜・早朝)は割増 これをデシジョンテーブルの形で表すと、以下のようになります。 このように、デシジョンテーブルを用いると、曜日と時間という条件の組み合わせごとに、料金が通常料金なのか割増料金なのかが明確に分かるようになります。 このデシジョンテーブルを活用するテストを「デシジョンテーブルテスト」と言います。 デシジョンテーブルで洗い出した条件とアクションについての組み合わせは、テストケースに横展開しやすく網羅性も高いため、デシジョンテーブルテストはあらゆるパターンを確認したい際に有効な手法です。 デシジョンテーブルの作成手順 デシジョンテーブルの構造を整理すると、以下のようになります。 デシジョンテーブルは、一般的には以下の手順を踏んで作成します。 【1】条件とアクションをまとめる 分析対象のシステムで起こりうる条件を「条件記述部」に、取りうるアクションを「動作指定部」に記入します。 【2】条件の組み合わせを記入する すべての条件の組み合わせを考え、条件に当てはまる場合は「Y」(Yes)またはT(True)、当てはまらない場合は「N」(No)または「F」 False を「条件指定部」に記入します。 また、表の上端の行にはルール名(条件の組み合わせとそれに対応するアクションをルールと呼びます)を記入します。 【3】動作指定部を記入する 【2】で記入した条件の組み合わせに対応して、どのようなアクションが起きるかを「動作指定部」に記入(アクションが起きる場合は「Y」、起きない場合は「-」)します。 デシジョンテーブルが大きくなってしまったら デシジョンテーブルの目的の一つは「複雑な仕様を分かりやすく整理すること」です。 デシジョンテーブルのサイズが大きくなってしまったら、以下のように工夫することで見やすくなります。 矛盾している条件を削除する デシジョンテーブルを作成し、論理的に矛盾している条件の組み合わせが生じた場合、その条件を削除することで、テーブルの項目を減らすことができます。 例えば、ある携帯電話事業者は子供・シニア割引を実施しており、15歳以下または60歳以上の利用者には割引料金が適用されるとします。 このとき「15歳以下」「60歳以上」を条件、「割引料金が適用」をアクションとして、デシジョンテーブルを作成した場合、 「15歳以下」「60歳以上」がともにYというケースはあり得ないため、この条件を省くことができます。 表を簡略化する デシジョンテーブルを見やすくするために、複数のルールをまとめて簡略化を図ることもできます。 例えば、ある遊園地ではゴーカートに乗るためには 小学校3年生以上かつ身長140cm以上でなければならないという規則を設けているとします。 表を分割する 他の条件との関連性が低い条件(独立性の高い条件)がある場合、表の分割が効果的です。 元の表から独立性の高い条件を除いて作成した表と、独立性の高い条件のみで作成した表の2つに分割することによって、表が見やすくなります。 デシジョンテーブルは他にも使える 【活用法1】発見した欠陥の原因を分析する デシジョンテーブルテストを実施して欠陥が見つかった場合、その 欠陥が発生する条件と類似の条件をデシジョンテーブルからから探し出し、その差異を調べて欠陥のありそうな条件を特定できます。 条件とアクションの関係性が表に整理されていることで、不具合結果の出方からシステムのどのあたりに問題があるのかあたりをつけやすくなり、不具合の検知スピードや確実性が上がるというメリットがあります。 【活用法2】仕様の漏れ抜け・曖昧な箇所を見つける ソフトウェアを動作させずに開発仕様書に誤りや不備がないことを確認することを静的テストと呼びますが、デシジョンテーブルはこの静的テストで活用できます。 デシジョンテーブルで条件の組み合わせを全て洗い出し、個々に期待されるアクションを割り振る作業をする中で、「この条件ではどのようにアクションすべきか、仕様書に書かれていない、又は曖昧である」箇所を見つけ出すことができます。 仕様に定義漏れや曖昧な箇所があれば、それは不具合に直結します。 このような不具合を、仕様定義や設計段階といった、テストを実施する前に見つけ出して対処すれば、結果的にテストで見つけられるバグは少なくなって、テストの実施効率向上・テスト時間圧縮・品質の安定化に繋がります。 まとめ 今回は、デシジョンテーブルの使い方についてご紹介しました。 デシジョンテーブルは複雑な条件を整理してテスト漏れを予防したり、不具合の原因箇所を特定したりすることに役立ちます。 システムの品質向上やテストスケジュールの遅延を防ぐためにも、デシジョンテーブルを活用してみてはいかがでしょうか。 資料ダウンロード.

次の

仕様変更の疲弊から脱却する「ビジネス・ルール・マネジメント」

ディシジョン テーブル

デシジョンテーブルとは デシジョンテーブルとは、決定表 JIS X 0125 [1]として規格が定義されています。 論理関係を表形式で整理するためのツールで、行方向に条件と動作、列方向にルールの組合せます。 プログラムの処理条件やポリシーなどをわかりやすく表現するために利用したり、ソフトウェアのテスト条件を整理するためにも利用されます。 デシジョンテーブルの例(駐車場料金の割引計算) デシジョンテーブルを作成する手順は一般的に以下の通りです。 分析対象・テスト対象の持つ条件・原因を洗い出し、それぞれを行として追加します• 処理・動作・結果を洗い出し、それぞれ行として追加します• 起こりうる条件・原因の組合せを作成し、それぞれ列として追加します• 作成した列のうち、集約可能な列の組を圧縮します• 組合せの作成と圧縮についての検算をします デシジョンテーブルを使うことで以下のようなメリットが挙げられます。 (作成中) しかし、以下のような分析対象・テスト対象を扱う場合は注意が必要です。 (作成中) デシジョンテーブルの構成 デシジョンテーブルは以下のような要素で構成されています。 条件記述部(condition stub) 考慮すべき条件・原因を列挙する部分で、図2では「3000円以上10000円未満」「シネマ利用」などが該当します。 制限指定の場合は、記述した語句が真であるか偽であるかが明確になるように命題形式で記述するとわかりやすいです。 拡張指定の場合は、記述した語句が数値や複数選択肢を持つことが明確になるように変数形式で記述するとわかりやすいです。 原因結果グラフ技法で使われるデシジョンテーブルは、制約指定のように命題形式で記述します。 条件指定部• 動作記述部(action stub) 考慮すべき動作・結果を列挙する部分で、図3では「30分無料」「3時間30分無料」などが該当します。 制限指定の場合は、記述した語句が実施されるかされないか(真であるか偽であるか)が明確になるように命題形式で記述するとわかりやすいです。 拡張指定の場合は、記述した語句が実施される動作そのものや結果そのものを記述するとわかりやすいです。 原因結果グラフ技法で使われるデシジョンテーブルは、制約指定のように命題形式で記述します。 動作指定部• 条件指定部(condition entry) それぞれの条件・原因を特定の値・意味で指定し、ひとつのルールと関連付けをします。 条件指定部には表1のような書き方をします。 すべての条件・原因の値・意味が指定されるとひとつのルールが定められ、自動的に動作・結果が決定されます。 また、ひとつのルールは他のルールと一致しないように値・意味の組合せをとります。 JIS X 0125 では規定していませんが、列挙される条件・原因の順序が判定順序などの意味を持つ場合もあります。 ただし、原因結果グラフ技法で使われるデシジョンテーブルの場合は、順序に関するREQ制約などを用いて判定順序を表現し、特にCEGTestでは列挙される順序を論理点の検証順序として利用しています。 条件指定について 表記 ルールで関連付ける意味 CEGTest 表記 Y (Yes) この行に対応する条件・原因が真であることを意味します。 T、t N (No) この行に対応する条件・原因が偽であることを意味します。 F、f 値、語句など この行に対応する条件・原因が記述された値であったり、語句を満たすことを意味します。 — この行に対応する条件・原因が無関係であることを意味します。 また、特に他の条件・原因の組合せによってこの行に対応する条件が起こり得ないことを「 」で表記する場合もあります。 条件指定部• 動作指定部(action entry) それぞれの動作・結果を特定の値・意味で指定し、ひとつのルールと関連付けをします。 列挙される動作・結果の順序は、実行される動作(生じる結果)の順序を表現しています。 動作指定部には表2のような書き方をします。 もし、順序の異なる動作・結果がある場合には、必要な順序組合せの個数分だけ動作指定部を記述する必要があります。 動作指定について 表記 ルールで関連付ける意味 CEGTest 表記 X (eXecute) この列に指定された条件・原因の真偽値にすべて適合する場合、この行に対応する動作・結果が生じることを意味します。 T、t — この列に指定された条件・原因の真偽値にすべて適合する場合、この行に対応する動作・結果が生じないことを意味します。 F、f 値、語句など この列に指定された条件・原因の真偽値にすべて適合する場合、この行に対応する動作・結果が記述された値であったり、語句を満たすことを意味します。 動作指定部 デシジョンテーブルの具体例 (作成中) 参考文献・引用文献 [1] , 日本規格協会.

次の

ビジネス・ルール管理システム(BRMS)

ディシジョン テーブル

ルールの中で使用するデータ・モデルの生成 Rule Designer のルール・プロジェクト・マップの設計の枠内の XOM のインポートをクリックします。 次に、実行オブジェクト・モデルのインポート・ウインドウでは、動的実行オブジェクト・モデル(XSD)を選択し、OK ボタンをクリックします。 プロパティーウインドウが開きますので、動的バインディング・タブの右側に表示される XSD の追加ボタンをクリックし、先ほど作成した XSD ファイルを選択して OK ボタンをクリックします。 次にルール・プロジェクト・マップの設計の枠内の BOM の作成をクリックします。 新規 BOM エントリー・ウインドウで、XOM の参照ボタンをクリックし、先ほど作成した、xsd ファイルを選択し、OK ボタンをクリックします。 図3 新規 BOM エントリー・ウインドウに戻り、パッケージの先頭にあるチェックボックスにチェックを入れて、終了ボタンをクリックします。 ルール・エクスプローラー・ペインの bom フォルダの中を展開し、 interfaceData クラスをクリックして、その構造を確認します。 図7にあるように、こんにちは世界のディシジョン・テーブルが表示されます。 表形式ですが、列の色が異なっています。 A 列から C 列までは、欄内が白く D 列は、グレーになっています。 これは、デフォルトでは、A — C 列を条件式、D 列に結果を入力できるように表示されただけで、編集可能です。 列の増減は、列名が表示されている欄上で右クリックをします。 図8 ここでは、単純化のために条件式の列を削除して、条件式の列を1つ、結果式の列を1つにします。 A 列の欄上で右クリックをして、条件式の編集を選択します。 擬似コードであらわすと、以下のような感じです。 図11 つまり、この列の行に入力したデータが、条件列式の と交換されたことになります。 次に、B 列の式を定義していきます。 B 列を右クリックし、アクション列の編集を選択します。 ここでは、入力文字列式の評価に合致した場合に、何をおこなうかを入力します。 入力文字列の操作と同様の操作で、アクション欄に式を入力します。 プロパティー欄のタイトルには、結果出力列と入力し、終了ボタンをクリックします。 図13 ディシジョン・テーブルの右上にある虫眼鏡がついたアイコンをクリックし、意思決定表プロパティーを開きます。 表ビューの欄のルール表示にチェックを入れて OK ボタンをクリックします。 ディシジョン・テーブルの1行目を選択すると、図のように、その行がどのようなルールを表現しているのかが確認できます。 2行目も式の構造は同じく、異なる文字列が入っていた場合に、評価されて文字列をセットします。 ディシジョン・テーブルは、式の構造が同じであるが、格納されている値によって、異なる結果をセットするような場合に便利な記述方式です。 ここでは、ひとつの条件式ですが、複数の条件式を持つこともできますし、それらの条件式の関係は、 AND 条件だけではなく、 OR 条件の記述を組み合わせることができます。 また、結果列も複数設定することができます。 テスト ODM では、テスト機能として、Decision Validation Service という機能を提供しています。 これは、テスト・シナリオとして、エクセル・ファイルに入力の値と期待する結果の値を記入しテスト・データとして実行させることができ、テストの実行結果は、 HTML で出力されます。 ルール・エクスプローラー上で、ルール・プロジェクトを右クリックし、メニューの Decision Validation Service を選択し、Excel シナリオ・ファイル・テンプレートの作成を選択します。 図15 保存する場所などはデフォルトのままで、予期した結果ウインドウまで進み、エレメント欄のマイデータの out string2 にチェックを入れて終了ボタンをクリックします。 図16 続いて、ルール・エクスプローラー内に作成された testsuite. xlsx ファイルを開きます。 図17のテスト・シナリオと図14のディシジョン・テーブルを見比べてみてください。 シナリオ2は、ディシジョン・テーブルの結果と同じでしょうか?今回はあえて、実行結果にエラーが表示されるようにテスト・シナリオを設定してみました。 適宜編集して実行させてみてください。 テストの実行 ルール・エクスプローラー上で、ルール・プロジェクトを右クリックし、メニューの実行を選択し、構成:実行を選択します。 構成:実行ウインドウが開くので、画面左側のメニューから DVS Excel ファイルを右クリックし、新規を選択します。 ソース欄の Excel ファイル、ルール・プロジェクトでそれぞれ、参照ボタンをクリックし、作成したエクセル・ファイルとルール・プロジェクトを選択します。 出力欄においても、参照ボタンをクリックしルール・プロジェクトを選択します。 適用ボタンをクリックし、実行ボタンをクリックします。 図18 実行ボタンをクリックすると、Rule Designer のコンソール・ペインに実行状態が表示されます。 実行終了の文字列が表示されたらルール・エクスプローラーのプロジェクト上で右クリックから更新を選択します。 report. html ファイルが出力されますので、右クリックから「次を使用して開く」を選択し、Web ブラウザーで開きます。 テスト結果を確認し、失敗した個所を特定し、ルールが間違えていたのか、シナリオが間違えていたのかを確認し、修正の後、再度テストを実行してみてください。 まとめ 本資料では、シンプルなルールを実装する手順のみを示しましたが、ディシジョン・テーブルの利用にあたっては、以下のような利用形態がありますので、実際のビジネス・ルールに応じて表現してみてください。 式の中に、 AND 条件と OR 条件を入れる• 式の値を選択式にする BOM 定義のドメイン値を利用します。 ドメイン値をエクセル・ファイルに定義してメンテナンスを簡単にするダイナミック・ドメインという方式も使用できます。 ディシジョン・テーブルの欄の中に、式を書く 例としては、金額算出のための式定義や、日付のチェックを行うなど。 Int 型や Date 型を持つ変数の時に記述可能です。 複数の変数を持つ複雑な表現式になる場合は、BOM メソッドを使って隠蔽化する BOM の中に複数の引数を持つメソッドを作成し、メソッドの中で Java 言語で式を記述し、言語化を行うことで、ディシジョン・テーブル上は簡易な表現形式をとることができます。 値 定数 をセットするために使用する.

次の