構造化プログラミング


エツハ・ビフ・デクストラ

  • ソフトウェアの科学発展に大きな貢献をした.
  • デックストラには解決したい問題があります.
  • プログラミングはシステム性がなく、プログラミングしても信頼できる結果を出すことは難しい.
  • この問題を
  • 数学的証明によって解決しようとした.
  • 数学証明失敗
  • ソフトウェアは科学的な方法を目標としている.
  • 文章

  • daychstraというgoto文は、モジュールがより小さな単位で再帰的に分解するプロセスを妨げることを発見した.
  • モジュールを取り外すことができなければ、合理的な証明を行う際に必要な分割征服方法を使用することはできない.
  • if/then/elseとdo/while

  • daychstraというgoto文を使用しても、モジュールの分解中に問題は発生しません.
  • if/then/elseおよびdo/whileはgoto文の良好な使用方法であり、単純な制御構造、すなわち分岐および繰返しに相当する.
  • モジュールがこのタイプの制御構造のみを使用する場合、モジュールを証明可能なユニットに再帰的に細分化することができる.
  • 構造化プログラミングの誕生

  • if/then/elseおよびdo/hile制御構造の発見は、すべてのプログラムが順序(sequence)、分岐(selection)、および反復(iteration)の3つの構造のみで表すことができることを意味する.
  • という発見は驚くべきものであり、モジュールの証明性は、その制御構造がすべての生成可能なプログラムの制御構造の最小集合と同じであり、これは構造化プログラミングの誕生を意味することを証明している.
  • コンピュータ言語の進化に伴いgoto文はほとんど消えた.→今の私たちは構造化プログラマーなので、ここには選択の余地がありません.
      제어흐름을 제약 없이 직접 전환할 수 있는 선택권 자체를 언어에서 제공하지 않기 때문이다.
    (もちろんサポートされている言語もあります.重要なのは、多くの言語がgoto文が有害であることを認識していることです)
  • モジュール化の開始

  • 構造化プログラミングにより、モジュールをより小さな証明可能なユニットに再帰的に分解することができ、これは、モジュールが最終的に機能的に分解できることを意味する.
  • の巨大な問題技術書を受け取っても、問題を高レベルの機能に分解することができ、これらの機能は低レベルの機能に再分解することができ、これらの分解過程を限りなく繰り返すことができる.
  • にこのような分解機能を加えると,構造化プログラミングの有限制御構造で表現できる.
  • 数学の証明の失敗

  • デックストラの数学的証明は失敗した.
  • は、各微細機能を厳格に証明する苦しい仕事から得られるメリットは大きくありません.
  • 科学的方法.

  • が正しいことを証明するためではなく、数学を使うべきだ.
  • 科学的方法は証明できないが、反証することができる.
  • 科学は、その内容が事実であることを証明する方法ではなく、記述の誤りを証明する方法で動作する.
  • の反例を挙げることができない記述があれば、目標に合致する程度が本当だと信じています.
  • TDD

  • ソフトウェアは科学と同じです.
  • テストでエラーが検出されるため、証明プログラムはエラーですが、プログラムが正しいことは証明できません.
  • テストで十分な努力がなされた場合、テストはプログラムが目標に合致していると十分に認識されることを保証することができる.
  • 構造化プログラミングでは、プログラムを証明可能な詳細機能セットに再分解する必要がある.
  • はその後、テストに合格し、証明可能な詳細機能が偽物であることを証明しようとした.
  • n/a.結論


    構造化プログラミングに価値があるのは
  • プログラミングで反証可能な単位を生成する能力があることを示す.
  • 現代言語が制約のないgoto文をサポートしていないことを確認します.
  • アーキテクチャは、機能分解をベストプラクティスの1つと見なします.
  • アーキテクチャの方向
  • ソフトウェアアーキテクチャは、モジュール、コンポーネント、およびサービスの反証(テストが容易)を容易にすることに力を入れなければならない.
  • このため、構造化プログラミングと同様の制限規則を吸収し、運用しなければならない.