「構造化プログラミング」の版間の差分
削除された内容 追加された内容
→外部リンク: 外部リンクの修正 http:// -> https:// |
編集の要約なし |
||
(同じ利用者による、間の1版が非表示) | |||
1行目:
[[ファイル:Jis-flowchart-fixed.png|境界|右|フレームなし|310x310ピクセル|順接・分岐・反復のフローチャート]]
{{Template:プログラミング・パラダイム}}
'''構造化プログラミング'''(こうぞうかプログラミング、{{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]]
なお、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'')の総称である。ステートメントは命令コードの一行を意味する。ブロックは一行以上のステートメントをまとめたものである。サブルーチンは一行以上のステートメントまたは一個以上のブロックを内包する。サブプログラムは直列状または入れ子状に並べられる。それらの実行順序を決定するものが制御構造であり、以下の三つがある。
#'''順次'''(''sequence'')サブプログラムを順々に実行する。
20行目:
== 歴史 ==
構造化プログラミングの誕生は、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年に計算機科学者[[コラド・ベーム]]とジュゼッペ・ヤコピーニは、あらゆるフローチャートは
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>」は、その物議を醸す題名でソフトウェア界隈に
ダイクストラとは別に、1970年代初期の産業プログラム分野では制御構造(''control structures'')を基軸に据えた[[フローチャート]]設計技法が
後年、ダイクストラは自身が作った構造化プログラミングという言葉に不快感を示して避けるようになった<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>。
30行目:
== ダイクストラの構造化プログラミング ==
「Structured Programming」という用語自体を生み出したのは計算機科学者[[エドガー・ダイクストラ]]であり、1969年のNATOソフトウェア工学会議で発表された論文が初出とされている。彼は2001年の
ダイクストラが提唱した構造化プログラミングは、[[正当性 (計算機科学)|プログラム正当性]][[プログラム検証|検証]]技術の確立を主な目的にして構想された数々の
=== 1968年の投書「goto文は有害」 ===
{{main|goto文#goto文論争}}1968年のCommunications of the [[Association for Computing Machinery|ACM]]に投書されたこの「Go To Statement Considered Harmful<ref name="go_to_statement_considered_harmful" />」は、そのセンセーショナルなタイトルでプロアマを問わずプログラマたちの間に大きな論争を巻き起こした。それは同時にプログラミング言語[[ALGOL]]から実装されていた順
* 人間が時間によって変化するプロセスを把握する能力は、プログラムの静的な関係を把握する能力に比べて劣っているため、静的なプログラムテキストの構造と時間によって変化するプロセスの構造をなるべく近づけるのが重要である。
54行目:
=== 双方で提示された三つの構造化文 ===
ダイクストラは「Go To Statement Considered Harmful<ref name="go_to_statement_considered_harmful"/>」および「Structured Programming<ref name="structured_programming"/>」において、好ましい構造として手続き呼び出しの他に、順
# 順
# 反復
# 分岐
=== 1972年の共著「構造化プログラミング」 ===
ダイクストラ提唱の構造化プログラミングを支持する[[ドナルド・クヌース]]は、1974年に自著「Structured Programming with go to Statements<ref name="structured_programming_with_go_to_statements" />」を上梓し、その中でgoto-lessの本質に関する補足と解説を加えた。これは当時のgoto文論争に一つの区切りを付け
=== 構造化定理との関係 ===
75 ⟶ 73行目:
ダイクストラは、プログラマは正しいプログラムを作り出すばかりでなく納得のいくやり方で正しさを証明(検証)することも仕事の一つであるという立場を取っていた<ref>[[構造化プログラミング#構造化プログラミング(1975)|構造化プログラミング(1975)]] p.6</ref>。ただしその検証<ref>D.グリースはプログラムの正しさの証明を、抽象的なレベルでは正当性証明、具体的なレベルではプログラムの検証と言葉を使い分けているが、ここでは厳密な区別はしない。
* 金山裕 編, "構造的プログラミング −批判と支持−", ''bit'', Vol.7, Issue 7, 1975, pp.6-13, 共立出版.</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>。1967年のノート「Towards Correct Programs」でダイクストラは
# 列挙(enumeration): 一人の人間の能力でできる範囲でプログラムの命令の妥当性を一つ一つ確認していく作業 → 順
# 数学的帰納(mathematical induction): while文など計算機特有の多数の繰り返し文についてのみ数学的帰納法を用いて確認する作業 → 反復
# 抽象(abstraction): プログラムのブロックなどに名前をつけ、さらに中身を見ないで正しいと仮定することで検証作業を後回しにする操作 → コードブロック、サブルーチン
116 ⟶ 114行目:
*[[構造化定理]]
*[[ジャクソンの構造化プログラミング]]
*[[段階的詳細化法]]
*[[正当性 (計算機科学)|プログラム正当性]]
*[[プログラム検証]]
124 ⟶ 123行目:
*[[抽象データ型]]
*[[ALGOL]]
*[[Pascal
*[[Simula]]
|