甲府方重信Blog

...Shigenobu Koufugatas Blog

  • Increase font size
  • Default font size
  • Decrease font size
Error
  • Unable to load Cache Storage: database
  • Unable to load Cache Storage: database
  • Unable to load Cache Storage: database
  • Unable to load Cache Storage: database
  • Unable to load Cache Storage: database
  • Unable to load Cache Storage: database
  • Unable to load Cache Storage: database
  • Unable to load Cache Storage: database
Home 業務日誌 Adaプログラミング Adaチュートリアル セクション17.5 - ソフトウェア・インスペクション

Adaチュートリアル セクション17.5 - ソフトウェア・インスペクション

E-mail Print PDF

セクション 17.5 - ソフトウェア・インスペクション/バグの見分け方

Adaは、一連のソフトウェアの不具合を避けることができますが、いかなる言語であってもバグをすべて取り去ることは不可能です。ソフトウェア品質を向上させ、開発コストと開発期間を低減させるひとつの方法は、ソフトウェア・インスペクションと呼ばれています。ソフトウェア・インスペクションは、不具合を発見する目的のために、小さなグループのペアによってプロダクトの厳格なレビューを行う方法です。レビューされる動作プロダクトは小さいのです。コードで言えば、おおよそ250行がひとつのインスペクションの対象となります。

Inspection Process

ひとつのインスペクションでは、各人(「インスペクター」)が、初期計画段階の間に、役割を与えられます。たとえば、「モデレータ」(モデレーターは、インスペクションをコントロールしますが、作者ではありません)。オプションとしてのプロダクトのオーバービューが作者によって与えられた後、各インスペクターは、プロダクト・コードを注意深く読むことで準備を行います。そこで彼らは完全にプロダクトを理解します。(これは一般的に、1-4時間かかります)。そして、インスペクターは全員で集まり、二時間以上はかけずに、共に不具合を探します。(後で利用するために、これはリストとして記録されます) 必要に応じて、彼らは改善の可能性や、不具合を発見するのとは関係ない事柄を議論するために「第三の時間」としてもう一度集合するかもしれません。作者は、その後、不具合の修正を行います。作者が修正を行った後、モデレーターは修正が大丈夫であることを確かにするためにチェックを行います。そして、再インスペクションが必要であれば行われます。 時として、「カジュアルな分析」のプロセスが共通の不具合とその原因を見分けるため、そしてどのようにその原因を取り除くかを見極めるために行われるべきでしょう。

明らかに、これはかなり厳格なプロセスです。驚くべきことは、多くの人々はインスペクションが実際に、最終的な品質の向上と同様に、トータルの時間とコストを低減させたと書き残していることです。なぜなら、インスペクションはエラーのコストと再作業を低減させることができるのです。インスペクションは、技術的には派手ではありませんが、結果として通常、派手なことよりもより重要です。

