どうも”ディシジョンテーブル”って、今まで本格的に使ったことがなかったこともあり、ある意味では苦手意識を持ってた。ディシジョンテーブルに関係する”原因-結果グラフ（CEG）”とかについても同様である。（以下では”原因結果グラフ”と表記。なお”CFD法”という手法もそれらに多少関係するが、今回ここでは触れないことにする。）
多少「苦手意識のままじゃいかん」と思い^.^;、今まで使ってこなかった明確な理由があるのかと考えながら、ちょっぴりディシジョンテーブルなどを勉強した。忘れるといけない程度に、メモを残しとく。念のためだけど、あくまで自分の整理のためで、ディシジョンテーブルそのものとか、その題材を否定してるわけじゃない。
なお、ディシジョンテーブルは規格としては、ISO 5806、JIS X 0125:1986 「決定表」。
なぜ避けてきたかを考えたら、、、、。
・そもそも利用したことがない。使う場面に遭遇しなかった/遭遇せずに済んだ。
・ディシジョンテーブルは表計算ソフトとかを利用すると操作しやすいが、原因結果グラフは描画するのが面倒。あるいはそのツールがあるのか良くわからない。
・論理記述の十分性チェック、項目漏れや最適化（論理の再整理）が、ツールで利用できるとありがたいが、その議論を余り聞かない。
・原因結果グラフでは、否定の記号が”∽”を上下逆にしたマークだったり、ANDやORの記号に馴染みがない。電子回路ではNOTやANDなどの記号があるし、そちらの方が入力線が明確だしその類のツールの利用ができるだろうにとついつい考えてしまう。
・勉強会での事例が入場料のようなビジネスプロセス系の話が少なくなくて、（組込みを含めた）ソフトウェアロジックの確認の用途と少し違う感覚が発生してしまう。
・ディシジョンテーブルをモデルの一つと考えると、自分としてはどうしてもコード生成やリバースエンジニアリングの事が頭をよぎるが、その辺りに言及した話が少ない。
・仕様変更などを考えると、履歴管理や差分抽出が行えるべきだが、原因結果グラフそのものでは難しそう。（原因結果グラフのCSVファイルなどで対応するしかないようだ。）
まっ、小学校での分数でつまづいた子が、その後も馴染めないのと似てるかな。^.^;;;
なお、上の”ビジネスプロセス系の話”の項で述べた件は、たとえばJaSST'07 Tokyoでの「三賢者、テストを語る （DTvsCEGvsCFD）」ではこうである。（ちなみに本ミニパネルは、ソフトウェアテストの人たちには有名。）
http://www.jasst.jp/archives/jasst07e/pdf/A5.pdf
テーマ２が入場料問題となっている。PDFのP28、P30。個人的には、ソフトウェアでの観点で”入場券売機”問題と考え、1200円、1000円、600円、500円のボタンがあれば良い気がしてしまう。あるいは、半額ボタンと1200円、1000円ボタン。（処理的には押されたボタンの券を発券する、後者だと半額ボタンが押された後なら半額券を発券。）
逆に入場でのチェック手順だとすると、団体での人数確認とか年齢確認、県内在住かの確認方法などが書かれてそうに思えてしまう。（厳密なチェックかは別として。）
入場料のような事項をベースにしたものがディシジョンテーブルの事例に少なくなくて、自分はどうもそこで頭が停止してしまうようだ。つまり、なんで入場券販売機の話にならないんだろうと考えてしまう。（ちなみにビジネスなりエンプラ系でのディシジョンテーブルの利用に関しては多少後述。）
で、今回「それじゃいかん」と思い、勉強なりおさらいしたことをいくつか。
まず、ディシジョンテーブルなどの歴史的なこと。これは、ソフトウェアテストPRESS Vol.8の「テスト技法の歴史」に書かれている。例えば、GE社には1960年に、ディシジョンテーブルから直接TABSOLというコンピュータ言語へのソースコード生成の方法があったと。”TABSOL”、”tabular systems oriented language”での検索でも引っかかる。
原因結果グラフに関しては、Myersの著書で広く知られるようになったとし、TELDAPというツールや日立製作所でのツールに関しても触れている。これらのツールは1970年とか1980年。所謂グラフィック端末を利用するツールだったのではないだろうかとふと思った。なお、GEや日立などのツールが、今でも、しかも外販等されていてポピュラーな言語への対応や開発環境に組み込まれていたら便利と思ったが、どうやらそれは無理そう。
ただし原因結果グラフでのTELDAPというツールは、今は”BenderRBT Test Case Design Tool”として利用可能なようだ。（価格までは不明。）
http://benderrbt.com/bendersoftware.htm
http://www.stickyminds.com/sitewide.asp?ObjectId=4436&Function=edetail&ObjectType=TOOL
ディシジョンテーブルのおさらいも兼ねて、Myersの「ソフトウェア・テストの技法」を再読。多少1版、2版を比較したけど、ここでは2版でのページ数などで。
この本での事例は、メモリダンプ（メモリの開始番地、終了番地を入力して、その値を表示する）。P70。 ”DISPLAY”というコマンドで、第1パラメータが開始番地、省略されたら、、、、。といたって具体的な仕様記述。
しかも、考えられるテストケースが列挙されている。P79、P80。2つのパラメータの省略とか終了番地の方が大きい場合など。さらに言えば、”DISPLAY”コマンドでのエラーメッセージ3種類が示されていて、各テストではどのエラーメッセージになるかとの予測まで書かれている。ある意味では当たり前だが。
そしてディシジョンテーブルを元に、原因と結果の紐付けと同時に、テストケースとの関係を述べている。なおテストケース22はあり得ないというのは、22のテストでは最終番地が７FFFなので、結果が1行で収まることはなくてテストケース33での結果と同じはずであるとのことと思われる。
ちなみにP68では、原因結果グラフと、それと等価な論理図（論理回路図）を示している。
また読者に考えさせられる記述（P82）もあり、”DISPLAY”の実行で1行以内かそうでないかの視点が大事ということである。ある意味テスト項目の変更なり見直しの必要性の述べていると考えた。また、限界条件のテストケース（P63）やエラー推定で追加した方が良さそうなテストケースについても述べている(P84)。
「ソフトウェア・テストの技法」を読むと、開発～テストの流れとしては、ある程度自然に思えてきた。原因結果グラフも、動作仕様の検討の際にどの条件から考えていくかには悪くない考え（かもしれない）と思えてきた。
では何故「ソフトウェア・テストの技法」で触れているのに、使ってみなかったかだけど、、、、。昔だと原因結果グラフの描画ツールが身近にないこととか、既に述べたように図のアイコンに馴染みがないのが大きな理由だろう。
また本に書かれている”DISPLAY”コマンドの事例では、パラメータは2つでその解析部分は同じような処理となる。そうなると、後は省略時とか開始のパラメータの方が大きい場合程度のテストを行えば良いことになる。なので、こじつけになろうが、表にまでする必要はないと感じたかもしれない。
「ソフトウェア・テストの技法」を読んで、テストの網羅性確認などにはディシジョンテーブルは良いかもしれないとの視点で、ネットなどを再調査してみた。ポツリポツリとネット上にツールを見つけることができた。もっと本格的なものがあるかもしれないが、目に付いたものを紹介。（一部は、以前から多少知っていたのもあるけど。）
・「CEGTest」
http://softest.cocolog-nifty.com/labo/CEGTest/
ソフトウェアテスト関連の人たちには有名なツール。”CEGTest”での検索で、実例とか関連する話題も引っかかる。
ブラウザ上で原因結果グラフの作成ができ、ディシジョンテーブルも描画される。画面上でCSV文字列をペーストしたりすることでインポートやエクスポートは可能だが、基本的に画面上の操作のみと考えた方がよい。
・「Testlink」でディシジョンテーブルのインポート
http://d.hatena.ne.jp/mamecyan2001/20090727/1248682218
テスト管理ツールのリンクが可能であるとのことで、ディシジョンテーブルそのものの論理性のチェックや最適化は別途行うことになる。
・「PICTMaster」でのディシジョンテーブル
http://ameblo.jp/pictmaster/theme-10011516354.html
PICTMasterは、組合わせテストの生成のためのツールとしてソフトウェアテスト関連の人たちには知られている。ただし個人的にはディシジョンテーブルはロジックを表すものとの理解なので、組合せテストでの制約条件の操作でディシジョンテーブルを生成できる方法は、こんな事もできるとの範疇と思える。
・オラクルのツールで、ビジネスルール記述でディシジョンテーブルを利用できるようだ。
http://thinkit.co.jp/story/2010/09/17/1762?page=0,0
・SAPでの真理値表に関するページ
http://help.sap.com/saphelp_46c/helpdata/ja/5b/d2331b43c611d182b30000e829fbfe/content.htm
単なる演算子の説明かもしれない。真理値表の（R3とかERPシリーズでの）利用方法などのページはすぐに見つからず。
・以下もビジネスルール記述ツールでの例
・モデリングツール「Enterprise Architect」でも、ディシジョンテーブルを使えるが、、、、
http://www.sparxsystems.jp/help/compose_business_rules.htm
ディシジョンテーブルそのものの論理記述の十分性チェックなどは行ってくれそうだが、ページの記述では良くわからない。あるいはコード生成の利用とかで判別するのかもしれないし、論理記述の十分性のチェックはできないのかもしれない。
いずれにしろ残念なことに（何故か）、Enterprise Architect Suite ビジネスモデリング版での機能で、（組込み系のための）システムエンジニアリング版では利用できないようだ。
・「デシジョン・テーブルを活用する」
http://homepage3.nifty.com/kaku-chan/q_and_p/decision_table.html
規格を踏まえての説明、表の圧縮などが丁寧に説明されている。
なお、ディシジョンテーブルは”真理値表”とも呼ばれ、論理回路を記述しチェックするのには利用されている。
・MATLABでの真理値表
http://www.mathworks.co.jp/help/ja_JP/toolbox/stateflow/ug/f32-95974.html
この後のコンテンツに、Simulink モデルでの利用が記載されている。
・組込みソフトモデリングでの特化ツール
真理値表記述が可能なものがあるようだ。
http://www.argo-s.com/ae/tuto/tuto.html
・ブール関数（論理式）の最簡形を求めるツール
簡単な論理式や、1出力に対する条件の最適を求める場合には有効。ソフトウェアロジックで利用する事は少ないと思われるが、参考程度に。
・EDAツールでの最適化
回路の最適化、つまり真理値表での不要な部分の削除や最適な回路への置き換えを行ってくれる。ここでの記述は一般的なものだが、大抵のEDAツールには備わっているだろう。
http://www.takagi.nuie.nagoya-u.ac.jp/~ktakagi/kougi/eda/first/index.html
ここで記載した上やMATLABでの真理値表以外にも、EDAやそれに類する世界には、モデリングやさらには最適化そして自動テストの類のツールが非常に多い。このようなツールを利用するのも1つの手段かもしれない。実際、ソフトウェアの検証のために活用している記事や、これらのツールでの出力結果の書き込みなどもぽつりぽつりとあるように感じる。
・論理回路用ツール
いくつかの入力に対して出力を記述することで、論理式を出力してくれるものがある。論理回路では、「カルノー図」なるものがあるがそちらを表示してくれるものもある。以下は、フリーの例。
http://www.vector.co.jp/soft/win95/edu/se314587.html
ディシジョンテーブルでの1つの結果（ここでは出力）を本ツールなどで論理式として表示させたりは可能だろうが、複数の結果を含めてさらに最適化まで検討するとなると、EDAツールの世界になりそう。特にソフトウェアロジックの検討時には論理式は必要なことがあるが、テストの検討では記述の十分性チェックや項目漏れが重要だからだ。
で、結論めいた話。プログラム作成でのロジック検証としてのディシジョンテーブルは、使っている開発環境のツールにあれば利用しても良いかな～程度に思えてきた。無くてディシジョンテーブルを利用したければ、表ソフトで作ってレビュー行うとかも良いかもしれない。なお状態遷移表でも（完璧は無理としても）、できるかもしれないのでちょっと検討してみるつもり。 ちなみに個人的には、ロジック検証などをさらに厳密に行うには、形式手法を利用したり、動的な網羅率の監視などの方が有効に思える。
またどちらかというと設計時にディシジョンテーブルを使うのは、最適化まで含めてソフトウェアロジックをシンプルとするメリットを念頭に置いた方がよいだろう。複雑なままではメンテナンスに苦慮する。
ソフトウェアテストの方は、設計でのディシジョンテーブルを利用したテスト項目は、必須テスト項目と考えて状況に応じて追加しても良い/大抵は追加すべきであろう。特にエラー推測などは別枠にして、ディシジョンテーブル上は代表項目程度にする方が良さそうに思う。これは「ソフトウェア・テストの技法」でのエラー推定追加に関する記載にも関連する。ブラックボックステストでの利用では、ディシジョンテーブルはテストケースの検討には悪くないかもしれない。特にテストの限界条件を探るのには悪くない。
注意点は、テスト追加のバランス。特定部分だけに追加テスト項目が偏るのは芳しくない。（テスト結果での不具合が偏ってテスト項目追加するような事態だと、その部分の設計手直しが重要になるだろう。）
なお、設計時のロジック検討で、原因結果グラフのようなもので検討することは悪くないだろうが、設計者とか設計チームの好き嫌いに依存しそうだ。社内規定で原因結果グラフの提出が必須なら別だが、そうでなければ思考用のツールを利用が良さそうに感じる。設計時は、どうモジュール化するかとか様々な検討も必要なためだ。テスト、特にブラックボックステストでも同様と言える。ただ、項目の詳細化の際にはディシジョンテーブルのように、明確に項目列挙してみるのは悪くない。表にY、NやXを埋める前に、入力や処理の項目自体が妥当かの確認は行った方が良いだろう。
ただし、いずれにしろ、ディシジョンテーブルを作成した場合の項目過不足チェックは重要。表計算（エクセルとか）のマクロなどでも良さそうだ。こちらもちょっと考えてみるか、、、、。というか、既にポピュラーなものがどこかにあったら教えてください。
