新人技術者のためのロジカル・シンキング入門（1） ―― いかにしてバグの原因を突き止めるか

【4】自分のブロックが原因かどうかを判定（1/2）

　"YES"か"NO"かで答えが出る設問を作る場合も，全体から部分へと進められるように設問を組み立てていくことがポイントとなります．認証モジュールをダミー・ルーチンに変える例でいうと，認証モジュールが犯人であることが濃厚となったとき，次に試すのは，認証モジュール単体でハングアップが起こせるかどうかです．

● 「デバッグを考えた設計」＝「切り分けしやすい設計」

　まず試みるのは，実際の製品から入力データを入手することでしょう．そして，入力データを認識モジュール単体に与えた場合，ハングアップが起こるかどうかを見ます．ハングアップが起こればアルゴリズムになんらかの問題があったことになるので，次はどこの関数がハングアップしているのかを特定していけばよいことになります．

　実システムからこのようにモジュールの入力データを取り出すのはなかなかたいへんなことで，そのためのデバッグ・コードを作り込んでおかなければならないことも少なくありません．しかし，もしシステムが入力データを絶対に取り出せないしくみになっていたとしたら，これはもはや設計そのものに問題がなかったかを検討する必要があります．とくにこの事例のような認証システムにおいては，認証に用いるモジュールのアルゴリズムとその実装が最重要部品です．したがって，この部分の切り分けができないような設計にしてしまっていたとしたら，そのことそのものが問題にされてしかるべきです．

● リファレンス・モデルとの比較が基本

　また，生体認証モジュールのように，なんらかの科学法則に基づいた方式にのっとって作られたモジュールの場合，かならず「リファレンス・モデル（方式シミュレータと呼ぶこともある）」というパソコンなどで動くC言語のプログラムが用意されているものです．このようにリファレンス・モデルを実ハードウェア上にポーティングして単体モジュールを作り込んだうえで，システムに結合するというのが通常の手順です．単体の組み込みモジュールを作る場合，同じ入力に対してかならずリファレンス・モデルの同じ出力を得ることが基本となります（図7，図8）．

図7　単体モジュール以降の切り分け
大まかにいうと，「リファレンス・モデルに問題がある」，「組み込みモジュールに問題がある」という二つを最初に切り分けたい．後者なら次にロジックに問題があるか，リアルタイム特有の問題かを切り分ける．

図8　リファレンス・モデル
なんらかのアルゴリズムをリファレンスとする場合，リファレンス・モデルから組み込みモジュールを実装することになる．そのため，両者がつねに同じ動きをするのが基本となっている．本文のハングアップの事例でも，両者に差分があるかをまず見極めることになる．

　そのため，入力データを入手したら，このリファレンスの処理結果と比較することになります．もしリファレンス・モデルもハングアップしてしまうようなら，そもそもリファレンス・モデルのアルゴリズムに問題があることになります．そのため，どんなにがんばって組み込みモジュールを作ってもハングアップの原因は潜在していたことになります．かりにリファレンス・モデルがハングアップしないにもかかわらず，組み込みモジュールがハングアップしたのであれば，組み込みモジュールの作り込みに問題があったことになります．

　また，切り分けを進めた結果，実は入力データのフォーマットがなんらかの原因で崩れていて，認証モジュールがハングアップしていたということがわかることもあるでしょう（図9）．そうすると，認証モジュールの前段の処理に実は問題があったということが判明します．

図9　ファイル入出力を用いた動作確認
単体モジュールがハングアップの原因とわかれば，単体での動作確認に移る．まずは，ファイル入出力を用いた動作確認を行う．これは，リアルタイム性を問われないテスト環境でプログラムのロジックに問題がないか（ハングアップするようなコードが含まれていないか）を確認するために行う．