コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

「構造化プログラミング」の版間の差分

出典: フリー百科事典『ウィキペディア（Wikipedia）』
履歴の双方向閲覧
← 古い編集新しい編集 →
削除された内容 追加された内容
ビジュアルウィキテキスト
戻す版を間違えていたので修正
(他の1人の利用者による、間の1版が非表示)
1行目: 1行目:
{{Otheruses|ダイクストラらによるソフトウェア工学的手法としての「構造化プログラミング」| goto文論争 |goto文}}
{{Otheruses|ダイクストラらによるソフトウェア工学的手法としての「構造化プログラミング」| goto文論争 |goto文}}
'''構造化プログラミング'''（こうぞうかプログラミング、{{lang-en-short|structured programming}}）は、1960年代後半に[[エドガー・ダイクストラ]]らによって提唱された、構造化されたプログラムの構成要素（[[制御構造]]）の利用や、<!--仮想機械モデルに基づく(<ref name="structured_programming_72"/> p.49)--><!--現代の文脈では「仮想機械モデル」と言うと、Java VMなどのVMや、VMwareなどの仮想化における仮想機械が先に出てきてしまうため、段階的詳細化を表現する語としては、冒頭では避けるべき-->[[段階的詳細化法|段階的詳細化]]などを特徴とするプログラミング手法である。
'''構造化プログラミング'''（こうぞうかプログラミング、{{lang-en-short|structured programming}}）とは、[[エドガー・ダイクストラ]]のプログラム正当性証明の教義を実現する方法で、ソフトウェアの複雑な制御フローを連接・選択・繰り返しおよび'''ネスティング'''（nesting）の多層化<ref>このネストの反復によって構成される多層的な「構造」が構造化プログラミングの言う「良い構造」である。ただし、一般にはその肝心の手法としてのネスティングの存在が欠如した説明がなされることがほとんどである。</ref>によって整理しながらプログラミングを行うダイクストラ流[[段階的詳細化法]]<ref>考えかたは同一であるが、手法的に異なる[[ニクラウス・ヴィルト|ヴィルト]]流の段階的詳細化法と呼ぶべきものも存在する。</ref>を言う<ref>[[#河村(1995)|河村(1995)]]pp.112-113、[[#構造化プログラミング(1972)|構造化プログラミング(1972)]]</ref>。単純にgoto文を使用しないgoto-lessプログラミングと理解されていることが多い<ref>構造化プログラミングがgoto-lessプログラミングとして普及してしまった原因として、IBMのハーラン・ミルズ（Harlan D. Mills）の提案の存在を指摘する声もある。H.D.Mills, R.C.Linger, a.R.Hevner, “ボックス構造化情報システム”{{cite book | 和書 | title=ソフトウェアエンジニアリング論文集80's | editor=Tom DeMarco, Timothy Lister(編著) | editor2=児玉公信(監訳) | publisher=翔泳社 | year=2006 | pages=pp.187-219}}収録
</ref><ref>
また、そのように誤解されたまま広まった理由としては、岩波情報科学『算法表現論』p. 58 によれば、「プログラマー（職業としてではなく職種としての）に <code>if …</code> や <code>if … else …</code> や <code>while …</code> だけを使用させ，<code>goto</code> の使用を禁止すれば，ダメな連中でも少しはましなプログラムを書いてくるだろう」というもので、「広く影響を及ぼしたが，内容は Dijkstra（ダイクストラ）流とはほとんど無関係」という側面があったからだとも言われる。
</ref>。


== 段階的詳細化 ==
データ構造化手法として、[[アントニー・ホーア]]および[[オーレ＝ヨハン・ダール]]による[[型]]や[[クラス]]の手法が当初から含まれていた<ref>[[#構造化プログラミング(1972)|構造化プログラミング(1972)]]</ref>。構造化プログラミングの教義は、プログラムの正当性検証<ref>D.グリースはプログラムの正しさの証明を、抽象的なレベルでは正当性証明、具体的なレベルではプログラムの検証と言葉を使い分けているが、ここでは厳密な区別はしない。
[[段階的詳細化法|段階的詳細化]]では、プログラミングの最初の段階では、いきなりプログラミング言語の言語機能を直接使ってプログラムを記述するのではなく、機能を抽象化した「仮想機械」を想定し、その「仮想機械が提供する命令群」でプログラムを構成する、というような手順からプログラミングを始める。普通、抽象化は1段階ではなく階層的である。各階層での実装の詳細は他の階層と隔離されており、実装の変更の影響はその階層内のみに留まる(<ref name="structured_programming"/> Abstract data structures)。各階層はアプリケーションに近い抽象的な方から土台に向かって順序付けられている。この順序は各階層を設計した時間的な順番とは必ずしも一致しない(<ref name="structured_programming"/> Concluding remarks)。
* 金山裕 編, "構造的プログラミング −批判と支持−", ''bit'', Vol.7, Issue 7, 1975, pp.6-13, 共立出版.</ref>の基礎である。
== 概要 ==
[[File:Flow chart of Planning and coding of problems for an electronic computing instrument, 1947.jpg|thumb| 初期のフローチャート 。現代の規格化されたフローチャートと異なり、一見しただけでは、どこからどう読めばよいか把握することが困難である。 "Planning and coding of problems for an electronic computing instrument," 1947 から]]
[[File:Jis-flowchart-fixed.png|thumb|180px| 制御処理が順序的プログラムである「連接」・「選択」・「繰り返し」に限定された現代的なフローチャート（なお、ネストはされていない）。上から下に人間の思考過程に沿った形でプログラムの処理過程を理解することができる。]]


== ダイクストラによるプログラムの正しさの検証手法 ==
プログラムの設計手法としての[[フローチャート]]（flow chart; 流れ図）は、歴史的には1947年に[[:en:Herman_Goldstine|Herman Goldstine]]及び[[フォン・ノイマン]]によって導入されたものである<ref name=planningcoding>{{citation|
コンピュータは与えたプログラムに応じてそれを計算し結果を出力するという装置であるが、プログラムに誤りがあると、当初の意図した命題（仕様）を肯定しないものとなる{{#tag:ref|たとえば、一律に個々の構成要素が正しい確率を p とすると、N 個の構成要素からなるプログラム全体が正しい確率 P は、安直に計算すれば、
author=Herman H. Goldstine, John von Neuman | title=Planning and coding of problems for an electronic computing instrument |year=1947 |url=https://library.ias.edu/files/pdfs/ecp/planningcodingof0103inst.pdf}}</ref>。フローチャートの導入は、それまでのほとんど設計をおこなわず直接プログラミングを行う職人芸的手法を改善するものであったが<ref>[[#河村(1995)|河村(1995)]] p.112</ref>、当時のプログラミング作法を反映して各制御のエリアの記載方法に統一性がなく、一つの入力に対して二つの出力があったり、必ずしも上から下に読めるように定められておらず、小規模ソフトウェアであれば一人の人間の力で把握することはできるものの、大規模なものとなればその把握は実質的に不可能なものであった。

大規模プログラムの開発に関心を持っていた<ref>[[#構造化プログラミング(1972)|構造化プログラミング(1972)]]p.2</ref>[[オランダ]]の[[エドガー・ダイクストラ]]は、仕様通り正しく動く大規模ソフトェア開発の困難さを、この巨大になったときその把握が人間の能力を超えてしまう当時の制御処理方法の無秩序さに求め、ソフトウェア開発において構成要素である各制御処理は、抽象化したとき『頭に一つの入口を持ち尻尾に一つの出口』を持つ'''順序的プログラム'''（sequential program）に限定すべきと主張した<ref>ダイクストラは作法としてプログラムは順序的プログラムであるように記述するべきとしただけで、プログラミング言語に構文論的制約をつけるかどうかについては述べていない。順序的プログラムはちょうど数学における"関数"（function）とみることもできることから、構造化プログラミングは関数型プログラミングと親和性が高い。</ref>。そのため順序的プログラムの構成を自動的に破壊してしまうgoto文は害があると主張し論争を巻き起こすこととなった（[[goto文|goto文論争]]<ref>論争だけが取り上げられた結果、goto-lessプログラミングやtop-downプログラミングは構造化プログラミングと同一視されることとなってしまった。{{cite journal|naid=110002720279 |last=筧 |first=捷彦 |title=ストラクチャード・プログラミング用言語 |journal=情報処理 |volume=16 |number=10 |year=1975 |page=856-863 |publisher=情報処理学会 }}。
</ref>）。

各制御処理を順序的プログラムに限定してしまえば、そのソフトウェアの設計におけるフローチャートは上から下に読めるものとなり、文書を読むように人間の思考の流れとプログラムの進行の流れとが一致することになる。さらにその構成要素の順序的プログラムは、'''経験的に'''<ref>任意の制御構造をもつ順序的プログラムがこの３種類の基本制御構造を組み合わせることで実現できるということを主張する構造化定理（structured theorem）は、ダイクストラらが構造化プログラミングを提唱した1972年の７年後の1979年にRichard C. Linger, Bernard I. Witt, H. D. Millsの共著本によって示された。[https://dl.acm.org/citation.cfm?id=578547 Structured Programming]
</ref>、連接（concatenation）・選択（selection）・繰り返し（repetition）の３種類に分けられるとし、その正しさは、一人の人間が最初の２つに対しては'''数え上げ推論'''（enumaration）、３つめに対しては'''数学的帰納法'''（mathematical induction）<ref>この数学的帰納法を用いる検証については計算機による自動化を行うことができる。[[自動定理証明|定理自動証明]]</ref>を適用することで確認できると主張した<ref>[[#構造化プログラミング(1972)|構造化プログラミング(1972)]]p.22</ref>。

上記道具立てを使用すれば、原理的には大規模ソフトウェアであっても開発することができ、正しさも検証することができる<ref>ここで、順序的プログラムの中にgoto文を一行でも入れてしまうと、数え上げ推論による正当性検証ができなくなってしまい、「ソフトウェア全体の正しさ」というものが原理的に定義できなくなってしまうのである。</ref>。しかしながら、例えば、提唱当時一般的であったアセンブラで、サブルーチンの概念が希薄なまま、順序的プログラムによるプログラミングを実施しても、記憶力という人間の能力の限界によってこれを巨大ソフトウェアに対して実行することは現実的ではない。これを解決する手段としてダイクストラが開発技法として導入したのが'''抽象'''（abstract）及びフローチャートのネスト（nest）すなわち[[段階的詳細化法|段階的詳細化]]<ref>[[段階的詳細化法|段階的詳細化]]では、プログラミングの最初の段階では、いきなりプログラミング言語の言語機能を直接使ってプログラムを記述するのではなく、機能を抽象化した「仮想機械」を想定し、その「仮想機械が提供する命令群」でプログラムを構成する、というような手順からプログラミングを始める。普通、抽象化は1段階ではなく階層的である。各階層での実装の詳細は他の階層と隔離されており、実装の変更の影響はその階層内のみに留まる(Abstract data structures)。各階層はアプリケーションに近い抽象的な方から土台に向かって順序付けられている。この順序は各階層を設計した時間的な順番とは必ずしも一致しない(Concluding remarks)。
</ref>である。

== ダイクストラの構造化プログラミングの教義 ==
大規模ソフトウェアの開発が一般に困難な理由の一つは、N 個の構成要素からなるソフトウェアを動作させたとき、その各構成要素が正しく動作する確率を便宜的に一律 p であるとすれば、正しく動作する確率 P は、
: P = p<sup>N</sup>
: P = p<sup>N</sup>
となり、 N が大きいプログラム（大規模なソフトウェア）においては、誤りの混入により命題（仕様）を肯定しない可能性は飛躍的に高まることがわかる。|group="注釈"}}。
となり、N 個の各構成要素をそれぞれ正しく記述して各 p を 1 に近づけなければならないことにある。これは N が大きい巨大プログラムでは、各構成要素に高い信頼性が要求されることを意味する。

正しく動作する大規模ソフトウェアの開発に関心のあったダイクストラは、人間の能力には限界があることから、当時の主なバグの温床である静的プログラムとその動的プロセスの概念上のギャップを小さくするための何か「独立の座標」が必要であると考えた<ref name="go_to_statement_considered_harmful" />。ダイクストラはその「独立の座標」をフローチャートに求め、プログラムは順序的プログラム（sequential program）に限定すべきとした。


さらに、大規模ソフトウェアの共同開発にあたっては、プログラマは正しいプログラムを作り出すばかりではなく、他の開発者に自身の開発したプログラムの正しさを納得のいくやり方で証明してそれを説明するのがプログラマの仕事であるという立場<ref>[[#構造化プログラミング(1972) |構造化プログラミング(1972)]] p.6 <br />
プログラマは、正しいプログラムを作り出すばかりでなく、納得のいくやり方で正しさを証明することも仕事の一つであるという立場を取っていた<ref>[[#構造化プログラミング(1975) |構造化プログラミング(1975)]] p.6</ref>ダイクストラは、プログラムの正しさの納得のいく証明を遂行するための手法を導入した<ref>これは計算機や大規模プログラムを一種のブラックボックス化された機械装置とみなしてテストによって正しさを確認する手法ではない。ダイクストラは、テストはプログラムに対する疑いを全て取り除くには不十分であることを主張していた。[[#構造化プログラミング(1975)|構造化プログラミング(1975)]] p.5 <br />
この立場は、正しく動作しないと思われるプログラムを提出されたとき、その正しさを共同開発者に示すことを求めても示すことができないことが多い、という一般的現象に対応するものと思われる。
</ref>であったことから、共同開発者などの他人にプログラムの正しさを証明して納得してもらうことができるようにするためには、プログラムは「うまく構造化」させた上で、次の三つの知性の道具
;三つの知性の道具
# '''数え上げ推論'''（enumeration）：一人の人間の能力でできる範囲でプログラムの命令の妥当性を一つ一つ確認すること
# '''数学的帰納法'''（mathematical induction）：while文など計算機特有の繰り返し文についてのみ数学的帰納法を用いて確認すること
# '''抽象'''（abstraction）：処理のまとまりに名前をつけた上で詳細化を後回しにし、仮に正しいとしておくこと
を使って納得させる必要があると説いた<ref>これは計算機や大規模プログラムを一種のブラックボックス化された機械装置とみなしてテストによって正しさを確認する手法ではない。ダイクストラは、テストはプログラムに対する疑いを全て取り除くには不十分であることを主張していた。[[#構造化プログラミング(1972)|構造化プログラミング(1972)]] p.5 <br />
これについてダイクストラは「テストはバグの存在を示すには有効だが、バグが存在しないことは証明できない」という表現を好んで用いた。
これについてダイクストラは「テストはバグの存在を示すには有効だが、バグが存在しないことは証明できない」という表現を好んで用いた。
* E.W.ダイクストラ, “謙虚なプログラマ”, ''ACMチューリング賞講演集'', 木村泉 訳, 共立出版, 1989, pp.23-43.
* E.W.ダイクストラ, “謙虚なプログラマ”, ''ACMチューリング賞講演集'', 木村泉 訳, 共立出版, 1989, pp.23-43.
43行目: 16行目:
* [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD288.html E.W.Dijkstra, "Concern for Correctness as a Guiding Principle for Program Composition", 1970. ]
* [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD288.html E.W.Dijkstra, "Concern for Correctness as a Guiding Principle for Program Composition", 1970. ]
* [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD361.html E.W.Dijkstra, "Programming as a discipline of mathematical nature", 1973. ]
* [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD361.html E.W.Dijkstra, "Programming as a discipline of mathematical nature", 1973. ]
</ref><ref>所与のプログラムの正しさを後付けで証明することは、はじめから証明を意識して作られたプログラムの場合より難しいことが経験的に知られている、と言われる。
</ref>。ただし、その検証<ref>D.グリースはプログラムの正しさの証明を、抽象的なレベルでは正当性証明、具体的なレベルではプログラムの検証と言葉を使い分けているが、ここでは厳密な区別はしない。
* 金山裕 編, "構造的プログラミング −批判と支持−", ''bit'', Vol.7, Issue 7, 1975, pp.6-13, 共立出版.</ref>を実行するためには対象となるプログラムは「うまく構造化」されていなくてはならず、その「うまく構造化」されたプログラムを開発する手法が'''構造化プログラミング'''である{{#tag:ref|すなわち、プログラム検証と構造化プログラミングとは不可分の関係にある。|group="注釈"}}<ref>所与のプログラムの正しさを後付けで証明することは、はじめから証明を意識して作られたプログラムの場合より難しいことが経験的に知られている、と言われる。
* E.W.Dijkstra, "Programming methodologies, their objectives and their nature", ''Structured Programming'', Infotech state of the art report, 1976, pp.205-212, Infotech International.</ref>。この他人に正しさを納得してもらう<ref>ダイクストラが提唱したので、少なくともダイクストラが存命のときであれば、この基準に従い正しさを証明できるように準備したプログラムをダイクストラに見せてその証明を説明すれば、この基準の範囲内の証明である限りにおいて、ダイクストラは「この人が作成したこのプログラムは正しい」と認めることができるということである。
* E.W.Dijkstra, "Programming methodologies, their objectives and their nature", ''Structured Programming'', Infotech state of the art report, 1976, pp.205-212, Infotech International.</ref>。
</ref>ためにうまく構造化されたプログラムを開発する方法を、構造化プログラミング（structured programming）と呼ぶ。


=== ダイクストラの構造化技法 ===
; ダイクストラの三つの知性の道具
# 数え上げ推論（enumeration）：一人の人間の能力でできる範囲でプログラムの命令の妥当性を一つ一つ確認していく作業
ダイクストラは、従来のフローチャートの進行方向を単線化するため、プログラムは順序的プログラムでなくてはならず、さらにその順序的プログラムは'''フローチャートの制御の規律を固守するため'''<ref>[[#構造化プログラミング(1972)|構造化プログラミング(1972)]] p.22<br />
# 数学的帰納法（mathematical induction）：while文など計算機特有の多数の繰り返し文についてのみ数学的帰納法を用いて確認する作業
すなわち、人間が把握することができるようにするために３つの種類に限定したのである。</ref>、連接（concatenation）・選択（selection）・繰り返し（repetition）の三種類の単位（[[ニクラウス・ヴィルト|ヴィルト]]はこれらを構造化文(structured statement)と呼んだ <ref name="systematic_programming">N.ヴィルト, ''系統的プログラミング/入門'', 野下浩平, 筧捷彦, 武市正人 訳, 近代科学社, 1978. </ref>）に限定し<ref>ただし、ダイクストラの構造化文の限定の仕方は数学的ではない。[[ペール・マルティン＝レーフ]]は自身の[[直観主義型理論]]において、フローチャートの代わりに[[ゲンツェン]]流の自然演繹を拡張したものを採用した上で、正しさを確認できるものとしての構造化文に代わるものとしてカノニカル表現（canonical expression）と呼ばれるものを採用している。</ref>、goto文は使用しないようにすべきであるとした<ref>goto文を含むプログラムの正しさを他者に証明して納得させる方法がないからである。</ref>{{#tag:ref|goto文を避けて構造化文を用いるようプログラマーに教えることが、構造化プログラミングの伝統的な知恵である<ref name="sp_in_introductory_programming_courses">C.A.R.Hoare, "Structured programming in introductory programming courses", ''Structured Programming'', Infotech state of the art report, 1976, pp.257-263, Infotech International. </ref>}}。
# 抽象（abstraction）：プログラムのブロックなどに名前をつけ、さらに中身を見ないで正しいと仮定することで検証作業を後回しにする操作
<gallery widths="200px" heights="200px" perrow=6 >
File:Concatenation in structured programming.png |「連接」
File:Ifdostatement in structured programming.png |「選択」の一例(if-do文)
File:Whiledostatment in structured programming.png |「繰り返し」の一例(while文)
</gallery>
;連接（concatenation）
:いくつかの部分順序プログラムの順序的（sequential）な合成は順序プログラムになるときの単位。
:他者に対しては数え上げ推論を用いることでその合成の正しさを納得させることができる。
;選択（selection）
:if-do文、if-then-elese文,ホーアのcase-of文などで、抽象的には一つの入口に対して一つの出口がある単位。
:他者に対しては数え上げ推論を用いることでその内容の正しさを納得させることができる。
;繰り返し（repetition）
:while文やfor文、until文などで、抽象的には一つの入口に対して一つの出口がある単位。
:他者に対しては数え上げ推論及び数学的帰納法を用いることでその内容の正しさを納得させることができる。


=== プログラムの正しさに関する様々な意見 ===
==== 抽象とフローチャートのネスト ====
構造化プログラミングの支持者らは、プログラムの正しさの重要性と証明の方法や表明(assertion)の使い方について熱心に説いた<ref name="the_science_of_programming"/><ref name="structured_programming_72"/><ref name="how_to_solve_it_by_computer">R.Geoff Dromey, ''How to Solve it by Computer'', Prentice Hall, 1982. </ref><ref name="the_craft_of_programming">[http://www.cs.cmu.edu/~jcr/craftprog.html John C. Reynolds, ''The Craft of Programming'', Prentice-Hall, 1981. ]</ref>。
[[File:Abstraction in structured programming.png|thumb|left|300px| 抽象（abstraction）の一例]]
ダイクストラは、プログラミングと同時にプログラムの証明を（わずかに証明を先行して）進めることを推奨している<ref name="a_discipline_of_programming">E.W.ダイクストラ, ''プログラミング原論 ― いかにしてプログラムをつくるか'', 浦昭治訳, サイエンス社, 1983. </ref>。そのようなアプローチでプログラムの正当性の問題にあたれば、複雑な問題であっても知的管理が可能であると述べた{{#tag:ref|ダイクストラはプログラミングと証明を並行するのに適した、最弱事前条件をによる検証方法を考案した。ホーア論理は作り終わったものは証明できるが、これから作るプログラムについては指標を与えてくれない<ref name="software_cleanroom">二木厚吉 監修, ''ソフトウェアクリーンルーム手法'', 日科技連, 1997. </ref>。|group="注釈"}}。
プログラムの正しさを証明するにあたって数え上げ推論（enumeration）は基本的な道具立てであるが、プログラムが非常に多数の構造化文から構成されている場合、その正しさを検証することは、人間の能力に限界があるので、現実的ではない。知性の道具としての数え上げ推論は、人間がプログラムの確かさを確認できる適切な範囲において有効な道具立てでしかない。


また、プログラムの証明に対する反論も存在する。マイケル・ジャクソンは、個々のプログラムに証明を付けることは現実的には難しいだろうと述べている<ref name="bit1979_software_design">マイケル・ジャクソン, 吉村鉄太郎, 山崎利治, 大野徇郎, "ソフトウェア設計哲学", ''bit'', Vol.11, Issue 2, 1979, pp.4-12, 共立出版.</ref>{{#tag:ref|ジャクソンは構造化プログラミング手法の一つであるジャクソン法で有名なコンピュータ・コンサルタント。|group="注釈"}}。
そのため、非常に多数の構造化文からなるプログラムについては、別の道具立てを用いる必要が出てくる。３つめの知性の道具立てである'''抽象'''（abstraction）はこれを解決するものであり、プログラムを構成する部分のまとまりに対して変数名をつけるように名前をつけることで、正しさを証明すべき箇所を分割する。


== 構造化プログラミングの構成要素 ==
例えば、左図のwhile文の正しさを他人に納得させることを考える。左図の左のwhile文は条件文が真のとき、非常に多数の連接された処理を実行しなければならないものとする。このとき、上記までのダイクストラの教義に従えば、その多数の連接された処理も含めて数え上げ推論と数学的帰納法を用いて、正しさを証明しなくてはならないが、すでに左図のようにその多数連接された処理にRという名前を与え、while文の証明（抽象処理Rの詳細レベル０のフローチャートの証明）の際には、仮に正しい手続きとしておけば、ふつうのwhile文の証明として扱うことができる。また、抽象処理R自体の証明（抽象処理Rの詳細レベル１のフローチャートの証明）はそれとは別途で行えばよいということになる。
goto-lessプログラミングやtop-downプログラミングは構造化プログラミングと同一視されることが多い<ref name="languages_for_structured_programming">{{cite journal|naid=110002720279 |last=筧 |first=捷彦 |title=ストラクチャード・プログラミング用言語 |journal=情報処理 |volume=16 |number=10 |year=1975 |page=856-863 |publisher=情報処理学会 }}</ref>。これらは規律あるプログラミングを実現するためのものと考えられている<ref name="problems_of_programming_methodology"/>。が、誤解（後述）も多い。その他にプログラムの検証、情報隠蔽、抽象データ型も構造化プログラミングの主要な概念として取り上げられることがある<ref name="program_design_chap6sec2"/>。


== 誤解 ==
すなわち、この一例における、多数の連接文を含むwhile文の証明は、知性の道具立ての一つである抽象を用いることで、
=== Millsによるgoto-lessプログラミング ===
:「抽象処理Rの詳細レベル０の証明」と「抽象処理Rの詳細レベル１の証明」
歴史的経緯から、構造化プログラミングはIBMの[[ハーラン・ミルズ]]（Harlan Mills）の提案に由来するgoto-lessプログラミングとして一部分を切り取られた形で広く知られている<ref name="goto_nested_loop">{{cite journal|和書|naid=110002712129 |last=金藤|first=栄孝 |last2=二木|first2=厚吉 |title=多重ループからの脱出でのgoto文の是非：Hoare理論の観点から |journal=情報処理学会論文誌 |volume45 |issue= 3 |year=2004 |page=770-784 }}</ref><ref name="goto_finite_state_machines">{{cite journal|和書|naid=110002712260 |last=金藤|first=栄孝 |last2=二木|first2=厚吉 |title=有限状態機械に基づくプログラミングでのgoto文使用の是非 : Hoare論理の観点から |journal=情報処理学会論文誌 |volume= 45 |issue= 9, 2004 |pages=2124-2137}}</ref><ref name="box_structured">H.D.Mills, R.C.Linger, a.R.Hevner, “ボックス構造化情報システム”, ''ソフトウェアエンジニアリング論文集80's'', Tom DeMarco, Timothy Lister編著, 児玉公信 監訳, 翔泳社, 2006, pp.187-219. </ref>。むしろそれこそが「構造化プログラミング」（あるいは「goto有害論」）であると信じて書かれている文献も多い。
の二つの証明に分離して実行することができるというメリットがある<ref>これは、計算機の動作機構である電子回路の世界における、回路設計を行う際の[[テブナンの定理|鳳・テブナンの定理]]の役割とほとんど一緒である。</ref>。


岩波情報科学『算法表現論』<ref group="注釈">木村泉・米澤明憲共著だが、該当部の担当は木村による。</ref>p. 58 から言葉を借りるならばその実態は「プログラマー（職業としてではなく職種としての）に <code>if …</code> や <code>if … else …</code> や <code>while …</code> だけを使用させ，<code>goto</code> の使用を禁止すれば，ダメな連中でも少しはましなプログラムを書いてくるだろう」というもので、「広く影響を及ぼしたが，内容は Dijkstra（ダイクストラ）流とはほとんど無関係」である。
=== ホーアとダールのデータ構造化技法 ===
“Structured Programming”<ref name="structured_programming"/>や“Structured Programming with go to Statements”<ref name="structured_programming_with_go_to_statements"/>においては抽象データ構造の重要性も主張されている。加えて1972年、[[オルヨハン・ダール]]、ダイクストラ、[[アントニー・ホーア|ホーア]]による書籍“Structured Programming”<ref name="structured_programming_72">O.-J. Dahl and E. W. Dijkstra and C. A. R. Hoare, ''Structured Programming'', Academic Press, London, 1972</ref>においてはSimulaによるクラスを使ったプログラムの階層化の考え方も紹介されている。これらの考え方は後の本格的なオブジェクト指向へと発展する。例えばC++の開発者である[[ビャーネ・ストロヴストルップ]]はオブジェクト指向について解説した記事“What Is Object-Oriented Programming?”<ref name="what_is_object-oriented_programming">Bjarne Stroustrup, “What Is Object-Oriented Programming?”, In ''IEEE Software'', Vol. 5, Issue. 3, IEEE Computer Society Press, Los Alamitos, CA, USA, 1988, pp. 10-20</ref>において抽象データ構造の発展としてオブジェクト指向を解説し、そのための手段としてSimulaの機能を紹介している。


=== 「三つの構造化文」 ===
=== プログラムの正しさに関する様々な意見 ===
==== 事実 ====
構造化プログラミングの支持者らは、プログラムの正しさの重要性と証明の方法や表明(assertion)の使い方について熱心に説いた<ref name="the_science_of_programming"/><ref name="structured_programming_72"/><ref name="how_to_solve_it_by_computer">R.Geoff Dromey, ''How to Solve it by Computer'', Prentice Hall, 1982. </ref><ref name="the_craft_of_programming">[http://www.cs.cmu.edu/~jcr/craftprog.html John C. Reynolds, ''The Craft of Programming'', Prentice-Hall, 1981. ]</ref>。
まず、以下のことに関してダイクストラが主張した、というのは事実である。
ダイクストラは、プログラミングと同時にプログラムの証明を（わずかに証明を先行して）進めることを推奨している<ref name="a_discipline_of_programming">E.W.ダイクストラ, ''プログラミング原論 ― いかにしてプログラムをつくるか'', 浦昭治訳, サイエンス社, 1983. </ref>。そのようなアプローチでプログラムの正当性の問題にあたれば、複雑な問題であっても知的管理が可能であると述べた{{#tag:ref|ダイクストラはプログラミングと証明を並行するのに適した、最弱事前条件をによる検証方法を考案した。ホーア論理は作り終わったものは証明できるが、これから作るプログラムについては指標を与えてくれない<ref name="software_cleanroom">二木厚吉 監修, ''ソフトウェアクリーンルーム手法'', 日科技連, 1997. </ref>。|group="注釈"}}。


ダイクストラは“Go To Statement Considered Harmful”<ref name="go_to_statement_considered_harmful"/>および“Structured Programming”<ref name="structured_programming"/>において、好ましい構造として手続き呼び出しの他に、順次・反復・分岐の3つを挙げた。[[ニクラウス・ヴィルト|ヴィルト]]はこれらを構造化文(structured statement)と呼んだ <ref name="systematic_programming">N.ヴィルト, ''系統的プログラミング/入門'', 野下浩平, 筧捷彦, 武市正人 訳, 近代科学社, 1978. </ref>。goto文を避けて構造化文を用いるようプログラマーに教えることが、構造化プログラミングの伝統的な知恵である<ref name="sp_in_introductory_programming_courses">C.A.R.Hoare, "Structured programming in introductory programming courses", ''Structured Programming'', Infotech state of the art report, 1976, pp.257-263, Infotech International. </ref>。
また、プログラムの証明に対する反論も存在する。マイケル・ジャクソンは、個々のプログラムに証明を付けることは現実的には難しいだろうと述べている<ref name="bit1979_software_design">マイケル・ジャクソン, 吉村鉄太郎, 山崎利治, 大野徇郎, "ソフトウェア設計哲学", ''bit'', Vol.11, Issue 2, 1979, pp.4-12, 共立出版.</ref>{{#tag:ref|ジャクソンは構造化プログラミング手法の一つであるジャクソン法で有名なコンピュータ・コンサルタント。|group="注釈"}}。

;順次
:'''順接'''、'''順構造'''とも言われる。プログラムに記された順に、逐次処理を行なっていく。[[プログラム (コンピュータ)|プログラム]]の記述と[[コンピュータ]]の動作経過が一致するプログラム構造である。
;反復
:一定の条件が満たされている間処理を繰り返す。
;分岐
:ある条件が成立するなら処理Aを、そうでなければ処理Bを行なう。

また、“Structured Programming”<ref name="structured_programming"/>や“Structured Programming with go to Statements”<ref name="structured_programming_with_go_to_statements"/>においては抽象データ構造の重要性も主張されている。加えて1972年、[[オルヨハン・ダール]]、ダイクストラ、[[アントニー・ホーア|ホーア]]による書籍“Structured Programming”<ref name="structured_programming_72">O.-J. Dahl and E. W. Dijkstra and C. A. R. Hoare, ''Structured Programming'', Academic Press, London, 1972</ref>においてはSimulaによるクラスを使ったプログラムの階層化の考え方も紹介されている。これらの考え方は後の本格的なオブジェクト指向へと発展する。例えばC++の開発者である[[ビャーネ・ストロヴストルップ]]はオブジェクト指向について解説した記事“What Is Object-Oriented Programming?”<ref name="what_is_object-oriented_programming">Bjarne Stroustrup, “What Is Object-Oriented Programming?”, In ''IEEE Software'', Vol. 5, Issue. 3, IEEE Computer Society Press, Los Alamitos, CA, USA, 1988, pp. 10-20</ref>において抽象データ構造の発展としてオブジェクト指向を解説し、そのための手段としてSimulaの機能を紹介している。


== 誤解 ==
==== 構造化定理と誤解 ====
==== 構造化定理と誤解 ====
以上の事実について後年の多くの論者が、「構造化定理」（[[:en:Structured program theorem]]）と結びつけ、構造化定理の示す所では、gotoを使わなくてもこの3種類の制御構造を組み合わせることでプログラムは書ける、というのだから、goto文を排除してプログラムを書くことが構造化プログラミングである、と、その名前の類似（日本語でも英語でも）や、「goto有害説」という表現のインパクトから、ほとんどの場合は誤解されている、と言っていいほどに誤解されている。
以上の事実について後年の多くの論者が、「構造化定理」（[[:en:Structured program theorem]]）と結びつけ、構造化定理の示す所では、gotoを使わなくてもこの3種類の制御構造を組み合わせることでプログラムは書ける、というのだから、goto文を排除してプログラムを書くことが構造化プログラミングである、と、その名前の類似（日本語でも英語でも）や、「goto有害説」という表現のインパクトから、ほとんどの場合は誤解されている、と言っていいほどに誤解されている。
96行目: 64行目:
ダイクストラも“Go To Statement Considered Harmful”においては最後の段落で、goto文の(論理的な)余分さを証明したようだと軽く触れたのみであり、作られるフローチャートは元のものより正しさの証明が簡単になるとは思えないためジャンプを含まないフローチャートの機械的な作成は推奨しないとした。
ダイクストラも“Go To Statement Considered Harmful”においては最後の段落で、goto文の(論理的な)余分さを証明したようだと軽く触れたのみであり、作られるフローチャートは元のものより正しさの証明が簡単になるとは思えないためジャンプを含まないフローチャートの機械的な作成は推奨しないとした。


== 歴史的発展 ==
== 歴史 ==
[[コンピュータ]]が実用化され、その有用性が認められるようになるにつれ、その上で動作するプログラムは次第に大規模なものとなっていった。ソフトウェアの低品質、納期遅れ、予算超過が頻発し、大規模なプログラムを正当に動作するように記述することの困難さが認識されるようになった<ref name="the_science_of_programming">{{cite book |first=D.|last=グリース |authorlink=:en:David Gries|title=プログラミングの科学 |translator=筧捷彦 |publisher=培風館 |year=1991 |isbn=4563007943}}</ref><ref>例えば、コンピュータ・プログラムのデバッグという仕事の大変さについて1949年に感じた、ということを自伝に残している[[モーリス・ウィルクス|ウィルクス]]が、その後に、[[アラン・チューリング]]が「大規模ルーチンの検証」といったことを話していた、と書いている。
[[コンピュータ]]が実用化され、その有用性が認められるようになるにつれ、その上で動作するプログラムは次第に大規模なものとなっていった。ソフトウェアの低品質、納期遅れ、予算超過が頻発し、大規模なプログラムを正当に動作するように記述することの困難さが認識されるようになった<ref name="the_science_of_programming">{{cite book |first=D.|last=グリース |authorlink=:en:David Gries|title=プログラミングの科学 |translator=筧捷彦 |publisher=培風館 |year=1991 |isbn=4563007943}}</ref>{{#tag:ref|[[ソフトウェア危機]]の始まりと構造化プログラミングの歴史について<ref name="the_science_of_programming"/>の第23章に詳しい。|group="注釈"}}。遡れば、コンピュータ・プログラムのデバッグという仕事の大変さについて1949年に感じた、ということを自伝に残している[[モーリス・ウィルクス|ウィルクス]]が、その後に、[[アラン・チューリング]]が「大規模ルーチンの検証」といったことを話していた、と書いている。
</ref>{{#tag:ref|[[ソフトウェア危機]]の始まりと構造化プログラミングの歴史について<ref name="the_science_of_programming"/>の第23章に詳しい。|group="注釈"}}。


1960年代ではプログラムはフローチャートによる設計が広く採用されており、goto文も広く使われていた<ref name="structured_programming_with_go_to_statements">{{Cite journal|id={{citeseerx|10.1.1.103.6084}} |first=D. E. |last=Knuth|authorlink=ドナルド・クヌース |title=Structured Programming with go to Statements Computing Surveys |volume= 6 |number=4 |journal=ACM, New York, NY, USA |year=1974 |pages= 261-301}}</ref><ref name="program_design_chap6sec1">山崎利治, "流れ図", ''プログラムの設計'', 共立出版, 1990, pp.110-113. ISBN 4320023781</ref>。その一方で[[goto文]]の多用はプログラムの質を下げるという性質や、多くのプログラムはgotoを使わずに記述できるという性質が経験則として知られていた。例えば1959年の[[ハインツ・ツェマネク]]によるgoto文への疑問<ref name="go_to_statement_considered_harmful"/>。1960年から始まるD. V. Schorreによる[[インデント]]で制御の流れを表すアウトライン形式のプログラム記述、1963年のPeter Naurのgo to文に隠れたfor文の指摘、その翌年のGeorge Forsytheによるアルゴリズムからのgo to文除去、1965年のダイクストラや1966年のPeter Landinによるgo to文なしプログラミングの実験に関する発表が挙げられる<ref name="structured_programming_with_go_to_statements"/>。
1947年、[[:en:Herman_Goldstine|Herman Goldstine]]と[[フォン・ノイマン]]が、米国陸軍兵站局からの委託研究報告書「電子計算装置の計画とコード化問題」<ref name=planningcoding />において、プログラムの設計のためのフローチャートを初めて導入する。


1966年、[[コラド・ベーム]]と[[ジュゼッペ・ヤコピーニ]]が、任意のフロー図式（flow diagram）は基本図式（base diagram）の組み合わせによる等価なフローチャートに変換できるという定理を示した<ref name="flow_diagrams_turing_machines_and_languages_with_only_two_formation_rules">{{Cite journal|id={{citeseerx|10.1.1.119.9119}} |first=C. |last=Böhm |first2=G |last2=Jacopini |title=Flow Diagrams, Turing Machines And Languages With Only Two Formation Rules |journal=Communications of the ACM |volume= 9 |issue=5 |journL=ACM, New York, NY, USA |year=1966 |pages=366-371}}</ref>。この定理は後年1979年に、IBMのMillsらによって構造化定理(Structure Theorem)として再定義された<ref name="sp_theory_and_practice">{{cite book | author=Linger,R.C., Mills, H.D., Witt, B.I. | title=Structured Programming: Theory and Practice | publisher=Addison-Wesly | year=1979 }}</ref>。
そして1966年[[コラド・ベーム]]と[[ジュゼッペ・ヤコピーニ]]によって、任意のフローチャートは基本フローチャートの組み合わせによる等価なフローチャートに変換できるという定理が示された<ref name="flow_diagrams_turing_machines_and_languages_with_only_two_formation_rules">{{Cite journal|id={{citeseerx|10.1.1.119.9119}} |first=C. |last=Böhm |first2=G |last2=Jacopini |title=Flow Diagrams, Turing Machines And Languages With Only Two Formation Rules |journal=Communications of the ACM |volume= 9 |issue=5 |journL=ACM, New York, NY, USA |year=1966 |pages=366-371}}</ref>。この定理は後に、IBMのMillsらによって構造化定理(Structure Theorem)として再定義された<ref name="sp_theory_and_practice">Linger,R.C., Mills, H.D., Witt, B.I., ''Structured Programming: Theory and Practice'', Addison-Wesly, 1979. </ref>{{要検証|date=2013年1月|title=ベームらの論文(1966)では構造化定理とは呼ばれていない。Millsら(1979)の著書がこの用語の初出であるという別な証拠か、より古い事例が存在するかの調査が必要。}}。なお前述のように、これを構造化プログラミングと結びつける論者は大変多いが誤解である。


1968年、ダイクストラが『Go to 文有害説』<ref name="go_to_statement_considered_harmful">{{Cite journal|id={{citeseerx|10.1.1.132.875}} |author=E. Dijkstra |authorlink=エドガー・ダイクストラ |title=Go To Statement Considered Harmful |journal=Communications of the ACM |volume=11 |issue= 3 |year=1968 |pages= 147-148 }},{{cite |author=E.W.ダイクストラ |authorlink=エドガー・ダイクストラ |title=GO TO 論争：第1部 go to 文有害説 |translator=木村泉 |journak=bit|volume=7 |issue= 5 |year=1975 |pages=6-9 |publisher=共立出版 }}</ref>という記事を発表する。この記事の発表を契機に、goto文を巡って論争が巻き起こる<ref name="bit1975_goto_controversy">{{cite |editor=B.リーヴェンワス編 |title=GO TO 論争：第2部 GO TO 論争 |translator=木村泉 訳 |journal=bit |volume=7 |issue=5 |year=1975 |pages=10-26 |publisher=共立出版 }}, {{citation | author=木村泉 | title=GO TO 論争：第3部 解説 | journal=bit | volume=7 | issue=5 | year=1975 | pages=27-39 | publisher=共立出版}}
1968年にダイクストラは“Go To Statement Considered Harmful”<ref name="go_to_statement_considered_harmful">{{Cite journal|id={{citeseerx|10.1.1.132.875}} |author=E. Dijkstra |authorlink=エドガー・ダイクストラ |title=Go To Statement Considered Harmful |journal=Communications of the ACM |volume=11 |issue= 3 |year=1968 |pages= 147-148 }}</ref><ref name="bit1975_go_to_statement_considered_harmful">{{cite |author=E.W.ダイクストラ |authorlink=エドガー・ダイクストラ |title=GO TO 論争：第1部 go to 文有害説 |translator=木村泉 |journak=bit|volume=7 |issue= 5 |year=1975 |pages=6-9 |publisher=共立出版 }}</ref>という記事を発表し、大きな反響を呼んだ<ref name="bit1975_goto_controversy">{{cite |editor=B.リーヴェンワス編 |title=GO TO 論争：第2部 GO TO 論争 |translator=木村泉 訳 |journal=bit |volume=7 |issue=5 |year=1975 |pages=10-26 |publisher=共立出版 }}</ref><ref name="bit1975_explanation">木村泉, "GO TO 論争：第3部 解説", ''bit'', Vol.7, Issue 5, 1975, pp.27-39, 共立出版.</ref>。<!--この記事が構造化プログラミングの提唱であるとする場合も多い{{誰2|date=2012年4月2|title=具体的な例や出典を示したい}}。-->この騒ぎがきっかけで構造化プログラミングを知った者が多いことを示して、クヌースは「go to文を用いた構造化プログラミング」の中で「go to 文除去の話の二番目の場面は，多くの人たちが第一幕だと思っている事実である．」とこの騒動を指して評している。1980年代にマイコンが普及した際に、その[[BASIC]]において（由来などの詳細は全く曖昧なまま）「GOTO命令を使わないのが『構造化プログラミング』」などと言われたりしたなど、騒動の影響は後年まで残った。<ref group="注釈">直接は無関係だが、ダイクストラはBASIC批判の急先鋒でもあった。マイコン普及以前の1970年代に既に、BASICでプログラミング教育をすべきでない、と強く主張している（[[wikiquote:Edsger W. Dijkstra#How do we tell truths that might hurt? (1975)]]）。</ref>
</ref><ref>この騒ぎがきっかけで構造化プログラミングを知った者が多いことを示して、クヌースは「go to文を用いた構造化プログラミング」の中で「go to 文除去の話の二番目の場面は，多くの人たちが第一幕だと思っている事実である．」とこの騒動を指して評している。<br />また、1980年代にマイコンが普及した際に、その[[BASIC]]において（由来などの詳細は全く曖昧なまま）「GOTO命令を使わないのが『構造化プログラミング』」などと言われたりしたなど、騒動の影響は後年まで残った。なお、ダイクストラはBASIC批判の急先鋒でもあった。マイコン普及以前の1970年代に既に、BASICでプログラミング教育をすべきでない、と強く主張していた（[[wikiquote:Edsger W. Dijkstra#How do we tell truths that might hurt? (1975)]]）。</ref>{{#tag:ref|1960年代ではプログラムはフローチャートによる設計が広く採用されており、goto文も広く使われていた<ref name="structured_programming_with_go_to_statements">{{Cite journal|id={{citeseerx|10.1.1.103.6084}} |first=D. E. |last=Knuth|authorlink=ドナルド・クヌース |title=Structured Programming with go to Statements Computing Surveys |volume= 6 |number=4 |journal=ACM, New York, NY, USA |year=1974 |pages= 261-301}}</ref><ref name="program_design_chap6sec1">山崎利治, "流れ図", ''プログラムの設計'', 共立出版, 1990, pp.110-113. ISBN 4320023781</ref>。その一方で[[goto文]]の多用はプログラムの質を下げるという性質や、多くのプログラムはgotoを使わずに記述できるという性質が経験則として知られていた。例えば1959年の[[ハインツ・ツェマネク]]によるgoto文への疑問<ref name="go_to_statement_considered_harmful"/>。1960年から始まるD. V. Schorreによる[[インデント]]で制御の流れを表すアウトライン形式のプログラム記述、1963年のPeter Naurのgo to文に隠れたfor文の指摘、その翌年のGeorge Forsytheによるアルゴリズムからのgo to文除去、1965年のダイクストラや1966年のPeter Landinによるgo to文なしプログラミングの実験に関する発表が挙げられる<ref name="structured_programming_with_go_to_statements"/>}}。


1968年10月、ドイツの[[ガルミッシュ]]で開催されたNATOの科学委員会後援の「ソフトウェア工学」に関する会議<ref name="software_engineering_conferences1968">[http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF B. Randell and J.N. Buxton, (Eds.), ''Software Engineering'', NATO Scientific Affairs Division, Brussels, Belgium, 1969.]</ref>において、1960年代中頃から問題となっていた[[ソフトウェア危機]]（software crisis）の存在が公に認められる<ref name="from_craft_to_scientific_discipline"/>。
1968年、NATO主催のソフトウェア工学会議<ref name="software_engineering_conferences1968">[http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF B. Randell and J.N. Buxton, (Eds.), ''Software Engineering'', NATO Scientific Affairs Division, Brussels, Belgium, 1969.]</ref>で[[ソフトウェア危機]]が共通認識となったとき、ダイクストラは時が来たと考えた<ref name="from_craft_to_scientific_discipline"/>。当時、ダイクストラを含むソフトウェア危機の存在に気づいていた人々は、プログラミング活動に対する変化の到来を予測していた。しかしこの転換期が訪れるまで、世間一般はそれを受け入れる準備ができていなかった<ref name="from_craft_to_scientific_discipline"/>。


1969年、再び開催されたNATOのソフトウェア工学会議において、ダイクストラは「'''構造化プログラミング'''(Structured Programming)」という語を提唱した<ref name="structured_programming">[http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1969.PDF E. W. Dijkstra, “Structured Programming”, In ''Software Engineering Techniques'', B. Randell and J.N. Buxton, (Eds.), NATO Scientific Affairs Division, Brussels, Belgium, 1970, pp. 84–88.]</ref>{{#tag:ref|このカンファレンスの発表が「構造化プログラミング」という語の元であるという主張の出典は<ref name="structured_programming_with_go_to_statements"/>|group="注釈"}}。ダイクストラはこの提唱において goto 文に一言触れただけで{{#tag:ref|"statements transferring control to labelled points" という言葉で一応 goto 文に触れている<ref name="structured_programming" />|group="注釈"}}、プログラムサイズが大きくなったとしても正しさを証明できる良く構造化されたプログラム(well-structured programs)、大きなプログラムの理解を助ける段階的な抽象化(step-wise abstraction)、抽象データとその操作の抽象文の共同詳細化(joint refinement)について述べた。
翌1969年、再び開催されたNATOのソフトウェア工学会議において、ダイクストラは「'''構造化プログラミング'''(Structured Programming)」という語を提唱した<ref name="structured_programming">[http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1969.PDF E. W. Dijkstra, “Structured Programming”, In ''Software Engineering Techniques'', B. Randell and J.N. Buxton, (Eds.), NATO Scientific Affairs Division, Brussels, Belgium, 1970, pp. 84–88.]</ref>{{#tag:ref|このカンファレンスの発表が「構造化プログラミング」という語の元であるという主張の出典は<ref name="structured_programming_with_go_to_statements"/>|group="注釈"}}。ダイクストラはこの提唱において goto 文に一言触れただけで{{#tag:ref|"statements transferring control to labelled points" という言葉で一応 goto 文に触れている<ref name="structured_programming" />|group="注釈"}}、プログラムサイズが大きくなったとしても正しさを証明できる良く構造化されたプログラム(well-structured programs)、大きなプログラムの理解を助ける段階的な抽象化(step-wise abstraction)、抽象データとその操作の抽象文の共同詳細化(joint refinement)について述べた。


ダイクストラは、構造化プログラミングという言葉を作ったとき2つの失敗をしたと述べた。商標登録しなかったことと定義しなかったことである<ref name="also_speech_dijkstra">和田英一, "ダイクストラかく語りき", ''bit'', Vol.9, Issue 1, 1977, pp.4-6, 共立出版. </ref><ref name="from_craft_to_scientific_discipline">{{cite |naid=110002753409 |authir=E.W.ダイクストラ |title=プログラミング−工芸から科学へ |journal=情報処理 |volume=18 |number=12 |year=1977 |page=1248-1256 |publisher=情報処理学会 }}</ref>。そのため、構造化プログラミングは標語（スローガン）となってしまい、IBMのプログラミング規範をまとめたIPT(Improved Programming Technologies)によって当時のプログラマに広く流布した<ref name="program_design_chap6sec2">山崎利治, "構造的プログラミング", ''プログラムの設計'', 共立出版, 1990, pp.113-142. </ref><ref name="tamai_40years_se" />。構造化プログラミングはIBMによって発明されたと信じる者も数多く存在した<ref name="classics_in_software_engineering">Edward Nash Yourdon ed., "Introduction (Chief Programmer Team Management of Production Programming)", ''Classics in Software Engineering'', YOURDON inc., 1979, pp.63-64. </ref>。しかしIBMの構造化プログラミングは、ダイクストラのそれとは異なるものであった<ref name="algorithm_representation_theory">木村泉, 米澤明憲, ''算法表現論'', 岩波書店, 1982. </ref><ref name="problems_of_programming_methodology">{{cite journal|naid=110002720277 |author=木村泉 |title=プログラミング方法論の問題点：超職業的プログラミングについて |journal=情報処理 |volume=16 |number=10 |year=1975 |pages=841-847 |publisher=情報処理学会 }}</ref>。産業界や米国ではダイクストラの原則はむしろ不人気でさえあった<ref name="out_of_thier_minds">D.シャシャ, C.ラゼール, "エズガー・W・ダイクストラ", ''コンピュータの時代を開いた天才たち'', 鈴木良尚 訳, 竹内郁雄 監訳, 日経BP社, 1998, pp.61-74. ISBN 4822280462</ref>。
ダイクストラは、構造化プログラミングという言葉を作ったとき2つの失敗をしたと述べた。商標登録しなかったことと定義しなかったことである<ref name="also_speech_dijkstra">和田英一, "ダイクストラかく語りき", ''bit'', Vol.9, Issue 1, 1977, pp.4-6, 共立出版. </ref><ref name="from_craft_to_scientific_discipline">{{cite |naid=110002753409 |authir=E.W.ダイクストラ |title=プログラミング−工芸から科学へ |journal=情報処理 |volume=18 |number=12 |year=1977 |page=1248-1256 |publisher=情報処理学会 }}</ref>。そのため、構造化プログラミングは標語（スローガン）となってしまい、IBMのプログラミング規範をまとめたIPT(Improved Programming Technologies)によって当時のプログラマに広く流布した<ref name="program_design_chap6sec2">山崎利治, "構造的プログラミング", ''プログラムの設計'', 共立出版, 1990, pp.113-142. </ref><ref name="tamai_40years_se" />。構造化プログラミングはIBMによって発明されたと信じる者も数多く存在した<ref name="classics_in_software_engineering">Edward Nash Yourdon ed., "Introduction (Chief Programmer Team Management of Production Programming)", ''Classics in Software Engineering'', YOURDON inc., 1979, pp.63-64. </ref>。しかしIBMの構造化プログラミングは、ダイクストラのそれとは異なるものであった<ref name="algorithm_representation_theory">木村泉, 米澤明憲, ''算法表現論'', 岩波書店, 1982. </ref><ref name="problems_of_programming_methodology">{{cite journal|naid=110002720277 |author=木村泉 |title=プログラミング方法論の問題点：超職業的プログラミングについて |journal=情報処理 |volume=16 |number=10 |year=1975 |pages=841-847 |publisher=情報処理学会 }}</ref>。産業界や米国ではダイクストラの原則はむしろ不人気でさえあった<ref name="out_of_thier_minds">D.シャシャ, C.ラゼール, "エズガー・W・ダイクストラ", ''コンピュータの時代を開いた天才たち'', 鈴木良尚 訳, 竹内郁雄 監訳, 日経BP社, 1998, pp.61-74. ISBN 4822280462</ref>。
124行目: 90行目:


== 参考文献 ==
== 参考文献 ==
* {{Citation |和書| title=構造化プログラミング | author=E.W.ダイクストラ | author2=C.A.R.ホーア | author3=O.-J.ダール | translator=野下浩平 | year=1975 | publisher=サイエンス社 | ref=構造化プログラミング(1972) }}
* {{Citation |和書| title=構造化プログラミング | author=E.W.ダイクストラ | author2=C.A.R.ホーア | author3=O.-J.ダール | translator=野下浩平 | year=1975 | publisher=サイエンス社 | ref=構造化プログラミング(1975) }}
* {{cite book |和書| title=ソフトウェア工学入門 | author=河村 一樹 | publisher=近代科学社 | year=1995 | ref=河村(1995) }}<small>（改訂版は内容が異なる）</small>
* {{Cite book |和書| title=ソフトウェア工学実践の基礎 －分析・設計・プログラミング | author=落水 浩一郎}}
* {{Cite book |和書| title=ソフトウェア工学実践の基礎 －分析・設計・プログラミング | author=落水 浩一郎}}
* {{citation | author=D.L.Parnas | year=1975 | title=Use of the concept of transparency in the design of hierarchically structured systems | url=http://ivizlab.sfu.ca/arya/Papers/SW/TranspDesignHierSys.pdf }}
* {{citation | author=D.L.Parnas | year=1975 | title=Use of the concept of transparency in the design of hierarchically structured systems | url=http://ivizlab.sfu.ca/arya/Papers/SW/TranspDesignHierSys.pdf }}
* {{citation | author=D.L.Parnas | year=1971 | title=Information Distribution Aspects of Design Methodology | url=http://cseweb.ucsd.edu/~wgg/CSE218/Parnas-IFIP71-information-distribution.PDF }}
* {{citation | author=D.L.Parnas | year=1971 | title=Information Distribution Aspects of Design Methodology | url=http://cseweb.ucsd.edu/~wgg/CSE218/Parnas-IFIP71-information-distribution.PDF }}
* {{citation | author=B.H.Liskov, S.N.Zilles | year=1974 | title=Programming with Abstract Data Type | url=http://www.znu.ac.ir/members/afsharchim/lectures/p50-liskov.pdf }}
* {{citation | author=B.H.Liskov, S.N.Zilles | year=1974 | title=Programming with Abstract Data Type | url=http://www.znu.ac.ir/members/afsharchim/lectures/p50-liskov.pdf }}
* {{Citation |title=多重ループからの脱出でのgoto文の是非 : Hoare理論の観点から | author=金藤 栄孝,二木 厚吉 | year=2004 | url=http://ci.nii.ac.jp/naid/110002712129}}
* {{Citation |title=有限状態機械に基づくプログラミングでのgoto文使用の是非 : Hoare論理の観点から | author=金藤 栄孝,二木 厚吉 | year=2004 |url=http://ci.nii.ac.jp/naid/110002712260}}
* {{Citation |title=システム設計言語DEAPLANについて | author=林 達也 | url=http://ci.nii.ac.jp/naid/110002719409}}
* {{Citation |和書| title=プログラミングの科学 | author=D.グリース | translator=筧捷彦 | year=1991 | publisher=培風館}}
* {{Citation |和書| chapter=第2章 go to文を用いた構造化プログラミング | title=文芸的プログラミング | author=Donald E. Knuth | translator=有澤誠 | year=1994 | publisher=アスキー}}
* {{Citation |和書| chapter=第2章 go to文を用いた構造化プログラミング | title=文芸的プログラミング | author=Donald E. Knuth | translator=有澤誠 | year=1994 | publisher=アスキー}}
* {{Citation |和書| title=プログラミング原論 ― いかにしてプログラムをつくるか | author=E.W.ダイクストラ | translator=浦昭治 | year=1983 | publisher=サイエンス社}}
* {{Citation |和書| title=プログラミングの方法 | author=E.W.ダイクストラ | author2=W.H.J.フェイエン | translator=玉井浩 | year=1991 | publisher=サイエンス社}}
== 関連項目 ==
== 関連項目 ==
* [[Simula]]
* [[Simula]]
141行目: 112行目:
* [[アントニー・ホーア]]
* [[アントニー・ホーア]]
* [[オーレ＝ヨハン・ダール]]
* [[オーレ＝ヨハン・ダール]]
* [[ペール・マルティン＝レーフ]]
* [[マイケル・アンソニー・ジャクソン]]


{{プログラミング言語の関連項目}}
{{プログラミング言語の関連項目}}

2018年8月26日 (日) 13:03時点における版

曖昧さ回避 この項目では、ダイクストラらによるソフトウェア工学的手法としての「構造化プログラミング」について説明しています。goto文論争については「goto文」をご覧ください。

構造化プログラミング（こうぞうかプログラミング、英: structured programming）は、1960年代後半にエドガー・ダイクストラらによって提唱された、構造化されたプログラムの構成要素（制御構造）の利用や、段階的詳細化などを特徴とするプログラミング手法である。

段階的詳細化

段階的詳細化では、プログラミングの最初の段階では、いきなりプログラミング言語の言語機能を直接使ってプログラムを記述するのではなく、機能を抽象化した「仮想機械」を想定し、その「仮想機械が提供する命令群」でプログラムを構成する、というような手順からプログラミングを始める。普通、抽象化は1段階ではなく階層的である。各階層での実装の詳細は他の階層と隔離されており、実装の変更の影響はその階層内のみに留まる([1] Abstract data structures)。各階層はアプリケーションに近い抽象的な方から土台に向かって順序付けられている。この順序は各階層を設計した時間的な順番とは必ずしも一致しない([1] Concluding remarks)。

ダイクストラによるプログラムの正しさの検証手法

コンピュータは与えたプログラムに応じてそれを計算し結果を出力するという装置であるが、プログラムに誤りがあると、当初の意図した命題（仕様）を肯定しないものとなる[注釈 1]。

プログラマは、正しいプログラムを作り出すばかりでなく、納得のいくやり方で正しさを証明することも仕事の一つであるという立場を取っていた[2]ダイクストラは、プログラムの正しさの納得のいく証明を遂行するための手法を導入した[3]。ただし、その検証[4]を実行するためには対象となるプログラムは「うまく構造化」されていなくてはならず、その「うまく構造化」されたプログラムを開発する手法が構造化プログラミングである[注釈 2][5]。

ダイクストラの三つの知性の道具
  1. 数え上げ推論（enumeration）：一人の人間の能力でできる範囲でプログラムの命令の妥当性を一つ一つ確認していく作業
  2. 数学的帰納法（mathematical induction）：while文など計算機特有の多数の繰り返し文についてのみ数学的帰納法を用いて確認する作業
  3. 抽象（abstraction）：プログラムのブロックなどに名前をつけ、さらに中身を見ないで正しいと仮定することで検証作業を後回しにする操作

プログラムの正しさに関する様々な意見

構造化プログラミングの支持者らは、プログラムの正しさの重要性と証明の方法や表明(assertion)の使い方について熱心に説いた[6][7][8][9]。 ダイクストラは、プログラミングと同時にプログラムの証明を（わずかに証明を先行して）進めることを推奨している[10]。そのようなアプローチでプログラムの正当性の問題にあたれば、複雑な問題であっても知的管理が可能であると述べた[注釈 3]。

また、プログラムの証明に対する反論も存在する。マイケル・ジャクソンは、個々のプログラムに証明を付けることは現実的には難しいだろうと述べている[12][注釈 4]。

構造化プログラミングの構成要素

goto-lessプログラミングやtop-downプログラミングは構造化プログラミングと同一視されることが多い[13]。これらは規律あるプログラミングを実現するためのものと考えられている[14]。が、誤解（後述）も多い。その他にプログラムの検証、情報隠蔽、抽象データ型も構造化プログラミングの主要な概念として取り上げられることがある[15]。

誤解

Millsによるgoto-lessプログラミング

歴史的経緯から、構造化プログラミングはIBMのハーラン・ミルズ（Harlan Mills）の提案に由来するgoto-lessプログラミングとして一部分を切り取られた形で広く知られている[16][17][18]。むしろそれこそが「構造化プログラミング」（あるいは「goto有害論」）であると信じて書かれている文献も多い。

岩波情報科学『算法表現論』[注釈 5]p. 58 から言葉を借りるならばその実態は「プログラマー（職業としてではなく職種としての）に if … や if … else … や while … だけを使用させ，goto の使用を禁止すれば，ダメな連中でも少しはましなプログラムを書いてくるだろう」というもので、「広く影響を及ぼしたが，内容は Dijkstra（ダイクストラ）流とはほとんど無関係」である。

「三つの構造化文」

事実

まず、以下のことに関してダイクストラが主張した、というのは事実である。

ダイクストラは“Go To Statement Considered Harmful”[19]および“Structured Programming”[1]において、好ましい構造として手続き呼び出しの他に、順次・反復・分岐の3つを挙げた。ヴィルトはこれらを構造化文(structured statement)と呼んだ [20]。goto文を避けて構造化文を用いるようプログラマーに教えることが、構造化プログラミングの伝統的な知恵である[21]。

順次
順接、順構造とも言われる。プログラムに記された順に、逐次処理を行なっていく。プログラムの記述とコンピュータの動作経過が一致するプログラム構造である。
反復
一定の条件が満たされている間処理を繰り返す。
分岐
ある条件が成立するなら処理Aを、そうでなければ処理Bを行なう。

また、“Structured Programming”[1]や“Structured Programming with go to Statements”[22]においては抽象データ構造の重要性も主張されている。加えて1972年、オルヨハン・ダール、ダイクストラ、ホーアによる書籍“Structured Programming”[7]においてはSimulaによるクラスを使ったプログラムの階層化の考え方も紹介されている。これらの考え方は後の本格的なオブジェクト指向へと発展する。例えばC++の開発者であるビャーネ・ストロヴストルップはオブジェクト指向について解説した記事“What Is Object-Oriented Programming?”[23]において抽象データ構造の発展としてオブジェクト指向を解説し、そのための手段としてSimulaの機能を紹介している。

構造化定理と誤解

以上の事実について後年の多くの論者が、「構造化定理」（en:Structured program theorem）と結びつけ、構造化定理の示す所では、gotoを使わなくてもこの3種類の制御構造を組み合わせることでプログラムは書ける、というのだから、goto文を排除してプログラムを書くことが構造化プログラミングである、と、その名前の類似（日本語でも英語でも）や、「goto有害説」という表現のインパクトから、ほとんどの場合は誤解されている、と言っていいほどに誤解されている。

実際のところは、構造化定理はフローチャートやそれによって表現されるプログラム・関数・チューリングマシンなどの理論的側面に注目している。これは任意の論理回路がNAND素子の組み合わせによって表現できるとか、λ式がSおよびKという名の2つのコンビネータによって表現できるとかいった研究に近い。回路設計者が直接NANDを組み合わせて電子回路を設計しないのと同じように、構造化定理は良いプログラムの作成を(少なくとも直接的には)意図していない。

クヌースは文献[22]において、良い構造が重要なのであり、良い構造はFORTRAN, COBOL, アセンブリ言語でも記述できるとした。一方で、（構造化定理により）機械的にgotoを除去する変換を掛けたプログラムとは実際にどんなものになるのか、変換法の一例を示し、1つのループがプログラム全体の振る舞いを含んでしまうため、抽象化レベルという点では無意味であるとした[22]。クヌースがそこで実際に示した、「機械的にgotoを除去」したコードと同様のものが en:Structured program theorem#Single-while-loop, folk version of the theorem に示されているが、見ればわかるようにgotoを使っていないというだけで、手続きのわかりやすい表現には全くなっていない。曰く「これですべての goto 文を除去できたわけであるが，実際にはすべての構造を失ってしまっている．」というわけである。

ダイクストラも“Go To Statement Considered Harmful”においては最後の段落で、goto文の(論理的な)余分さを証明したようだと軽く触れたのみであり、作られるフローチャートは元のものより正しさの証明が簡単になるとは思えないためジャンプを含まないフローチャートの機械的な作成は推奨しないとした。

歴史

コンピュータが実用化され、その有用性が認められるようになるにつれ、その上で動作するプログラムは次第に大規模なものとなっていった。ソフトウェアの低品質、納期遅れ、予算超過が頻発し、大規模なプログラムを正当に動作するように記述することの困難さが認識されるようになった[6][注釈 6]。遡れば、コンピュータ・プログラムのデバッグという仕事の大変さについて1949年に感じた、ということを自伝に残しているウィルクスが、その後に、アラン・チューリングが「大規模ルーチンの検証」といったことを話していた、と書いている。

1960年代ではプログラムはフローチャートによる設計が広く採用されており、goto文も広く使われていた[22][24]。その一方でgoto文の多用はプログラムの質を下げるという性質や、多くのプログラムはgotoを使わずに記述できるという性質が経験則として知られていた。例えば1959年のハインツ・ツェマネクによるgoto文への疑問[19]。1960年から始まるD. V. Schorreによるインデントで制御の流れを表すアウトライン形式のプログラム記述、1963年のPeter Naurのgo to文に隠れたfor文の指摘、その翌年のGeorge Forsytheによるアルゴリズムからのgo to文除去、1965年のダイクストラや1966年のPeter Landinによるgo to文なしプログラミングの実験に関する発表が挙げられる[22]。

そして1966年コラド・ベームとジュゼッペ・ヤコピーニによって、任意のフローチャートは基本フローチャートの組み合わせによる等価なフローチャートに変換できるという定理が示された[25]。この定理は後に、IBMのMillsらによって構造化定理(Structure Theorem)として再定義された[26][要検証 – ノート]。なお前述のように、これを構造化プログラミングと結びつける論者は大変多いが誤解である。

1968年にダイクストラは“Go To Statement Considered Harmful”[19][27]という記事を発表し、大きな反響を呼んだ[28][29]。この騒ぎがきっかけで構造化プログラミングを知った者が多いことを示して、クヌースは「go to文を用いた構造化プログラミング」の中で「go to 文除去の話の二番目の場面は，多くの人たちが第一幕だと思っている事実である．」とこの騒動を指して評している。1980年代にマイコンが普及した際に、そのBASICにおいて（由来などの詳細は全く曖昧なまま）「GOTO命令を使わないのが『構造化プログラミング』」などと言われたりしたなど、騒動の影響は後年まで残った。[注釈 7]

1968年、NATO主催のソフトウェア工学会議[30]でソフトウェア危機が共通認識となったとき、ダイクストラは時が来たと考えた[31]。当時、ダイクストラを含むソフトウェア危機の存在に気づいていた人々は、プログラミング活動に対する変化の到来を予測していた。しかしこの転換期が訪れるまで、世間一般はそれを受け入れる準備ができていなかった[31]。

翌1969年、再び開催されたNATOのソフトウェア工学会議において、ダイクストラは「構造化プログラミング(Structured Programming)」という語を提唱した[1][注釈 8]。ダイクストラはこの提唱において goto 文に一言触れただけで[注釈 9]、プログラムサイズが大きくなったとしても正しさを証明できる良く構造化されたプログラム(well-structured programs)、大きなプログラムの理解を助ける段階的な抽象化(step-wise abstraction)、抽象データとその操作の抽象文の共同詳細化(joint refinement)について述べた。

ダイクストラは、構造化プログラミングという言葉を作ったとき2つの失敗をしたと述べた。商標登録しなかったことと定義しなかったことである[32][31]。そのため、構造化プログラミングは標語（スローガン）となってしまい、IBMのプログラミング規範をまとめたIPT(Improved Programming Technologies)によって当時のプログラマに広く流布した[15][33]。構造化プログラミングはIBMによって発明されたと信じる者も数多く存在した[34]。しかしIBMの構造化プログラミングは、ダイクストラのそれとは異なるものであった[35][14]。産業界や米国ではダイクストラの原則はむしろ不人気でさえあった[36]。

1980年代以降、ソフトウェア工学の分野はプログラミング言語や方法論から組織やプロジェクトの管理手法へと軸足を移していた[33]。1987年の第9回ソフトウェア工学国際会議(ICSE)において、Millsは会場にチューリング賞受賞者がいないことを確かめると「ダイクストラやホーア達はどこへ行ってしまったのか。我々はもう彼らから学ぶものがないのか。」とその現状を批判した[37][38]（しかし木村泉の見解が当たっていたとするならば、「ソフトウェア工学」をそういったものにしていった張本人こそが、その発言をしたMillsであるということになる）。

後年、ダイクストラは自身が作った構造化プログラミングという言葉に不快感を示し、避けるようになった[39]。この言葉を名付けたとき、かれはプログラミングが手工芸から科学へ発展することを予測していた[32]。しかし構造化プログラミングという言葉は実利を求めるために使われるようになった[39]。次のような逸話がある。ヨードンの会社に依頼の電話がかかってきた。部下全員に構造化プログラミングなどの構造化技法を1日で叩きこんで欲しいという内容である。それが終わったら開発期間を半分にするという。なぜなら「構造化技法は生産性を2倍にしますから」というものであった[40]。かくして構造化プログラミングは、ダイクストラの期待とは異なった形で世に広まっていくことになる。

脚注

注釈

  1. ^ たとえば、一律に個々の構成要素が正しい確率を p とすると、N 個の構成要素からなるプログラム全体が正しい確率 P は、安直に計算すれば、
    P = pN
    となり、 N が大きいプログラム（大規模なソフトウェア）においては、誤りの混入により命題（仕様）を肯定しない可能性は飛躍的に高まることがわかる。
  2. ^ すなわち、プログラム検証と構造化プログラミングとは不可分の関係にある。
  3. ^ ダイクストラはプログラミングと証明を並行するのに適した、最弱事前条件をによる検証方法を考案した。ホーア論理は作り終わったものは証明できるが、これから作るプログラムについては指標を与えてくれない[11]。
  4. ^ ジャクソンは構造化プログラミング手法の一つであるジャクソン法で有名なコンピュータ・コンサルタント。
  5. ^ 木村泉・米澤明憲共著だが、該当部の担当は木村による。
  6. ^ ソフトウェア危機の始まりと構造化プログラミングの歴史について[6]の第23章に詳しい。
  7. ^ 直接は無関係だが、ダイクストラはBASIC批判の急先鋒でもあった。マイコン普及以前の1970年代に既に、BASICでプログラミング教育をすべきでない、と強く主張している（wikiquote:Edsger W. Dijkstra#How do we tell truths that might hurt? (1975)）。
  8. ^ このカンファレンスの発表が「構造化プログラミング」という語の元であるという主張の出典は[22]
  9. ^ "statements transferring control to labelled points" という言葉で一応 goto 文に触れている[1]

出典

  1. ^ a b c d e f E. W. Dijkstra, “Structured Programming”, In Software Engineering Techniques, B. Randell and J.N. Buxton, (Eds.), NATO Scientific Affairs Division, Brussels, Belgium, 1970, pp. 84–88.
  2. ^ 構造化プログラミング(1975) p.6
  3. ^ これは計算機や大規模プログラムを一種のブラックボックス化された機械装置とみなしてテストによって正しさを確認する手法ではない。ダイクストラは、テストはプログラムに対する疑いを全て取り除くには不十分であることを主張していた。構造化プログラミング(1975) p.5
    これについてダイクストラは「テストはバグの存在を示すには有効だが、バグが存在しないことは証明できない」という表現を好んで用いた。
  4. ^ D.グリースはプログラムの正しさの証明を、抽象的なレベルでは正当性証明、具体的なレベルではプログラムの検証と言葉を使い分けているが、ここでは厳密な区別はしない。
    • 金山裕 編, "構造的プログラミング −批判と支持−", bit, Vol.7, Issue 7, 1975, pp.6-13, 共立出版.
  5. ^ 所与のプログラムの正しさを後付けで証明することは、はじめから証明を意識して作られたプログラムの場合より難しいことが経験的に知られている、と言われる。
    • E.W.Dijkstra, "Programming methodologies, their objectives and their nature", Structured Programming, Infotech state of the art report, 1976, pp.205-212, Infotech International.
  6. ^ a b c グリース, D. 筧捷彦訳 (1991). プログラミングの科学. 培風館. ISBN 4563007943 
  7. ^ a b O.-J. Dahl and E. W. Dijkstra and C. A. R. Hoare, Structured Programming, Academic Press, London, 1972
  8. ^ R.Geoff Dromey, How to Solve it by Computer, Prentice Hall, 1982.
  9. ^ John C. Reynolds, The Craft of Programming, Prentice-Hall, 1981.
  10. ^ E.W.ダイクストラ, プログラミング原論 ― いかにしてプログラムをつくるか, 浦昭治訳, サイエンス社, 1983.
  11. ^ 二木厚吉 監修, ソフトウェアクリーンルーム手法, 日科技連, 1997.
  12. ^ マイケル・ジャクソン, 吉村鉄太郎, 山崎利治, 大野徇郎, "ソフトウェア設計哲学", bit, Vol.11, Issue 2, 1979, pp.4-12, 共立出版.
  13. ^ 筧, 捷彦 (1975). “ストラクチャード・プログラミング用言語”. 情報処理 (情報処理学会) 16 (10): 856-863. NAID 110002720279. 
  14. ^ a b 木村泉 (1975). “プログラミング方法論の問題点：超職業的プログラミングについて”. 情報処理 (情報処理学会) 16 (10): 841-847. NAID 110002720277. 
  15. ^ a b 山崎利治, "構造的プログラミング", プログラムの設計, 共立出版, 1990, pp.113-142.
  16. ^ 金藤, 栄孝、二木, 厚吉「多重ループからの脱出でのgoto文の是非：Hoare理論の観点から」『情報処理学会論文誌』第3号、2004年、770-784頁、NAID 110002712129。 
  17. ^ 金藤, 栄孝、二木, 厚吉「有限状態機械に基づくプログラミングでのgoto文使用の是非 : Hoare論理の観点から」『情報処理学会論文誌』第45巻9, 2004、2124-2137頁、NAID 110002712260。 
  18. ^ H.D.Mills, R.C.Linger, a.R.Hevner, “ボックス構造化情報システム”, ソフトウェアエンジニアリング論文集80's, Tom DeMarco, Timothy Lister編著, 児玉公信 監訳, 翔泳社, 2006, pp.187-219.
  19. ^ a b c E. Dijkstra (1968). “Go To Statement Considered Harmful”. Communications of the ACM 11 (3): 147-148. CiteSeerx: 10.1.1.132.875. 
  20. ^ N.ヴィルト, 系統的プログラミング/入門, 野下浩平, 筧捷彦, 武市正人 訳, 近代科学社, 1978.
  21. ^ C.A.R.Hoare, "Structured programming in introductory programming courses", Structured Programming, Infotech state of the art report, 1976, pp.257-263, Infotech International.
  22. ^ a b c d e f Knuth, D. E. (1974). “Structured Programming with go to Statements Computing Surveys”. ACM, New York, NY, USA 6 (4): 261-301. CiteSeerx: 10.1.1.103.6084. 
  23. ^ Bjarne Stroustrup, “What Is Object-Oriented Programming?”, In IEEE Software, Vol. 5, Issue. 3, IEEE Computer Society Press, Los Alamitos, CA, USA, 1988, pp. 10-20
  24. ^ 山崎利治, "流れ図", プログラムの設計, 共立出版, 1990, pp.110-113. ISBN 4320023781
  25. ^ Böhm, C.; Jacopini, G (1966). “Flow Diagrams, Turing Machines And Languages With Only Two Formation Rules”. Communications of the ACM 9 (5): 366-371. CiteSeerx: 10.1.1.119.9119. 
  26. ^ Linger,R.C., Mills, H.D., Witt, B.I., Structured Programming: Theory and Practice, Addison-Wesly, 1979.
  27. ^ E.W.ダイクストラ 木村泉訳 (1975), GO TO 論争：第1部 go to 文有害説, 7, 共立出版, pp. 6-9 
  28. ^ B.リーヴェンワス編, ed. (1975), “GO TO 論争：第2部 GO TO 論争”, bit (共立出版) 7 (5): 10-26 
  29. ^ 木村泉, "GO TO 論争：第3部 解説", bit, Vol.7, Issue 5, 1975, pp.27-39, 共立出版.
  30. ^ B. Randell and J.N. Buxton, (Eds.), Software Engineering, NATO Scientific Affairs Division, Brussels, Belgium, 1969.
  31. ^ a b c “プログラミング−工芸から科学へ”, 情報処理 (情報処理学会) 18 (12): 1248-1256, (1977), NAID 110002753409 
  32. ^ a b 和田英一, "ダイクストラかく語りき", bit, Vol.9, Issue 1, 1977, pp.4-6, 共立出版.
  33. ^ a b 玉井哲雄 (2008), “ソフトウェア工学の40年” (PDF), 情報処理 49 (7): 777-784, NAID 110006830060, http://www.graco.c.u-tokyo.ac.jp/~tamai/pub/40yearsSE.pdf 
  34. ^ Edward Nash Yourdon ed., "Introduction (Chief Programmer Team Management of Production Programming)", Classics in Software Engineering, YOURDON inc., 1979, pp.63-64.
  35. ^ 木村泉, 米澤明憲, 算法表現論, 岩波書店, 1982.
  36. ^ D.シャシャ, C.ラゼール, "エズガー・W・ダイクストラ", コンピュータの時代を開いた天才たち, 鈴木良尚 訳, 竹内郁雄 監訳, 日経BP社, 1998, pp.61-74. ISBN 4822280462
  37. ^ 玉井哲雄, "ソフトウェア産業とソフトウェア研究の沈滞状況について"， SEAMAIL, Vol.11, No.3, 1997, pp.2-5.
  38. ^ 玉井哲雄, "9th ICSEに参加して"， SEAMAIL, Vol.2, No.7, 1987, pp.22-25.
  39. ^ a b 中山晴康, "ダイクストラ教授との3日間", bit, Vol.9, Issue 1, 1977, pp.7-9, 共立出版.
  40. ^ Edward Nash Yourdon, 構造化手法によるソフトウェア開発, 黒田純一郎, 渡部研一 訳, 日経BP社, 1987.

参考文献

関連項目

関連人物

コンピュータ・プログラミング言語の関連項目
言語水準
言語処理系
言語分類
その他
関連項目
「https://ja-two.iwiki.icu/w/index.php?title=構造化プログラミング&oldid=69719640」から取得