programming)は、コンピュータプログラムに「構造」の考え方を導入してソフトウェアの開発効率と品質の向上を図ったプログラミング技法である。今日の「構造化プログラミング」は一般に誤解を招く言葉になっており、以下の3つの解釈が存在している。1969年に計算機科学者のダイクストラが発表した論文[1]。programming)という言葉はこれが初出となる。内容はプログラムの構造設計に関するものであり、抽象から細部へのトップダウン設計、抽象データ+抽象ステートメントのモジュール、細部ジョイントといった考え方が提唱されていた。1966年に計算機科学者のベームとヤコピーニが発表した論文。三つの手段であらゆる計算処理を行えると提唱し、その数学的証明が添えられていた。theorem)として紹介された為にダイクストラの構造化プログラミングとの混同を招く事になった。58」などを先例とし、また上述の構造化定理がその定義名の由来になったと思われるプログラミングパラダイムの一つ。いった制御フローとサブルーチンをブロック単位で記述し、それらを直列または入れ子状に配置する事でプログラムの構造化を実現するという考え方である。プログラミング言語を分類する際のカテゴリ名として使われる事が多い。今日の構造化プログラミングに対する一般的な認識は(3)になっている。(1)のダイクストラが提唱した理論が本来の意味での「構造化プログラミング」であり本稿では(1)について説明する。(2)については「構造化定理」が該当記事になる。structures)を導入する事を意味する。ブロックとは括弧記号またはBEGIN&ENDなどで区切られた一行以上のステートメントのかたまりであり、それぞれは直列または入れ子状に配置される。視覚的に判別しやすいブロックの起点と終点が自動的にフロージャンプの位置指定になるので、結果的に無差別ジャンプのgoto文を使わないで済むようになる。制御構造には以下の四種がある。(sequence)ステートメントを順々に処理する。選択(selection)条件式の結果に従って次に実行するステートメントまたはブロックを選択してフロー分岐する。反復(repetition)特定の状態の間、ステートメントまたはブロック内を繰り返す。状態の確認は反復起点時または反復終点時の二通りある。サブルーチン(subroutine)これをコールした次のステートメントに復帰(return)する事を前提にして対象ブロックの起点にジャンプする。終点に達すると自動的に復帰する他、任意の途中位置でも復帰できる。ソフトウェア工学評議会のワーキングペーパーに計算機科学者エドガー・ダイクストラは「構造化プログラミング」と題した一文を寄稿している[1]。その論旨はいわゆるソフトウェア危機の解決策として従来のボトムアップ設計からトップダウン設計への移行を推奨するものであった。ソフトウェア工学の中でトップダウン設計の必要性が公に提唱されたのはこれが初回とされる。correctness)を証明(demonstration)する為のテスト回数が指数的に増加して完遂が不可能になるというソフトウェア危機の問題について触れられている。ダイクストラは、各部品を下から一つ一つ積み上げてプログラム全体を完成させるという1960年代当時の標準的な開発手順では、膨大化したテスト回数の作業量に対する人手が到底追い付かなくなる事を実際の工程数計算を例に出して警鐘を鳴らした。後半では抽象(abstraction)と細部(refinement)という二つの対になる言葉が定義され、プログラム全体をピラミッド風に階層分割して上の方を抽象化、下の方を細部化とした。abstraction)と呼び、テスト結果と進捗状況を明確にする堅実な手段であるとしながらも、あえてこれとは逆方向の開発手順を提唱した。細部からの開発手順は各部品間の依存関係を生みやすく、これがテスト回数の指数的な増加につながり、ひいてはソフトウェア危機の元凶になっていると見なしたからである。structures)に触れられたのはこの文節だけである。refinement)というプログラム概念を提示した。これは抽象階層では仕様決定できない実装データ(=細部データ)を扱うための仕組みである。statements)とされた。抽象データとそれに関連する抽象ステートメントをひとまとめにしたいわゆるモジュールをダイクストラは真珠(pearl)と呼んだ。細部ジョイントはオブジェクト指向におけるインターフェース、真珠はクラスに相当するものと考えてよい。同論上でSimula67のclass構文も引き合いに出されている。各真珠は互いに依存関係がない独立したモジュールなので連結または分離時の副作用が無く、これによりテスト回数の指数的な増加を回避できるとされた。真珠は細部ジョイントによって抽象から細部に向けて順々に連結されてプログラム全体を構築する。pearls)と呼んだ。真珠は細部ジョイントから随時切り離して必要に応じた別の真珠に交換する事も出来るので、テスト回数を増やす事なく移植や仕様変更にも柔軟に対応できるものとされた。いずれの眼目もプログラムの正当性(correctness)を証明(demonstration)する為のテスト作業量を軽減する事にある。これがダイクストラの唱える構造化プログラミングの趣旨である。歴史[編集]コンピュータが実用化され、その有用性が認められるようになるにつれ、その上で動作するプログラムは次第に大規模なものとなっていった。遡れば、コンピュータ・プログラムのデバッグという仕事の大変さについて1949年に感じた、ということを自伝に残しているウィルクスが、その後に、アラン・チューリングが「大規模ルーチンの検証」といったことを話していた、と書いている。1960年代ではプログラムはフローチャートによる設計が広く採用されており、goto文も広く使われていた[3][4]。その一方でgoto文の多用はプログラムの質を下げるという性質や、多くのプログラムはgotoを使わずに記述できるという性質が経験則として知られていた。1959年のハインツ・ツェマネクによるgoto文への疑問[5]。to文なしプログラミングの実験に関する発表が挙げられる[3]。1966年コラド・ベームとジュゼッペ・ヤコピーニによって、任意のフローチャートは基本フローチャートの組み合わせによる等価なフローチャートに変換できるという定理が示された[6]。前述のように、これを構造化プログラミングと結びつける論者は大変多いが誤解である。Harmful”[5][8]という記事を発表し、大きな反響を呼んだ[9][10]。文除去の話の二番目の場面は,多くの人たちが第一幕だと思っている事実である.」とこの騒動を指して評している。1980年代にマイコンが普及した際に、そのBASICにおいて(由来などの詳細は全く曖昧なまま)「GOTO命令を使わないのが『構造化プログラミング』」などと言われたりしたなど、騒動の影響は後年まで残った。3]1968年、NATO主催のソフトウェア工学会議[11]でソフトウェア危機が共通認識となったとき、ダイクストラは時が来たと考えた[12]。当時、ダイクストラを含むソフトウェア危機の存在に気づいていた人々は、プログラミング活動に対する変化の到来を予測していた。この転換期が訪れるまで、世間一般はそれを受け入れる準備ができていなかった[12]。refinement)、そして真珠のネックレスに例えたプログラムの階層化について述べた。ダイクストラは、構造化プログラミングという言葉を作ったとき2つの失敗をしたと述べた。商標登録しなかったことと定義しなかったことである[13][12]。Technologies)によって当時のプログラマに広く流布した[14][15]。構造化プログラミングはIBMによって発明されたと信じる者も数多く存在した[16]。IBMの構造化プログラミングは、ダイクストラのそれとは異なるものであった[17][18]。産業界や米国ではダイクストラの原則はむしろ不人気でさえあった[19]。1980年代以降、ソフトウェア工学の分野はプログラミング言語や方法論から組織やプロジェクトの管理手法へと軸足を移していた[15]。1987年の第9回ソフトウェア工学国際会議(ICSE)において、IBMの研究員ハーラン・ミルズ(英語版)は会場にチューリング賞受賞者がいないことを確かめると「ダイクストラやホーア達はどこへ行ってしまったのか。我々はもう彼らから学ぶものがないのか。」とその現状を批判した[20][21]。木村泉の見解が当たっていたとするならば、「ソフトウェア工学」をそういったものにしていった張本人こそが、その発言をしたハーラン・ミルズであるということになる。2]という言葉を作り、IBMの研究員の立場を利用して、構造化プログラミングと構造化定理を混同させたと言える。後年、ダイクストラは自身が作った構造化プログラミングという言葉に不快感を示し、避けるようになった[22]。この言葉を名付けたとき、かれはプログラミングが手工芸から科学へ発展することを予測していた[13]。構造化プログラミングという言葉は実利を求めるために使われるようになった[22]。次のような逸話がある。ヨードンの会社に依頼の電話がかかってきた。部下全員に構造化プログラミングなどの構造化技法を1日で叩きこんで欲しいという内容である。それが終わったら開発期間を半分にするという。「構造化技法は生産性を2倍にしますから」というものであった[23]。して構造化プログラミングは、ダイクストラの期待とは異なった形で世に広まっていくことになる。Mills)の提案に由来するgoto-lessプログラミングとして一部分を切り取られた形で広く知られている[24][25][26]。Dijkstra(ダイクストラ)流とはほとんど無関係」である。三つの構造化文[編集]事実[編集]まず、以下のことに関してダイクストラが主張した、というのは事実である。