# 構造化プログラミング Navigation: [[index]] ## 定義 構造化プログラミング(structured programming)とは、[[Edsger W. Dijkstra]] が1969年の NATO Rome 会議への寄稿「Structured Programming」で提唱した、プログラムの正しさをテストではなく数学的証明によって保証しようとする立場・技法を指す。Dijkstra は「プログラムテストはバグの存在を明らかにするために使えるが、その不在を示すためには決して使えない」と主張し、バグの不可避性を前提に入念なテストでそれを発見するアプローチに対し、プログラムが正しく動作することを証明できるようにプログラムの構造そのものを制約し、その構造をプログラミング言語とコンパイラに組み込むことを目指した。(Source: [[@1990__CWIQuarterly__The Roots of Software Engineering]] §6) ## 横断的知見 - Michael S. Mahoney [[@1990__CWIQuarterly__The Roots of Software Engineering]] は、構造化プログラミングを「試して壊れたら直す(test-and-debug)」という [[Henry Ford]] 流の実験的モデルへの対抗として位置づける。NATO会議の一部参加者がソフトウェア設計を実験科学とみなし信頼性を許容誤差の観点で捉えていたのに対し、Dijkstra を含む数学志向の計算機科学者たちは Ford のモデルに応答する形で、証明可能性という別の生産性の道を追求したという構図である。 - Boehm 1976([[@1976__IEEE-TC__Software Engineering]])では、1976年時点で構造化コード(SEQUENCE, IF-THEN-ELSE, CASE, DO WHILE, DO UNTIL の限定制御構造 + 階層的ブロック構造)への移行が進んでいたと報告されており、Pascal・Concurrent Pascal・ALPHARD・CLU などの新言語がその実装として台頭していた。同論文はまた IBM のトップダウン構造化プログラミング + チーフプログラマチームという管理手法にも言及しており、Dijkstra が提唱した「数学的証明としての構造化」が、10年もたたないうちに「制御構造の限定」という実装レベルの技法へと意味を狭めて普及した過程が両ソースの突き合わせから見える。 - 一方、Boehm 1976 はプログラム証明について「1973年時点で100行を証明するのに約1人月の専門家の作業が必要」であり Fortran・Cobol では利用困難と報告しており、Dijkstra が目指した「テスト不要なほどの数学的証明」という理想と、実務で普及した「制御構造の限定」という現実との間には、当初から大きな乖離があったことが分かる。 ## 未解決の問い - Dijkstra が本来意図した「プログラム正当性の数学的証明」としての構造化プログラミングと、実務で定着した「GOTO 排除・限定制御構造」としての構造化プログラミングは、いつどのように分岐したか。 - 形式手法(formal methods)は Dijkstra の当初の理想をどこまで実現したか、あるいは実現できなかった理由は何か。 ## 関連 - source: [[@1990__CWIQuarterly__The Roots of Software Engineering]] / [[@1976__IEEE-TC__Software Engineering]] - entity: [[Edsger W. Dijkstra]] - concept: [[ソフトウェア工学の起源]](数学的検証モデルとしての位置づけ) ## 出典 - Michael S. Mahoney, "The Roots of Software Engineering", *CWI Quarterly* 3, 4 (1990), 325–334. - Edsger W. Dijkstra, "Structured Programming", NATO Rome 会議(1969)寄稿。Peter Naur, Brian Randell, J.N. Buxton (eds.), *Software Engineering: Concepts and Techniques* (NY: Petrocelli/Charter, 1976), 223.