第5回レポートの講評

1． 前回のガソリンスタンドの例を function-oriented design で書きなさい。前回のオブジェクト指向デザインについても、修正したい場合は再チャレンジして出してもらってかまいません。

• FOD の場合、DFD を書き、次に function call tree を書くというのが設計手順になります。どちらか一方しか書いていない人もいました。
• 設計そのものはあまり間違いがありませんでした。やはり、OOD よりはとっつきやすいようです。

２． 次のａ〜ｃのいずれかを回答しなさい。なるべくａを回答すること
（ａ） これまでの実験演習、あるいはその他の場（趣味やアルバイト等）でプログラムを作成した経験の中で、ソフトウェアの誤りの発見に苦労した例や、誤りが発覚するのが遅れた例などを一つ挙げ、その際のテストの方法や設計方法について反省・改善すべき点があれば書きなさい。 （ｂ以下の問題文は略。）

• いろいろな意見がありました。
• 一部に、何が反省点なのかわからない解答がありました。
• 精神的訓話もあってかまわないのですが、ソフトウェア工学ですから、方法論やツールがどうあるべきかという観点で書くことが大事です。たとえば、「気を付ける」というだけでは精神論です。「○○に関するチェックリストを用意して、チェックする。」だと方法論です。

３． 一行の英文テキストを入力し、連続した空白を一個の空白に置き換えて出力するプログラムがある。例えば、"This△is△△a△△△pen." (△は空白) を入力すると、"This△is△a△pen." を出力する。このプログラムをテスト (black-box test)するのに必要なテストケースを書き下しなさい。仕様の詳細で不明点があれば、適当に仮定し、その仮定を示すこと。 　

• 仕様の不明確点として、入力を受け付ける長さの制限があります。これを指摘して制限を仮定し、制限長を越える文字列を入力するテストを含めてくれた人がいました。良い解答です。
• 単語一個のみ、空白のみ、長さゼロの文字列の入力なども必要です。忘れている人がいました。
• たとえば、長さゼロの入力は受け付けないという仕様を仮定した場合でも、長さゼロの文字列を入力するテストは必要です。これは、正しく「受け付けない」ことを確認するためです。一般に、許容外の入力がなされた場合にどのような振るまいをするかも仕様としては明確にせねばなりません。

４．プログラムの Static Verification (レビュー) の利点を、Dynamic Verification と比較してまとめなさい。

• 低コストでエラーを見つけられる、開発の早期から開始できる、一度に多数のエラーを見つけられる、一つのエラーの悪影響で出現するエラーに惑わされない、ソースコード以外のドキュメントも対象にできる、ソースコードのドキュメント性の向上（変数名、コメント）、要員教育効果などが利点です。
• コストの件とドキュメント性の件がよく洩れていました。大事な話なのですが。
• 半面、一つのエラーの悪影響が出ないという点は、意外に多くの人が指摘していました。やはり、コストの話よりわかりやすいのでしょうか。