Wikipedia

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

履歴の双方向閲覧
← 古い編集新しい編集 →
削除された内容 追加された内容
ビジュアルウィキテキスト
m 引用エラーの修正
(同じ利用者による、間の4版が非表示)
1行目:
{{プログラミング言語|index=こうそうかふろくらみんく}}
[[ファイル:Jis-flowchart-fixed.png|境界|右|フレームなし|320x320310x310ピクセル|順接・分岐・反復のフローチャート]]
 
'''構造化プログラミング'''（こうぞうかプログラミング、{{lang-en-short|''structured programming''}}）とは、コンピュータプログラムの明瞭化を目的にした手法であり、一般的には順接、分岐、反復の三つの制御構造（''control structures''）によって、処理の流れを記述することであると認識されている<ref>{{Cite web|title=構造化プログラミングとは - IT用語辞典|url=http://e-words.jp/w/%E6%A7%8B%E9%80%A0%E5%8C%96%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0.html|website=IT用語辞典 e-Words|accessdate=2020-06-01|language=ja}}</ref><ref>{{Cite web|title=構造化プログラミング - 意味・説明・解説 : ASCII.jpデジタル用語辞典|url=https://yougo.ascii.jp/caltar/%E6%A7%8B%E9%80%A0%E5%8C%96%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0|website=yougo.ascii.jp|accessdate=2020-06-01}}</ref>。[[ブロック (プログラミング)|コードブロック]]と[[サブルーチン]]も加えられることがある。
 
このプログラミング手法の普及に貢献したのは、1968年の計算機科学者[[エドガー・ダイクストラ]]による[[Association for Computing Machinery|ACM]]機関紙への投書「''Go To Statement Considered Harmful''」と言われている。しかし、翌1969年に同じくダイクストラが[[NATO]]科学会議で発表した論文名「''Structured Programming''」との混同を招き、こちら側の名称で知られるようになってデファクトスタンダード化した。以来、国内外の多くの書籍において構造化プログラミングは、制御構造に関する説明に結び付けられている。
 
なお、1969年の論文の内容はプログラムの構造設計に関するものであり、抽象から細部へのトップダウン設計、抽象データ構造と抽象ステートメントを定義するモジュール、共同詳細化といった考え方が提唱されていた<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>。
 
== 制御構造の概要素 ==
{{main|ミルズの構造化プログラミング}}制御構造（''control structures''）は、サブプログラム（''subprogram''）単位で記述される。サブプログラムとはプログラムを構成する一定量の命令コードを意味しており、[[ステートメント]]単位または（''statement''）[[コードブロック (プログラミング)|ブロック]]単位（''block''）[[サブルーチン]]（''subroutine''）の総称で記述されある。ステートメントは命令コードの一行を意味する。ブロックとは括弧記号やBEGIN-ENDキーワードなどで区切られた一行以上のステートメントのかたをまりとめたものである。それぞれサブルーチンは一行以上のステートメントまたは一個以上のブロックを内包する。サブプログラムは直列状または入れ子状に配置さ並べられる。視覚的に判別しやすいブロックそれらの起点と終点が自動的にフロージャンプの位置指実行順序を決定になするもので、結果的に無差別ジャンプであるgoto文を使わないで済むようになる。が制御構造にはであり、以下の四種三つがある。
 
#'''順次'''（''sequence''）ステートメントサブプログラムを順々に処理実行する。
#'''選択'''（''selection''） 条件式の結果が導出した状態に従ってい、次に実行するステートメントまたはサブプロックグラムを選択してフロー分岐する。
#'''反復'''（''repetition''）条件式が導出した特定の状態の間、ステートメントまたはサブプロック内グラムを繰り返し実行す。状態の確認は反復起点時または反復終点時の二通りある。
#'''サブルーチン'''（''subroutine''）これをコールした次のステートメントに復帰（''return''）する事を前提にして対象ブロックの起点にジャンプする。終点に達すると自動的に復帰する他、任意の途中位置でも復帰できる。
<br />[[ファイル:Structured_program_patterns.png|中央|サムネイル|700x700ピクセル|順次、選択、反復の描写図（青はNSダイアグラム、緑はフローチャート）]]
<br />'''サブルーチン'''（''subroutine''）は一定量の命令コードを任意の定義名で抽象化し、その実装内容を分離したものである。ブロックとサブルーチンは相互再帰の関係にある。ブロックの中のステートメントからサブルーチンが呼び出され、そのサブルーチンの中にもまたブロックとステートメントがあるといった具合である。サブルーチンはその終点に達すると復帰（''return''）されて、呼び出したステートメントの次の行に制御が移る。また終点前の任意の位置でも復帰できる。
<br />
 
制御構造の登場は19581960年公開のプログラミング言語[[ALGOL|ALGOL58]]または「[[ALGOL|ALGOL60]]」まで遡る事ができる。1966年に[[コラド・ベーム|ベーム]]とヤコピーニが順次・選択・反復のフロー万能性を数学的に証明したが、それはあくまで論理的研究だった。1968年の[[エドガー・ダイクストラ|ダイクストラ]]の投書でによって制御構造に対する関心は大きな注目を集めく高まった。ただしその物議を醸すタイトル（goto文は有害）を付けたのは[[ニクラウス・ヴィルト|ヴィルト]]であった。1970年代、制御構造の普及を重視していたIBM社の[[ハーラン・ミルズ|ミルズ]]は、1969年にダイクストラが発表してこれも反響を得ていた論文タイトル（構造化プログラミング）を自社の技術セミナーマーケティングに活用する事にし、同時にベームとヤコピーニの証明を独自のタイトル（[[構造化定理]]）で復刻させて信憑性を高めるための技術的裏付けにした。その後、制御構造による構造化プログラミングは一世を風靡した。
 
== 歴史 ==
構造化プログラミングの誕生は、1960年代から浮上した[[ソフトウェア危機]]問題と密接に結びついている。ソフトウェア危機とはコンピュータ性能の進化に伴うソフトウェア要求度の高まりが、プログラムサイズの際限無い肥大化と複雑化を招き、近いうちに現実的な期間内でのプログラム開発が不可能になるだろうとする悲観的予測である{{#tag:ref|[[ソフトウェア危機]]の始まりと構造化プログラミングの歴史について<ref name="the_science_of_programming"/>の第23章に詳しい。|group="注釈"}}。実際に60年代のソフトウェア開発現場では仕様不一致、納期遅れ、予算超過といった事態が頻発していた<ref name="the_science_of_programming">{{cite book |first=D.|last=グリース |authorlink=:en:David Gries|title=プログラミングの科学 |translator=筧捷彦 |publisher=培風館 |year=1991 |isbn=4563007943}}</ref>。当時のプログラムは[[goto文]]を多用するタコ足[[フローチャート]]によるものが大半であり<ref name="program_design_chap6sec1">山崎利治, "流れ図", ''プログラムの設計'', 共立出版, 1990, pp.110-113. ISBN 4320023781</ref>、複雑怪奇なジャングルフロー図と化しているものも珍しくなかった<ref name="structured_programming_with_go_to_statements">{{Cite journal|last=Knuth|first=D. E.|year=1974|title=Structured Programming with go to Statements Computing Surveys|journal=ACM, New York, NY, USA|volume=6|number=4|pages=261-301|id={{citeseerx|10.1.1.103.6084}}|authorlink=ドナルド・クヌース}}</ref>。計算機科学者[[ハインツ・ツェマネク]]などgoto文の多用に警鐘を鳴らす識者はすでに60年代初期から存在した。1960年に公開されたプログラミング言語「[[ALGOL|ALGOL60]]」は、BEGINとENDで区切られたコードブロックを制御するIF選択文とFOR反復文を初めて提供していた。1966年に計算機科学者[[コラド・ベーム]]とジュゼッペ・ヤコピーニは、あらゆるフローチャートは連結・選択・反復の組み合わせで表現できることの数学的証明をし、これは[[構造化定理|ベームとヤコピーニの証明]]と呼ばれた<ref name="flow_diagrams_turing_machines_and_languages_with_only_two_formation_rules">{{Cite journal|last=Böhm|first=C.|last2=Jacopini|first2=G|year=1966|title=Flow Diagrams, Turing Machines And Languages With Only Two Formation Rules|journal=Communications of the ACM|volume=9|issue=5|pages=366-371|id={{citeseerx|10.1.1.119.9119}}|journl=ACM, New York, NY, USA}}</ref>。計算機科学者[[ドナルド・クヌース]]は、これらの潮流を構造化文（''structured statement''）の第一幕と定義した<ref name="structured_programming_with_go_to_statements" />。
[[コンピュータ]]が実用化され、その有用性が認められるようになるにつれ、その上で動作するプログラムは次第に大規模なものとなっていった。ソフトウェアの低品質、納期遅れ、予算超過が頻発し、大規模なプログラムを正当に動作するように記述することの困難さが認識されるようになった<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年に感じた、ということを自伝に残している[[モーリス・ウィルクス|ウィルクス]]が、その後に、[[アラン・チューリング]]が「大規模ルーチンの検証」といったことを話していた、と書いている。
 
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"/>。
 
そして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の研究員[[ハーラン・ミルズ]]らによって[[構造化定理]](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><ref group="注釈" name=":0">[http://www.wisdom.weizmann.ac.il/~dharel/SCANNED.PAPERS/OnFolkTheorems.pdf Harel,David (1980)."On Folk Theorems"(PDF)]のP381の左列の中央にハーラン・ミルズ（Harlan Mills）が未公表の講義資料の中で "The Structure Theorem" と名付けたことが書かれている。この資料の出典[67]が1972年のため構造化定理が発明されたのは1970年代初頭と推測される。</ref>。なお前述のように、これを構造化プログラミングと結びつける論者は大変多いが誤解である。
 
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文を用いた構造化プログラミング」の中で "The next chapter in the story is what many people regard as the first, because it made the most waves."（「go to 文除去の話の二番目の場面は，多くの人たちが第一幕だと思っている事実である．なぜなら，この一幕が大きな波を生じた原因となったからである．」有澤誠訳『文芸的プログラミング』p.45）とこの騒動を指して評している。1980年代にマイコンが普及した際に、その[[BASIC]]において（由来などの詳細は全く曖昧なまま）「GOTO命令を使わないのが『構造化プログラミング』」などと言われたりしたなど、騒動の影響は後年まで残った。<ref group="注釈">直接は無関係だが、ダイクストラはBASIC批判の急先鋒でもあった。マイコン普及以前の1970年代に既に、BASICでプログラミング教育をすべきでない、と強く主張している（[[wikiquote:Edsger W. Dijkstra#How do we tell truths that might hurt? (1975)]]）。</ref>
 
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)、そして真珠のネックレスに例えたプログラムの階層化について述べた。
 
ダイクストラは、構造化プログラミングという言葉を作ったとき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>。
 
1968年、計算機科学者[[エドガー・ダイクストラ]]の[[Association for Computing Machinery|ACM]]機関紙への投書「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>。これを構造化文の第二幕と定義したクヌースは「第二幕はそのムーブメントの大きさによって多くの人にとっての第一幕になった」と自著で述べた<ref>有澤誠訳『文芸的プログラミング』p.45</ref>。同68年に開催された[[北大西洋条約機構|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" />。翌1969年度開催の同会議に、ダイクストラは「Structured Programming<ref name="structured_programming" />」と名付けた論文を寄稿した。これが「構造化プログラミング」の正式な初出である。内容はソフトウェア危機解決策としての[[正当性 (計算機科学)|ソフトウェア正当性]][[プログラム検証|検証技術]]の確立に焦点を当てたものであり、[[トップダウン設計とボトムアップ設計|トップダウン設計]]、[[抽象化 (計算機科学)|抽象化]]、[[モジュール|モジュール化]]といったプログラム全体の構造設計手法が提唱されていた。goto文回避など構造化文に関する事柄は数行に留まっていたが{{#tag:ref|"statements transferring control to labelled points" という言葉で一応 goto 文に触れている<ref name="structured_programming" />|group="注釈"}}、goto文論争に熱心なプログラマたちの間ではこの論文を昨年の投書の延長と見る向きも少なからず存在していた。後年のダイクストラは構造化プログラミングという言葉を作った際に二つの失敗をしたと述べている。商標登録しなかった事と、厳密な定義化を避けた事である<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>。
1980年代以降、ソフトウェア工学の分野はプログラミング言語や方法論から組織やプロジェクトの管理手法へと軸足を移していた<ref name="tamai_40years_se">{{cite|url=http://www.graco.c.u-tokyo.ac.jp/~tamai/pub/40yearsSE.pdf |format=PDF|author=玉井哲雄 |title=ソフトウェア工学の40年 |journal=情報処理 |volume=49|number=7|year=2008 | pages=777-784 |naid=110006830060}}</ref>。1987年の第9回ソフトウェア工学国際会議(ICSE)において、IBMの研究員[[ハーラン・ミルズ]]は会場に[[チューリング賞]]受賞者がいないことを確かめると「[[エドガー・ダイクストラ|ダイクストラ]]や[[アントニー・ホーア|ホーア]]達はどこへ行ってしまったのか。我々はもう彼らから学ぶものがないのか。」とその現状を批判した<ref name="tamai_inactive_se">[http://www.graco.c.u-tokyo.ac.jp/~tamai/pub/inactiveSE.pdf 玉井哲雄, "ソフトウェア産業とソフトウェア研究の沈滞状況について"， ''SEAMAIL'', Vol.11, No.3, 1997, pp.2-5.]</ref><ref name="tamai_9thicse">[http://www.graco.c.u-tokyo.ac.jp/~tamai/pub/9thICSE.pdf 玉井哲雄, "9th ICSEに参加して"， ''SEAMAIL'', Vol.2, No.7, 1987, pp.22-25.]</ref>。
 
ダイクストラとは別に、1970年代初期の産業プログラム分野では制御構造（''control structures''）を基軸に据えた[[フローチャート]]設計技法が積極的に導入されていた。[[IBM|IBM社]]の上席研究員[[ハーラン・ミルズ]]は制御構造を重視し、[[ニューヨーク・タイムズ|ニューヨークタイムズ社]]のニュースアーカイブシステム構築のプロジェクトで大きな成功を収めていた。順次・選択・反復の制御構造は、IBM社のプログラミング規範をまとめたImproved Programming Technologies通称「IPT」に採用され、後に同社の技術セミナーなどを通して広く流布されるようになった<ref name="program_design_chap6sec2">山崎利治, "構造的プログラミング", ''プログラムの設計'', 共立出版, 1990, pp.113-142. </ref><ref name="tamai_40years_se">{{cite|url=http://www.graco.c.u-tokyo.ac.jp/~tamai/pub/40yearsSE.pdf|format=PDF|author=玉井哲雄|title=ソフトウェア工学の40年|journal=情報処理|volume=49|number=7|year=2008|pages=777-784|naid=110006830060}}</ref>。同70年代初期に計算機科学者デビッド・ハレルは、前述のベームとヤコピーニの証明に「[[構造化定理|Structure theorem]]''」''という全く新しい題名を付けて[[Association for Computing Machinery|ACM]]機関紙上などで紹介した<ref name="sp_theory_and_practice">Linger,R.C., Mills, H.D., Witt, B.I., ''Structured Programming: Theory and Practice'', Addison-Wesly, 1979. </ref><ref name=":0" group="注釈">[http://www.wisdom.weizmann.ac.il/~dharel/SCANNED.PAPERS/OnFolkTheorems.pdf Harel,David (1980)."On Folk Theorems"(PDF)]のP381の左列の中央にハーラン・ミルズ（Harlan Mills）が未公表の講義資料の中で "The Structure Theorem" と名付けたことが書かれている。この資料の出典[67]が1972年のため構造化定理が発明されたのは1970年代初頭と推測される。</ref>。ハレルはこの命名がミルズの提案であったことを後年に明かしている<ref name=":0" />。構造化定理はIPTの合理性を裏付ける根拠として盛んに引用されたので、構造化（''Structured''）プログラミングと言えば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>。その違いを指摘して本来のダイクストラ流を改めて紹介する動きもあったが、抽象化に傾倒するダイクストラ理論は産業界ではむしろ不人気でさえあった<ref name="problems_of_programming_methodology">{{cite journal|author=木村泉|year=1975|title=プログラミング方法論の問題点：超職業的プログラミングについて|journal=情報処理|volume=16|number=10|pages=841-847|publisher=情報処理学会|naid=110002720277}}</ref><ref name="algorithm_representation_theory">木村泉, 米澤明憲, ''算法表現論'', 岩波書店, 1982. </ref><ref name="out_of_thier_minds">D.シャシャ, C.ラゼール, "エズガー・W・ダイクストラ", ''コンピュータの時代を開いた天才たち'', 鈴木良尚 訳, 竹内郁雄 監訳, 日経BP社, 1998, pp.61-74. ISBN 4822280462</ref>。クヌースの言葉を借りれば、構造化文の第三幕は[[IBM|IBM社]]と[[ハーラン・ミルズ]]がプロモートした制御構造の舞台になり、こちらが事実上のスタンダードと化した。
しかし、木村泉の見解が当たっていたとするならば、「ソフトウェア工学」をそういったものにしていった張本人こそが、その発言をしたハーラン・ミルズであるということになる。ミルズは「[[構造化定理]]」<ref name=":0" group="注釈" />という言葉を作り、IBMの研究員の立場を利用して、'''構造化プログラミング'''と'''構造化定理'''を混同させたと言える。
 
後年、ダイクストラは自身が作った構造化プログラミングという言葉に不快感を示し、て避けるようになった<ref name="three_days_with_dijkstra">中山晴康, "ダイクストラ教授との3日間", ''bit'', Vol.9, Issue 1, 1977, pp.7-9, 共立出版. </ref>。この言葉を名付け作ったとき時、かれ彼はプログラミングが手工芸から科学へ発展することを予測期待していた<ref name="also_speech_dijkstra" />。しかし構造化プログラミングという言葉は実利を求めるために使われるようになった<ref name="three_days_with_dijkstra" />。次のような逸話がある。ソフトウェア技術者[[エドワード・ヨードン|ヨードン]]の会社事務所にセミナー依頼の電話がかかってきた。部下プロジェクトメンバー全員に構造化プログラミングなどの構造化技法を1日で叩きこんで欲しいという内容である。それが終わったら開発プロジェクト期間を半分にするという。なぜならその理由は「構造化技法プログラミングは生産性を2倍にしますから」るというもの触れ込みですから」であった<ref name="managing_the_structured_techniques">Edward Nash Yourdon, ''構造化手法によるソフトウェア開発'', 黒田純一郎, 渡部研一 訳, 日経BP社, 1987. </ref>。かくして構造化プログラミングは、ダイクストラの期待とは異なった形で世に広まっていくことになる。
 
== ダイクストラの構造化プログラミング ==
42 ⟶ 32行目:
「Structured Programming」という用語自体を生み出したのは計算機科学者[[エドガー・ダイクストラ]]であり、1969年のNATOソフトウェア工学会議で発表された論文が初出とされている。彼は2001年の[http://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1308.html ノート]で、自分が作り出した「構造化プログラミング」という用語は結局異なる解釈で持ち去られてしまったと述べている。
 
ダイクストラが提唱した構造化プログラミングは、[[正当性 (計算機科学)|プログラム正当性の効率的な]][[プログラム検証|検証]]技術の確立を主な目的にして構想された数々のソフトウェア開発理論の習複合体である。遅くとも1967年からその構想は始められていた。1968年の[[goto文]]に依存しないシーケンスの制御、1969年の[[トップダウン設計とボトムアップ設計|トップダウン設計]]、[[抽象化 (計算機科学)|抽象化]]、[[モジュール化]]から始まり、1972年には[[抽象データ型|抽象データ構造]]と情報隠蔽といった考えも取り上げられていた<ref name="languages_for_structured_programming">{{cite journal|last=筧|first=捷彦|year=1975|title=ストラクチャード・プログラミング用言語|journal=情報処理|volume=16|number=10|page=856-863|publisher=情報処理学会|naid=110002720279}}</ref><ref name="problems_of_programming_methodology" /><ref name="program_design_chap6sec2" />。ただし実際のプログラミング言語仕様などに具体化される事はなく、あくまでソフトウェアアーキテククチャとしての理論提唱に留まっている。数々の後発言語に影響を与えているのは衆目の一致するところである。
 
=== 1968年の投書「goto文は有害」 ===
55 ⟶ 45行目:
 
=== 1969年の論文「構造化プログラミング」 ===
1969年度[[北大西洋条約機構|NATO]]ソフトウェア工学会議に寄稿されたこの「Structured Programming<ref name="structured_programming" />」は、[[正当性 (計算機科学)|プログラム正当性]]の効率的な[[プログラム検証|検証技術]]に重点を置き、当時問題視されていたコードサイズの際限なき肥大化による[[ソフトウェア危機]]の解決策として従来の[[ボトムアップ設計]]から[[トップダウン設計とボトムアップ設計|トップダウン設計]]への移行を推奨していた。
 
論文の前半では、プログラムサイズの肥大化に伴い、各プログラム部品およびそれらを組み合わせた際のプログラムの正当性（''program correctness''）の立証（''demonstration''）に必要な労力が指数的に増加して完遂が不可能になるという[[ソフトウェア危機]]の問題について述べている。ダイクストラはプログラムの正しさに対して証明を与える従来の研究を分析して、証明の手続きを考えずに書かれたプログラムは証明に必要な労力がプログラムのサイズに対して爆発するとし、「与えられたプログラムに対してどうやって証明をするか」ではなく「証明がしやすいプログラムの構造とは何か」についてフォーカスするとした。
64 ⟶ 54行目:
 
=== 双方で提示された三つの構造化文 ===
ダイクストラは「Go To Statement Considered Harmful<ref name="go_to_statement_considered_harmful"/>」および「Structured Programming<ref name="structured_programming"/>」において、好ましい構造として手続き呼び出しの他に、順次・反復・分岐の3つを挙げた。[[Pascal|PASCAL]]の開発者[[ニクラウス・ヴィルト]]はこれらを構造化文（structured statement）と呼んだ<ref name="systematic_programming"/>。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>。
 
# 順次（concatenation）: 順接、順構造とも言われる。プログラムに記された順に、逐次処理を行なっていく。プログラムの記述とコンピュータの動作経過が一致するプログラム構造である。
73 ⟶ 63行目:
 
=== 1972年の共著「構造化プログラミング」 ===
ダイクストラ、[[オルヨハン・ダール]]、[[アントニー・ホーア]]らによる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「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の機能を紹介している。
 
ダイクストラ提唱の構造化プログラミングを支持してgoto-lessの本質などの解説を加えていする[[ドナルド・クヌース]]もは、1974年のに自著書「Structured Programming with go to Statements<ref name="structured_programming_with_go_to_statements" />」を上梓し、その中で抽象データ構造goto-lessの重要性本質に関する補足と解説を主張し加えた。これは当時のgoto文論争に一つの区切りを付けたと見なされているが、広範囲の認知を得るには到らなかったようで同様の論争はその後も泥炭の火の如く燻ぶり続けた。
 
=== 構造化定理との関係 ===
99 ⟶ 89行目:
ダイクストラは2001年のノート「[http://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1308.html What led to “Notes on Structured Programming”]」(構造化プログラミング表記の由来）でこのように述べている。
 
1968年の自分は「A case against goto statement」(goto文が不利な事例）と題した記事（''article''）をCommunications of the ACM（[[Association for Computing Machinery|ACM]]の機関紙）に投稿したが、当期の刊行を急ぐ編集担当者の意向で投書（letter（''letter to the Editor）Editor''）にされる事になり、更にその担当者独自の考えで「The goto statement considered harmful」(goto文は有害）という全く新しい題名を付けられた。その担当者とは[[ニクラウス・ヴィルト]]であった。また、自分が提唱した構造化プログラミングの本質的内容の普及を好まない某社が、[[ハーラン・ミルズ]]の主導でgoto文を廃止するかのようなプログラミング手法へとトリビア化し、構造化プログラミングという用語まで持ち去ってしまった。
 
ダイクストラの著書は、分かりにくいことと誤解を招きやすいことで定評がある<ref name="bit1975_explanation"/><ref name="software_cleanroom"/><ref name="bit1976_guarded_command">木村泉, "ダイクストラ教授とふた付き命令", ''bit'', Vol.8, Issue 9, 1976, pp.29-34, 共立出版. </ref>。それを憂いた{{仮リンク|ディビット・グリース|en|David Gries}}は、ダイクストラ流のプログラミングについて体系化した書籍「プログラミングの科学」(The Science of Programming)を書いた<ref name="software_cleanroom"/>。
126 ⟶ 116行目:
*[[構造化定理]]
*[[ジャクソンの構造化プログラミング]]
*[[正当性 (計算機科学)|プログラム正当性]]
*[[プログラム検証]]
*[[goto文]]
*[[トップダウン設計とボトムアップ設計]]
*[[モジュール化]]
*[[抽象化 (計算機科学)]]
*[[抽象データ型]]
*[[ALGOL]]
*[[Pascal|PASCAL]]
*[[Simula]]
 
139 ⟶ 135行目:
*[[ドナルド・クヌース]]
*[[ハーラン・ミルズ]]
*[[コラド・ベーム]]
*[[ビャーネ・ストロヴストルップ]]
* マイケル・アンソニー・ジャクソン
「https://ja.wikipedia.org/wiki/構造化プログラミング」から取得