インスペクションについてもっと情報を探すひとつの良い方法は、インスペクションについての拙著を買うことです。 (how's that for a plug?). タイトルは、 Software Inspection: An Industry Best Practice, by David A. Wheeler, Bill Brykczynski, and Reg Meeson [Wheeler 1996]; これは、IEEEによって出版されています。インスペクションについては多くの論文が発表されています。ひとつ、よく参照される論文は Michael Fagan [1986]です。 インスペクションについての、いくらかのオンライン情報があります。特筆すべきは、 WWW Formal Technical Review Archive であり、 Software Inspection and Review Organization (SIRO) のホームページです。

 

Adaとバグの見分け方

もしあなたがAdaのコードのインスペクションを担うのであれば、もしくは、自身のコードから不具合らしき部分を探すために単純に読むのであれば、Adaプログラマーの「より共通した」エラーは何であるかを知っておくのは役に立つでしょう。インスペクションでは、「チェックリスト」と呼ばれるリストのようなものがあります。不運なことに、私はあらゆる特定のAdaチェックリストをサポートする公的に配布されているいかなる公的データについて情報を持っておりません。しかしながら、事例情報によれば(John B. Goodenough氏の共通Adaプログラミングエラーのリストのような)、私はあなたが開始点として使用できるような次のチェックリストを挙げることができます。私はみなさんに、みなさん自身のコードにおける共通の不具合を決定するための経験を積むように、みなさんの状況に合わせてこのチェックリストを更新するよう強く勧めます。

Ada チェックリスト - 見分けるポイント:

  1. 初期化されていない変数を読むこと。 Adaコンパイラーは、しばしば初期化されていない変数を発見しますが、常にそうとは限りません。アクセス値は、常にnullに初期化されます。そして、プログラマー自身の型を作成する際に、初期値を強制するようにすることが出来るからです。しかしながら、ほかの型に対しては、特別に初期値が与えられていない変数は、任意のセットの「ゴミ」ビットセットを持っているかもしれません。そして、後に問題を引き起こすこの「ゴミ」データを使うことがあります。 変数を宣言する際に、必要な場合には初期値を与えるというのはしばしばよい考えです。Adaでは、非初期化変数を許すかどうかさえもが、大きな議論の話題となってきました。非初期化変数の許可の根拠は、性能劣化の理由となるため、初期化は必要ないというものです。安全で、セキュアなオプションは、pragma Normalize_Scalarsを付け加えることです。これは、範囲外の変数がありそうな、非初期化変数を設定します。(これにより、非初期化変数の発見が容易になります)
  2. Off-by-oneの境界条件 (ループ条件、配列インデックス、あるいは、比較に対して) これは、ほぼ正しいバウンダリーが持っているエラーです。たとえば、<=を意味する際に、<を使ってしまったらどうでしょう?すべてのプログラムの比較と、ループ境界をチェックします。もしプログラマーが境界外の要素にアクセスを試みれば、実行時例外が上がるでしょう。これは、特定の状況においては役に立ちますが、すべてのケースに当てはまる訳ではないのです。
  3. アクセス型(ポインター)と、ストレージ管理エラー。 (特に、nullリストのような境界条件) 隠れているアクセス(ポインター)値を試そうとすると、プログラムの小さな一部分が、それらを扱おうとするときさえ、初期化・ファイナライズ操作をあなたのストレージを管理するために使用しなければなりません。それは、プログラマーがそうであるべきときにでも「空の」ケースを取り扱うことができるようにするためです。
  4. 返り値の取り扱いが正しくない。 たとえば、rangeを返す関数があるとして、そのrangeの中にすべての値が入っていることを確かにするためには、プログラムによって適切に取り扱わなければなりません。
  5. 特別な条件の取り扱いが正しくない。 すべてのケースを取り扱ったことがあるでしょうか?もし、プログラマーがセンサーからの読み取りを行っている場合、プログラマーはいんちきなセンサー値を取り扱うでしょうか?プログラマーはすべての適切な例外を取り扱うでしょうか?
  6. 配列境界が正しくない。配列の下位境界は、常に1とは限りません。そのため、'First、'Last、'Length、'Rangeなどを配列を渡すときに使用してください。たとえば、渡された文字列は、スライスかもしれません。その場合、文字列の最初の要素は、インデックス値1を持っていないかもしれません。'Firstと'Lastが異なる引数に対しては同じであると仮定しないでください。または、それらが基本型と同じであると仮定しないでください。S'Length(S'Lastではない)を使用して長さを特定してください。
  7. 実体化された制約されない配列。 大きな配列指数(整数もしくは、正の数のような)の配列や、それらを含むようなレコードは、自身のバウンドセットを持っていなければなりません。「Integer'Max」配列要素を持つことができる計算機は少ないのです。
  8. 逆向き「for」ループにおいて「reverse」キーワードを忘れる。 プログラマーは次のようにすべきです。:
        for I in reverse 1..5
    
  9. タスクが予期しない例外にさらされる。もし、タスクが例外をキャッチしないのであれば、そのタスクは終了するでしょう。
  10. タスクにおける無効な公平性の仮定。 いくつかのタスク操作は、「公平性」を保証されていません。たとえば、いくつかの開かれた選択肢において選択を待っている場合には、Adaは、選択肢のどれの間でも取り上げるのは自由です。決して、それらの間を「公平に」取り上げる必要はありません。

出典: http://www.adahome.com/Tutorials/Lovelace/s17s5.htm

Last Updated on Wednesday, 14 August 2013 13:25  

ニュース速報

何千とある無料のエクステンションのライブラリより、あなたはサイトを拡張するために必要とするものを追加できます。 今すぐ Joomla! エクステンション ライブラリに目を通してください。