ロジックとアーキテクチャの境界を設計する（その１） ～設計者やプログラマにお勧めする原因結果グラフ技法～
UMLやSysMLと同等の位置づけで原因結果グラフ活用をお勧めする理由
原因結果グラフ技法は、ソフトウェアテストの国際規格ISO/IEC/IEEE 29119の中にも示され、ソフトウェアテストのテスト設計技法として知られているものです。しかし、ここでは特に開発設計者やプログラマの皆さまに役立てて頂くことを念頭に置いて、この技法を数回に分けて紹介しています。
原因結果グラフ技法がテスト技法としてよく知れ渡るに至っているのは、デシジョンテーブルが自動生成できるとか、テスト数を減らすことができるとか、MC/DCカバレッジを満たす(通す)テスト設計が簡単にできるとか、わかりやすいメリットがテスト設計に関わるからのように思います。
もっと本質的な効用があると思うので、本稿はそのことについて記載します。
原因結果グラフは、UMLやSysMLと同等の位置づけで活用すると良いのではないかと思います。それは、論理演算処理の部分とアーキテクチャの境界を明確に図解表現できるからです。
ここでアーキテクチャと呼んでいるものは、取り急ぎちょっとした仕組みぐらいの意味で捉えて頂ければよいものです。例えば以下のようなものです。
・たった一つの選択肢しか選べないように強制するラジオボタンやプルダウンメニュー
・グレーアウトされて選択できなくなってしまうチェックボックスやメニュー項目
・受話器を上げないと硬貨の投入を受け付けない公衆電話(これはもしかしたら「おつりを受け取るには受話器を元の場所に戻してフックを下げなければならない公衆電話」ということだったのかもしれません。)
・Pレンジでブレーキを踏んでいなければオンにならないイグニッションスイッチ
・銀行振り込みとクレジットカード払いの選択で遷移先が異なる画面遷移システム
インターロックなどの安全機構やインストーラなどでよく見るウィザード、もっと広くナッジのようなものを思い浮かべて頂いても良いと思います。
こうしたアーキテクチャ(仕組み)は、利用者への利便性の提供のためであったり、安全対策のためであったり、といった側面があって導入されることなので、それによってその処理を行うソフトウェアの論理的な処理の複雑さを縮減もしているという側面について忘れられがちであるように思います。
設計者やプログラマは、こうしたアーキテクチャ(仕組み)と組み合わせることで、望ましくない論理的組み合わせが起こることを排除できます。つまり、これを利用して設計で考慮すべき論理関係の複雑さを縮減し、残りの論理演算処理に集中することができるようになります。
例えば、次のようにラジオボタンやプルダウンメニューを使用すれば、複数の選択肢の中の一つを必ず選ばせることができます。
ですから、論理演算処理の方では、もうそれ以外のケースがないことを前提とした単純化した設計で済ませることができます。選択肢が一つも選ばれていないケースや、複数選択されてしまっているケース、思いもかけない他の値が入ってくること等を想定した処理を考えなくて良くなるわけです。
そうしたアーキテクチャは、ハードウェアによるものであるとか、予め用意されたGUI部品のような、必ずしも外側で用意されるものばかりとは限りません。例えば似たような意味で画面遷移も活用されています。銀行口座の入力画面に遷移してきた処理を考える際には、もうクレジットカードでの支払いやコンビニ払いの可能性を想定する必要は無くなっていることでしょう。
このような、言ってみればアーキテクチャと論理演算処理での分掌は、普通に行われていることだと思います。形式手法で定義するのが難しいと感じている人が、フロー図でなら描き始めることができるのは、こうした思考プロセスと深く関係しているとも思います。
さて、このこと自体に問題があると主張する考えは全くありません。しかし、設計者やプログラマが割と無自覚にアーキテクチャ(仕組み)と論理演算処理の境界を切り分けている場合があることには問題があると思っています。無自覚に行われると、明示化されることがありませんし、情報共有もされないということになるからです。
実際、この境界を誤認したり、メンバー間で異なった認識を持っていたりすることが、しばしばバグを招き寄せる要因になっています。バグの分析を行って、その原因を辿っていくと、この問題が出てくることが結構あるのです。
利用者の効用とは別に、開発・設計における複雑さの縮減を明示した方が良い理由
何らかの利用者の効用を狙いとすることと、開発・設計における複雑さの縮減という狙いは、まずはそれぞれ独立したものとして評価・検討されるべきです。しかし、実際にほとんどの現場では、そうしてはいません。
利用者が迷わないように複雑さを縮減した結果、開発・設計における複雑さも縮減された、ということは、もちろん普通にあることです。普通だから自覚されないことが多いのかもしれません。
もちろんそれで問題が起こらなければ良いわけですが、先述した通り、バグを呼び込む要因の一つになっていると考えられます。そこで、改めてこの辺りの関係を少し整理してみようと考えました。そして先述した異なる狙いに相当する２つの軸で象限を分けて図にしてみたのが下図になります。
このように整理してみると、象限別に少しずつ違った手法やスタンスで設計や検証に取り組んでいることが多いことに気付きます。
例えば、論理関係をしっかり整理しようと考えたときに、一般によく用いられるのがデシジョンテーブルだと思います。
ただ、デシジョンテーブルは、図の右上の象限の部分を中心に作成されることが多く、それ以外のところは省略されることも多いです。
また、省略せずにかなり丁寧に作成された場合でも、結局デシジョンテーブルからでは、そのどの部分がアーキテクチャに任され、どの部分が論理演算処理されるのか、境界線を読み取ることができません。境界線を曖昧にしてきていることに気付かされます。
それに対して、原因結果グラフでは、論理演算すべき部分を命題表現したノードと論理演算子を用いたブールグラフで、そしてアーキテクチャ部分を「制約関係」と呼ぶ別の表記方法でグラフに描き加えることができます。
超単純な実例で紹介する原因結果グラフ
実際にやってみないとどういうことなのか分かり難いと思いますので、超単純な事例についてグラフを描いてみたものを以下に示します。
要求仕様から、A, B, Cの3つの選択肢があり、そのうちの一つだけを選ぶことができるものとします。そこでまず、A, B, Cの3つの選択肢の中の一つだけがちゃんと選択されているか確認する処理を考えてみます。ここではその確認できた場合を「One制約が成り立っている」と表現しています。
上図は、A, B, Cの3つの選択肢について、そのうちの一つだけが選ばれているかどうかを論理演算で確認する場合を表現しています。
デシジョンテーブルを見るとわかる通り、#1, #5, #7のケースが「One制約が成り立っている」を満たしており、それ以外は無効系として取り扱わなければならないことがわかります。
しかし、そもそもラジオボタン等のGUI部品を用いて、最初からA, B, Cの一つしか選択しようのないインタフェースになっていたらどうなるでしょうか？
その場合、上図の#2のように一つも選択しないとか、#3や#4のように二つの項目を同時に選択状態にするとか、そんな入力自体が行えなくなりますよね。
このように、アーキテクチャによってたった一つしか選択肢が選ばれないことを表現するのに、原因結果グラフでは以下の図のようにOne制約と呼ぶ制約関係を描き入れることでそれを表現することができます。
生成されたデシジョンテーブルの方を見てください。#1～#3までのケースは、A, B, Cの選択肢の中のたった一つが選択されたケースのみを示しており、一つも選ばれなかったり、複数選ばれたりするケースは取り除かれていることがわかります。
テスト技法としては、「原因結果グラフ法で制約関係を描き入れれば、実際にはそのような状況を作り出すことができず、テストできないケースを取り除くことができ、テスト数を減らすことができる」と説明されることが多いのですが、設計やプログラミングをする立場に立てば、「#1～#3までのケースを上手く処理するプログラムを作成すれば良く、それ以外の入力があることは考えなくて良い」と、複雑さが縮減され、問題が単純化されたことになります。
このように、原因結果グラフ法では、論理演算部分のグラフに加えて、アーキテクチャによる制約関係を区別して描き込むことができます。
今回はOne制約だけを紹介しましたが、他にも何通りかの制約関係の表記法が定められています。もちろん、その制約関係に合わせて生成されるデシジョンテーブルも変化することになります。
まとめ
「何をアーキテクチャに担わせたのか？」「それはどの程度確実に機能するべきか？」「アーキテクチャと論理処理の狭間に落ちるケースはないか？」こういった問題を吟味したり、検証方法を検討したりする際に、原因結果グラフはとても役立ちます。
UMLやSysMLでモデルを描いて検討したりレビューしたりするのと同様に、原因結果グラフを描けば、効果的に論理関係と制約関係(アーキテクチャ)、さらにそれらの間の境界を検討したりレビューしたりすることができます。テスト設計のためだけではなく、開発設計においても活用することをお勧めします。
この記事が気に入ったらサポートをしてみませんか？