第230回： 「ソフトウェアテストしようぜ」43 CEGTest（13.制約REQ）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、「制約INCL」がテーマでした。
制約INCLは、「制約ONEの複数版」でした。
制約INCLは制約ONEの「原因ノードのすべてがFであることは認めない」を引き継ぎつつ制約ONE「原因ノードは排他的で1つだけがTとなれる」という制約が「原因ノードのうち少なくとも1つはTでなければならない」ものということです。
かえって分かりにくいなあと思われたかもしれません。でもこの理解の方が応用が利くので、まずはこちらで覚えることをお勧めします。
（よくわからないときには、制約INCLは使わないという手もあります）
さて、今回は、5つの制約である、「ONE」、「EXCL」、「INCL」、「REQ」、「MASK」のうちから「REQ」について書きます。
制約REQは、「順序を指定する」制約です。
（といわれても、、、という感じだと思いますが、読み終わるころには「分った」と言ってもらえるように書きます。）
≡ 制約REQとは
これまでと同様に、まずはドリル本に載せたものを示します。
制約REQは、Require（前提）の略で、あるノードが真になるために、事前に真になっていることが必要となるノードを指定します。
上図は、文字列検索を行うダイアログです。図の左下に注目してください。コンボボックスが、選択不能になっています。
実は、下図のように「見つかったすべての項目を強調表示する」にチェックを入れることによって初めてコンボボックスは選択可能となります。
この関係を、原因結果グラフで表すと、次のようになります。
文で書けば、「強調表示箇所を指定するためには、“見つかったすべての項目を強調表示する”というチェックボックスをチェックしておく必要がある」です。
以上が『青ドリル』で書いた例です。ダイアログが古くて懐かしいですね。いつものベン図と、ベン図と同等の表も載せておきます。
ベン図と表ですが、集合Aが、BとCに対してREQしている図となっています。
右表を見ると、Aが真（T）のときには、5, 6, 7行がN/Aつまり、適用できないことがわかります。て今日できない理由はBとCのどちらかにFがあるためです。
ここで、間違い易いのは、AがFの時です。表のNo.1〜4は、AがFの場合の組合せの可・不可を表しています。制約結果はすべてAですので、制約はないということです。
制約REQは、制約もと（この場合はA）がFのときには、何も制約を受けないということです。
ところで、改訂版の『赤ドリル』（59-60ページ）ではWordの「下線の色は、下線の種類を入力してからでないと選ぶことができない」という機能を例として説明しています。『青ドリル』のときのダイアログがなくなっていたからです。
■ 下線の色の指定ができない様子
■ 下線の種類が決まったので、下線の色を選択できるようになった様子
ふと思ったのですが、上記は、次回の制約MASKの例とした方が良かったかもしれません。（アイテムを不活性化＝MASKしているから）
制約REQについての説明なしに、二つの例を見ていただきました。「第177回： 原因結果グラフのREQ制約」で書いた例も見てもらうと更に良いです。
こうして多くの例を見ていただいている理由は、どんなところに制約REQが使えるのかを見ていただいて、「順序を指定する制約」という意味を「ぼんやりと」でもよいので、わかってもらいたいからです。
というのは、「操作順序」が制約になっていることに私たちは気が付かずに生活していることが多いからです。
例えば、私が学生の頃には、ジュースの自動販売機は「硬貨や紙幣を入れてから、商品を選択する」のは、当たり前のことでした。
当たり前ということは、そこに「操作順序の制約」があると気が付いている人はあまりいないということです。
だから、ジュースの自動販売機で電子マネー（SUICAなど）が使えるようになったときに、「商品を選択してから、SUICAをかざす」という、これまでの操作順序が逆転していることに戸惑いました。
故にまずは、「操作順序の制約」の例を見ていただくことが大切と思いました。
制約REQの理解のために、単純な例をもう一つ書きます。
上記は、Twitterのツイート入力画面です。右下の「ツイートする」ボタンが薄い色になっています。この状態では、「ツイートする」ボタンを押すことが出来ません。
理由は一文字も入力していないからです。
制約REQを適用しやすいように、仕様を書き直してみます。
「ツイートする」ボタンは文字が入力されていることを要求している。
以下のような原因結果グラフとなります。比較のため、制約REQを取ったものも載せておきます。
まず、制約REQには方向があることに注目してください。「ツイートする⇒文字が入っている」の方向に矢印が揃っています。
これまでの制約、ONE、EXCL、INCLには方向がありませんでした。
上図のように、制約ONEは「制約ノードから制約を受けている原因ノード「→」が引かれています。制約EXCLのほうも、「抹茶パウダー」、「キャラメルシロップ」、「クラッシュナッツ」に同じように線が引かれているだけです。
書籍『ソフトウェア・テストの技法』や市販のツールなど、一般的には、制約ONEと制約EXCLと制約INCLは矢印にしません。CEGTestツール独自の表現と考えてください。
以下の2つの原因結果グラフは、私が会社でつくったX-CEGツールの表現です。（矢印の有無に着目してください。制約ONEと制約EXCLには矢印がなく、制約REQには矢印があります。）
さて、原因結果グラフにはいろいろな表現方法があることが分かったところで、制約REQでデシジョンテーブルがどう変わったかについて、詳しく見てみたいと思います。
まずは、原因結果グラフとデシジョンテーブルを再掲します。
結果がANDなので、全部がTとひとつずつFのルールがCEGTestツールによって生成されています。
ところが、制約REQによって、「ツイートする」ボタンがTになるためには「文字が入っている」がTであることを要求しているため、ルール3がFTFからfffになっています。
FTFの組合せが制約REQで出せなくなっているということです。カバレッジ表で確認します。
カバレッジ表の最後の行は、論理式 3について制約REQが理由で網羅できないことを示しています。
ちなみに、fffというように、デシジョンテーブルの条件セルがすべて小文字のルールはテストしなくてよいです。（実際テストできません）
上の方で紹介したX-CEGツールでは、テストできないのでデシジョンテーブルには表示していません。
この辺は、好みの問題なのでどちらが正しいということではありません。
≡ おわりに
今回は、「制約REQ」の説明でした。
「制約ONE」と、含意の命題「ならば」が同じ関係という話を書こうか迷った挙句、書きませんでした。
「AがBをREQする」と「A⇒B」（A ならば B）は同じという話です。気になる人は、こちらのウェブページなどをお読みください。
このように制約REQを含意の命題「ならば」で理解する方法もあるのですが、今回は「順序」の制約として説明しました。
その方が分かりやすいですし、どこで使うかも明確になるからです。
次回は、「MASK」を書く予定です。制約は全部で5種類なので、次回の「MASK」で制約の説明は終わりです。
結論を先に書けば、「MASK」は、知っているだけでよい（使わなくてよい）です。
いきなり学習するモチベーションを下げてすみません。大きな原因結果グラフを描くときに制約MASKは大活躍するのですが、「大きな原因結果グラフが必要となるような設計は問題がある」ので、その点を設計レビューの時に指摘してあげる方が100倍マシなんです。
とはいえ、開発するシステムには、商用部品（COTS）を使っていることもあるでしょうしから、制約MASKを使わざるを得ないこともあります。
